> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2025/w46-database-migration-case-study.md).

# W46-データベース移行のケーススタディ

[How We Migrated 1 Billion Records from DB1 to DB2 Without Downtime](https://medium.com/@himanshusingour7/how-we-migrated-db-1-to-db-2-1-billion-records-without-downtime-c034ce85d889) という移行の経験談を読んだ。10億件の金融データを持つデータベースクラスターを、停止せず移行した振り返りだ。

私たちの技術リスク対策の考えと、多くの共通点がある。リスクを段階的に制御し、一歩ずつ独立して検証し、戻せるようにする。可観測性を優先し、DB 内部の WAL ログやキャッシュヒット率から、業務層の注文数や収入の流れまで監視して、異常を早く見つける。さらに、DB やバックエンドの移行には Shadow Reads という巧みな方法があると知った。

データ移行は本質的に、複雑なシステム設計の問題だ。著者は五つの重要な設計を挙げている。

第一に、シャーディング、並列処理、インデックスの無効化によって、コールドデータを一括移行する。

第二に、二重書き込みと Kafka の再試行キューを組み合わせ、旧 DB と新 DB のリアルタイムの書き込みを同期し、冪等性も保つ。

第三に、Shadow Reads で本番検証する。利用者の要求には旧 DB から読み出す一方、各クエリを裏で新 DB にも実行し、結果の差を比べる。数週間続けたことで、タイムゾーン処理、NULL の既定の挙動、文字列の照合順序など、テスト環境ではつかめない問題を多く見つけた。後から思えば、昨年の決済バックエンドの構成移行も似た方法だった気がする。しかしフロントエンドでは再現しにくい。

第四に、低トラフィックの時間帯に慎重に切り替え、キャッシュのウォームアップ、ロールバック計画、密な監視で滑らかな移行を確保する。

最後に著者は、全工程を通じた高い可観測性の役割を強調する。

フロントエンドで Shadow Reads を使いにくいのは、利用者がアクセスする版が一つに決まるからだ。新しい版を使えば古い版は使えない。DB の Shadow Reads は結果集合を見えないところで比べるが、フロントエンドの正しさはデータの一致よりはるかに複雑だ。操作、性能体験、アクセシビリティの一貫性、端末差への互換性などが関わり、安く検証する手段に乏しい。段階的なトラフィック公開、利用行動分析、業務指標の監視、人による確認が、なお最も有効な方法だ。