デプロイ戦略の選定 — ローリング/ブルーグリーン/一括の使い分け

デプロイ戦略の選定は、「サービスを止めるか止めないか」という二択ではなく、許容停止時間・切り戻し速度・インフラコスト・セッション設計の四軸で判断する設計行為です。一括・ローリング・ブルーグリーンそれぞれに得意な構成と不得意な構成があり、要件を整理しないまま「無停止が正義」と選んだ結果、運用コストが倍増した事例は現場で珍しくありません。この記事では、構築担当者が選定を誤りやすいポイントを先に整理した上で、判断軸を体系化します。

「止めて入れ替え」しか選択肢がない構成の落とし穴

計画停止が組織慣性になるとき

深夜メンテナンス窓を毎月設定し、その時間帯にサービスを停止してデプロイする運用が定着した組織では、担当者が交代した後も「夜間停止でデプロイするのが普通」という慣行だけが残ることがあります。サービスの規模が10台から40台超に拡大しても同じ手順が踏襲され、停止影響が実際には広がっているにもかかわらず、停止窓をただ延長して乗り切るケースが報告されています。問題は計画停止そのものではなく、「停止を前提とした設計が積み重なること」にあります。依存サービスのタイムアウト設定や外部APIの再試行ロジックが停止前提で調整されると、後からローリングデプロイへ移行しようとした際に、それらの前提をすべて洗い直す工数が発生します。

一括デプロイが隠すリスクの構造

一括デプロイは全インスタンスに同時に新バージョンを適用するため、問題が起きたときの影響範囲が最大になります。本番環境の全台に適用した後に障害に気づくと、影響を受けるユーザーは100%です。切り戻しも全台ロールバックを意味するため、復旧まで停止が継続します。とくに長期間変更を蓄積した後の大規模更新では、ステージング環境で問題が出なくても、本番の実トラフィック・実データ量・実ネットワーク遅延の組み合わせで初めて再現するバグが顕在化しやすく、その時点で全台が新バージョンに置き換わっていると安全に戻れる手段が限られます。

「停止窓」依存が積み上げる設計債務

停止を前提に設計された構成は、無停止化の難易度を年々高めていきます。データベースのスキーマ変更がマイグレーションスクリプト一本で行われ、ロールバックスクリプトが存在しない構成でローリングデプロイへの移行を検討すると、まずDB変更の分割設計から着手しなければならず、戦略の切り替えだけでは済まなくなります。半年分の変更を一括で含んだデプロイバイナリが当たり前になっている場合、変更の粒度を細かくする文化変革も同時に必要になり、構築担当者が「デプロイ戦略を変えようとして初めて見えてくる」債務の大きさに直面するケースがあります。

各デプロイ戦略が向く構築・向かない構築

一括デプロイが合理的な場面

一括デプロイが適切に機能するのは、計画停止が許容されているサービス・単一インスタンス構成のバッチサーバー・社内限定ツール系システムです。利用者が社内に限定されており、深夜帯の1時間停止が事前告知で受け入れられるなら、余分なインフラを持たず単純な手順でデプロイできる一括方式には合理性があります。デプロイ頻度が月1〜2回以下で変更範囲が大きい場合も、ローリングやブルーグリーンへの投資対効果が低くなる傾向があります。変更の粒度が小さくデプロイ頻度が高いサービスほど、無停止戦略への移行投資を回収しやすくなります。

ローリングアップデートが真価を発揮する条件

ローリングアップデートは複数インスタンスを順番に入れ替えることで停止を発生させずにデプロイする戦略です。ただし、アプリケーションが「旧バージョンと新バージョンが混在して同時に稼働する状態」に耐えられることが前提になります。APIのレスポンス形式が後方互換を保っていること、セッションが特定インスタンスに依存しないこと、DBスキーマ変更が前後のバージョン両方から読み書き可能な状態で進められること——これらが揃って初めてローリングが安全に機能します。ロードバランサー配下に複数台のWebサーバーがある構成で変更頻度が週1〜2回以上ある場合、ローリングは最もコスト対効果の高い選択肢になることが多いです。

ブルーグリーンデプロイが必要な場面

ブルーグリーンは本番環境(blue)と同等の構成をもう一セット(green)用意し、テスト完了後にトラフィックをまるごと切り替える戦略です。ローリングと異なり、切り替えの瞬間まで旧バージョンが完全に稼働しているため、問題があればDNS切り替えやロードバランサーの向き先変更だけで元に戻せます。デプロイ失敗時の復旧時間を秒〜分単位に抑える必要があるサービスや、デプロイ前に本番相当の環境で最終検証を行いたい要件がある構成で強みを発揮します。金融・決済・医療など、データ整合性と切り戻し速度が最優先される領域では、ブルーグリーンが事実上の標準選択肢となっています。

