無停止移行とカットオーバー当日 — 切り戻し判断基準まで

「このシステムは止められない」と言われた瞬間に、移行の難易度は一段上がります。技術そのものより、当日の段取りと「戻すか進むか」の判断で勝負が決まるからです。この記事は、ブルーグリーンとDBの継続レプリケーションで停止時間を最小化する手法から、カットオーバー当日のタイムライン・役割分担、そして切り戻しを数値で事前に決める方法までを、百貨店POSのような止められない現場の経験を踏まえて整理します。

「無停止移行」という言葉は、正確には二つの意味を含みます。ひとつは本当に一秒も止めないこと。もうひとつは数分〜数十分の計画停止に抑えて、利用者への影響を実質ゼロに近づけることです。前者は難易度もコストも跳ね上がるため、まず「どちらを本当に求められているのか」を握るところから始めます。多くの現場では、深夜帯の数分停止が許容されるなら、それを前提にした設計のほうが安全で確実です。移行全体の進め方はオンプレからAWSへの移行フローに、方式選定の勘所は移行方式を決める5つの判断にまとめています。この記事はその最終フェーズ、カットオーバー当日に絞った実務編です。

01「止めない」の定義を先に握る

止めないための技術は、突き詰めればコストと複雑さのトレードオフです。だからこそ、要件を数字で握らずに設計へ入ると、過剰にも過小にもなります。最初の打合せで必ず確認するのは次の3点です。

許容停止時間（ダウンタイム）：完全ゼロか、5分か、30分か。深夜のバッチ空き時間に何分取れるか。
許容データ損失（RPO）：切替の瞬間に取りこぼしを許すか、1件も落とせないか。決済系はほぼ後者です。
切替の可逆性：切り戻せる状態をいつまで維持するか。旧環境を何日残すか。

この3点はDR設計のRPO/RTOと地続きです。DR側の考え方はマルチリージョンDRの設計も併せて読むと、切替と復旧が一本の線でつながります。

現場のコツ：「止められない」と言う担当者に、では過去の計画停止は何分だったかを聞くと、たいてい深夜に30〜60分は取れていた実績が出てきます。「無停止」は要望であって制約ではないことが多い。ここを丁寧にほぐすと、設計が一段シンプルになります。

02ブルーグリーン — 新環境を隣に建てて切替える

止めずに移す基本形は、旧環境（ブルー）を動かしたまま新環境（グリーン）をAWS側に構築し、準備が整った瞬間に流れを切り替える方式です。切替のスイッチとして代表的なのが、DNS（Amazon Route 53）による向き先の変更と、ロードバランサ（ALB）配下でのターゲット切替です。

DNS切替：切替対象のレコードを新環境のエンドポイントへ向け替えます。事前にTTLを60秒程度まで下げておくのが鉄則です。TTLが長いままだとクライアント側のDNSキャッシュが残り、切替後も旧環境へトラフィックが流れ続けます。ただしキャッシュはこちらで完全には制御できないため、旧環境は「もう来ていない」と監視で確認できるまで落とさないこと。
加重ルーティング（Weighted Routing）：Route 53で新旧に重み付けし、10%→50%→100%と段階的に寄せられます。一気に全振りせず、各ステップで監視して問題がなければ次へ進む。いわゆるカナリア的な寄せ方で、影響範囲（ブラストradius）を小さく保てます。

どちらを採るかは、切り戻しの速さで決めます。DNSは巻き戻しても伝播にTTL分の時間がかかる一方、ALBのターゲット切替やRoute 53の重み変更はより速く戻せます。「戻す速さ」は当日の判断で効いてくるので、方式選定の段階から意識してください。

03DBの継続レプリケーション — DMS CDCで差分を追い続ける

アプリは隣に建てれば済みますが、データベースはそうはいきません。移行元は本番として更新され続けているからです。ここで使うのがAWS DMS（Database Migration Service）の継続レプリケーション（CDC：Change Data Capture）です。DMSの標準的な進め方は「フルロード＋CDC」で、まず既存データを一括コピーし、その後は移行元DBのトランザクションログから変更差分を拾い続けて新DBへ流し込みます。

