このままではサービスの継続が難しい……エンジニアの起案で進んだ移行プロジェクト
──Auroraからのマイグレーションをどのように推進していきましたか。
金井：課題を認識し始めたのは4年前の2021年頃で、翌年の2022年からそろそろ対応しなければと考え、私が起案して「自律プロジェクト」として立ち上げました。自律プロジェクトとは、会社の成長に寄与するアイデアがあれば、本業に影響しない範囲で誰でもプロジェクト化できる社内制度です。
まずプロジェクトという箱を作った上で、どのような課題があり、いつまでにやらないとサービス継続が厳しくなる、といった情報を整理しました。そしてボードメンバーをはじめ、会社の課題として認知をしてもらうことに注力しました。ボードメンバーに認知をしてもらったところで、正式なプロジェクトとして発足させ、Gregをメンバーに引き入れました。2022年10月のことです。
データベース移行プロジェクトで最も意識したポイントは、アプリケーション変更の有無です。それによって開発期間やリソースが変わってしまうからです。また、移行には2時間程度のダウンタイムを想定していたので、ターゲット広告などの施策に影響が出ます。そのため、ステークホルダーとの情報共有も意識しました。
Greg：会社が大きくなるにつれ、複数の開発プロジェクトが並行して動くようになりました。ですが私たちのバックエンドAPIはモノリシックな構成になっており、どのプロジェクトも必ずバックエンドのコードベースに影響します。データベースをSpannerに移行する上で、どうすれば他のプロジェクトと並走できるのかは重要なポイントでしたね。
プロダクトの未来を左右するデータベース、移行先選定のポイントは？
──データベースの移行先を決定するにあたり、どのような検討をしたのでしょうか。
金井：実際、データベースの移行が始まったのは2024年1月ですが、その前に約1年かけて、データベース移行の準備を行いました。
最初に行ったのは移行先データベースの選定です。影響を最小限にしたいという思いがあったので、MySQLがそのまま使える「Vitess」、Vitessのマネージドサービスである「PlanetScale」、そして「Spanner」の3つを候補としました。
Vitessは当社のCTOが押していましたが、自前運用が大変になることが目に見えていました。そこでPlanetScaleを検討したのですが、コストがまったく合いませんでした。
Spannerは、当時の私たちの状況では選択するのが難しいと思っていましたが、分析にBigQueryを使っており、データエンジニアがGoogle Cloudの担当に引き合わせてくれたのです。その担当者と会話をし、Spannerを導入するにあたってのワークショップを3日間開催してもらうことになりました。そこで共に、サービスやデータベース移行に関する課題の洗い出しができたのです。ここまでの協力体制を築けるのであれば、移行に対するハードルが下がると考えました。その上で、もう一度、総合的にどのデータベースが良いか判断することにしました。
──最終的にSpannerを選定した決め手は何ですか。
金井：Spannerを選定した理由は3つあります。第1に、分析ですでにGoogle Cloudを利用していること。第2に社内コラボレーションツールとしてGoogle Workspaceを使っており、アカウント管理との連携が容易なこと。第3にGoogleという巨大システムがSpannerを利用していること。今後、AI活用が当たり前になる時代において、よりフルマネージドな状態でAIと連携できる方がプラスになると判断しました。
実際のところ、Spannerへの移行はビジネスロジック側のクエリの仕様を変更する必要があり、とても大変でした。ですが移行してしまえば、運用に関してはSpannerが一番楽だと思います。
Greg：コスト面を優先的に考えるとVitessになるのですが、運用を考えると専任のチームが必要になる。しかも今は採用市場が激化しているので、スペシャリストの採用は難しいと考えました。とはいえ、Spannerはプロトコルもデータモデルも既存のデータベースと異なるので、本当に移行ができるのか不安でしたが、Google Cloudの担当者がワークショップを通して、実現可能性を示してくれたことで、ポジティブに考えられるようになりました。
Spannerへの移行は3つのステップで実施
──Spannerへの移行をどのように進めていったのでしょうか。
金井：とにかく期間を重要視していたため、基本的には私とGregの2人体制で進めました。2人なら意思決定のスピードを早めることができるからです。
まず私がロードマップを作成し、タスクの洗い出しをしました。2人とも移行プロジェクトに専念できる状態だったので、タスクはそこまで細かく洗い出しすることなく、適宜発生するタスクに関してはアジャイルに進めることにしました。
Greg：マイグレーションのステップとしては大きく3段階に分かれます。第1段階ではアプリケーション側でSpannerに対応させていく。第2段階ではAurora内のデータをSpannerに流し込む。第3段階で、Google Cloud環境に基盤を構築する。第3段階のタイミングでメンバーを一人増やしました。
金井：移行テストの実施は2024年3月から。どうすれば期間内に移行ができるのか、検証しました。それと並行してバックエンドにどんな変更が必要になるのかも調査しました。
5月から本格的にマイグレーションを開始。またデータベース周辺のアプリケーションについても、移行の有無を検証した上で、Google CloudとAWSのマルチクラウドで稼働させるための設計を行いました。
そこからは実装しながら検証するという方法で、マイグレーションしていきました。当初はGoogle Cloudが提供しているSpannerマイグレーションツール（SMT）を使って移行しようと考えていました。ですが何回か検証すると、最終的に私たちが想定していたようにはいかないことがわかったので、同じくGoogle Cloudが提供するDatastreamとDataflowというサービスを組み合わせて移行しました。
Greg：私たちのサービスはRuby on Railsを使っており、多くのテーブルではプライマリーキーであるIDを単調増加させ、レコードをデータベースに追加していくという仕様になっていました。ですが、このような仕様はSpannerとの相性が悪く、ホットスポットという問題が起きてしまう。そこで使ったのがビット反転シーケンスというSpannerの機能。この機能を使いつつ、既存データのプライマリーキーの値も変換しました。
金井：Spannerの場合、データを自動的に分割処理（オートシャーディング）してくれるのですが、当社のサービスの特性上、新しい予定が登録されると、IDが1から順に採番されます。例えば昨日作った予定は1番ですが、今日作った予定が30番となる。ですが、ユーザーが見るのは、新しい予定。新しい予定にばかりアクセスが偏ると、それを分割される危険性がある。それを回避するために、サービス移行のロジックにビット反転シーケンスを組み込み、時間をかけて検証しながらデータ移行を行いました。
データ移行は2025年1月12日午前2時から開始。当初は午前4時に終わる予定が、4時間超のダウンタイムの発生と、その後もアラートの対応に追われ、無事完了したのは午後7時のことでした。
