章: 第8章: パフォーマンスと本番運用実践
1000万件のテーブルにカラムを追加したら、何が起きますか？
ALTER TABLE をそのまま実行すると、完了するまでテーブルがロックされます。数分間の書き込み停止が発生し、サービス障害として記録されます。
本番DBへのマイグレーションは「速さ」より「テーブルロック時間の最小化」と「戻せること」を優先した設計が必要です。
問題の本質と解決策
問題: 巨大テーブルへの直接変更はロック時間が長く、その間のリクエストが詰まります。また、失敗時にロールバックが難しいケースもあります。
解決策: 「追加 → 移行 → 切替 → 削除」の4段階で変更を積み上げます。各ステップを別リリースとして実施することで、いつでもロールバックできる状態を保ちながら変更を完了できます。
一括変更 vs 段階変更 比較
| 観点 | 一括変更（ALTER直実行） | 4段階の段階変更 |
| テーブルロック時間 | 全データ件数に比例して長い | 各ステップは短時間 |
| サービスへの影響 | 書き込み停止が発生 | 各ステップで影響を最小化 |
| ロールバック | 難しいケースがある | 各段階で戻せる |
| 変更完了までの時間 | 短い（リスクは高い） | 複数リリースをまたぐ |
チェックポイント: 本番DBへの変更手順に「ロールバック条件と手順」が含まれていますか？手順書に「戻し方」が書かれていない変更は、障害時に判断が遅れます。
マイグレーション戦略サンプル
# 例: 段階移行
# 1) nullableな新カラム追加
# 2) バッチで既存データ移行
# 3) アプリを新カラム参照に切替
# 4) 旧カラム削除（別リリース）
まとめ & 次のステップ
- 本番DBマイグレーションはロック時間の最小化と「戻せること」を優先します
- 「追加→移行→切替→削除」の4段階を別リリースとして実施するのが安全策です
- 大量データの移行はバッチで分割して実行し、長時間ロックを避けます
pt-online-schema-changeやgh-ostなどのツールも選択肢に入れましょう- まずは本番DBへの変更に必ずロールバック手順を付ける習慣をつけましょう
次回は Queue監視とアラート設計 を学びます。ジョブの遅延と失敗を早期に検出するための監視設計を解説します。
