Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

ekanai

June 13, 2024
Tweet

More Decks by ekanai

Other Decks in Technology

Transcript

  1. データベースの物理的な上限 → Aurora についての話です • ストレージ ◦ 128 TB •

    コネクション数 (max_connections) ◦ GREATEST({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemo ry/8187281408)*1000}) ◦ 16,000 まで拡張できるが上限がある • ローカルストレージ ◦ オンライン DDL で大量消費 ◦ 変更できない
  2. 様々な影響 • データ保存 ◦ ストレージがいつかは必ず上限に到達するので保存自体ができなくなる • アプリケーションサーバースケーリング ◦ たまに 80%

    くらいまで上昇するのでちょっと危険 ◦ 今後もアプリケーションサーバーはスケールしていく • オンライン DDL ◦ 枯渇によりオンライン DDL が失敗する時も ◦ 運用に大きな支障が起きる寸前 ◦ 現状は計画停止でカバーできている
  3. どうやって推進したか 2019 モニタリングを充実さ せて計測 この頃から Issue とし て管理していたがあく まで将来的なものとし て周知

    2022 いよいよ始めないと まずいという空気感 を出し始める 採用をやる 2024 具体的な課題と重要性を整理 PJ を立ち上げて全社の課題として周知 手段を決定 コスト算出 スケジュール決定 取締役会承認
  4. 認知 重要度、コスト、難易度を踏まえた上でサービスを 継続させるために必要な課題であることを会社全 体で認知してもらう 常に情報を発信する 推進の肝 モニタリング スグに顕在化する問題ではないがいつかは顕在化 するもの 安全な状況のうちから課題として捉えておくことが

    重要 認知にも有用なものとなる サービスの状況 中長期のサービス目標を把握することは必須 サービス目標を考慮した上で問題の顕在化の前に 対応するタイミングが重要 会社がいつアクセルを踏むか&踏む時には課題を 解決できている状態がベスト 協力&巻き込み 1人では困難なので興味がありやり切れる人を巻き 込む スケジュール上リリースなどに制限がかかることも あるので協力してもらえるように働きかける 移行に注力できる体制を整える(関係チームの採 用など)
  5. 2 つの決断 • 実施するのか ◦ 本当にやる必要があるのか? ◦ Aurora の進化を待つ方が良いのでは? ◦

    サービス成長の中長期目標はどうなの? ◦ スケジュールは? • 手段 ◦ Vitess ◦ Planet Scale ◦ Google Cloud Spanner
  6. 実施するのか → する  → 数年前から課題感を認知してもらっていたので比較的スムーズだった • サービス成長においてとても重要な課題 • 分析用データがさらに必要になるので増加スピードが早まる可能性 •

    中長期目標として不確実な Aurora の進化を待つことはリスキー • ただしスケジュールはシビアに • 今まで通りのサービスの成長や信頼性の妨げにならない体制を整える
  7. 手段 Vitess MySQL でいける YouTube が開発し利用し ていて他にも実績あり CNCF ではスタンダード 運用事例が多い

    V PlanetScale MySQL でいける Vitess をある程度運用し てくれる セミマネージド サポートあり(US only) P Google Cloud Spanner Google 自体が利用していて 実 績あり フルマネージド Google Cloud サービスとの シームレスな連携 サポートあり(JP) S
  8. 手段 → Google Cloud Spanner • 実績 • Google Cloud

    サービスとの連携 • コスト • フルマネージド • サポート
  9. Google Cloud Spanner に決まるまでの壁 問題 問題詳細 解決に向けた行動 意見の相違 手段の推しが分かれていた 最初は私だけ

    Spanner 推し 移行時のコストは大きいが 5-10 年後の運用の想定を共有 TAP で理解を深めた MySQL -> Spanner の事例がそこそこあることを知った 開発への影響 MySQL とは違う 開発コスト ベンダーロックイン 新しい挑戦として意識を向けてもらう 楽しんでもらえる人を探す Spanner に強い会社として成長する クラウド移行 データベースだけではない 大きなカネが動く 経営としての判断も必要 移行しても問題ないようにインプット&アウトプットをとことんやる サポートをフル活用 より具体的なコスト計画を算出(TAP によるコストの把握) 移行することで Google Cloud サービスとの連携がシームレスになり自社サー ビスの成長にプラスになることを説明