図：フルロードで既存データを移し切り、CDCで差分を追い続ける。レプリケーションラグがほぼゼロになった瞬間にDNSを切替える。

ポイントは「レプリケーションラグ（同期遅延）がほぼゼロに収束した瞬間」を切替の合図にすることです。CDCはリアルタイム同期ではなく、移行元の負荷・ネットワーク・レプリケーションインスタンスのリソース・移行先の取り込み能力によって遅延が変動します。特に注意すべきは移行元の長時間トランザクションで、これはカットオーバー直前にラグを跳ね上げる典型的な原因です。当日はできる限りバッチや大量更新を止めた状態で切替に臨みます。DMS本体の選び方や制約はDB移行ツールとDMSの使いどころに、移行後の性能確認は移行後の性能問題にまとめています。

現場のコツ：CDCで拾えないもの（シーケンスの現在値、一部のDDL、ラージオブジェクトの扱い等）は必ず存在します。「DMSが全部運んでくれる」と信じ切らず、切替直前に手当てする項目のチェックリストを別建てで用意してください。ここを詰め切れているかが、当日の事故率を大きく分けます。

04リハーサル — 本番と同じ手順を、本番前に通す

カットオーバーで一番効くのは、当日の巧みさではなく事前リハーサルの回数です。手順書を頭で追うのと、実際にコマンドを叩いて時間を計るのとでは、見えてくるものがまるで違います。リハーサルで確認するのは次のような項目です。

所要時間の実測：各作業が手順書どおりの時間で終わるか。DNS切替後の疎通確認まで含めて計る。
切り戻しの実測：戻す手順も必ず一度は通す。「戻せるはず」と「戻したことがある」は別物です。
データ整合性の検証：新旧DBで件数・チェックサム・主要テーブルの突き合わせを行う手順を固める。
役割と合図の確認：誰がどのコマンドを叩き、誰が「GO/NO-GO」を宣言するか。連絡経路が実際に機能するか。

リハーサルは最低2回、可能なら本番同等のデータ量で通します。1回目は手順の穴出し、2回目はタイムラインの精度出しです。ここで洗い出した「想定外」こそが、当日を救います。

05カットオーバー当日 — タイムライン・役割・判定ポイント

当日は時刻・作業・担当・判定を1枚に落とした進行表で動きます。誰が何をいつ叩き、どこで立ち止まって判断するかを、全員が同じ紙で共有している状態を作ります。

図：当日は「最終確認 → 書込停止・最終同期 → 切替・スモークテスト → 監視強化」の順に進み、各GO/NO-GOで進むか戻すかを判定する。

進行表で守るべき原則は3つです。第一に、判定ポイント（GO/NO-GO）を明確に置くこと。「なんとなく進む」を許さず、決められた人が決められた基準で宣言します。第二に、書込停止から切替完了までの時間を最短に設計すること。ここが実質的なダウンタイムです。第三に、役割を固定すること。作業する人、確認する人、判断する人、外部と連絡する人を分けます。特に「判断する人」は作業に手を出さず、全体を見て冷静にGO/NO-GOを宣言する役に専念させます。

現場のコツ：当日の合言葉は「疑わしきは戻す」です。人は準備してきた作業を完遂したい心理が働き、微妙な兆候を見て見ぬふりをしがちです。だからこそ、次のセクションの数値基準を事前に決めておく。当日その場で「これは切り戻すほどか？」と議論を始めた時点で、もう判断は遅れています。

06切り戻しの判断基準を、事前に数値で決める

切り戻し（ロールバック）で最悪なのは、当日その場で「戻すべきか」を議論することです。焦りと当事者意識が判断を鈍らせ、傷を広げます。だから基準は事前に数値で確定し、進行表に明記しておく。「この条件に触れたら、議論せず戻す」というラインを引くわけです。

