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

Slide 1

Slide 1 text

Proprietary スケーラビリティと信頼性を追求： Global で 5,500 万ユーザーを抱えるカレンダーシェアアプリのデータベースを Aurora から Cloud Spanner へ移行株式会社 TimeTree

Slide 2

Slide 2 text

02 Proprietary Google Cloud Next Tokyo ’24 金井栄喜 (miu) SRE チームマネージャー Greg SRE チームソフトウェアエンジニア

Slide 3

Slide 3 text

03 Proprietary Google Cloud Next Tokyo ’24 共有とコミュニケーションを前提につくられたカレンダーシェアアプリ TimeTree は、予定の「共有」「可視化」とそこで生まれる「コミュニケーション」によって、予定管理をだれにとってもあたりまえで簡単なものにします。数ある予定管理サービスの中で、唯一パーソナル × 共有を軸に価値提供しているプロダクトです。

Slide 4

Slide 4 text

04 Proprietary Google Cloud Next Tokyo ’24 公開カレンダー

Slide 5

Slide 5 text

05 Proprietary 01 背景と決断 02 移行アジェンダ

Slide 6

Slide 6 text

06 Proprietary Google Cloud Next Tokyo ’24 背景と決断

Slide 7

Slide 7 text

07 Proprietary 背景と決断 01 背景サービスの状況と移行が必要になった背景 02 決断 1 データベース移行の決断 03 決断 2 Cloud Spanner の選択

Slide 8

Slide 8 text

08 Proprietary & Confidential Google Cloud Next Tokyo ’24 01 背景サービスの状況と移行が必要になった背景

Slide 9

Slide 9 text

09 Proprietary Google Cloud Next Tokyo ’24 データの増加サービスの成長に伴い順調にユーザーやセッションが増加しています。結果的にデータベースに登録されるデータ量も増加していきます。主な要因データベースリミット Amazon Aurora には様々な上限が存在します。中には変更できないような上限もありデータの増加に伴いスケールアップだけでは対応できなくなっていきます。

Slide 10

Slide 10 text

010 Proprietary Google Cloud Next Tokyo ’24 サイズデータの増加ユーザーレコード数 Aurora 移行時から現在の比較 800 万 5500 万 20 億 250 億 1TB 13TB

Slide 11

Slide 11 text

011 Google Cloud Next Tokyo ’24 項目拡張可否サービスから見た状況ストレージ不可短期では余裕があるように見えるがいずれ上限に到達する見込み。コネクション数条件付き可変更可能だが上限あり。拡張することによりメモリへの影響が懸念される。ローカルストレージ条件付き可スケールアップによって拡張可能だが現状でかなり大きなサイズを利用している状況なので拡張にも余裕がない。データベースリミット

Slide 12

Slide 12 text

012 Google Cloud Next Tokyo ’24 項目影響ストレージ上限に到達した場合データの追加が不可能になる。サービスの成長率によっては中期で到達する恐れもあるため早めの対応が必要。コネクション数ユーザーやセッションの増加、施策の追加に伴いアプリケーションのスケールアウトが増加するためコネクションが増加する。コネクションが上限に達成した場合スケールアウトも制限される。現状でも状況によっては 80% に到達しているため早めの対応が必要。ローカルストレージオンライン DDL を実行する際に急激に消費される。現状で大きなテーブルの場合は枯渇して DDL が中断されることもある。ワークアラウンドで回避可能な場合もあるが早急な対応が必要。データベースリミットによる影響

Slide 13

Slide 13 text

013 Proprietary & Confidential Google Cloud Next Tokyo ’24 02 決断 1 データベース移行の決断

Slide 14

Slide 14 text

014 Proprietary Google Cloud Next Tokyo ’24 決断に必要だったもの課題認識と共有 Aurora に移行した直後からモニタリングを整理。顕在化した問題を継続的に発信することでボードメンバーを含め全社への共有。サービス成長目標今後のサービス成長目標を把握することでデータ増やアクセス増などを予測。実行する時期を見極める。

Slide 15

Slide 15 text

