ASMのきもち

DBとAnsibleが気になって仕方ない人のブログ

よくあるオンプレOracleからRDSに移行したDBAの反省文

OracleDB

この記事は JPOUG Advent Calendar 2021 - Adventar 17日目の記事です。

昨日はShinodaさんの「Oracle Database から PostgreSQL への接続を試す - Qiita」でしたね。
いやーOracle Database Gateway for ODBC全然使ったことがなかったので、これはぜひやってみよ…あれ、RDSでできるの？明日AWSサポートに早速連絡してみよう…

最近ブログを書く頻度がアドベントカレンダー以外書く頻度がない感じになってきております…コレハ、マズイ、ゾ！！笑

さて弱気な内容はおいておいて…ここ最近、ろくに活動もできなかったのはこれをやっていたからなのです。
そうよくある、(꜆꜄•ω•)꜆꜄꜆オンプレOracleからRDSに移行した話。
今更感あるのですが、私と同じミスを減らすきっかけになれば。と思い、書いてみます。

結論

結論を最初に書くのが大事なので、これ一番最初に書きます。
私の反省は、以下の3つです。
本当はいっぱい書きたいけど、そうすると長すぎるのでやめましょう。

  1. 性能試験は必ずしましょう
  2. DB移行で一番大事なのはNWです
  3. 運用の見直しを忘れずに

かいたひと

これを書いた人は、10年ちょいSIerで開発PM→DBA→DBチームリーダーをしていた人でした。DB移行回数は…数えるのやめましょう。
ずっとオンプレOnly、パブリッククラウドはAWSですら未経験の人です。
もう数年SQLを打つことさえしなくなり（設計計画とマネジメントしかしない）、現場の仕事がしたいなぁと思って心機一転、全く別業種の社内DBAに転職してみました。

前提

転職後、とあるDBの移行プロジェクトにアサインされました。

移行元のDBはシステムの最も重要なDBでした。
ほとんどのシステム、業務処理がそのDBを利用しており、そのDB停止＝サービスほぼ全停止、という会社において最もミッションクリティカルなDBです。

私が参画段階では既にAWS RDSで移行することも、その移行先のRDSサイズや構成も決められていました。
AWSさんがしっかり入って検討してくださっていて、先方のエンジニアの方も凄腕のDBエンジニアさんでした。
転職直後ということもあり、事前検討はしっかりされているのだろうなと考え、私は計画や全体の流れではなく技術的に細かいことを検討することに集中しようと考えました。

これだけ見ると、とても順調に進んでいるように見えたのです。
ところが…まぁ、そうですよね。順調にいかないのがDB移行。もちろん、沢山の問題が発生しました。

反省その①：性能試験ができないDBの移行

最初に躓いたのはこちらでした。
試験計画（一応作った）を作っていたところ…突然、想定外のことを言われました。

性能試験は出来ません。

詳細は会社的にアレなので割愛させてください…
この時点で、「あ、SIer時代だったら丁重にお断りする案件だな」と思いました。　←素直
AWSの担当さんから、性能試験無しのDB移行はやめてくれ、最大のアンチパターンだと念押しで言われました。
でも、出来ないことは出来ないのです。
ということで私は性能試験ができない、けれどミッションクリティカルなDBの移行をすることになったのです。

これはこのDB移行プロジェクトの、最大のリスクでした。
ここで投げ出したかったんですが、それじゃあ私の存在意義はないですよね？

このことから性能問題が必ず発生することを予測し、 Oracle Enterprise Manager（後述OEM）の利用を訴え、Diagnostics PackとTuning Packの購入を上申しました。
RDSのPerfomance Instight（後述PI）は非常に有用ですが、OEMで見れるような詳細な情報を追うことは出来ません。また、Tuning Packは非常に強力な性能改善機能です。
これはPIが悪いということではありません。様々なDB製品を扱う中、同様のIFであれだけ詳細な情報を見せれるPIは本当に素晴らしい機能です。が、OracleDBの深淵を覗くには浅すぎるのです。
幸い、上層は新参者のぎゃーぎゃーした言い分を聞いてくださり、この2つのライセンスを購入していただくことになりました。これは私にとって、最大の幸運でした。

