これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
前回に続いて、2024年に公開された論文「Transparent Migration of Datastore to Firestore」を紹介します。この論文では、Cloud DatastoreからFirestoreへのデータマイグレーションについて、その舞台裏の技術が解説されています。今回は、移行プロジェクトを通して得られた知見を紹介します。
Googleでは、これまでも大規模なシステム変更を経験してきましたが、このデータマイグレーションには、固有の特殊性がありました。それは、Cloud Datastoreのユーザーに一切の影響を与えずに実施するという点です。これには、ユーザー側とのスケジュール調整が不要で、プロジェクトの進捗を比較的自由に管理できるというメリットがありますが、逆にいうと、ユーザーに何らかの変更を依頼することはできず、移行前のシステムのすべての機能や挙動を保って移行する必要があることにもなります。既存のユーザーには、移行を通知するメールが送られましたが、それに対する返信はほとんどありませんでした。そのため、特定の機能や挙動に依存するユーザーの有無が不明な場合は、基本的には該当の機能や挙動を変更せずに移行する必要がありました。
冒頭の論文では、このような特殊性を持ったプロジェクトを通して得られた知見が8項目にまとめられています。これらを順番に紹介していきましょう。
前回の記事で移行処理のステップを説明しましたが、これは、移行処理のキャンセルを考慮した設計になっています。たとえば、「verification」の段階でデータの不一致が発生した場合、単純にSpannerにコピーされたデータを破棄すれば、移行処理を最初からやり直すことができます。また、その後「terminate_writes」の段階でデータの書き込み処理がSpanner側に移行するまでは、Spanner側に移行した読み込み処理をMegastoreに戻すことで、「verification」の段階まで戻ることができます。そして、データの書き込み処理がSpanner側に移行した後は、Spannerに発生した書き込みのログをMegastoreに転送して適用する、逆向きのレプリケーションを実行することで、SpannerとMegastoreが保持するデータが一致する状態を保つ仕組みを実装したということです。
第197回の記事で、MegastoreとSpannerの処理性能の比較例を紹介しましたが、一般的なベンチマークだけでは、現実のユーザーのワークロードへの影響を完全に把握することはできません。そこで、移行プロジェクトチームは、本番環境のライブトラフィックを複製して、性能比較データを取得するシステムを構築したということです。
前回の記事で説明したように、データ移行は複数のステップに分けて行われます。それぞれのステップにおけるシステムの状態を明確に定義することで、実際に意図通りの状態になっているかを徹底的にテストしながら、移行処理を確実に進められます。
このプロジェクトでは、膨大な数のデータベースを移行する必要があるため、移行の順番にも考慮が必要でした。論文によると、データ量が少なく、長期間アクセスがないものなど、失敗のリスクが低いデータベースから移行を行いました。具体的には、「28日間アクセスがないデータベース」「10,000QPS以下のデータベース」「エンティティーグループによるトランザクションを使用する500,000QPS以下のデータベース」など、いくつかの区分を設けて、それぞれの区分ごとに移行を進めたということです。ただし、リスクの高いデータベースを後回しにするという事は、それらに固有の問題点の存在に気づくのが遅れるというデメリットもあります。論文では、早期の移行に協力的なユーザーを見つけて、早い段階で複雑な移行作業に挑戦することの価値も指摘しています。
(4)で触れたように、このプロジェクトでは、データベースをいくつかのグループに分けて移行を進めましたが、全体で100万以上のデータベースがあるので、グループ分けや順序づけに応じた移行の実施は、すべて自動化が行われました。さらに、自動化による移行状況を把握するダッシュボードを構築して、問題が発生した場合に発生箇所を特定するためのログ管理システムなども用意したということです。
移行に伴う未知の影響を完全に排除することはできませんので、ユーザーに対して移行プロセスに関する情報を提供することは大切です。特に、実際に移行処理が行われる日時に関する情報は、ユーザー側のアプリケーションに問題が発生した際に、移行の影響かどうかを切り分けるために有用です。前述のメール通知に加えて、クラウドコンソール上にも移行に関する通知が表示されるようにしたほか、一部の大規模ユーザーには、双方向での情報のやり取りも行ったということです。
(6)に類似した内容ですが、ユーザーによっては、移行プロセスを自律的に管理したい場合もあります。そこで、一定規模以上のユーザーには、移行を避ける期間が指定できるオプションを提供して、トラフィックが集中したり、本番環境の変更がある期間の移行を回避できるようにしました。また、さらに規模が大きいユーザーに対しては、移行を一時停止・再開する機能も提供したということです。
長期的なプロジェクトでは、進捗状況を客観的に把握して、チーム全体で共有すると共に、ステークホルダーに報告する必要があります。移行プロジェクトチームでは、旧システムと新システムのそれぞれで稼働中のデータベース数、ストレージ容量、QPSなどの時系列データをリアルタイムに把握するダッシュボードを構築して、これらの数値を定期的に報告したということです。新システムのQPSが旧システムを上回るなどのマイルストーンを達成すると、非公式のチームパーティを開催するなど、チームのモチベーションを高める工夫もしたそうです。
今回は、2024年に公開された論文「Transparent Migration of Datastore to Firestore」に基づいて、Cloud DatastoreからFirestoreへのデータマイグレーションについて、移行プロジェクトを通して得られた知見を紹介しました。
次回は、大規模言語モデルによるソフトウェアレビュー支援に関する話題をお届けします。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
