😎
大規模データベース移行の技術的チャレンジと実践例に参加なぅ
こちらは Findy さん主催の「【増枠】大規模データベース移行の技術的チャレンジと実践例」に参加している僕のイベントレポートとなります。
ハッシュタグ: #techbrew_findy
LT1「VoicyのTiDB移行 失敗ポイント集」
-
株式会社Voicy 千田 航己さん @thousan_da
-
最近メイン DB を TiDB に移行した
- 移行を決めるまではアーカイブがある
- 今回は実際の移行についての共有
足りなかった SQL 知識
- アプリケーション開発者に必要なのは使い方の知識だった
- 限られた予算内で十分なパフォーマンスを出すにはチューニングが必要
- TiDB だからと言って特別なことは少ない
- データベースを勉強したいあなたに送る技術書17冊(+11冊1講義7link)
- 限られた予算内で十分なパフォーマンスを出すにはチューニングが必要
反映し忘れた設定
- 変更した設定を管理できていなかった
- テストやチューニング中にいろいろな設定を変更した
- が、どれを変更したか管理できていなかった
- 結果移行時に設定漏れがあり障害発生
途切れてしまったレプリケーション
- ２段階にレプリケーションすることでリバートを用意
- まずはレプリケーションを設定
- Aurora -> TiDB -> バックアップ
- 読み取りを TiDB に向けたタイミングで前半のレプリケーションがダウン
- 監視を整えたり一部が落ちても障害にならないように仕組み化が必要
- Aurora -> TiDB -> バックアップ
- 障害原因は Aurora -> TiDB のレプリケーションが SPOF
- まずはレプリケーションを設定
古すぎた Lambda
- 接続するデータベースを TiDB に変更しようとした時に問題発生
- lambda のバージョンが古すぎて変更できない
- 本番だけでしか動いていない Lambda だった
- EOL 対応は日頃からやっておきましょう
- lambda のバージョンが古すぎて変更できない
耐えられなかった負荷
- 移行後に DB のキャパオーバーでサービスダウン
- 本番の負荷が道だった
- ピーク時に必要なキャパシティを見誤った
- 本番相当の req/sec で API を叩いている検証はしていた
- サービス的に朝によく使われがち
- 音声だけなので長良で聴けることからそのようなサービス特性に
- ピーク時のキャパを見誤った
- CPU 負荷 50% の時 「あと ２倍まで耐えられる！」 とは限らない
- 専用の負荷試験環境を作って実際のワークロードを再現することが大事
- TiDB には Serverless でない場合、自動スケールはしない
LT2「スケーラビリティの課題解決に向けたココナラのデータベース移行戦略」
- 株式会社ココナラ 川崎 雄太さん @yuta_k0911
急拡大していた中で抱えた課題
- QCD のバランス確保やライフサイクルへの追従で悩んできた
- 設定した KPI より RDS の SLA の方が低い
- 自社でコントロールできないところで KPI が他生が難しい
- 意図せず KPI として無理があった
- 自社でコントロールできないところで KPI が他生が難しい
- 近い将来 IOPS の上限に抵触する
- CPU や Memory には問題がな買ったが IOPS の上限に抵触しそうになった
- 暫定的にストレージを拡張することで IOPS の上限を上げていったが一時凌ぎだった
- 設定した KPI より RDS の SLA の方が低い
課題にどう向き合ったか
- Aurora に移行した
- KPI／IOPSともに達成可能であることが見えた
- 経営層に「技術課題として一番リスクと難易度が大きいもの」とインプットするために対応するタスクの整理とマイルストーン設定から着手
- Blue/Green Deployments を採用
- GA タイミングですぐ使ったがバグをいくつか引いた
- SQL が 8億本もあった
- Insights Database Testing を活用した SQL テストの自動化
今後の取り組み
- データベース以降は事前の準備が大事
- 集められる情報は集めて、自社としての最適解を見つける
- 考慮するポイントは様々
- 数年位一度は必ず訪れるイベント
- 集められる情報は集めて、自社としての最適解を見つける
- 無停止でメンテナンスイベントをこなす最適解を見つける
- 基盤のメンテナンスは切っても切れない
- 極力システムメンテナンスがない世界を実現するための机上・実機検証を続ける
LT3「Aurora から Spanner への移行の決断と背景」
- 株式会社TimeTree 金井 栄喜さん
背景
-
データ量増加
- ユーザー増加 & セッション
- レコード数 & データ量
- 施策増加
-
データベースの物理的な上限
- ストレージ
- コネクション数
- ローカルストレージ
-
様々な影響
- データ保存
- アプリケーションサーバスケーリング
- オンライン DDL
-
データ量
- １TB -> １３TB
-
様々な影響
- データ保存
- ストレージがいつかは必ず上限に達する
- アプリケーションサーバスケーリング
- オンライン DDL の影響
- 枯渇によりオンライン DDLが失敗することもある
- 運用に大きな支障が起こる寸前
- 現状は計画停止でカバー
- データ保存
推進
- 2019年
- モニタリングを充実させて計測
- この頃から Issue として管理していたがあくまでも将来的なものとして検知
- モニタリングを充実させて計測
- ２０２２年
- いよいよ始めないとまずいという空気感を出し始める
- この頃から採用をやる
- 2024年
- 具体的な課題と重要性を整理
- PJ を立ち上げて前者の亜ｋ代として周知
- 手段を決定
- コスト算出
- 水深の木も
- モニタリング
- サービス状況
- 認知
- 協力 & 巻き込み
決断
- 2つの決断
- 実施するのか
- 本当にやる必要があるのか
- する
- サービス成長においてもとても重要な課題
- 分析データがさらに必要になるので増加スピードが早まる可能性
- 中長期目標として不確実な Aurora の進化を待つのは。。
- する
- Aurora の進化を待つ方がいいのでは？
- サービス成長の中長期目標はどうなのか
- スケジュールは？
- 本当にやる必要があるのか
- 手段
- Vitess
- PlanetScale
- Google Cloud Spanner
- 実績
- Google Cloud サービスとの連携
- コスト
- フルマネージド
- サポート
- 壁
- 意見の相違
- 手段の押しが分かれていた
- 開発への影響
- MySQL とは違う開発コスト・ベンダーロックイン
- クラウド移行
- 意見の相違
- 実施するのか
まとめ
- データベースの移行が大事なのではなく、サービスの課題として捉えることが重要
- できれば事前に課題として把握し、対応案をとことん考えて決める
- できるだけ対ｔー無やメンバーの試作に影響を与えないようなｓｊスケジュールを考える
- 情報は常に発信する
- 一緒にやり切ることのできるメンバーを集める
- やり切る
おまけ
- spanner-migration-tool
- 世界5400万ユーザー超え！ 日本発のプロダクト「TimeTree」を支える、エンジニアとしての総合力
LT4「Raftとは？／仕組みから考える得意なこと苦手なこと」
- btj.systems合同会社 bootjpさん @bootjp
目的
- 多くの NewSQL データベースが Raft を採用している
- その概要を説明する
- 得意不得意がある
- 仕組みを知ることで発生しうるトラブルを事前に予測することも
Raft?
- 分散合意アルゴリズム
- TiDB
- CockroachDB
- YugabyteDB
- RQLite
- etcd
- Consul
- Raft がやってくれること
- 自動フェイルオーバー
- いい感じのデータレプリケーション
- 一貫性を保ってくれる
- なぜ Raft が必要なのか
- ２ Phase Commit ではダメなのか？
- 故障したり復活したりするとすぐ壊れる
- 回復中に壊れるパターンや回復ノードが壊れるパターンまで上げ出すと壊せるシナリオは山ほど出てくる
- つまり。。。
- 2 Phase Commit はバグっている
- ２ Phase Commit ではダメなのか？
- Raft は何をしてくれるのか
- 自動フェールオーバー
- ノードがクラッシュしても自動でリカバリする
- データの自動同期
- Raft ではログレプリケーションという
- アプリケーションログとは違い State Machine への命令
- 一貫性の維持や分断に対する耐性
- リーダーを必ず経由するモデルを取ることで一貫性を維持する
- 自動フェールオーバー
まとめ
- 分散システムは難しい
- ２Phase Commit や不十分なレプリケーションはデータが消えうる
- Raft は自動フェイルオーバー、自動同期、一貫性の維持、ネットワーク分断に対する耐性を達成してくれる
- Raft が苦手なこと
- 小さなレーテンシーでレスポンスを返すこと
- スループットが要求される時
- リーダー障害児の可用性の低下
Discussion