CI/CD の流れは分かったのに、デプロイの段に「インプレース」「ブルー/グリーン」「カナリア」「リニア」と似た言葉が並び、どれをいつ選べばいいのか決められない。そんな場面でつまずきやすいのは、用語が1本の線上に並んでいると思い込むことです。実際には2つの軸が混ざっています。この記事では、軸を分けたうえで、戻しやすさと止められない度から方式を選ぶ理由を説明します。
この記事の結論
- 方式の違いは2軸です。①新旧を同じ場所で入れ替えるか、並べて置くか。②トラフィックを一度に切り替えるか、段階的に流すか。
- インプレースは簡単で追加の環境が要りませんが、戻すのは「前の版の再デプロイ」です。ブルー/グリーンは旧環境が残る間、トラフィックを戻すだけで戻せます。
- カナリアは最初の少量で様子を見て残りを一括、リニアは等間隔で等量ずつ増やします。どちらも「見るもの（アラーム）」があって初めて意味を持ちます。
- 選ぶ軸は、止められない度・戻しやすさ・費用（二重に持つ間の分）・見張る指標があるかの4つです。
- AWS CodeDeploy は EC2/オンプレミスでインプレースとブルー/グリーン、Lambda と ECS ではブルー/グリーン（canary / linear / all-at-once の移し方）を選べます。
デプロイ方式は何を選んでいるのか｜「新旧の置き方」と「切り替え方」の2軸
デプロイとは、新しい版のアプリケーションを動く場所に載せ、利用者のリクエストをそちらへ向けることです。そこで実際に決めているのは、次の2つです。
- 新旧の置き方: 動いているサーバーの中身を新しい版に入れ替えるのか（インプレース）、新しい環境を別に用意して並べて置くのか（ブルー/グリーン）。
- 切り替え方: 利用者のトラフィックを一度に全部移すのか（all-at-once）、少量から段階的に移すのか（カナリア、リニア）。
ブルー/グリーンは「環境を2つ並べる」という置き方の話で、カナリアとリニアは「流す割合をどう増やすか」という切り替え方の話です。だから「ブルー/グリーンでカナリア」のように組み合わせられます。CodeDeploy の ECS や Lambda では、まさにこの組み合わせを選びます。
IN-PLACE VS BLUE/GREEN新旧の置き方
戻し方は旧版が残るかで決まる
インプレース
同じサーバーを入れ替える
- 新旧の置き方旧版は置き換わる
- 戻し方前の版を再デプロイ
- 費用追加の環境は要らない
- 向く場面小さな変更・台数に余裕がない
ブルー/グリーン
新環境を並べて置く
- 新旧の置き方旧環境が並行して残る
- 戻し方向き先を旧環境へ戻す
- 費用二重に持つ間の分
- 向く場面止められない・すぐ戻したい
インプレースとは何か｜同じサーバーを入れ替える方式の利点と、戻し方の限界
インプレースデプロイは、すでに動いているインスタンスの上で、アプリケーションを新しい版へ入れ替える方式です。CodeDeploy では EC2 とオンプレミスのサーバーが対象です。
利点は、追加の環境を用意しなくてよいことです。台数も増えないので、費用の面でも手軽です。
限界は、戻し方にあります。入れ替えた時点でそのサーバーの旧版は置き換わっているため、戻すとは直前の正常な版をもう一度デプロイし直すことになります。CodeDeploy では、デプロイグループに CloudWatch アラームを関連付けておくと、しきい値に達したときに自動で停止し、直前の正常な版の再デプロイによるロールバックができます。人が気づくのを待たずに戻せますが、再デプロイの時間はかかります。
一度に何台を入れ替えるかで、速さと可用性が決まる
インプレースでは、全台を同時に止めると一時的に誰も応答できなくなります。そこで、デプロイ中も最低何台を正常に保つかを決めます。CodeDeploy の定義済みの設定には、1台ずつ進める OneAtATime、半数ずつ進める HalfAtATime、全台を一度に進める AllAtOnce があります。正常なホストの最小数は、台数か割合のどちらかでも指定できます。たとえば20台のうち15台を保ちたいなら、割合で言えば75%を最小の正常ホストとするカスタム設定です。
保つ台数を増やすほど可用性は上がりますが、入れ替えが進むのは遅くなります。「一度に絞って順に入れ替える」この形が、いわゆるローリング更新です。
起動後の検証をどこに挟むか
インプレースの流れは、AppSpec ファイルのライフサイクルイベントの順に進みます。新しい版を置いた後、アプリを起動し、その後に ValidateService で動作を確認します。ここで失敗を返せば、デプロイを失敗として扱えます。順序は BeforeInstall、AfterInstall、ApplicationStart、ValidateService の並びです。AppSpec の細かい書き方は公式ドキュメントに任せ、この記事では「起動した後に検証の関所を置ける」ことだけを押さえてください。
CHECK 1ここまでの確認
インプレースデプロイで直前の版へ戻したいとき、基本になるのはどれ?
答えと解説
答え: 2. 前の正常な版をもう一度デプロイし直す
インプレースは同じサーバーの中身を入れ替えるので、旧版は残りません。戻すとは前の版を再デプロイすることです。「インプレースとは何か」の章を読み直してください。
ブルー/グリーンとは何か｜新環境を並べて置き、切り替える方式と費用
ブルー/グリーンデプロイは、いま動いている環境（ブルー）はそのままに、新しい版の環境（グリーン）を別に用意し、準備ができたらトラフィックの向き先をグリーンへ切り替える方式です。
最大の利点は、旧環境が残っている間は、向き先を旧環境へ戻すだけで切り戻せることです。再デプロイを待つ必要がありません。また、本番へ流す前に新環境だけを検証できます。ECS の場合は、本番とは別のテスト用リスナーで新しいタスクセットに検証リクエストを送り、合格してから本番のリスナーを切り替える設計が取れます。
EC2 での形
EC2 では、Auto Scaling グループを CodeDeploy が複製して置き換え環境を作り、新しいインスタンスに新しい版をデプロイして、ロードバランサーの向き先を切り替えます。元のインスタンスは、設定した待機時間のあとに終了させます。この待機時間が「戻せる期間」にあたります。
費用の考え方
切り替えの前後は、新旧の環境を二重に持つことになります。その分の費用がかかりますが、金額は旧環境をいつ止めるかで決まります。確認が済んだらすぐ止めるのか、しばらく残して戻せる構えを保つのか。戻しやすさを買うために、何時間・何日の二重持ちを許すかを先に決めておくのが設計です。
CHECK 2ここまでの確認
ブルー/グリーンで、旧環境をまだ止めていない間に問題が見つかった。切り戻しはどうなる?
答えと解説
答え: 2. トラフィックの向き先を旧環境へ戻す
旧環境が残っている間は、向き先を戻すだけで済みます。旧環境をいつ止めるかが、戻しやすさと費用の分かれ目です。「ブルー/グリーンとは何か」の章を読み直してください。
カナリアとリニアはどう違うのか｜段階的に流す2つの型と、見るアラーム
どちらも、新しい版にいきなり全トラフィックを向けず、割合を段階的に増やします。違いは増やし方です。
- カナリア: 最初に少量（たとえば10%）だけ新しい版へ流し、一定時間様子を見て、問題がなければ残りを一括で移します。2段階です。
- リニア: 等しい割合を、等しい間隔で増やします。たとえば決まった間隔ごとに10%ずつ、最終的に100%へ向かいます。段数が多く、だんだん増えます。
CodeDeploy では Lambda と ECS のデプロイ設定として、canary、linear、all-at-once が用意されています。割合と間隔の組み合わせは定義済みの名前で選べます。具体的な値は更新されうるので、設定時に公式の一覧を確認してください。
CANARY VS LINEAR段階的に流す
カナリアは少量→残り一括、リニアは等しく少しずつ
-
少量を新版へ
たとえば最初の10%
-
アラームを見る
基準を超えたら止めて戻す
-
カナリア
問題なければ残りを一括
-
リニア
等しい割合を等間隔で追加
段階的に流す意味は「見るもの」で決まる
少量だけ流しても、何も見ていなければ、問題を見逃したまま全量に進むだけです。段階の合間にエラー数やレイテンシーのアラームを見て、基準を超えたら自動で止めて戻す。この「見るもの」とセットで初めて、カナリアやリニアは意味を持ちます。
Lambda の場合は、関数のエイリアスが新旧のバージョンに振り分ける重みを段階的に変えることで、トラフィックを移します。移行前に結合テストを走らせたいときは、ライフサイクルフックの BeforeAllowTraffic にテスト用の関数を指定します。失敗を返せば、本番のトラフィックを流す前にデプロイを止められます。AWS SAM を使っている場合は、DeploymentPreference で型とアラームを書くと、CodeDeploy と連携した段階的な公開と自動ロールバックをテンプレートだけで入れられます。
CHECK 3ここまでの確認
最初に少量のトラフィックで新しい版を試し、問題がなければ残りを一度に移す型はどれ?
答えと解説
答え: 2. カナリア
カナリアは「少量で様子見→残りを一括」、リニアは「等しい割合を等しい間隔で」増やす型です。「カナリアとリニアはどう違うのか」の章を読み直してください。
どれを選ぶか｜止められない度・戻しやすさ・費用で決める判断表
ここまでの内容を、選ぶ軸に落とします。
| 軸 | インプレース | ブルー/グリーン | カナリア／リニア（段階的に流す） |
|---|---|---|---|
| 新旧の置き方 | 同じサーバーを入れ替える | 新環境を並べて置く | ブルー/グリーンの上で移し方を選ぶ（Lambda・ECS） |
| 戻し方 | 前の版を再デプロイ | 向き先を旧環境へ戻す | 割合を0へ戻す・止める |
| 追加の費用 | 少ない | 二重に持つ間の分 | 二重に持つ間の分 |
| 影響の広がり | 台数の絞り方次第 | 切り替えの瞬間に全量 | 少量から。広がる前に止められる |
| 前提 | ほぼ無し | 環境を複製できる設計 | 見るアラームがあること |
判断は、次の順で考えると迷いません。
- 止められないサービスか。 止められないなら、戻しやすさを優先してブルー/グリーンを第一候補にします。
- 戻しやすさを最優先にするか。 旧環境を並行して残せるブルー/グリーンが向きます。台数に余裕がなく二重持ちが難しいなら、インプレースで台数を絞り、アラームで再デプロイを自動化する形になります。
- 見張る指標があるか。 エラー率などのアラームがあるなら、段階的に流す型（カナリア、リニア）で影響を小さくできます。指標が無いなら、段階的にしても効果は薄いです。
HOW TO CHOOSE選ぶ3つの問い
3つの問いで方式の第一候補が決まる
-
1.止められないサービスか
はい → 旧環境を残せるブルー/グリーン
-
2.戻しやすさを最優先か
はい → 向き先を戻すだけで済む方式。二重持ちが難しいなら台数を絞ったインプレース
-
3.見張る指標（アラーム）があるか
はい → カナリア／リニアで影響を小さく。無ければ効果は薄い
どの方式にも「必ず正解」はありません。同じサービスでも、変更の大きさで選び分けることがあります。小さな設定変更なら台数を絞ったインプレースで十分でも、データの扱いが変わる大きな変更なら、ブルー/グリーンで旧環境を残しておく、という具合です。
CHECK 4ここまでの確認
止められないサービスで、問題が出たらすぐに戻せる構えを最優先にするときの第一候補は?
答えと解説
答え: 2. ブルー/グリーン
旧環境を並行して残せるブルー/グリーンは、向き先を戻すだけで切り戻せます。代わりに二重に持つ費用がかかります。「どれを選ぶか」の章を読み直してください。
CodeDeploy では何が選べるのか｜EC2・Lambda・ECS の対応と、検証のフック
CodeDeploy が選べる方式は、デプロイ先の計算基盤で決まります。
| デプロイ先 | 選べる方式 | 移し方の設定 |
|---|---|---|
| EC2／オンプレミス | インプレース、ブルー/グリーン | 一度に更新する台数（OneAtATime、HalfAtATime、AllAtOnce、または最小正常ホスト数） |
| Lambda | ブルー/グリーン（エイリアスの重みで移す） | canary、linear、all-at-once |
| ECS | ブルー/グリーン（タスクセットを切り替える） | canary、linear、all-at-once |
検証のフックも、基盤ごとに置ける場所が違います。EC2 のインプレースでは起動後の ValidateService、Lambda では移行前の BeforeAllowTraffic、ECS ではテスト用リスナーに新しいタスクセットを向けた状態での検証です。どの基盤でも、「本番に流す前、または流す途中に、失敗を返せる関所を置ける」という考え方は同じです。
appspec の書き方やコンソールの操作は、版が変わると画面や項目が変わるので、この記事では扱いません。公式ドキュメントで確認してください。
戻す条件を先に決める｜アラームと自動ロールバックの考え方
方式を決めたら、最後に「何が起きたら戻すか」を、デプロイの前に決めておきます。デプロイの最中に基準を考えると、判断が遅れるためです。
決めることは3つです。
- 何を見るか: エラー率、レイテンシー、特定のエラー数。基準は CloudWatch のアラームとして用意します。
- どう戻すか: インプレースなら前の版の再デプロイ、ブルー/グリーンなら向き先の切り戻し、段階的な移行ならそこで止めて割合を戻す。
- いつまで戻せるか: ブルー/グリーンで旧環境を残す期間。ここが過ぎると、戻し方は再デプロイに変わります。
CodeDeploy は、デプロイグループにアラームを関連付けておくと、デプロイが失敗したとき、またはアラームが鳴ったときに、自動で停止やロールバックができます。ただし、アラームの対象が実際の障害を映していなければ、鳴るべきときに鳴りません。どの指標を、どのしきい値で見るかは、監視の設計（kanshi-sekkei）で決めることです。
まとめ
デプロイ方式は、「新旧の置き方」（インプレース／ブルー/グリーン）と「切り替え方」（一括／カナリア／リニア）の2軸でできています。選ぶときは、止められない度、戻しやすさ、二重に持つ費用、見張る指標の4つを見ます。そして、方式を決めたら、戻す条件とアラームを先に決めます。
次は、インフラの変更そのものを安全に入れる仕組みとして CloudFormation の変更セットを、戻す条件に使う監視の設計として kanshi-sekkei を読むと、デプロイの前後がつながります。
READ ALSO — 実務向け・段3 基盤
監視設計｜何を見るかは SLO から逆算する。4つのシグナルと、アラームを鳴らす基準の決め方
参照ソース
- AWS CodeDeploy とは（ユーザーガイド） — デプロイ種別（インプレース／ブルー/グリーン）、計算基盤ごとに選べる方式、ブルー/グリーンの利点、自動停止・ロールバックの根拠に使った
- CodeDeploy のデプロイ設定（ユーザーガイド） — OneAtATime / HalfAtATime / AllAtOnce、Lambda・ECS の canary / linear / all-at-once の考え方の根拠に使った