さて、移行後の今…私が最も評価された事は「OEMの導入」になってしまいましたorz
案の定移行後のDBは安定せず、気を抜くとCPU使用率が100%近くになってしまうのですが…
CPUが上がってき始めた段階で各待機イベントの割合を占めているSQL IDをOEMで確認、Tuning PackでSQLチューニングをかけて対処方法を提示することで、今も順調に稼働しています。これを順調に稼働と呼んでいいのかはさておき。

結果、性能の担保をOracleDBの持つ製品機能とお金の力で解決しました。
DBのチューニングを華麗にやった！という素敵な内容でなくてごめんなさい。でもこれが、性能試験をせずにDB移行をした結果です。
まだお金の力でどうにかなっただけ、マシだとお考え下さい。本当に、性能試験無しは絶対だめです。移行後性能出なくても、文句言っちゃだめです。
余談ですが、製品の力を借りたSQLチューニングは個人スキルに依存しない為、安定したDB運用方法かなと考えています。一人の凄腕SQLチューニングエンジニアがいないと動くこともままならないDB、危険すぎますよね。


反省その②：DB移行の鍵はNW

プロジェクトを進めていく中で、現行と移行先の構成は決まっていたのに、移行方法がぽっかり空いていることに気づきました。
そのため私は、移行計画の作成に着手したわけです。
そうしてほうぼうにヒアリングをしていく中で気付くのです…

AWS向けのDirect Connectの回線の帯域は？

本当によーーーーく抜け漏れるのですが、DB移行作業の重要なポイントはNWなのです。
簡単な例は、引っ越しです。
一般家庭の引っ越し用のトラックが1tだったとして、何フロアも借りている企業のオフィス引越しも、1tトラックで済むと思いますか？
そりゃあなた、荷物の量が全然違うじゃないですか。1tトラックだったら何回往復しないといけないじゃない。そう、そうなんです。

通常MB、多くて1G程度のデータ転送しか発生しない回線であれば、Mbpsでいいのかもしれません。
ただ相手はDB、それもOracleDBなんて使ってるのですから、大抵データ量は多いのが相場です。

現状の回線帯域を聞いて青ざめた私は、すぐにNWエンジニアの方に移行計画内容を伝え、転送データ、秒間あたりの転送量を伝えて、10Gは最低でも用意してほしいという旨を伝えました。
その内容を聞いていただいたNWエンジニアの方は、同様に顔を青ざめて「それはまずい」と言ってくださり、すぐ10Gの回線の手配をしてくださいました。
ただ、気づくのが遅く、大分ギリギリに対応していただいたというのが、私の反省点です。
今思えばあれがなかったら、移行作業時間は何十倍も膨れ上がっていたと思います。本当にNWエンジニアの方には感謝しかありません。
これはRDSでなくとも、通常の移行時においても非常に重要なポイントだと思います。


反省その③：運用の見直しを忘れずに

※責任共有モデルのことは割愛させてください。

AWS RDS for Oracle。いやー本当にすごいですよね。
すぐDB作れるし、CPU/Memory/DISK増やせられるし、IOPSもこちらで指定できるし、MuritiAZで冗長化。Point Time in Recoveryですぐ戻せる。
それも全部ボタンぽちか、awsコマンド、Terraform applyでできちゃうんですよ。これオンプレでやってた時、どれだけ大変だったか。
パブリッククラウド最高！これは間違いないです。

こう見るとすべての課題、なんでも解決すると思いますよね？
それに、OracleからOracleに移行でしょ？やったー色々楽になるぞー！
私も同僚も、そう思っていたんです…いや、もちろん解決したことは沢山あったんですが…移行検証や運用をしていく中で気づくのです。

できなくなっていることが、割と苦痛。

