大規模データベース移行の技術的チャレンジと実践例に行ってきた #techbrew_findy

大規模データベース移行の技術的チャレンジと実践例に参加しました。今回は久しぶりのオフライン参加。簡単に所感をまとめます。

久しぶりにオフラインのイベントに参加しました。

全体的に共通してたのは、データベース移行は組織全体で取り組むものであり、事前の準備が重要であるとのこと。以前、GitHub の MySQL 5.7 から 8.0 アップグレードの話のときにも同じようなことを言ってたような気がする。データベース移行は、組織の馬力が試される案件だなと思いました。

あと、SQL 8億本のテスト自動化すごい。月次で動くバッチとかもあるはずなので SQL の収集が大変そう。

Raft とか Paxos は初めて聞いた。いや、Spanner 調べてるときに Paxos の話があったようななかったような...、でも全然理解できてなくて頭に入ってなかったのかもしれない...。

Jepsen Test も初めて聞いた。分散システムはまだまだ知らないことが多いので勉強が必要。

以下、メモから抜粋。

(メモ取ったけど外部公開 NG とのことだったので割愛)
(データベース移行に限らずシステム構築においてはわりと一般的に考慮が必要な話だったような気はする)

リポジトリ
- 45 → 170+ (3年で)
データベース課題
- QCD バランス
- ライフサイクル
SLO 99.96%以上
- Amazon RDS SLA 99.95%
- プラットフォーム側がすでに足りてない
IOPS上限
- ストレージ拡張して凌いでいた
MySQL 5.7 EOL
RDS → Aurora
- SLA 99.99%以上
- IOPS上限撤廃
B/G Deployments
Insight Database Testing
- SQL テスト自動化
- 8億本
- 地道な作業必要... (2~3ヶ月かかった)
- バッチと SQL の相関関係をまとめたり
データベース移行は準備が8割
- 類似の事例を参考にしつつ
- 自社の最適解 (ベストプラクティス) を探す
無停止メンテナンスを実現したい

データ増
- 線形にデータが増えていく
リソースの限界 (Auroraの限界)
- ストレージ
- コネクション数
- ローカルストレージ
アプリケーションがスケーリングできない
オンラインDDL
- ローカルストレージ枯渇でDDL失敗
- インスタンスタイプ変更でしか増やせない
- 計画停止でカバー
データベース移行は会社として重要な意思決定
- 本当にやる必要があるのか
- 必要性を説明できるように
モニタリング
- 課題の可視化
Vitess
Planet Scale
Cloud Spanner
- Google Cloud サービスとの連携
- フルマネージド
spanner-migration-tool
- https://googlecloudplatform.github.io/spanner-migration-tool/
- Aurora → Spanner
単調増加キーが使えない
インターリーブ
- 親子関係
- データ量が大きいところに着目する
- 結合
移行元データのクレンジング
- 移行不要なデータは削除しておく