10TBのデータベースをダウンタイムゼロで移行する：その計画は？

Question

IT Interview Practice · Accepted Answer

**旧と新にダブルライトし、履歴をバックグラウンドでバックフィルし、CDCで末尾を追いつかせ、シャドウリードで検証し、その後読み取りをアトミックに切り替えます。各ステップにロールバックパスを備えます。** アプリを決して停止せず、新DBが証明可能に同一になるまで両DBを並行稼働させ、その後カットオーバーします。

## アーキテクチャ

```text
        ┌── write ──▶ OLD DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NEW DB ◀──── backfill job (historical rows)
                        │
   shadow reads (compare OLD vs NEW) ─▶ diff metrics ─▶ atomic cutover ─▶ NEW is truth
                                                          (flip flag; rollback = flip back)
```

## 仕組み

1. **ダブルライト。** アプリはすべての変更を旧と新の両方に書きます。新しい行は今後同期され続け、欠けているのは履歴だけです。
2. **バックフィル。** バックグラウンドジョブが履歴行をバッチでコピーします（本番保護のためスロットリング）。冪等で再実行安全になるよう `INSERT ... ON CONFLICT DO NOTHING` を使います。
3. **CDCキャッチアップ。** ダブルライトは切り替え時に書かれた行を取りこぼしえます。**Debezium**が旧DBのWAL/binlogをストリーミングしてすべての変更をリプレイし、バックフィルが埋められないギャップを閉じます。
4. **シャドウリード。** 旧と並行して新から読み、**結果を比較**し、差分メトリクスを発行します。時間経過で差分ゼロ = 新は信頼できます。
5. **カットオーバー。** フィーチャーフラグを切り替えて読み取り（次に書き込み）を新へ向けます。デプロイではなく設定変更で、即時かつ**切り戻しで可逆**です。

## 面接での観点

面接官は、**データ損失なしとダウンタイムなしをどう保証するか**、そして**ロールバック**があるかを見たいのです。良い回答はダブルライトに言及します。優れた回答は、**レース窓を捕らえるCDC**、**信頼する前に検証するシャドウリード**、そして**アトミックで可逆なフラグ切り替え**を加えます。典型的な罠は「バックフィルして切り替え」で検証なし。ユーザーが遭遇して初めて不一致を発見し、戻る手段がありません。

## トレードオフと障害

- **ダブルライトの一貫性。** 新の書き込みが失敗し旧が成功すると乖離します。旧を権威とし、ユーザーのリクエストを失敗させるのではなくCDCに新を修復させます。
- **コストと複雑性。** 2つのDB + CDC + バックフィルの稼働は高価で運用負荷が重いです。大規模でクリティカルなストアでのみ正当化されます。
- **移行中のスキーマ変更**はリスクを倍増させます。カットオーバーまでスキーマを凍結します。
- **バックフィル負荷。** スロットリングされていないバックフィルは本番I/Oを飽和させ障害を引き起こしえます。目的の逆です。バッチ化しrate-limitします。
- **ロールバック窓。** カットオーバー後も数日間ダブルライト（今度は新→旧）を続け、潜在バグが表面化したら切り戻せるようにします。その後にのみ旧を廃止します。
- **不要な場合：** メンテナンス窓を持つ小さなDBはこれを必要としません。30分の `pg_dump`/リストアの方が、CDCパイプラインよりシンプルで安全です。

アーキテクチャ

仕組み

面接での観点

トレードオフと障害

関連する質問