典型的な例は以下です。あまりにも有名なので、何を今更と思われるかもしれませんが。
頭ではわかっていたんです。ただ、使い始めると特に、以下のようなことに悩まされます。
（ほとんどは責任共有モデルで解決できそうな予感/すみませんまだ未検証です…）

  1. OSレイヤにアクセスできないことによる変更
    1. DB Serverにクライアントインストールする系のツールが軒並み使えなくなる
    2. 大好きだったoratopはもう使えない
    3. インストール時にデフォルト存在するスクリプト系を準備しないといけない（@$ORACLE_HOME配置下のSQL達）
    4. Dumpファイル等の操作も全部SQLでしないといけない
    5. DataPumpのコマンドをクライアント経由で実行する内容に変更しないといけない
    6. 「ロングランのプロセスKILL」が出来ない　→AWSさんに言ったらできるかもしれないですが、よほどのことない限りNGと思われる。また、やり取り大変。何せこちら、ps -efすら打てない。
      1. こちらコメントにて指摘いただいたので追記します。「ロングランのプロセス」と雑に書いて申し訳なかったです。ここの意味は「バグ引いてロングランになったり応答返さなくなったけどセッション保持したままのOracleDB Serverのプロセスをkill -9で強制停止させる」という荒業のタイプですので、通常時の運用ではrdsadminでセッションKILLしてくださいね
    7. OracleDB最大の秘奥義「個別パッチ」が当てられない。わかってたけど。そんな時に限ってすぐBugひく
  2. SYS権限が打てないことによる変更
    1. SYS≠マスターユーザであることを意外と皆さん知らない
    2. 特にうっかり間違えてalter system打ちがち。そして権限エラーが出ますよねすいませｎ
    3. rdsadminに慣れる期間が必要。同時に開発者にもそれを伝える必要がある。（開発環境のDBでDBA権限持つ人が、やっぱりalter system打つ）
    4. SYS系が持っているTABLEはSYS.をつけて実行しましょう
  3. DBAロールの権限差分
    1. 特にGRANTが打てなくなっているのが本当につらい。セキュリティ向上のためなのだと思いますが、開発環境でもマスターユーザーしかgrant打てないのつらい。だったらcreate userもDBAから外しておいてほしかった
  4. RACは使えない
    1. ADGでスタンバイは増やせますが、Actは当然増やすことが出来ません。つまりRDS for OracleはシングルライターマルチリーダーのDBなのです。ちなみに増やすときはちゃんとOracle営業さんと相談しましょう


人は、いままで自由だったことが制限されると、こんなにフラストレーションを感じるのだと、改めて知りました。
ちなみにこれ、RDSの悪口ではありません。マネージドサービスなので、当たり前なのです。ちゃんと、出来ないって書いてあります。
特権が持てない代わりに、運用をお任せできる。それがマネージドなんですよね。
頭で理解していたつもりが実際やるとこんなに変わるのだと、身をもって理解しました。

同時に、運用ルールや運用手順、運用に関わる様々なことを変更しなければなりませんでした。
私の盲点は、これを事前に行うことが出来ず、移行直前に慌てて運用設計の見直しをし始めたということです。
これがOracleDB→PostgreSQLであれば、さすがに事前検討や社内周知をしていました。ただ、OSにアクセスできない、SYS権限はない等が具体的に日々の開発や運用にどれほど影響を与えるのか、理解できていなかったのです。

これの対策は、やはり早期から移行検証や軽く運用をしてみて、そのシステムやサービスに応じて検討をしておく必要があったと痛感しました。
同時に、柔軟に対応できるようにする私たちエンジニアの動き。システムやプログラムに文句を言うのは筋違いですよね。



まとめ

他にもここでは書けないようなことが山ほどありましたが、無事移行できたことはほっとしつつ…反省点山盛りだったことは否めません。
そして現在も、私は運用ルールの整備とDB性能チューニングに、日々悩まされております。そろそろ平穏が欲しいよ、相棒のRDS for OracleDB！


明日は、おおのさんの記事です。わくわく、今から楽しみですね！