こんにちは、かたいなかです。
2024年2月に長年の悲願だったマッハバイトのメインDBのAuroraへの移行を完遂しました！！！
この記事では、どのようにマッハバイトのAurora移行を進めていったかを記事として残します。
なお、この記事の中では結構レガシーな部分の対応に苦しんだところも出てくるのですが、DB移行が終わったあとで、弊社内でこのレベルのレガシー対応を行う必要があることはほぼないと考えているので、リブセンスに興味を持っている方も安心して読んでいただければと思います。
やったこと
オンプレのDBをAuroraに移行しました。オフィス移転の関係で、当初DBは本番環境ではオンプレ、ステージング環境ではEC2でした。
DB移行はAWS DMSを用いて行いました。残念ながらDMSのCDC機能を使った無停止での移行はできませんでしたが、目立った問題が起きることなく移行を終えることができました。
移行後は、Auroraを使ったシンプルな構成に寄せることができました。
プロジェクトの流れ
1年半にわたるDB移行プロジェクトの流れを時系列順に紹介します。
テックリードから聞く初耳の単語: 『Mroonga』
個人的な事情で一度リブセンスを離れていたのですが、リブセンスに戻ってきたのは2021年7月のことでした。
リブセンスに戻った当初、マッハバイトの技術的負債の解消が大きな課題となっていました。
当時のDB周りの構成図は以下です。
当時は、オフィス移転のタイミングで、ステージング環境だけAWSに移行してしまっていました。
これにより、本番とステージング環境で使用しているインフラ基盤が異なる歪な状態となっていました。可能なら早いタイミングで本番もAWS化してしまいたかったのですが、技術的負債がそれを許さない状態にあるようでした。
そこでマッハバイトのテックリードの方に現状の状況を詳しくヒアリングしました。
ヒアリングの結果、メインのDBとして使っているMariaDBで、Auroraでは使えない全文検索のためのMroongaというプラグインを使っているため、AWS移行の目処が立っていないのが課題になっていました。DBがAWS移行できる目処が立たないまま、アプリケーションだけAWSに移行してしまうとパフォーマンス面での不安があるため、なかなかクラウド移行に本腰を入れられないようでした。
さらに、Mroongaを使っていたのが、パフォーマンスやメンテナンス性から社内で悪名高い社内管理画面用のPHPのレガシーアプリケーションで、使用箇所の調査もあまり進んでいない状況でした。
個人的に面食らったところはあったものの、誰かが真剣にこの問題に向き合って道筋を立てないと、本格的にクラウド移行に取り掛かることすらままならないことに危機感を感じ、まずは『Mroonga周りの調査』のタスクとして引き受けることにしました。
状況をざっくりと調査
当時は、Mroonga問題を中心としたDB周りの課題感がクラウド移行を全力で進めるうえで大きな不安材料になってしまっていたこともあり、まずはAWS移行が可能そうか見通しを立てることを目標に以下をゴールとして調査を進めました。
Mroonga
- Mroongaによる全文検索の使用箇所の大雑把な洗い出し
- 使用箇所をAuroraでも使えるngramインデックスに置き換えても問題ないかの調査
DB移行
- 移行に使えそうなツールの選定
Mroongaについては、PHPのコードがかなり複雑なスパゲッティコードとなってしまっており、特定のクエリがどのパスへのアクセスで呼ばれているのか確定させるのがかなり困難な状況となっていたため、この時点で「100%大丈夫！」と確証を得るというよりは、「9割方大丈夫そう」であるか確認するつもりで調査をすすめました。
調査の結果、Mroongaによる全文検索機能が使用されていそうな箇所は、おそらく数か所だけであり、それらはAuroraでも使えるngramインデックスに置き換えても業務上支障がなさそうなことがわかりました。
移行ツールについては、MariaDB 10.3.12からMySQL8相当のAuroraへ一度に移行することを目指したことや、細かいスキーマの差分を吸収できる必要がありそうだったため、AWS DMSを選定しました。
DMSを候補としたあとは、以下の図ようにマスキングDBからステージングAWS環境に用意した検証用Auroraに移行してみる形で調査を進めました。
結果的に、一部の極端に重いテーブル以外はCDCを使わないフルロードでは移行できることがわかりました。
この時点で、他のアプリケーションも含めてAWS移行を進めても大丈夫そうであるという見通しが立ちました。
このコード使われてるの？使われてないの？
ざっくりとした調査が終わったあと、不安材料として一番大きかったのは、Mroongaの全文検索機能を使っていないという100%の確証が得られていないことでした。そのため、Mroongaが使われていないことを確定させるための精密な調査をはじめました。
Mroonga関連のSQLが発行されているのはレガシーPHPのアプリケーションです。このレガシーPHPのなかで、KeyValue形式で検索条件を指定したオブジェクトを渡すと、SolrのクエリもしくはSQLに変換する複雑なライブラリがあります。このライブラリが、レガシーPHPのいたるところで使われており、状況の調査を難しくしていることがわかりました。
このライブラリのコードを丁寧に読み解きながら、相互に依存して絡み合った不要なコードを削除していき、結果的に数万行のコードを消しました。
これによってMroonga関連のSQLがコードベース上から消滅し、Mroongaが移行時の心配事項ではなくなりました。
DMSの検証本格化
DMSについては、以下の事項が未調査として残りました。
- DMSのCDC機能が未検証
- 移行用のDDLのレビュー可能性の担保
このうち、移行用のDDLのレビュー可能性の担保については、以前に記事で解説した通り、Ridgepoleの導入によって解決しました。詳しくはリンク先の記事をご覧ください。
AWS DMSのCDC機能は、レプリケーション元のDBの変更をレプリケーション先のDBに書き込みを行ってくれる機能です。当時は、これを使えばダウンタイムの短い移行ができるのではないかと考えていました。
最初の検証では、書き込みが行われていない開発用DBを使って行ったことで、CDCの検証はまだ手つかずになっていました。そのため、このタイミングで本番DBにDB移行用のレプリカを用意し本番AWSアカウントへの移行検証を行いました。
検証の結果、VPNやオンプレのネットワークの弱さに起因する問題やDMSのバグと思われる事象に遭遇し、CDCを使ったDB移行を諦めることにしました。今から考えても無停止の移行ができなかったことにエンジニアとして残念な気持ちは残りますが、一方で停止時間を設けて確実な移行を優先することができたのかなと思っています。
移行準備期
ここまでで移行の方式が決まり、あとはテストや各所との調整を進めるだけとなりました。
まずは、ユニットテストで移行先のAuroraと同等のMySQLを使ったバージョンを現行のものと並列で走らせるようにしました。マッハバイトではレガシーPHPアプリケーション以外ではしっかりと単体テストが書かれており、ほとんどのクエリをユニットテストで検証しています。そのため、テストが落ちて発覚した問題を修正し、ユニットテストを通すことができた時点でかなりの安心感がありました。
次に、検証環境での動作確認を進めました。まずはステージング環境と同等でDBだけがAuroraを向いている検証用の環境を用意し、動作確認項目をアプリケーション開発者にリストアップしてもらい動作確認しました。
さらに、ある程度テストが終わったところで、日々の開発の中でも移行に起因するおかしな挙動に気づける問題を洗い出せるように、ステージング環境を本番環境に先んじてAuroraに切り替えてしまいました。
そして、移行手順の確認のために2回リハーサルを実施しました。あとから考えると、このリハーサルを実施しておいたことで、以下のようなメリットがありました。
- アプリケーションとSolrを同時の移行となったが、全体の移行作業を何度も確認でき、不安事項を洗い出せた。
- 移行に直接かかわらないメンバーに、手順を最終確認してもらう際の資料として使えた。
- リハーサル時のログをしっかりSlackに残しておいたため、本番移行時にも安心して移行に望めた。
ついに、本番移行
ここまでの準備で移行までにできることはほぼほぼやりきったようには感じていましたが、移行作業の中で想定外の大きな問題が起きてしまうのではないかと不安で、移行作業が始まる前は胃がとても痛かったのを記憶しています。
いざDB移行となると、結果的に大きな問題が起きることはなく、予定していたメンテナンス終了時刻よりも前倒しで移行を終えることができました。また、移行完了後も今のところはDB移行を直接の原因とする大きな障害は起きていません。
移行完了により、以下のような構成に落ち着きました。
Auroraに移行してよかったこと
パフォーマンス改善
移行後は、パフォーマンスが大きく改善しました。
Redis等先にAWS移行したコンポーネントとの距離が近くなったこともあり、アプリケーションのレイテンシが大きく改善しました。
以下はHTTPのレスポンスタイムのグラフです。
レイテンシ以外でも、Solrへのインデックスを行うバッチ処理が高速に終わるようになったり、いたるところでパフォーマンスの恩恵が現れています。
一方で、一部の重いクエリで逆にオンプレ時代より遅くなってしまった箇所もあるため、実装を見直すなど改善を引き続き進めていきます。
Performance Insightsが便利！！！
Auroraに移行してすぐ、デッドロック関連の障害が起きたのですが、Performance Insightsのおかげでかなり迅速に問題クエリを特定することができました。
直感的に情報を見られるため、すでに導入されているAPMとあわせ、今後パフォーマンス改善を進めていくうえで大きな武器になってくれそうです。
DB移行を終えてみての感想
個人的にやっと終わったなという安心感がとても強いです。また、自分のエンジニア人生の20代の締めくくりとしても大きな山場を乗り越えられてよかったなと感じています。
今回、DBのクラウド移行をインフラエンジニアを主体とした動きで達成しましたが、Auroraが新たなインフラエンジニアの聖域になってしまっては、クラウド移行の意義も半減してしまうでしょう。 そのため、Datadog APMやPerformance Insightsを見ながら重いクエリの改善を進める動きの中で、事業部のエンジニアの中にもオーナーシップ意識を少しずつ醸成していけたらと考えています。
マッハバイトのクラウドジャーニーは始まったばかり。さらにクラウド最適化されたよりよい形をもとめてシステムの改善を進めていきます。