比較表: 停止時間・切り戻し速度・必要リソース

戦略	停止時間	切り戻し速度	必要リソース	向く構成・条件
一括デプロイ	デプロイ全体の時間（分〜数十分）	遅い（全台再デプロイ）	既存構成のみ	単一インスタンス・社内ツール・月1〜2回以下のデプロイ
ローリングアップデート	ほぼゼロ（インスタンス単位の瞬断は残る）	中程度（逆方向ローリングが必要）	既存構成のみ（波数分の余裕が必要）	複数台構成・ステートレスアプリ・週次以上のデプロイ
ブルーグリーン	ほぼゼロ（切り替え瞬間のみ）	速い（トラフィック切り替えのみ）	本番相当の二重環境	切り戻し速度最優先・本番前最終検証が必要な構成
カナリアリリース	ほぼゼロ	速い（トラフィック比率を下げるだけ）	トラフィック分割機能（LB/サービスメッシュ）	段階的な本番検証・影響範囲を絞って新機能を展開したい場合

状態・セッションをどう扱うかで変わる選定

ステートレス設計がデプロイ戦略の自由度を広げる

セッション情報をアプリケーションサーバーのメモリ上に保持するスティッキー構成では、ローリングデプロイ中に旧インスタンスが停止するとそこに結びついていたユーザーのセッションが失われます。解消するにはセッション情報をRedisやMemcachedなどの外部ストアに移す必要があり、それ自体がひとつの構築工数になります。反対にステートレスに設計されたサービスは、どのインスタンスがリクエストを処理しても結果が同じになるため、ローリング中のインスタンス入れ替えによる影響が生じません。ステートレス化はデプロイ戦略の選択肢を広げるだけでなく、オートスケーリングの設計も単純化します。

スティッキーセッションが及ぼす構成上の制約

ロードバランサーのスティッキーセッション機能で同一ユーザーを同一インスタンスに誘導している構成は、ローリングデプロイと根本的に相性が悪いです。当該インスタンスが入れ替え対象になると、接続中のユーザーのセッションを切る前に新インスタンスへ移行するドレイン処理が必要になり、設定の複雑さが上がります。ドレイン時間を30〜60秒に設定してもセッションを維持できない長時間処理（帳票生成・バッチ連携など）が存在する場合、ローリング中に処理が中断するリスクを受け入れるか、当該処理を別の方式で扱うかの判断を迫られます。この種の「部分的例外」が増えるほどデプロイパイプラインが複雑化し、人的ミスのリスクが高まります。

DBスキーマ変更がデプロイ方式の分岐点になる

セッション管理だけでなく、DBスキーマの変更もデプロイ戦略を制約します。ローリングでは旧バージョンと新バージョンが同時に稼働するため、どちらのコードからも問題なく読み書きできるスキーマ状態を「デプロイの中間状態」として設計しなければなりません。カラムのリネームや削除は、新名カラムを追加→コードが新名を使うよう新バージョンをデプロイ→旧カラムを削除という3フェーズで進めるのが基本方針です。この分割アプローチに不慣れな組織では最初の一件だけで通常の2〜3倍の設計工数がかかることもありますが、一度習慣化するとデプロイリスクが大幅に下がります。

切り戻し(ロールバック)前提の設計判断

ロールバックを「例外処理」ではなく「設計の一部」とする

「問題が起きたら戻す」という方針は正しいですが、「戻せるかどうか」を事前に設計していない構成では、実際に問題が起きたときに判断が混乱します。デプロイ前に「この変更を元に戻せるか」を具体的に確認することがロールバック前提の設計です。アプリケーションコードのロールバックは比較的容易ですが、DBスキーマ変更を含むと複雑さが跳ね上がります。ブルーグリーンであればblue環境を保持したままgreenへ切り替えるため、ロールバックはトラフィックをblueに戻すだけで完結します。ローリングの場合は逆方向ローリングが必要なため、その時間分だけ混在状態が続く点を事前に理解した上で戦略を選ぶことが重要です。

データベース変更がロールバック判断を左右する

マイグレーションによってデータが変換・削除された後にアプリケーションコードだけを旧バージョンに戻すと、DBが旧コードと不整合を起こします。この状態からの復元はバックアップからのリストアか逆変換スクリプトの実行になり、どちらも本番稼働中に数十分以上の処置時間を要する場合があります。「ロールバック不可能なデプロイ」と意識的に区別することが設計判断の質を高めます。ロールバック不可のデプロイは、ステージング検証をより厳密に行う、低トラフィック時間帯に限定するなどの補完的な判断と組み合わせることが必要です。

