スキーマ進化とローリングデプロイの互換性

問題の起点：デプロイ中は新旧コードが必ず同居する

ローリングデプロイ（/devops/deployment-strategies/）は、サーバー群を一斉に置き換えず、一部ずつ新バージョンへ入れ替えます。その帰結として、更新が完了するまでの一定期間、旧コード（vN）と新コード（vN+1）が同時に本番で稼働します。この同居期間の長さは、置き換え戦略とインスタンス数で決まります（その台数計算は /devops/rolling-update-math/ を参照）。

ここで両バージョンが同一のデータベースを共有しているのが急所です。アプリのコードはローリングで段階的に切り替わりますが、共有DBのスキーマはある瞬間に切り替わる単一の状態しか持てません。つまり、

ある時点のスキーマ S に対して、
  vN   のコードも S 上で正しく動く必要がある（古い側）
  vN+1 のコードも S 上で正しく動く必要がある（新しい側）

を同時に満たさねばなりません。列のリネーム email -> email_address を1回のマイグレーションで適用したとします。マイグレーション直後、まだ生き残っている vN は email を読みに行き、存在しない列で即座に落ちます。逆にマイグレーション前に vN+1 を出せば、vN+1 が email_address を探して落ちます。破壊的変更を1ステップで当てると、新旧どちらかが必ず壊れる——これがローリングデプロイとスキーマ進化の根本的な緊張です。

前方互換と後方互換：二方向の両立が要件

この要件を二つの互換性に分解します。視点は「コードがスキーマをどう見るか」です。

• 後方互換（backward compatible）：新しいコードが、古いスキーマ上でも正しく動く。新コードを先に出しても落ちない。
• 前方互換（forward compatible）：古いコードが、新しいスキーマ上でも正しく動く。マイグレーションを先に当てても旧コードが落ちない。

ローリングデプロイの同居期間を生き延びるには、各マイグレーションが前方互換であることが決定的です。なぜなら、マイグレーション適用の瞬間にはまだ旧コードが動いており、その旧コードは新スキーマに対して「何も知らないまま」クエリを投げ続けるからです。新スキーマが旧コードのクエリを壊さない——これが前方互換の意味です。

安全なステップの条件：
  スキーマ変更を当てた直後、
  「変更を知らない旧コード」のすべてのクエリが
  そのまま成功し続けること（= 前方互換）

列の追加（NULL 許容またはデフォルト付き）はこの条件を満たします。旧コードはその列を SELECT 句に書かず INSERT 時にも触れませんが、列が NULL 可かデフォルトを持つので旧コードの INSERT は成功します。一方、列の削除・リネーム・NOT NULL 化・型の縮小（例：bigint が int 未満へ）はいずれも前方互換を壊します。破壊的変更とは、本質的に前方互換を破る変更のことだと言い換えられます。

expand/contract（拡張収縮）パターン

破壊的変更を安全にする中心戦略が expand/contract（parallel change とも呼ぶ） です。発想は単純で、破壊的な1ステップを、前方互換な複数ステップに分解すること。各ステップ単独では何も壊さず、ステップ間には必ずデプロイの完了を挟みます。email -> email_address のリネームを例に、四段で追います。

[1] Expand（拡張）：
    新列 email_address を NULL 許容で追加（破壊なし・前方互換）
    必要なら既存行を email -> email_address へバックフィル

[2] Migrate（二重書き＋読み替え）：
    新旧両対応コードをデプロイ。
    書き込みは email と email_address の両方へ（dual write）
    読み込みは email_address を優先、無ければ email にフォールバック

[3] Cleanup（旧参照の除去）：
    email を一切参照しないコードをデプロイ。
    二重書きをやめ email_address のみを使う

[4] Contract（収縮）：
    どのコードも email を読まなくなったことを確認し、
    旧列 email を削除（このときには安全）

