切替当日の方式選定 — 一斉カットオーバーか並行稼働かの判断

カットオーバー方式の選定は、設計フェーズで判断基準を固めておかなければ、当日に時間と判断根拠の両方を失う。一斉切替・段階移行・並行稼働のどれを選ぶかは、データの整合性要件・トラフィック特性・ロールバック許容時間という三つの軸で決まる。本記事では、方式選定の判断基準と、当日に判断が機能するための設計上の論点を整理する。当日に詰め直せる余地はほぼない。

切替手順を当日に詰めて戻せなくなる構造

判断の先送りが生む「当日依存」の設計

プロジェクト後半になっても方式が決まらないまま進むと、切替当日の作業量が膨張する。ある構築現場では、カットオーバー2週間前の時点でロールバック手順が未定義のまま、当日の手順書作成と並行して方式を確定させるという状況が発生していた。手順書は「決まった方式を実行する手順」であって、「方式を決める手順」ではない。この二つが同時進行になると、どちらの精度も下がる。設計フェーズで選定が完結していれば、手順書のレビューに集中できる体制が整う。方式選定を後回しにするプロジェクトは、後半の手順設計が常に不安定になる傾向がある。

時間の圧力がロールバック判断を封じる

切替当日は時間的な圧力が高い。メンテナンスウィンドウが4時間であれば、問題が発生したときの調査・判断・作業の全体を4時間以内に収める必要がある。ロールバックを発動するかどうかの判断を「その場の状況で決める」という設計は、実質的にロールバックを諦めた設計に近い。判断基準が事前に数値化されていないと、現場責任者は切替続行を選びがちになる。これは判断力の問題ではなく、判断材料が整備されていないことへの自然な反応として起きる。時間が迫るほど「戻せる」という選択肢が心理的に消えていく構造を、設計段階で壊しておく必要がある。

前提条件の確認漏れが判断基準を消す

切替方式は前提条件と一体で決まる。「ピーク時間帯を外してメンテナンスウィンドウを確保できる」「旧システムを切替後も最低72時間は起動維持できる」という条件が崩れると、選んだ方式自体が成立しなくなる。前提条件を方式選定と同時に文書化していないプロジェクトでは、条件が変わっても方式だけが残り、現場が矛盾した手順を抱える結果になる。方式と前提条件は一枚の判断書にセットで記録しておくことが、後からの追跡を可能にし、変更が生じたときの再判断を迅速にする。

一斉切替に耐える案件と並行稼働が要る案件の違い

一斉切替が成立する三つの条件

一斉カットオーバーが現実的な選択肢になるのは、次の三つが揃う場合に限られる。第一に、切替直前にデータの全量一致を確認でき、書き込みを一時的に停止できること。第二に、切替後に不具合が見つかった場合でも業務が許容できる時間的な猶予があること。第三に、旧システムを即時停止しても影響範囲が限定的なこと。典型例は、利用者50名以下の社内管理系ツール、バッチ処理が主体のシステム、または外部アクセスが発生しない内部データ基盤になる。この三条件のいずれかが欠ける場合は、方式の再検討が必要になる。条件の有無を確認せずに一斉切替を選んだプロジェクトが、当日に行き詰まる事例が現場ではよく聞かれる。

並行稼働が要る案件の判断基準

外部ユーザーが常時アクセスするシステム、または書き込みを24時間止められないシステムでは、一斉切替はリスクが高い。ECサイト・予約システム・決済処理など、分単位で取引が発生する環境では、メンテナンスウィンドウ自体を取れないことも多い。こうした案件では並行稼働期間を設けて段階的にトラフィックを移行する設計を選ぶことになる。ただし、並行稼働は「安全策」ではなく「複雑さを追加する選択」でもある。リスクの軽減と引き換えに、データ同期・二重監視・整合性確認という設計コストが生じる点は、選定時点で明確に認識しておく必要がある。

トラフィック特性とデータ特性による分岐

判断をより精緻にするには、トラフィックとデータという二つの軸で整理するとよい。読み取りが大半を占めるシステムは切替の難易度が低く、一斉切替でも許容範囲に収まることが多い。一方、書き込みが頻繁なシステムでは、切替期間中のデータ差分管理が複雑になる。さらに、スキーマが旧新で互換性を持たない場合、並行稼働中のデータ同期設計は格段に難しくなる。この二軸を事前に整理しておくことが、方式選定の議論を具体化させる起点になる。設計レビューの場でこの二軸を提示するだけで、議論が「方式の好み」から「案件の制約」に移行する。

比較表: 一斉切替・段階移行・並行稼働の比較

