TimeTree のデータベースを Aurora から Cloud Spanner へ移行

Transcript

1. Proprietary スケーラビリティと信頼 性を追求： Global で 5,500 万ユーザーを抱えるカ レンダーシェアアプリのデータベースを Aurora から Cloud Spanner へ移行 株式会社 TimeTree
2. 02 Proprietary Google Cloud Next Tokyo ’24 金井 栄喜 (miu) SRE チーム マネージャー Greg SRE チーム ソフトウェアエンジニア
3. 03 Proprietary Google Cloud Next Tokyo ’24 共有とコミュニケーションを 前提につくられた カレンダー シェアアプリ TimeTree は、予定の「共有」「可視化」とそこで生まれ る「コミュニケーション」によって、予定管理をだれにとっ てもあたりまえで簡単なものにします。数ある予定管理 サービスの中で、唯一パーソナル × 共有を軸に価値提 供しているプロダクトです。
4. 04 Proprietary Google Cloud Next Tokyo ’24 公開カレンダー
5. 05 Proprietary 01 背景と決断 02 移行 アジェンダ
6. 06 Proprietary Google Cloud Next Tokyo ’24 背景と決断
7. 07 Proprietary 背景と決断 01 背景 サービスの状況と移行が必要になった背 景 02 決断 1 データベース移行の決断 03 決断 2 Cloud Spanner の選択
8. 08 Proprietary & Confidential Google Cloud Next Tokyo ’24 01 背景 サービスの状況と移行が必要になった背景
9. 09 Proprietary Google Cloud Next Tokyo ’24 データの増加 サービスの成長に伴い順調に ユーザーやセッションが増加し ています。結果的にデータベー スに登録されるデータ量も増加 していきます。 主な要因 データベースリミット Amazon Aurora には様々な上 限が存在します。 中には変更できないような上限 もありデータの増加に伴いス ケールアップだけでは対応でき なくなっていきます。
10. 010 Proprietary Google Cloud Next Tokyo ’24 サイズ データの増加 ユーザー レコード数 Aurora 移行時から現在の比較 800 万 5500 万 20 億 250 億 1TB 13TB
11. 011 Google Cloud Next Tokyo ’24 項目 拡張可否 サービスから見た状況 ストレージ 不可 短期では余裕があるように見えるがいずれ上限に到達する見込み。 コネクション数 条件付き可 変更可能だが上限あり。 拡張することによりメモリへの影響が懸念される。 ローカル スト レージ 条件付き可 スケールアップによって拡張可能だが現状でかなり大きなサイズを利用している状 況なので拡張にも余裕がない。 データベースリミット
12. 012 Google Cloud Next Tokyo ’24 項目 影響 ストレージ 上限に到達した場合データの追加が不可能になる。 サービスの成長率によっては中期で到達する恐れもあるため早めの対応が必要。 コネクション数 ユーザーやセッションの増加、施策の追加に伴いアプリケーションのスケールアウトが増加するためコ ネクションが増加する。コネクションが上限に達成した場合スケールアウトも制限される。 現状でも状況によっては 80% に到達しているため早めの対応が必要。 ローカル ストレー ジ オンライン DDL を実行する際に急激に消費される。 現状で大きなテーブルの場合は枯渇して DDL が中断されることもある。ワーク アラウンドで回避可能な 場合もあるが早急な対応が必要。 データベース リミットによる影響
13. 013 Proprietary & Confidential Google Cloud Next Tokyo ’24 02 決断 1 データベース移行の決断
14. 014 Proprietary Google Cloud Next Tokyo ’24 決断に必要だったもの 課題認識と共有 Aurora に移行した直後からモ ニタリングを整理。顕在化した 問題を継続的に発信すること でボードメンバーを含め全社へ の共有。 サービス成長目標 今後のサービス成長目標を把 握することでデータ増やアクセ ス増などを予測。実行する時期 を見極める。
15. 015 Proprietary Google Cloud Next Tokyo ’24 2023 稼働開始 課題を解決するために必 要なメンバーを募集し重 要なプロジェクトとして稼 働を開始 2019 課題の共有 いつか対応しなければい けないが時間的にはまだ 余裕がある課題として発 信し始める 2018 課題を認識 モニタリングを拡充し状 況を整理することで課題 を認識 課題認識と共有 2022 重要度の共有 そろそろ対応しないと危 険であることをボードメン バー含め共有 プロジェクトとして稼働す る準備を進める
16. 016 Proprietary Google Cloud Next Tokyo ’24 分析 分析に必要な情報を予想 分析が多用されることにより必要な データが増加 施策 機能拡張や外部連携など 海外展開 本格的な海外展開時期 ユーザー、セッション いつまでにどれくらいのユーザー数を 目指しているか サービス成長目標
17. 017 Proprietary Google Cloud Next Tokyo ’24 現状と目標 現状 順調に成長 目標に向けて 成長速度を上げるための 施策検討 人員計画 … 目標に向けて 施策開始 施策開始 俗にいうアクセルを踏む という時期 実行する時期 目標に向けて 人員計画 採用強化 ここら辺の時期に完了するのがベスト
18. 018 Proprietary & Confidential Google Cloud Next Tokyo ’24 03 決断 2 Cloud Spanner の選択
19. 019 Proprietary Google Cloud Next Tokyo ’24 PlanetScale Vitess を運用してくれるプラット フォーム 運用実績多数 Vitess MySQL 対応の水平シャーディ ングツール CNCF で Graduated Kubernetes での自前運用が 必要 運用実績多数 選択肢 Cloud Spanner Google Cloud が提供するフ ル マネージド サービス 水平シャーディング 運用実績多数（Google 自身も 利用）
20. 020 Google Cloud Next Tokyo ’24 機能 メリット 詳細 フル マネージ ド 運用負荷軽減 シャーディングやリシャーディングが自動で行われる 運用実績 安定性 Google の巨大なデータを運用できているという実績が安定性に期待できる BigQuery 連携 運用負荷軽減 コスト削減 成長期待 分析基盤として利用している BigQuery とのシームレスな連携による運用負荷の 軽減やコスト削減が見込まれる 分析基盤の成長への期待も見込まれる Google Workspace セキュリティ運用 簡易化 IdP として利用している Google Workspace との連携によりセキュリティ運用の簡 易化と強化が見込まれる Spanner を選択した理由
21. 021 Proprietary Google Cloud Next Tokyo ’24 PM & 開発チームの協力 Cloud Spanner PM や PM を 通した開発チームの協力によ る弊社の開発効率の向上 Tech Acceleration Program (TAP) Google Cloud チームがオフラ インで我々がやりたいことに対 しディスカッション実施し可能性 を高める その他ブースト
22. 022 Proprietary Google Cloud Next Tokyo ’24 データベース移行から クラウド移行へ
23. 023 Proprietary & Confidential Google Cloud Next Tokyo ’24 まとめ やってよかったこと やった方がよかったこと
24. 024 Proprietary Google Cloud Next Tokyo ’24 移行
25. 025 Proprietary & Confidential Google Cloud Next Tokyo ’24 NOTE 現在移行途中です！！！
26. 026 Proprietary 移行 01 スケジュール 移行範囲の決定とロードマップ作成 02 インフラ 移行範囲を踏まえた移行プランの作成と 実行 03 アプリケー　 ション 移行対象の精査とスキーマの検討 04 データ マイグ　 レーション テスト マイグレーションによる課題解決と 最終的な移行プランの作成
27. 027 Google Cloud Next Tokyo ’24 01 スケジュール 移行範囲の決定とロードマップ作成
28. 028 Proprietary Google Cloud Next Tokyo ’24 移行範囲の決定とロードマップ 作成 データベースを中心に、移行しなけ ればいけないもの、そうではないも のを整理して最小限に止めます。 （右表は例） ロードマップを作成して共有するこ とで全社の認識を深めます。 サービス 実施有無 理由 Aurora 有り 本来の目的であるため ECS 有り データベースへ接続するた め CDN 無し 現状のままで継続可能なため DynamoDB 無し 現状のままで継続可能なため
29. 029 Proprietary & Confidential Google Cloud Next Tokyo ’24
30. 030 Google Cloud Next Tokyo ’24 02 インフラ 移行範囲を踏まえた移行プランの作成と実行
31. 031 Proprietary Google Cloud Next Tokyo ’24 人員計画 移行完了に必要な人員（誰なのか、い つなのか）を計画 スプリント開始 ロードマップを完了するためのスプリン トを開始 マイルストーン作成 移行完了時期の確定と各作業の依存 関係と期間を整理 移行範囲の整理 移行範囲の整理と具体的な作業の洗 い出し 移行範囲を踏まえた移行プランの 作成と実行
32. 032 Proprietary Google Cloud Next Tokyo ’24 Architecture after migration from Amazon Aurora to Google Cloud Spanner Migration Phase 1: Overview AWS Cloud Front S3 (Log) Load Balancer ECS (App) Aurora Dynamo DB ECS (ETL) S3 (Assets) Cloud Load Balancing Cloud CDN Cloud Run Memorystore Cloud Spanner Cloud Storage Pub/Sub Looker BigQuery
33. 033 Google Cloud Next Tokyo ’24 03 アプリケーション 移行対象の精査とスキーマの検討
34. 034 Proprietary Google Cloud Next Tokyo ’24 AWS 依存 AWS 固有の様々な機能を利 用しているため、今回の移行で スコープに含めるべきか、スケ ジュールやパフォーマンスの調 査などを踏まえて判断 移行機能の選定 クローズした機能 コードベースや Database から クローズされたサービスに関す る機能を削除し、検討事項を減 らす Database 固有の処理 INSERT ... ON DUPLICATE KEY UPDATE、SELECT for UPDATE など、Spanner には 存在しない機能を利用している
35. 035 Proprietary Google Cloud Next Tokyo ’24 スキーマ設計 サービスの特徴としてリードアクセスが多く、パフォーマンスのた めにインターリーブを活用したい。 • アクセス パターンの調査 • インデックス見直し • インターリーブ導入のための Primary Key 変更
36. 036 Proprietary Google Cloud Next Tokyo ’24 複数のインターリーブを繋ぐ中間テーブル 関連テーブルのスプリットを横断的に探索
37. 037 Proprietary Google Cloud Next Tokyo ’24 インクリメンタルな PK 利用しているフレームワーク （Ruby on Rails）の都合上、ほ とんどのテーブルでホットス ポットが発生する ビット反転シーケンス Spanner Adapter 対応 Google が OSS として提供して いる Ruby on Rails 用の Spanner Adapter でこの機能 を利用するため、バージョン アップや複合主キー対応を実 施 再反転処理の導入 ビット反転された値を再反転 し、元の値を利用可能にする
38. 038 Google Cloud Next Tokyo ’24 04 データ マイグレーション テスト マイグレーションによる課題解決と最終的な移 行プランの作成
39. 039 Proprietary Google Cloud Next Tokyo ’24 spanner-migration-tool マイグレーションには Google Cloud が OSS として GitHub に公 開している spanner-migration-tool (以下 SMT) を利用しています。
40. 040 Proprietary Google Cloud Next Tokyo ’24 Orchestrated by SMT Migrate from Amazon Aurora to Google Cloud Spanner by SMT SMT: Overview SMT installed compute Connect to AWS Compute Engine Compute Engine Dataflow Cloud Spanner Pub/Sub Datastream Cloud Storage Cloud VPN
41. 041 Proprietary Google Cloud Next Tokyo ’24 Cycle 4 期間確認 Phase 2 Spanner のスキーマから インデックスを外し、イン ターリーブを追加した状 態での期間確認 ランダムな Backfill 実行 の場合膨大なエラーが発 生することがわかったた め中断 Cycle 1 SMT 稼働確認 SMT が動作するための 環境を用意 テスト環境で動作を確認 Spanner にデータが登録 されていることを確認 Cycle 2 Production 稼働確 認 Production データのマ イグレーションに問題が ないか確認 想定していないエラーが 発生したためパッチを適 用 テスト マイグレーションによる課題解決 と最終的な移行プランの作成 Cycle 3 期間確認 Phase 1 現在のスキーマをそのま ま Spanner に変換した 状態での期間確認 膨大な時間がかかること がわかったため中断
42. 042 Google Cloud Next Tokyo ’24 大変だったこと 今後の課題と展望 まとめ
43. 043 Google Cloud Next Tokyo ’24 Proprietary Ask the Speaker にぜひお越しください セッションに関する質問にスピーカーが直接お答えします！ Ask the Speaker G213 G214 G216 G217 2F
44. Thank you 044 Proprietary
45. 045 Proprietary Google Cloud Next Tokyo ’24 下記リンクより図のサンプル スライドがご確認いただけます。 Google Cloud Official Icons and Solution Architectures アーキテクチャ図の構築方法