要点は、列の削除（収縮）が、その列をもう誰も読まなくなってから初めて行われることです。ステップ間でデプロイ完了を待つのは、「旧コードが本番から完全に消えた」ことを保証してから次の破壊度の高い操作へ進むためです。各ステップは「列追加」「両対応コードのデプロイ」「片対応コードのデプロイ」「列削除」であり、どれも単独では新旧コードを壊しません。

書き込み側の INSERT も同じ理屈で対称に守られます。新列を追加する段階では旧コードはその列を知らないので、新列は NULL 許容かデフォルト付きでなければ旧コードの INSERT が壊れます。だから expand は必ず「足すだけ・緩めるだけ」の方向にし、「消す・厳しくする」方向の操作はすべて contract 側へ寄せます。

バックフィルと二重書きの一貫性

expand の後、既存行には新列の値が入っていません。これを埋めるのがバックフィルです。素朴に UPDATE table SET email_address = email を一発で流すと、大きなテーブルでは長時間のロック・WAL 膨張・レプリカ遅延を招きます。実務では主キー範囲でバッチに刻み、各バッチを小さなトランザクションでコミットしながら進めます。

# バックフィルの骨格（バッチ処理）
last = 0
loop:
    UPDATE table
       SET email_address = email
     WHERE id が last 超かつ last+1000 以下
       AND email_address IS NULL      # 二重書きで埋まった行は触らない
    last = last + 1000
    if 影響行が0なら終了
    （短い休止でレプリカ遅延を吸収）

ここで効くのが、ステップ[2]の 二重書き（dual write） との組み合わせです。バックフィルが過去の行を埋めている間も、新規・更新される行は二重書きで email_address が常に最新に保たれます。「過去はバックフィルが、現在以降は二重書きが」両側から埋めることで、収縮の時点で全行に値が揃います。二重書きを欠いたままバックフィルだけ行うと、バックフィル中に更新された行で email だけが新しく email_address が古い、という取りこぼしが生じます。

ロック・ロールバック・運用上の落とし穴

スキーマ変更そのものがダウンタイムを生む経路にも注意が要ります。多くのDBで、列追加はメタデータ操作で済む一方、デフォルト値付きの列追加や型変更が全行の書き換え（テーブル全体の排他ロック）を伴うことがあります（バージョンに依存。近年の PostgreSQL は定数デフォルトの列追加を即時化しています）。安全側に倒すなら、まず NULL 許容で足し、デフォルトはアプリ側で書くかバックフィルで埋め、制約は後から追加します。

ロールバックも互換性の対象です。vN+1 に問題が見つかり vN へ戻すとき、スキーマは前進したままであることが普通です。expand/contract を守っていれば、新スキーマは前方互換なので vN は新スキーマ上でも動き続け、安全にコード側だけ巻き戻せます。逆に収縮（列削除）を急いで先に当ててしまうと、ロールバック先の vN が消えた列を参照して戻れなくなります。**「収縮は、そのバージョンへロールバックする可能性が消えてから」**が運用上の鉄則です。

これは結局、どのバージョンが何を読み書きしてよいかという一貫性の境界をデプロイの時間軸に沿って設計する問題で、状態一貫性の議論（/devops/consistency-models/）と地続きです。

まとめ

• ローリングデプロイ中は新旧コードが共有DBへ同時アクセスするため、破壊的変更を1ステップで当てると新旧どちらかが必ず壊れる。
• 安全なマイグレーションの要件は前方互換（旧コードが新スキーマで落ちない）。破壊的変更とは前方互換を破る変更のことだと捉える。
• expand/contract は、リネーム・削除・NOT NULL 化・型変更を「拡張→二重書き＆読み替え→旧参照の除去→収縮」の前方互換な小ステップに分解し、各ステップ間にデプロイ完了の境界を置く。
• バックフィルは主キー範囲でバッチ化し、原子的な二重書きと組で過去と現在の両側から新列を埋める。読み込みは新列優先・旧列フォールバックで移行中の不揃いを吸収する。
• 列削除（収縮）は、その列を誰も読まなくなり、かつそのバージョンへロールバックする可能性が消えてから初めて行う。