比較軸	一斉切替	段階移行	並行稼働
切替にかかる時間	単一のメンテナンスウィンドウ内で完結	複数フェーズに分散（フェーズ間に業務継続）	移行期間全体にわたって段階的に推移
ロールバックの容易さ	高い（切替前状態に戻せる）	フェーズ単位で戻せるが設計が要る	旧系が残るため技術的には戻しやすい
データ同期コスト	低い（一時点で確定）	フェーズ間の差分管理が必要	継続的な同期設計・整合性確認が必要
切替期間中の運用コスト	低い（短期集中）	中程度（フェーズ数に比例）	高い（二重管理・二重監視が続く）
適した案件の特性	小〜中規模・書き込み停止が可能	機能単位で分離できるシステム	大規模・常時書き込みが発生する環境
設計の複雑さ	低い	中程度（フェーズ設計が追加で必要）	高い（同期・競合設計が核心になる）
失敗時の影響範囲	全体に及ぶ（一度に全切替）	対象フェーズに限定できる	新系のみに限定（旧系が稼働継続）

各方式の位置づけと使い分けの原則

三つの方式はリスクの分散方法がそれぞれ異なる。一斉切替はリスクを短時間に集中させる代わりに設計の複雑さを最小化し、段階移行はリスクを時間軸で分散するが各フェーズの整合性確認コストを引き受ける。並行稼働はリスクを並列稼働で吸収するが二重管理コストが発生する。「どれが正しいか」ではなく「どれがこの案件の制約に合うか」を問うことが、選定の本質になる。比較表は選定の結論を出すものではなく、議論の論点を可視化して合意を取るための道具として使うのが有効になる。

段階移行が見落とされがちな理由

段階移行は一斉切替と並行稼働の中間に位置するが、設計コストが高いため実際には選ばれにくい。各フェーズの切替基準・データ引き継ぎ設計・フェーズ間のロールバック設計を個別に定義する必要があるためになる。現場では「段階移行と言っていたが実質的に並行稼働期間が長くなっただけ」という状態に陥ることがあり、二つの方式の設計コストを両方負担した形になる。段階移行を選ぶ場合は、各フェーズの完了基準を切替設計の段階で明示しておくことが不可欠になる。

戻す判断を誰が、いつ、どの基準で下すか

ロールバック権限の事前定義

ロールバック判断は当日の現場責任者に委ねられることが多いが、「問題があれば戻す」という合意だけでは不十分になる。「誰が・どの指標の閾値を超えたときに・何分以内に判断するか」まで決めておく必要がある。ロールバックの判断者・判断補助者（計測担当）・実行担当者という三つのロールを切替前に明示することが、当日の判断速度を高める。役割が曖昧なまま当日を迎えたプロジェクトでは、判断が遅れて戻す余地がなくなってから合意が取れるというケースが発生している。ロールバックを「誰かが決める」ではなく「基準に達したら動く」という設計にしておくことが、判断の属人化を防ぐ。

Go/No-Goのタイミング設計

切替作業の中に「Go/No-Go判断ポイント」を複数設けることで、判断の粒度を下げられる。「データ移行完了後・旧系停止前」「旧系停止後・新系公開前」という二段階を設けると、各ポイントでの確認事項が明確になり、判断の根拠が記録として残る。このタイムライン設計を手順書とは別の「判断記録書」として持つプロジェクトは、問題発生時の合意形成が早くなる傾向がある。手順書は「何をするか」を示し、判断記録書は「何を確認してGoを出したか」を残す。この二つを混在させると、作業中に判断の根拠が流れて消えてしまう。

判断基準を数値で合意する

ロールバック基準を「エラーが多い」という定性表現で持つと、当日の判断が属人化する。事前に「HTTP 5xxエラー率が1分間で3%を超えた場合」「応答時間の95パーセンタイルが2秒を超えた状態が5分継続した場合」のように数値で定義しておくと、モニタリングの観測値が基準に達した時点で即座に動ける。この数値は、ステージング環境で事前計測した平常値を基準に設定するのが現実的になる。判断基準の合意に利害関係者を設計フェーズで巻き込んでおくと、当日に異議が出にくくなる。基準を後から変更するときの手続きも、事前に決めておくとよい。

データ同期の停止点と差分反映をどう設計するか

切替直前の同期停止点をどこに置くか

データ移行を伴う切替では、「どの時点のデータを新系に持ち込むか」という停止点の設計が核心になる。全量移行が完了した後も旧系への書き込みが続いていれば差分が生じる。この差分をゼロにするためには、旧系の書き込みを止めるか、差分を継続的に反映し続けるかのどちらかを選ぶことになる。書き込みを止める場合は業務停止時間が発生し、差分反映を続ける場合は同期の整合性チェックコストが発生する。どちらを選ぶかは、業務が許容できるダウンタイムと同期設計の実装工数のトレードオフで決まる。この判断を後回しにすると、切替直前に設計変更が発生し、テストが巻き戻る。

差分反映の方式と整合性確認の設計

差分反映の代表的な方式は、ログベース（Change Data Capture）による継続同期と、タイムスタンプ差分による定期同期の二つになる。CDCは高精度だが導入コストが高く、既存システムがバイナリログを出力していない場合は追加設計が必要になる。タイムスタンプ差分は実装が比較的容易だが、更新タイムスタンプが存在しないレコードや削除レコードの同期が漏れやすい。いずれの方式でも、切替前に「旧新のレコード件数一致」と「チェックサムの照合」を実施してから切替に進む手順を設計に含めることが必要になる。手を動かす実装の詳細は本番設計と並行して進めるが、方式の選定は設計フェーズで確定させる。