図：切替直後は事前に決めた数値基準（エラー率・応答時間・整合性）で判定し、どれか一つでも外れたら議論せず切り戻す。

基準に含める代表的な指標は次のとおりです。いずれも「いつまでに、どの値を超えたら戻す」という形で、時間と閾値をセットで決めます。

エラー率：切替後○分以内に5xxエラーが○%を超えたら戻す。平常時のベースラインを事前に測っておくのが前提です。
応答時間：主要トランザクションのレイテンシがベースラインの○倍を超えたら戻す。
データ整合性：新旧DBの主要テーブルで件数・チェックサムに差異が出たら戻す。ここは基本ゼロ許容です。
復旧の期限（リカバリの締切）：切替後○分たっても正常確認が取れなければ、原因が特定できていなくても戻す。「あと少しで直りそう」を許さないための時間の壁です。

閾値は、リハーサルで測ったベースラインと、業務側が許容できる影響から逆算して決めます。監視の閾値設計そのものの考え方は監視設計の型、初期の監視構築はCloudWatch監視のはじめ方が参考になります。

07切替後の監視強化期間 — ここまでが移行

DNSを切替えて疎通が取れても、移行は終わりではありません。DNSキャッシュの残りで旧環境へ来るトラフィックが消えるまで数十分〜数時間かかることもあり、旧環境は「もう来ていない」と監視で確認できるまで落とさないのが鉄則です。加えて、切替直後は平常時より監視の目を厚くする監視強化期間（ハイパーケア）を設けます。

旧環境の温存期間を決める：切り戻し可能な状態を、業務の1〜2サイクル（日次・月次バッチが一巡するまで）は維持します。夜間バッチや月末処理は、切替後に初めて新環境で走るタイミングで問題が出やすいためです。
アラートの閾値を一時的に厳しく：強化期間中は通常より低い閾値でアラートを上げ、小さな兆候を早く拾います。バッチの監視・再実行の考え方はバッチの監視と再実行設計にまとめています。
正式完了の宣言：あらかじめ決めた期間・条件をすべてクリアしたら、正式に移行完了を宣言し、旧環境の撤去計画に進みます。ここを曖昧にすると、いつまでも旧環境が残りコストが漏れ続けます。

現場のコツ：百貨店POSのような止められない現場では、全店を一度に切替えず店舗単位・機能単位で段階的に寄せることが多いです。1店舗で数日運用して安定を確認してから次へ。段階移行は所要期間こそ延びますが、事故ったときの影響が1店舗に閉じるため、経営が安心して判断できます。「速さ」より「戻せる小ささ」を優先するのが、止められない現場の作法です。

—まとめ

無停止移行の勝負どころは、派手な技術ではなく段取りと判断です。要点を整理します。

まず「止めない」の定義（許容停止時間・RPO・可逆性）を数字で握る。
ブルーグリーンで新環境を隣に建て、DNS切替やRoute 53の加重ルーティングで段階的に寄せる。TTLは事前に下げる。
DBはDMSのフルロード＋CDCで差分を追い続け、レプリケーションラグがほぼゼロになった瞬間に切替える。
リハーサルは最低2回。切り戻しも必ず一度は通す。「戻せるはず」を「戻したことがある」に変える。
当日はタイムライン・役割・GO/NO-GOを1枚に。切り戻し基準は事前に数値で確定し、疑わしきは戻す。
切替後は監視強化期間を設け、旧環境は「もう来ていない」と確認できるまで温存する。

止められないシステムほど、当日の胆力より事前の設計がものを言います。EMWは百貨店POSをはじめ、止められない現場の段階移行とカットオーバーを実際に手を動かして支えてきました。移行全体の地図はオンプレからAWSへの移行フローから、個別の相談はお問い合わせからどうぞ。

止められないシステムのカットオーバー設計と切り戻し基準づくりは、EMWの実務経験が最も活きる領域です。当日の段取りに不安がある方は、お問い合わせからお気軽にご相談ください。

相談する

← ブログ一覧へ戻る