015 Proprietary Google Cloud Next Tokyo ’24 2023 稼働開始課題を解決するために必要なメンバーを募集し重要なプロジェクトとして稼働を開始 2019 課題の共有いつか対応しなければいけないが時間的にはまだ余裕がある課題として発信し始める 2018 課題を認識モニタリングを拡充し状況を整理することで課題を認識課題認識と共有 2022 重要度の共有そろそろ対応しないと危険であることをボードメンバー含め共有プロジェクトとして稼働する準備を進める

Slide 16

Slide 16 text

016 Proprietary Google Cloud Next Tokyo ’24 分析分析に必要な情報を予想分析が多用されることにより必要なデータが増加施策機能拡張や外部連携など海外展開本格的な海外展開時期ユーザー、セッションいつまでにどれくらいのユーザー数を目指しているかサービス成長目標

Slide 17

Slide 17 text

017 Proprietary Google Cloud Next Tokyo ’24 現状と目標現状順調に成長目標に向けて成長速度を上げるための施策検討人員計画 … 目標に向けて施策開始施策開始俗にいうアクセルを踏むという時期実行する時期目標に向けて人員計画採用強化ここら辺の時期に完了するのがベスト

Slide 18

Slide 18 text

018 Proprietary & Confidential Google Cloud Next Tokyo ’24 03 決断 2 Cloud Spanner の選択

Slide 19

Slide 19 text

019 Proprietary Google Cloud Next Tokyo ’24 PlanetScale Vitess を運用してくれるプラットフォーム運用実績多数 Vitess MySQL 対応の水平シャーディングツール CNCF で Graduated Kubernetes での自前運用が必要運用実績多数選択肢 Cloud Spanner Google Cloud が提供するフルマネージドサービス水平シャーディング運用実績多数（Google 自身も利用）

Slide 20

Slide 20 text

020 Google Cloud Next Tokyo ’24 機能メリット詳細フルマネージド運用負荷軽減シャーディングやリシャーディングが自動で行われる運用実績安定性 Google の巨大なデータを運用できているという実績が安定性に期待できる BigQuery 連携運用負荷軽減コスト削減成長期待分析基盤として利用している BigQuery とのシームレスな連携による運用負荷の軽減やコスト削減が見込まれる分析基盤の成長への期待も見込まれる Google Workspace セキュリティ運用簡易化 IdP として利用している Google Workspace との連携によりセキュリティ運用の簡易化と強化が見込まれる Spanner を選択した理由

Slide 21

Slide 21 text

021 Proprietary Google Cloud Next Tokyo ’24 PM & 開発チームの協力 Cloud Spanner PM や PM を通した開発チームの協力による弊社の開発効率の向上 Tech Acceleration Program (TAP) Google Cloud チームがオフラインで我々がやりたいことに対しディスカッション実施し可能性を高めるその他ブースト

Slide 22

Slide 22 text

022 Proprietary Google Cloud Next Tokyo ’24 データベース移行からクラウド移行へ

Slide 23

Slide 23 text

023 Proprietary & Confidential Google Cloud Next Tokyo ’24 まとめやってよかったことやった方がよかったこと

Slide 24

Slide 24 text

024 Proprietary Google Cloud Next Tokyo ’24 移行

Slide 25

Slide 25 text

025 Proprietary & Confidential Google Cloud Next Tokyo ’24 NOTE 現在移行途中です！！！

Slide 26

Slide 26 text

026 Proprietary 移行 01 スケジュール移行範囲の決定とロードマップ作成 02 インフラ移行範囲を踏まえた移行プランの作成と実行 03 アプリケー　ション移行対象の精査とスキーマの検討 04 データマイグ　レーションテストマイグレーションによる課題解決と最終的な移行プランの作成

Slide 27

Slide 27 text

027 Google Cloud Next Tokyo ’24 01 スケジュール移行範囲の決定とロードマップ作成

Slide 28

Slide 28 text

