数億リクエストを止めるな。SREが教える「データベース移行」のアンチパターンと実践戦略
はじめに
データベースの移行は、単なる「引っ越し」ではありません。
失敗すればデータ破損、長時間のダウンタイム、最悪の場合はビジネスそのものを止めてしまう、エンジニアにとって最も胃が痛くなるプロジェクトの一つです。
私はこれまで、いくつかの大規模サービスで、数億・数十億リクエストをさばくデータベースの移行や信頼性向上（DBRE）に取り組んできました。
その経験をまとめた書籍：『実践DBRE Vol.1』から、今回は 「AuroraからTiDBへの移行」 という少し珍しい、しかし非常に学びの多かった事例を抜粋して紹介します。
「理論はわかったけど、実際どうやるの？」という疑問に、泥臭い現場の実践知でお答えします。
その「なんとなく」が事故の元。移行における3つの観点
移行プロジェクトが失敗する最大の原因は、技術的な難易度よりも 「見えていない依存関係」 や 「曖昧なリスク評価」 にあります。
私が移行プロジェクトに入るときは、まず以下のフレームワークで現状を整理します。
- リスク評価（Risk Management）
- 依存関係分析（Dependencies & Architectural Inventory）
- 移行計画（Planning）
1. リスク評価グリッド
「すべてのリスクをゼロにする」ことは不可能です。限られたリソースで戦うために、リスクを「発生頻度」と「影響度」で分類し、優先順位をつけます。
特に 「頻度は低いが、起きるとサービスがやばい（影響大）」 リスク（発生時の備えと検知・復旧手順の整備）に対する検知・復旧手順が整備されているか？ここがSREの腕の見せ所です。
図1：リスク評価グリッド（『実践DBRE Vol.1』より）
| 低頻度 | 高頻度 | |
|---|---|---|
| 影響大 | 発生時の備えと検知・復旧手順の整備 | 最優先 |
| 影響小 | 必要に応じて最低限の対応 | 自動化などで運用負荷を下げる検討 |
2. 依存関係の可視化
「このDBはアプリAしか使っていないはず」と思い込んで移行したら、実は 「月次バッチB」 や 「分析ツールC」 も繋がっていて、切り替え時にそれらが全滅した……というのは「あるある」です。
これを防ぐために、アーキテクチャインベントリを作成し、依存関係を図解します。見栄えは二の次で、「誰がどこに繋がっているか」をチーム全員が指差し確認できる状態にすることが重要です。
図2：依存関係図の例（『実践DBRE Vol.1』より）
| カテゴリ | 内容 |
|---|---|
| データセンター/環境 | オンプレミス、各クラウドリージョン、本番・ステージング・検証環境など |
| アーキテクチャコンポーネント/ティア | ・アプリケーションサーバー ・ロードバランサー ・キャッシュ (Redis、Memcached など) |
| ストレージ | オブジェクトストレージ、ブロックストレージなど |
| コンポーネント内の役割 | ・プライマリ/セカンダリ ・読み取り専用レプリカ ・バックアップ用インスタンス など |
| サービス間の相互作用/通信パス | ・どのサービスが、どのデータベースに接続しているか ・どの API が、どのバックエンドを呼び出しているか |
| ジョブやバッチ処理 | ・ETL (データ同期・変換) ・定期的な集計・レポート ・キャッシュのリフレッシュ |
| CDN へのデータロード など | - |
【実録】Aurora → TiDB 移行の「新旧同期パターン」
ここからは具体的なケーススタディです。
かつて私が担当したプロジェクトでは、大規模キャンペーンによる一時的なアクセス急増に耐えるため、Amazon Auroraから、より水平スケーリングに強い分散データベースTiDBへの移行を決断しました。
しかし、稼働中の大規模サービスを一瞬で切り替えるのは無謀です。
そこで採用したのが 「新旧同期パターン」 です。
移行のステップ
- 新旧並行稼働: 旧DB（Aurora）をメイン（書き込み先）としたまま、新DB（TiDB）をレプリカとして配置し、レプリケーションでデータを常に同期させる。
- 昇格: 切り替えのタイミングで、新DBをメインに昇格させる。
- 逆同期（ここが重要）: 新DBがメインになった後も、「新DB → 旧DB」への同期（逆方向レプリケーション）を継続する。
図3：新旧同期パターンの移行構成図（『実践DBRE Vol.1』より）
この構成の最大のメリットは、 「切り戻し（ロールバック）が数秒でできること」 です。
もし新DBで未知のトラブルが起きても、旧DBには最新データが同期されているため、アプリの接続先を戻すだけで復旧できます。この「命綱」があるからこそ、大胆な移行が可能になるのです。
地味だけど最強の検証術「p6spy」
「MySQL互換」を謳うデータベースは多いですが、100%の互換性を信じてはいけません。
特に大規模トラフィック下では、微妙な挙動の違いが障害の引き金になります。
そこで私たちが徹底したのが、 「本番トラフィックのミラーリング検証」 です。
具体的には、p6spyというJDBCドライバのラッパーツールを使用しました。
-
キャプチャ: 本番環境（Aurora）で流れるSQLを
p6spyですべて記録する。 - リプレイ: 記録したSQLを、検証環境のTiDBに対して流し込む。
- 比較: 両者の実行結果（ResultSet）とパフォーマンスを比較する。
この検証により、「特定のクエリだけTiDBだと遅くなる」「この関数は挙動が違う」といった地雷を事前にすべて踏み抜き、修正することができました。ドキュメントを読むだけでなく、「自分たちのワークロード」で検証することが何より重要です。もちろん安全な環境環境を用意して行います。
おわりに：DBAからDBREへ
かつてデータベース管理（DBA）は「設定ファイルを守る仕事」でしたが、これからの時代は信頼性をエンジニアリングする 「DBRE（Database Reliability Engineering）」 へと役割が変わっていきます。
今回紹介した「新旧同期」や「トラフィックリプレイ」は、まさに信頼性をコードとアーキテクチャで担保するDBRE的なアプローチです。
より詳細なリスク管理シートの作り方や、他ケースの移行事例（オンプレ北海道→東京など）、そしてSREチームビルディングの話などは、全3巻のシリーズとしてまとめています。もし興味があれば、手に取っていただけると嬉しいです。
📘 『実践DBRE Vol.1 DBREの基礎とデータベース移行戦略』SRE時代のデータベース運用パラダイムと移行戦略
📘 『実践DBRE Vol.2 大規模システムのスケーラビリティ改善: スケールアウト、シャーディング、分散DBの実践
📘 『実践DBRE Vol.3 運用の信頼性向上とチームビルディング: インシデント対応、SLO/SLI設計、チーム連携の実践
Discussion