LASSIC Media らしくメディア
デプロイ・リリース戦略の外注｜無停止リリース設計
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- カナリア・ブルーグリーン・ローリングの3戦略は、それぞれダウンタイムリスク・切り戻し速度・インフラコストで明確に使い分けられます。
- デプロイ戦略を誤ると本番障害時の切り戻しが数時間に及び、サービス停止による売上損失に直結します。
- 体制が整っていない場合に外注する際は、デプロイ戦略の設計・CI/CD組み込み・観測体制の3点をスコープに含めることが成果につながります。
目次
デプロイ戦略とは何か：リリース事故を防ぐ設計思想
デプロイ・リリース戦略とは、新バージョンのアプリケーションを本番環境へリスクを抑えて展開するための手順・方式の設計を指します。単に「ファイルを差し替える」作業ではなく、ダウンタイムをゼロに近づけ、問題が発生した際の切り戻し（ロールバック）を迅速に行えるようにする仕組みの全体設計です。
Googleが公開しているSREの実践（Google SRE Book, 2016年）では、リリースエンジニアがSREと協力して「変更をカナリア化する戦略」を開発し、本番環境の一部のみへ段階的に展開する手法が採用されていると記載されています*1。
デプロイ戦略を設計せずに本番リリースを行うと、障害が発生した際の切り戻しに長時間を要します。Webサービスやオンラインシステムでは、その間の売上損失・信頼毀損がリリースコストを大きく上回る場合があります。
ダウンタイム・切り戻し困難が招く本番事故のリスク
デプロイ戦略を「一斉更新（All-at-Once）」で行う場合、問題が発生したときの影響範囲は全サーバー・全ユーザーに及びます。AWSのブルーグリーンデプロイメントに関するホワイトペーパー（2023年）は、従来の一括デプロイについて「以前のバージョンへの再展開でロールバックするため時間がかかり、その間アプリケーションが長時間利用不可になる」と指摘しています*2。
具体的なリスクとして、以下の3点が挙げられます。
- 全サーバー同時更新：新バージョンにバグがあった場合、全ユーザーが影響を受けます。ECサイトであれば決済停止・カートロストが直接売上に響きます。
- データベーススキーマ変更の非互換：アプリとDBのバージョンが一時的に混在するローリング更新中に、DBスキーマが新旧両方と非互換になるケースがあります。これが起きると切り戻しだけでは修復できません。
- ロールバック手順の未整備：デプロイ前にロールバック手順を設計していないと、本番障害時に対応方針が定まらず、復旧に数時間を要します。
デプロイを内製で行う場合、戦略設計にはCI/CDエンジニア・インフラエンジニア・SRE（サービス信頼性エンジニア）の知識が必要です。これらを担える人材が社内にいない場合、デプロイ設計ごと外注することが現実的な選択肢になります。
主要デプロイ戦略4種の仕組みと使い分け
現在主流のデプロイ戦略は、ローリング・ブルーグリーン・カナリア・フィーチャーフラグの4種類です。それぞれの仕組みと向き不向きを理解することが、適切な戦略選定の出発点になります。
ローリングアップデート：段階的な差し替えで停止を最小化
ローリングアップデートは、サーバー（インスタンス）を数台ずつ順番に新バージョンへ差し替えていく手法です。全体のうち常に一定割合を稼働させたままアップデートを進めます。
AWSのCodeDeployでは、EC2/オンプレ向けにローリング系の設定が標準提供されています。`CodeDeployDefault.HalfAtATime`は「半数ずつ更新し、半数以上の成功でデプロイ成功とみなす」設定です*3。`CodeDeployDefault.OneAtATime`は「1台ずつ更新する」影響範囲を最小化した設定で、デプロイ中も残りのインスタンスが本番トラフィックを受け続けます。
利点はインフラコストの追加が少ない点で、既存のサーバー群をそのまま使います。欠点はデプロイ中に新旧バージョンが混在することです。アプリケーションが新旧間で非互換なAPIを持つ場合、混在期間中にエラーが発生するリスクがあります。
ブルーグリーンデプロイ：本番環境を2系統で切り替える
ブルーグリーンデプロイは、現行バージョン（Blue環境）と並行して新バージョン（Green環境）を別途立ち上げ、テスト完了後にトラフィックをBlueからGreenへ一括切り替える手法です。
AWSのBlue/Greenデプロイに関するホワイトペーパー（2023年）は「ブルーグリーンデプロイはほぼゼロダウンタイムとロールバック能力を提供する。根本的な考え方は、異なるバージョンのアプリケーションを実行する2つの同一環境間でトラフィックを切り替えることにある」と定義しています*2。
切り戻しは、ロードバランサーのトラフィックをBlue環境に戻すだけで完了します。これがローリングとの大きな違いです。欠点は、Green環境のインフラを別途用意するコストが発生する点です。クラウド環境ではオートスケールを活用して短時間だけGreen環境を起動し、移行完了後にBlue環境を廃棄するアプローチでコストを抑えられます。
カナリアデプロイ：少量のトラフィックで段階的に検証
カナリアデプロイは、新バージョンへのトラフィックを最初は少量（例：10%）に絞り、問題がなければ段階的に増やしていく手法です。Google Cloud Deployの公式ドキュメントは「カナリアデプロイとは、アプリケーションの段階的デプロイであり、最初はインフラの一部にのみデプロイされる」と説明しています*4。
AWSのCodeDeployでは、ECS（コンテナ）とLambdaに対してカナリア設定が標準提供されています。たとえば`CodeDeployDefault.ECSCanary10Percent5Minutes`は「最初の5分間はトラフィックの10%だけを新バージョンへ流し、問題がなければ残り90%を移行する」という設定です*3。同様にLambda向けにも`CodeDeployDefault.LambdaCanary10Percent5Minutes`等が用意されています。
利点は、問題発生時の影響範囲を限定できる点です。10%のユーザーで問題が検出された場合、残り90%には影響が及びません。欠点は、モニタリング基盤が整っていないと「カナリアが問題を検知できないまま全量移行してしまう」リスクがある点です。
フィーチャーフラグ：コードを変えずに機能を切り替える
フィーチャーフラグ（Feature Flag / Feature Toggle）は、設定値の変更だけでアプリケーションの機能をON/OFFする手法です。Martin Fowlerは「フィーチャーフラグはコードを変更せずにシステムの動作を変更できる強力な技術である」と説明し、リリースフラグ・実験フラグ・操作フラグ・権限フラグの4種類に分類しています*5。
Google SRE Bookも「新機能を実装する変更は、その機能を設定するフラグ設定と共にリリース可能であり、バイナリを再構築せずに設定値を変更できる」と記載しています*1。
フィーチャーフラグを使うと、コードは本番に展開済みでも機能は特定ユーザーにのみ公開する「段階的ロールアウト」が可能になります。デプロイとリリースを分離できるため、深夜のデプロイ後に翌朝機能を有効化するといった運用ができます。
| 戦略 | ダウンタイム | 切り戻し速度 | インフラコスト | 主な用途 |
|---|---|---|---|---|
| ローリング | ほぼなし | 中（再ロールアウト必要） | 低い | 日常的なアップデート・ステートレスなサービス |
| ブルーグリーン | ほぼゼロ | 速い（トラフィック切替のみ） | 高い（2環境分） | 重要リリース・DB移行を伴う変更 |
| カナリア | ほぼゼロ | 速い（トラフィック戻すのみ） | 中程度 | 影響範囲を絞って本番検証したいリリース |
| フィーチャーフラグ | なし | 即時（フラグOFF） | 低い | 機能の段階公開・A/Bテスト・緊急無効化 |
切り戻し・ヘルスチェック・段階的公開の設計
デプロイ戦略を選んだだけでは不十分です。実際に本番で機能させるには、切り戻し手順・ヘルスチェック設定・段階的公開の基準を事前に設計しておく必要があります。
切り戻し（ロールバック）手順の事前設計
AWSのホワイトペーパー（2023年）は「トラフィックをBlue環境に戻すことがロールバックの基本」であり、「ブルーグリーンデプロイではデプロイ中のいつでもBlue環境にロールバックできる」と述べています*2。ポイントは「ロールバックの判断基準と手順をデプロイ前に決めておく」ことです。
切り戻し設計の要素は3つです。
- 判断基準の定義：エラーレートが何%を超えたら、レスポンスタイムが何msを超えたらロールバックするかを数値で定めます。
- 自動ロールバックの設定：CodeDeployやArgo CDなどのツールは、ヘルスチェック失敗時に自動でロールバックするよう設定できます。
- DBマイグレーションの互換性担保：スキーマ変更を新旧アプリ両方に対して互換にする「後方互換マイグレーション」を実装しておくと、アプリのロールバック後もDBが壊れません。
ヘルスチェックの設計
ヘルスチェックは、新バージョンが正常に動作しているかをデプロイパイプラインが自動検証する仕組みです。HTTPエンドポイントへのGETリクエストに200レスポンスが返るかを確認する「Liveness/Readinessプローブ」が標準的です。
チェック項目として、HTTPステータスコード・レスポンスタイム・エラーレート（4xx/5xx比率）・メモリ/CPU使用率が基本になります。カナリアデプロイでは、少量トラフィックの観測期間（5分・15分等）内にこれらが閾値を超えなければ次フェーズへ進む設計にします。
段階的公開の基準設定
段階的公開はトラフィックの割合を「10% → 50% → 全量」のように増やしていく際に、各フェーズの「移行条件」を明示することが重要です。AWSのCodeDeployではECS向けに`CodeDeployDefault.ECSCanary10Percent5Minutes`（5分間10%観測後に90%移行）や`CodeDeployDefault.ECSLinear10PercentEvery3Minutes`（3分ごとに10%ずつ増やす）などの設定が標準提供されています*3。
Google Cloud Deployでは、Cloud Runへのカナリアデプロイで新旧リビジョンのトラフィック比率を50:50に設定し、検証後に全量へ切り替えるワークフローが公式ドキュメントに示されています*4。
CI/CDパイプラインへの組み込みと観測
デプロイ戦略は、CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインと連携させて初めて自動化・継続運用できます。手動でのデプロイはヒューマンエラーのリスクが高く、深夜障害時の対応速度も遅くなります。
パイプラインへの組み込み手順
典型的なパイプラインの構成は、コードプッシュ→CIビルド・ユニットテスト→アーティファクト生成→ステージング環境へのデプロイ→E2Eテスト→本番へのカナリア/ブルーグリーンデプロイ→ヘルスチェック→完全移行（or自動ロールバック）という流れです。
AWSのCodeDeployはEC2・ECS・Lambdaそれぞれに対してリニア・カナリア・一括のデプロイ設定を提供しており、CodePipelineと連携することで上記のパイプラインを構成できます*3。GitOpsの文脈ではArgo CDやFlux CDを使い、Gitリポジトリの状態をKubernetesクラスタへ自動反映する構成も普及しています。
観測（Observability）の設計
カナリアデプロイやブルーグリーンデプロイを機能させるには、新バージョンの動作をリアルタイムで観測できる体制が必要です。観測の3本柱はメトリクス（CPU・メモリ・レスポンスタイム・エラーレート）・ログ・トレースです。
これらが整っていない状態でカナリアデプロイを導入しても、「異常を検知できないまま全量移行してしまう」リスクが残ります。観測基盤の整備は、デプロイ戦略の実装と並行して進める必要があります。
デプロイ戦略を内製実装するのに必要なスキルと工数
ブルーグリーン・カナリアデプロイをCI/CDに組み込むには、以下のスキルを持つ人材が必要です。
- IaC（Infrastructure as Code）の知識：Terraform・AWS CDK等でインフラをコード化し、Blue/Green環境を自動構築する
- CI/CDツールの設定経験：CodePipeline・GitHub Actions・GitLab CI等でデプロイパイプラインを構築・管理する
- コンテナ・Kubernetesの運用知識：ECSやKubernetesのデプロイ設定・ヘルスチェック設計を行う
- 観測基盤の構築経験：CloudWatch・Datadog・Prometheus等でメトリクス収集・アラート設定を行う
これらを担えるエンジニアを複数名確保して体制を組むことは、多くの中堅・中小企業では難しい状況です。
体制が整っていない場合の外注の進め方
デプロイ戦略の設計・CI/CD構築・観測基盤の整備を外注する場合、発注範囲・評価基準・運用移管の3点を事前に整理することが成果につながります。
外注スコープの明確化：設計・実装・運用移管を分ける
外注スコープを曖昧なまま発注すると、「ツールは導入されたが運用手順がわからない」「ロールバック手順が文書化されていない」といったトラブルが発生しやすくなります。発注前に以下の3点を明示することを推奨します。
- 設計フェーズ：現状のデプロイ手順の整理・戦略選定・ヘルスチェック基準・ロールバック手順の設計書作成
- 実装フェーズ：CI/CDパイプライン構築・IaCによるインフラ定義・観測基盤のセットアップ
- 運用移管フェーズ：社内エンジニアへの手順説明・障害対応フローの文書化・ランブックの整備
ベンダー選定の評価軸：実績・技術スタック適合・元請体制
ベンダー選定では、3つの軸を確認することが重要です。
第一に、自社が利用するクラウド・コンテナ基盤での実績です。AWSのCodeDeployとECSを使うのか、KubernetesとArgo CDを使うのかによって、必要な知識は異なります。使用技術スタックの実績を具体的に確認します。
第二に、元請（プライムベンダー）として受託するかどうかです。複数のベンダーを使い分けると、設計責任の所在が曖昧になります。デプロイ戦略設計からCI/CD構築・観測基盤まで一貫して担当できる体制のベンダーを選ぶことで、責任分界点が明確になります。
第三に、運用移管後のサポート体制です。初期構築だけでなく、変更発生時の対応・ツールのバージョンアップ対応まで含めた契約が望ましいです。
RFP（提案依頼書）に含めるべき要件
外注する際のRFPには、現状のデプロイ方法・インフラ構成（AWS/GCP/オンプレ等）・デプロイ頻度・障害時のRTO（目標復旧時間）の4点を記載することが基本です。RTOが4時間以内であればブルーグリーン、数十分以内であればカナリア＋自動ロールバックという選定の切り分けが生まれます。これが明示されていると、ベンダーが適切な戦略を提案しやすくなります。
まとめ：デプロイ戦略選定の3つの判断軸
本稿では、デプロイ・リリース戦略の設計について、事故リスク・主要4戦略・切り戻し設計・CI/CDへの組み込み・外注の進め方を整理しました。要点を3つに集約します。
第一に、切り戻し速度とコストのトレードオフで戦略を選ぶことです。ブルーグリーンは切り戻しが速い分インフラコストが高く、ローリングはコストが低い分切り戻しに時間がかかります。RTOと予算の両面から判断することが大切です。
第二に、観測基盤なしのカナリアは機能しないという点です。カナリアデプロイはメトリクス・ログ・アラートが整っていて初めて「問題の早期検知」という本来の効果を発揮します。ツールの導入と観測基盤の整備は並行して進める必要があります。
第三に、設計・実装・運用移管の3フェーズを外注スコープに含めることです。実装だけ外注して運用手順が残らないケースは、将来の担当者交代時に大きなリスクになります。ランブック（運用手順書）の整備まで契約に含めることが重要です。
よくある質問
ブルーグリーンデプロイとカナリアデプロイはどう使い分けますか？
ブルーグリーンデプロイは「全量切り替えを素早く行い、問題があれば即座に戻す」用途に向いています。カナリアデプロイは「少量のトラフィックで本番環境を試し、問題がなければ段階的に増やす」用途に向いています。DB移行を伴う大規模リリースや明確なRTOがある場合はブルーグリーンを、高頻度の機能リリースで本番の反応を確かめながら進めたい場合はカナリアを選ぶ判断が実務上多く見られます。
フィーチャーフラグはデプロイ戦略の代替になりますか？
フィーチャーフラグはデプロイとリリースを分離する手段であり、デプロイ戦略（ローリング・ブルーグリーン等）の代替ではなく補完的に使うものです。コードを本番に展開した後、機能の公開タイミングを制御する用途に向いています。Martin Fowlerはフィーチャーフラグについて「コードを変更せずにシステムの動作を修正できる強力な技術である」と述べる一方、「フラグは管理コストを伴う在庫であり、その在庫はできるだけ少なく保つべきだ」として、不要になったフラグを積極的に削除する運用を推奨しています*5。フラグが増えすぎるとコードの複雑性が増すため、定期的な整理が必要です。
デプロイ戦略の外注費用はどのくらいかかりますか？
費用はスコープ・使用技術・期間によって大きく変わるため、公的機関や業界団体による一般的な相場データは現時点で公表されていません。費用の主な変動要因は、現状の環境調査から設計・実装・運用移管まで含めるかどうか、AWS/Kubernetesなどの技術スタックの難易度、観測基盤（モニタリング）の整備が含まれるかどうかです。まずRFP（提案依頼書）に現状のデプロイ方法・インフラ構成・RTOを明記し、複数のベンダーから見積もりを取ることを推奨します。
小規模なWebサービスでもカナリアデプロイは必要ですか？
サービス規模よりも「デプロイ失敗時の影響範囲」で判断することを推奨します。ユーザー数が少なくても決済・認証など障害時の影響が大きい機能を持つサービスでは、カナリアデプロイやブルーグリーンデプロイを検討する価値があります。リリース頻度が月1回程度で影響範囲が限定的なサービスであれば、まずローリングアップデート＋ヘルスチェック自動ロールバックから始め、リリース頻度や規模が大きくなった段階でカナリアへ移行するアプローチが現実的です。
AWSとGoogle Cloudではデプロイ戦略のサポート内容が異なりますか？
はい、差があります。AWSのCodeDeployはECS・Lambda・EC2の3基盤に対してカナリア・リニア・一括の設定を標準提供しており、`CodeDeployDefault.ECSCanary10Percent5Minutes`のように設定名で即座に利用できます*3。Google Cloud Deployはカナリアと標準デプロイの2戦略を公式に提供しており、Cloud Runへの段階的トラフィック移行が公式ドキュメントで説明されています*4。どちらのクラウドでも主要戦略は実装可能ですが、設定の詳細やツールの組み合わせが異なるため、使用クラウドの実績があるベンダーへ相談することを推奨します。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Google「Site Reliability Engineering（SRE Book）- Release Engineering」（2016年）https://sre.google/sre-book/release-engineering/
- *2 出典：Amazon Web Services「Blue/Green Deployments on AWS（Whitepaper）」（2023年）https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/introduction.html
- *3 出典：Amazon Web Services「Working with deployment configurations in CodeDeploy」AWS公式ドキュメント（2024年）https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html
- *4 出典：Google Cloud「Deployment strategies — Google Cloud Deploy」公式ドキュメント（2024年）https://cloud.google.com/deploy/docs/deployment-strategies
- *5 出典：Martin Fowler「Feature Toggle（aka Feature Flags）」martinfowler.com（2017年）https://martinfowler.com/articles/feature-toggles.html