028 Proprietary Google Cloud Next Tokyo ’24 移行範囲の決定とロードマップ作成データベースを中心に、移行しなければいけないもの、そうではないものを整理して最小限に止めます。（右表は例）ロードマップを作成して共有することで全社の認識を深めます。サービス実施有無理由 Aurora 有り本来の目的であるため ECS 有りデータベースへ接続するため CDN 無し現状のままで継続可能なため DynamoDB 無し現状のままで継続可能なため

Slide 29

Slide 29 text

029 Proprietary & Confidential Google Cloud Next Tokyo ’24

Slide 30

Slide 30 text

030 Google Cloud Next Tokyo ’24 02 インフラ移行範囲を踏まえた移行プランの作成と実行

Slide 31

Slide 31 text

031 Proprietary Google Cloud Next Tokyo ’24 人員計画移行完了に必要な人員（誰なのか、いつなのか）を計画スプリント開始ロードマップを完了するためのスプリントを開始マイルストーン作成移行完了時期の確定と各作業の依存関係と期間を整理移行範囲の整理移行範囲の整理と具体的な作業の洗い出し移行範囲を踏まえた移行プランの作成と実行

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

033 Google Cloud Next Tokyo ’24 03 アプリケーション移行対象の精査とスキーマの検討

Slide 34

Slide 34 text

034 Proprietary Google Cloud Next Tokyo ’24 AWS 依存 AWS 固有の様々な機能を利用しているため、今回の移行でスコープに含めるべきか、スケジュールやパフォーマンスの調査などを踏まえて判断移行機能の選定クローズした機能コードベースや Database からクローズされたサービスに関する機能を削除し、検討事項を減らす Database 固有の処理 INSERT ... ON DUPLICATE KEY UPDATE、SELECT for UPDATE など、Spanner には存在しない機能を利用している

Slide 35

Slide 35 text

035 Proprietary Google Cloud Next Tokyo ’24 スキーマ設計サービスの特徴としてリードアクセスが多く、パフォーマンスのためにインターリーブを活用したい。 ● アクセスパターンの調査 ● インデックス見直し ● インターリーブ導入のための Primary Key 変更

Slide 36

Slide 36 text

036 Proprietary Google Cloud Next Tokyo ’24 複数のインターリーブを繋ぐ中間テーブル関連テーブルのスプリットを横断的に探索

Slide 37

Slide 37 text

037 Proprietary Google Cloud Next Tokyo ’24 インクリメンタルな PK 利用しているフレームワーク（Ruby on Rails）の都合上、ほとんどのテーブルでホットスポットが発生するビット反転シーケンス Spanner Adapter 対応 Google が OSS として提供している Ruby on Rails 用の Spanner Adapter でこの機能を利用するため、バージョンアップや複合主キー対応を実施再反転処理の導入ビット反転された値を再反転し、元の値を利用可能にする

Slide 38

Slide 38 text

038 Google Cloud Next Tokyo ’24 04 データマイグレーションテストマイグレーションによる課題解決と最終的な移行プランの作成

Slide 39

Slide 39 text

039 Proprietary Google Cloud Next Tokyo ’24 spanner-migration-tool マイグレーションには Google Cloud が OSS として GitHub に公開している spanner-migration-tool (以下 SMT) を利用しています。

Slide 40

Slide 40 text

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 Dataﬂow Cloud Spanner Pub/Sub Datastream Cloud Storage Cloud VPN

Slide 41

Slide 41 text

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 に変換した状態での期間確認膨大な時間がかかることがわかったため中断

Slide 42

Slide 42 text

042 Google Cloud Next Tokyo ’24 大変だったこと今後の課題と展望まとめ

Slide 43

Slide 43 text

043 Google Cloud Next Tokyo ’24 Proprietary Ask the Speaker にぜひお越しくださいセッションに関する質問にスピーカーが直接お答えします！ Ask the Speaker G213 G214 G216 G217 2F

Slide 44

Slide 44 text

Thank you 044 Proprietary

Slide 45

Slide 45 text

045 Proprietary Google Cloud Next Tokyo ’24 下記リンクより図のサンプルスライドがご確認いただけます。 Google Cloud Official Icons and Solution Architectures アーキテクチャ図の構築方法