マイグレーションの影響が考慮され、安全な実施計画があるか？¶
Type: Structure
Category: データ
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
スキーマ変更やデータ変換を伴うマイグレーションは、システム障害やデータ破損の重大リスクを含むため、実施タイミング・手順・リカバリ方法まで含めて設計段階から明確にしておくべき
本番環境でのダウンタイム0を可能にするために段階的な展開やデプロイ戦略が求められる
例¶
- nullable → not null のような制約追加はデプロイ前に全データの整合性を確認・補正する
- Enumへの値追加はアプリ側との互換性を確認した上でリリース順を調整する
- カラムのデータ変換が必要なケースでは安全以降のため多段階移行する（backfillと新旧カラムを並行運用など）
よくある失敗例¶
- 大量のデータに対してインデックス・制約を即時追加したせいで、ロックでシステム停止
- スキーマ変更にアプリの対応が間に合わず、実行時例外が発生
- マイグレーションのリハーサルやバックアップ・ロールバック設計を行わず、本番で復旧不可のデータ破損
FAQ¶
Q. マイグレーションはどのタイミングで設計すべき？
A. 設計初期から意識しておくのが理想。特に後方互換性の担保や段階的移行の構成をあらかじめ想定して設計すべきで、運用設計と密接に関係するため開発フェーズの後半で議論すると手遅れになることが多い
Q. データ変換が必要なマイグレーションの安全策は？
A. 本番環境ではnullableでカラム追加してbackfill → 新旧カラムを並行運用 → 旧カラム利用停止 → 旧カラム物理削除という多段階戦略が無難。backfillによる変換処理は再実行可能・部分実行可能であることが望ましく、障害時のロールバック手段やログの設計も重要