カナリアリリースをロールバック前提として位置づける

トラフィックの5〜10%だけを新バージョンに流し、問題がなければ段階的に割合を上げるカナリアリリースは、「本番トラフィックで検証しながら、問題があれば最小コストで戻せる」という設計思想に基づいています。ただしカナリアは、ロードバランサーやサービスメッシュによるトラフィック分割機能が前提になるため、既存構成にその機能がなければ基盤整備から始める必要があります。デプロイ戦略の選定と同時に、トラフィック制御の仕組みが現構成に存在するかを確認することが先決です。

過剰な無停止化でコストが跳ねる境界

ブルーグリーンの二重環境コストを正確に見積もる

ブルーグリーンデプロイは本番相当の環境をもう一セット保持することが前提です。クラウド環境でオンデマンドに起動・停止できる構成であれば、デプロイ時だけgreen環境を立ち上げて切り替え後にblueを廃棄するアプローチにより、常時二重化のコストを避けられます。しかし物理サーバーやライセンス課金のソフトウェアを含む構成では、green環境の維持コストが無視できない規模になります。20台構成のサービスにブルーグリーンを適用するとピーク時には40台分のリソースが必要になり、その費用対効果がデプロイ失敗リスクの低減と切り戻し速度要件によって正当化されるかどうかは、サービスの性質と停止インパクトで判断が分かれます。

ローリングの整備工数が運用コストに転化するケース

ローリングデプロイは二重環境を持たない代わりに、デプロイ中の混在状態を管理するコストがあります。旧バージョンと新バージョンの互換性を保つ実装規約の整備、デプロイパイプラインの自動化、モニタリングの強化——これらの初期整備工数はサービスの規模と変更頻度によって変わります。デプロイ頻度が月1〜2回程度で変更内容も小規模であれば、ローリングのための基盤整備に要する工数が、停止窓を維持するコストより大きくなる場合があります。「無停止化すべきか」の判断は、頻度×影響範囲×停止コストの積算で考えることが実務的です。

「無停止」要件の精査が最初の設計判断になる

「無停止でデプロイしたい」という要求の背景には、停止によって具体的に何が発生するかという実害があるはずです。その影響が「ユーザーがエラー画面を見る」なのか「取引が失敗して補填が必要になる」なのかで、許容できる停止時間と投資規模は大きく変わります。要件定義の段階で「許容停止時間」と「停止インパクト」を数値化しておくと、過剰な投資を防げます。「0秒停止が望ましい」という曖昧な要件だけで進んだ結果、ブルーグリーン導入の工数をすべてかけた後に実は深夜2〜4時台の30分停止でも許容できたと判明するケースは、現場でよくある話です。

デプロイ戦略選定チェックフレーム

以下の項目を上から順に確認することで、自環境に適したデプロイ戦略を絞り込めます。「手を動かす前に判断軸を固める」という考え方が、戦略選定の基本姿勢です。個別の設定手順や自動化ツールの操作については、ハンズオンのセミナーや実践ドキュメントで補完してください。

1. 許容停止時間を数値で定義できているか ——「できるだけ短く」は判断軸にならない。秒・分・時間単位で関係者の合意を取ることが先決。
2. 本番環境のインスタンス数と構成を把握しているか ——単一インスタンス構成なら一括デプロイが最初の選択肢。複数台かつロードバランサーありならローリングが現実的な出発点になる。
3. セッション管理がステートレスまたは外部ストアに移せているか ——スティッキーセッションのままローリングへ移行しようとすると、ドレイン設定の複雑さとともに例外処理が増える。
4. DBスキーマ変更を含むデプロイで旧・新バージョンが同時動作できるか ——できない場合はローリング適用前にスキーマ変更の分割設計が必要になる。
5. ロールバック手順が文書化されており、デプロイ担当者以外でも実行可能か ——口頭伝承のロールバック手順は緊急時に機能しない。「戻せる」ことと「誰でも戻せる」ことは別の問題として扱う。
6. ブルーグリーンを選ぶ場合、二重環境のコストを正当化できるか ——デプロイ頻度・停止インパクト・切り戻し速度要件の三点で判断する。物理環境とクラウド環境では見積もりが大きく異なる。
7. カナリアを検討する場合、既存LBまたはサービスメッシュがトラフィック分割に対応しているか ——基盤がなければカナリアより先に整備工数が発生する。その工数をローリング改善に充てた方が合理的なケースもある。
8. デプロイ失敗の検知をモニタリングで自動化できているか ——手動確認に頼ると混在状態が長引き、問題の発見と切り戻し判断が遅れる。自動アラートの整備はデプロイ戦略の変更と同時に進めることが望ましい。