Blue-Green Deploymentとは？

Blue-green deploymentは、2つの同一の本番環境を実行し、すべてのトラフィックを古いものから新しいものへ一度に切り替えます。

Blue-green deploymentは、即座の切り替えを中心に構築された戦略です。blueとgreenとラベル付けした2つの環境を保持し、アイドル側に新しいバージョンをデプロイして検証し、トラフィックを切り替えます。何か問題があれば、切り替えて戻します。

仕組み

いつでも、一方の環境(例えばblue)がライブですべてのトラフィックを処理し、もう一方(green)はアイドルです。blueがユーザーに提供し続ける間に、greenに新しいバージョンをデプロイしてテストします。greenが検証されたら、ルーターを切り替えてすべてのトラフィックをgreenに送ります。blueは即座のフォールバックとして待機したまま残ります。

即座のrollbackという利点

前のバージョンが今アイドルになった環境でまだ実行されているため、rollbackはスイッチを切り替えて戻すだけです。rebuildもredeployもなく、回復はほぼ即座です。これが目玉となる利点です: 不良リリースを数秒で元に戻せます。

例

あるチームがgreen環境にバージョン5をデプロイし、バージョン4がblueからユーザーに提供します。greenに対してsmoke testsを実行し、それからload balancerをgreenに切り替えます。ユーザーはシームレスにバージョン5に移動します。1時間後に問題が現れたので、調査する間、数秒でblueに切り替えて戻します。

トレードオフ

Blue-greenはおよそ2倍のインフラを必要とします。deployの前後で2つの完全な環境が存在するためです。また、データベースのようなstatefulなコンポーネントには注意が必要です。それらは通常共有され、切り替え中は両方のバージョンと互換性を保つ必要があります。そのコストが、高速でクリーンなcutoverとrollbackを買うのです。

いつ使うか

Blue-greenは、downtimeが許容できず高速なrollbackが追加コストに見合うサービス、そしてアプリが主にstatelessか、そのデータ層が両方のバージョンを短時間サポートできる場合に適しています。より細かいリスク制御には、canary deploymentがまず少数のユーザーに新しいバージョンをさらします。

重要なポイント

Blue-greenは2つの環境を保持し、トラフィックを一度に切り替えます。
rollbackは即座です: まだ実行中の古いバージョンに切り替えて戻します。
追加のインフラのコストがかかり、共有stateには注意が必要です。