[TimeTree] Aurora から Spanner への 移行の決断と背景

Transcript

1. Aurora から Spanner への 移行の決断と背景
2. 自己紹介 金井 栄喜（カナイ エイキ） 株式会社TimeTree SRE チームマネージャー
3. サービスの紹介させてください
4. プロダクト Product 共有とコミュニケーションを 前提につくられた カレンダーシェアアプリ TimeTreeは、予定の「共有」「可視化」とそこで生まれ る「コミュニケーション」によって、予定管理をだれに とってもあたりまえで簡単なものにします。数ある予定 管理サービスの中で、唯一パーソナル ×共有を軸に価 値提供しているプロダクトです。
5. ※公開カレンダー機能はPC、SPにおいて予定をより多くの人に公開できる機能です 全世界ユーザー数5,500万以上 プライベートな予定とオープンな予定の一括管理が可能 家族 カップル 仕事 共有カレンダー 公開カレンダー ショップ・EC スポーツ 芸能 TV・配信 すべてのカレンダー etc… etc…
6. 公開カレンダー カレンダー形式でイベントの情報発信ができる TimeTreeの新しいサービス X（Twitter）と連携して情報を一括管理 TimeTreeユーザーへの告知も可能 ⚫ イベント情報発信に最適なカレンダー形式 インターネット上で誰でも見れます ⚫ ⚫ ⚫ Copyright©TimeTree,Inc.All rights reserved
7. ❶カレンダーを作成 発信者 ユーザー （お客様・ファン） ❷イベント登録 ②イベント情報をチェック ①カレンダーをフォロー 発信者：公開カレンダーを作成し予定を登録するだけ ユーザー：公開カレンダーをフォローするだけ 公開カレンダーの使い方 7
9. 楽天 キャンペーンカレンダー、人気です
10. 01. 背景 02. 推進 03. 決断
11. 01. 背景 02. 推進 03. 決断
12. データベースの物理的な 上限 ストレージ コネクション数 ローカルストレージ 01.背景 データ量増加 ユーザー増加&セッション レコード数&データ量 施策追加 様々な影響 データ保存 アプリケーションサーバース ケーリング オンライン DDL
13. 800 万 2018 5500 万 2024 約7倍 データ量増量の具体例 ユーザー数
14. 10 億 2018 130 億 2024 約13倍 データ量増量の具体例 レコード数
15. データ量増量の具体例 データ量 1 TB 2018 13 TB 2024 約13倍
16. データベースの物理的な上限 → Aurora についての話です • ストレージ ◦ 128 TB • コネクション数 (max_connections) ◦ GREATEST({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemo ry/8187281408)*1000}) ◦ 16,000 まで拡張できるが上限がある • ローカルストレージ ◦ オンライン DDL で大量消費 ◦ 変更できない
17. 様々な影響 • データ保存 ◦ ストレージがいつかは必ず上限に到達するので保存自体ができなくなる • アプリケーションサーバースケーリング ◦ たまに 80% くらいまで上昇するのでちょっと危険 ◦ 今後もアプリケーションサーバーはスケールしていく • オンライン DDL ◦ 枯渇によりオンライン DDL が失敗する時も ◦ 運用に大きな支障が起きる寸前 ◦ 現状は計画停止でカバーできている
18. 01. 背景 02. 推進 03. 決断
19. どうやって推進したか 2019 モニタリングを充実さ せて計測 この頃から Issue とし て管理していたがあく まで将来的なものとし て周知 2022 いよいよ始めないと まずいという空気感 を出し始める 採用をやる 2024 具体的な課題と重要性を整理 PJ を立ち上げて全社の課題として周知 手段を決定 コスト算出 スケジュール決定 取締役会承認
20. 認知 重要度、コスト、難易度を踏まえた上でサービスを 継続させるために必要な課題であることを会社全 体で認知してもらう 常に情報を発信する 推進の肝 モニタリング スグに顕在化する問題ではないがいつかは顕在化 するもの 安全な状況のうちから課題として捉えておくことが 重要 認知にも有用なものとなる サービスの状況 中長期のサービス目標を把握することは必須 サービス目標を考慮した上で問題の顕在化の前に 対応するタイミングが重要 会社がいつアクセルを踏むか＆踏む時には課題を 解決できている状態がベスト 協力＆巻き込み 1人では困難なので興味がありやり切れる人を巻き 込む スケジュール上リリースなどに制限がかかることも あるので協力してもらえるように働きかける 移行に注力できる体制を整える（関係チームの採 用など）
21. 01. 背景 02. 推進 03. 決断
22. 2 つの決断 • 実施するのか ◦ 本当にやる必要があるのか？ ◦ Aurora の進化を待つ方が良いのでは？ ◦ サービス成長の中長期目標はどうなの？ ◦ スケジュールは？ • 手段 ◦ Vitess ◦ Planet Scale ◦ Google Cloud Spanner
23. 実施するのか → する 　→ 数年前から課題感を認知してもらっていたので比較的スムーズだった • サービス成長においてとても重要な課題 • 分析用データがさらに必要になるので増加スピードが早まる可能性 • 中長期目標として不確実な Aurora の進化を待つことはリスキー • ただしスケジュールはシビアに • 今まで通りのサービスの成長や信頼性の妨げにならない体制を整える
24. 手段 Vitess MySQL でいける YouTube が開発し利用し ていて他にも実績あり CNCF ではスタンダード 運用事例が多い V PlanetScale MySQL でいける Vitess をある程度運用し てくれる セミマネージド サポートあり（US only） P Google Cloud Spanner Google 自体が利用していて 実 績あり フルマネージド Google Cloud サービスとの シームレスな連携 サポートあり（JP） S
25. 手段 → Google Cloud Spanner • 実績 • Google Cloud サービスとの連携 • コスト • フルマネージド • サポート
26. Google Cloud Spanner に決まるまでの壁 問題 問題詳細 解決に向けた行動 意見の相違 手段の推しが分かれていた 最初は私だけ Spanner 推し 移行時のコストは大きいが 5-10 年後の運用の想定を共有 TAP で理解を深めた MySQL -> Spanner の事例がそこそこあることを知った 開発への影響 MySQL とは違う 開発コスト ベンダーロックイン 新しい挑戦として意識を向けてもらう 楽しんでもらえる人を探す Spanner に強い会社として成長する クラウド移行 データベースだけではない 大きなカネが動く 経営としての判断も必要 移行しても問題ないようにインプット＆アウトプットをとことんやる サポートをフル活用 より具体的なコスト計画を算出（TAP によるコストの把握） 移行することで Google Cloud サービスとの連携がシームレスになり自社サー ビスの成長にプラスになることを説明
27. まとめ
28. まとめ • サービスの課題として捉えることが重要 • できれば事前に課題として把握し対応案をとことん考えて決める • できるだけ他チームやメンバーの施策に影響を与えないようなスケジュールを考える • 情報は常に発信する • 一緒にやり切ることのできるメンバーを巻き込む • 挫けない心
29. おまけ
30. spanner-migration-tool https://googlecloudplatform.github.io/spanner-migration-tool/
31. TimeTreeでは一緒に働くエンジニアを募集しています https://timetreeapp.com/intl/ja/corporate/careers
32. Google Cloud Next Tokyo 2024 に登壇します https://cloudonair.withgoogle.com/events/next-tokyo-24?talk=d1-db-03