はじめに
本記事はGoogle Cloud Next Tokyo 2024 のDay1(8/1)において Timetree の 金井さん と Gregさん が講演された「スケーラビリティと信頼性を追求: Global で 5,500 万ユーザーを抱えるカレンダー シェアアプリのデータベースを Aurora から Cloud Spanner へ移行」のレポートです。
公式セッション紹介
当社は Amazon Aurora から Google Cloud Spanner への移行を決断しました。
なぜ移行が必要になったのか、その背景や Spanner を選んだ理由について、そして移行の際に出会った問題や Tips についてお話ししたいと思います。
発表資料
- アーカイブ動画は9月に公開されるとのこと(Google Cloud Next Tokyo 2024として)
- [TimeTree] Aurora から Spanner への 移行の決断と背景 というテーマで発表されていた資料が近しいので一緒にあげておきます
概要／おすすめポイント
ビジネスの成長(2018年 → 2024年 : 1TB → 13TB)とともに Amazon Aurora の限界を再認識し、幾つか選択肢を検討した結果 Cloud Spannerを採用した、という発表になります。
ちなみに Amazon Aurora for MySQL の最大値は現時点(2024/8/3)において r6i.32xlarge の128vCPU、ストレージは 128TB となるため相当の規模にはなりますが、将来的にこの辺の最大値が気になる際の検討の参考にもなると思いました。
セッション内容の紹介
Auroraの物理的な限界
課題となったAuroraの限界値は次の三点
- ストレージ最大値
- 128TB
- コネクション数
- 16,000(スケールアップが必要): 現状で(現時点の最大値の) 80%程度になることもあり、対応が必要
- ローカルストレージ1
- 2,560GiB(スケールアップが必要): オンラインDDLなどで大きく利用され、大きなテーブルの場合にはDDLが実行できない場合も発生している
目標値の再確認
具体的な値は述べられてませんでしたが、以下の項目について組織としては数値や時期を設定されて決断に臨まれた、という背景があると理解しました。
- ユーザ数・セッション数
- 施策(機能拡張や外部連携の予定)
- 海外展開
- 分析用途
移行先の選択
次の3つのデータベースから選定をおこない、フルマネージドで安定している(Googleのプロダクトである)こと、BigQueryやWorkplaceとの連携が行いやすいことからCloud Spannerを選択されたとのことでした。
- Vitess
- PlanetScale
- Cloud Spanner
Cloud Spannerの利用に際しては Google CloudのTAP(Tech Acceleration Program)の利用や、Cloud Spannerのプロダクトチームの協力も得ることができ迅速な課題解決を行えていた、という話もありました。
Cloud Spannerの利用と移行に対しての検討
リードアクセスが多くなるためインターリーブを意識したスキーマ設計の実施と、ビット反転シーケンスの利用によってホットスポットを作らない形の設計を改めて実施されたとのことでした。
また、Spanner-Migration-Tool もプレビューだが活用して移行方式の検討・テストを実施中、特にデータ量が多いので1サイクルで効率的に検証できるよう推進中になるそうです。
まとめ
現時点では絶賛移行中という話でした。「Aurora から Spanner への 移行の決断と背景」が二カ月前くらいの発表で、その時には移行の話はあまりされていなかったので、そのあたりはだんだん進んでいると受け止めました。
本レポートでは省略していますが、ビジネス側との認識合わせなども発表時には触れられていたので、アーカイブが公開されたら是非確認してみてください。
また、MySQLを利用しているという事で、TiDBなどは候補に入らなかったのか、お聞きしてみたいです。
-
Aurora のローカルストレージは、エラーログ、一般ログ、スロークエリログ、監査ログ、および InnoDB 以外の一時テーブルの保存に使用される領域で、インスタンスクラスの変更によってのみ変更が可能 ↩