並行稼働中の書き込み競合の扱い

並行稼働期間中に旧新両系への書き込みが発生する構成では、同一データへの競合書き込みが生じるリスクがある。これを避ける設計として広く採られるのは、「書き込みは常に一方に集約し、もう一方は読み取り専用として扱う」というものになる。この設計を徹底しないと、切替後に旧新で異なるデータが存在する状態が生まれ、どちらを正とするかの判断に多大な工数がかかる。規模の大きいシステムでは、この後処理だけで数十人日に及ぶこともある。競合書き込みの許容は、切替設計の中でも特に注意が必要なアンチパターンの一つになる。

並行稼働を引っ張って二重運用が固定化する境界

並行稼働の延長が生む管理コストの実態

並行稼働期間が当初の想定を超えて延長されると、運用チームは二つのシステムを維持し続けるコストを負担することになる。インフラ費用の二重発生に加え、障害対応・監視・パッチ適用も二系統で行う必要が出てくる。20台規模のサーバー構成が旧新両系で存在する場合、運用工数は単純に倍増しない代わりに、差異の追跡・同期確認・整合性チェックという付加的な作業が上乗せされ、単系運用の1.5倍から2倍の工数がかかる状態が続くことがある。並行稼働の延長は「リスク回避」に見えるが、別種の運用リスクと疲弊を積み上げている点を認識する必要がある。

延長判断の境界をどこに置くか

並行稼働の延長判断は、多くの場合「まだ問題が出るかもしれない」という心理的な保留から始まる。問題を確認するための十分な期間を設計段階で定義しておかないと、延長基準が曖昧なまま長期化する。「新系で月次バッチが2サイクル正常に完了したら旧系を停止する」「新系での累計取引件数が10,000件を超えたら旧系を切り離す」といった具体的な完了基準を持つプロジェクトは、延長の歯止めが効く。完了基準を数値で持つことが、関係者間の合意形成を容易にする前提条件になる。期限が近づくにつれて、旧系への依存を自然に減らす設計の動線が生まれる。

終了を設計の一部として組み込む

並行稼働の終了を意思決定だけに委ねると、終了判断が先送りになりやすい。アーキテクチャ面での対策として、旧系環境のリソースに対して意図的な期限を設ける方法がある。クラウド環境であれば、旧系インスタンスに停止スケジュールを組み込み、期限の到来を周知することで終了に向けた動きを自然に促せる。オンプレミス環境でも、旧系の保守契約や電源供給の期限を事前に設定することで同様の効果が得られる。「終了を設計の一部として扱う」という思想が、二重運用の固定化を防ぐ。終了設計を後から追うより、切替設計と同時に定義する方が現場の合意も取りやすい。

カットオーバー設計チェックフレーム

切替設計のレビューおよび当日の判断ポイントの確認に使えるチェック項目を、方式選定フェーズ・当日判断フェーズ・切替完了後の三段階に整理した。

方式選定フェーズのチェック項目

1. 切替対象システムへの書き込みを一時停止できるか（停止可能な時間幅を含め）確認したか
2. 利用者数・取引頻度・ピーク時間帯を定量的に把握しているか
3. 旧新システムのスキーマ互換性を確認し、非互換の箇所を洗い出したか
4. ロールバックに必要な時間（手順・確認・切り戻し完了まで）を試算したか
5. メンテナンスウィンドウの確保可能時間が、切替所要時間とロールバック所要時間の合計を上回るか
6. 並行稼働を選んだ場合、終了基準（数値）を定義しているか
7. 段階移行を選んだ場合、各フェーズの完了基準と次フェーズへの移行判断を定義しているか
8. 方式の前提条件を文書化し、利害関係者の合意を取っているか

当日Go/No-Go判断フェーズのチェック項目

1. ロールバックの判断者・判断補助者（計測担当）・実行担当者の三ロールを事前に周知しているか
2. Go/No-Go判断ポイントを作業タイムラインの中に明示しているか
3. ロールバック発動のトリガー条件（数値）をモニタリングダッシュボードで確認できる状態か
4. 切替直前のデータ一致確認（件数照合・チェックサム）の手順が手順書に含まれているか
5. 各判断ポイントでの確認結果を記録する判断記録書を用意しているか
6. 技術判断を現場で取れない場合のエスカレーション先と連絡手順を明示しているか

切替完了後のクローズ判断チェック項目

1. 新系での初期動作確認（ヘルスチェック・代表的な業務トランザクション）を完了したか
2. 並行稼働の場合、旧系停止の完了基準に達したことを定義した条件で確認しているか
3. 旧系のリソース（インスタンス・ストレージ・ライセンス）の停止・返却スケジュールを決めているか
4. 切替後の監視強化期間（例：切替後72時間の集中監視体制）を設定しているか
5. 切替結果の振り返り（タイムラインの実績と計画の差分・判断ポイントでの所見）を記録しているか