ブルーグリーンとカナリアのリリース

（セクション： アーキテクチャとプロトコル）

1）なぜ「安全なロールアウト」が必要なのか"

最新のシステムでは、リリースはコード配信だけでなく、販売における制御された実験でもあります。2つの古典的な戦略-ブルーグリーンとカナリア-異なる方法でこれを解決しますが、共通の目標：ゼロのダウンタイム、迅速なロールバック、SLOによる観測性。

2）基本的な定義

ブルーグリーン

本番環境では、アクティブ（Blue）がトラフィックを提供し、パッシブ（Green）が新しいバージョンを準備しています。スイッチングは、バランサ/ルータレベルのアトミック（スイッチ/フリップ）です。それが悪くなったら、すぐにブルーに戻ります。

カナリア島

まずトラフィックの小さな％（例えば、1-5％）にロールアウトし、メトリクス/SLOを観察し、ステップバイステップでシェアを増加させます（10％→25％→50％→100％）。劣化中-前の安定したステップでロールバックまたは停止します。

3）どのアプローチがベストか

• 複雑な操作をせずに即座にロールバックする必要があります。
• アーキテクチャ/予算により、デュアルインフラストラクチャーの複製が可能です。
• 大規模な移行やプラットフォームアップデート（OS/JDK/ランタイム）を単独で実行したいと考えています。
• アプリケーション/接続プールは、段階的な「混合」状態に敏感です。

• ブラスト半径を最小化し、ユーザーの共有の挙動を確認する必要があります。
• 高い解放率、正常として進歩的な配達。
• 成熟した観測性と自動ゲート（エラー予算、レイテンシ、変換）があります。
• 製品チームは仮説をテストしたいと考えています：変換、保持、LTVなどへの影響。

4）リリース成功のための一般原則

Idempotentビルドアーティファクト：すべての段階で同じイメージ/パッケージ。
決定論的構成：コードとしての設定、環境の比較可能性。
設計による可視性：ログ、メトリック、トレース、アラート；前もってSLI/SLO。
高速、自動ロールバック：ロールバックボタン/コマンドはパイプラインの一部であり、手動ではありません。
互換性のあるスキーマ変更：expand-migrate-contract strategy（第10条を参照）。
L7ルーティング（望ましい）：APIヘッダー/クッキー/パス/バージョンの柔軟性。

5）青緑： 建築とプロセス

5.1トポロジー

2つのプロッドスタック：青（アクティブ）と緑（候補）。
共通の外部依存関係：CDN、外部API、キュー；DBは特別なケースです（第10章を参照）。
スイッチポイント：balancer/Ingress/Gateway。

5.2ステップバイステップの流れ

1.私たちは新しいアーティファクト（vNext）の下でグリーンを上げ、スモークテストを行います。
2.グリーンに対して自動実行（e2e、 contract、 regression）。
3.キャッシュ/セッションをウォームアップし（該当する場合）、バックグラウンドジャブ/キューを同期します。
4.トラフィックをグリーンに切り替える：atomic flip （DNS TTL low、 Route/Listener swap、 Ingress weight=100％）。
5.私たちは、最初の分/時間（黄金の信号：レイテンシ、エラー、飽和+ビジネスメトリック）でSLOを観察します。
6.問題が発生した場合-即座にBlueに戻ります（反転）。

5.3長所/短所

長所：インスタントロールバック、シンプルな精神モデル、純粋な分離。
短所：インフラストラクチャの倍増、ステートフルコンポーネントの難しさ、データ移行。

6）カナリア建築とプロセス

6.1トポロジー

単一の生産のクラスタ；単一の前面の後ろにサービスのいくつかのバージョン（安定したとカナリア）。
トラフィックは重み（1-5-10-25-50-100％）またはターゲット（ヘッダー/クッキー/ID）によって分けられます。

6.2ステップバイステップの流れ

1.カナリバージョンを同じクラスタ/ASG/NSGにデプロイします。
2.いくつかのトラフィック（例えば、1-5％）をカナリアにルーティングします。
3.SLI/SLOとビジネスメトリックの自動チェック;CI/CD内のゲート（エラー率、p95レイテンシ、CPU/RES、変換、拒否/リターン）。
4.ゲート通過時のトラフィックのシェアの段階的な増加。
5.100％への完全なロールアウトと古いバージョンの無効化。劣化の場合-自動ロールバック。

6.3長所/短所

長所：ほとんどのユーザーにとって最小限のリスク、データ駆動型ソリューション。
短所：成熟した観測性、有能なルーティング、インスタンス間の「バージョンスキュー」のリスクが必要です。

7）トラフィックルーティング

レイヤL4： IP/ポートによるバランス；シンプルですが柔軟性はほとんどありません。
Level L7： HTTP/Sルール-パス、ホスト、ヘッダー、クッキー、ユーザーエージェント、GeoIP、 SNI。

• 重み付けルーティング（重み1〜100％）。
• ヘッダーベース/クッキーベース。
• セッションの粘着性（ステートフル/キャッシュされたスクリプトに重要）。
• シャドウ/トラフィックミラーリング（新しいバージョンへのミラーリクエストは「静かに」）。

8）ツールと実装（例）

Kubernetes： Ingress （NGINX、 Contour）、 Service Mesh （Istio/Linkerd）、 Argo Rollouts、 Flagger。
AWS ALB/ELB、ルート53加重レコード、ECS/EKS；GCPロードバランシング+NEG；Azure Front Door/Appゲートウェイ。
CDプラットフォーム：Spinnaker、 Argo CD、 GitHub Actions+Progressive Deliveryプラグイン、GitLab/CD。

9）観察可能性、SLI/SLOおよびゲート

黄金信号：レイテンシー（p95/p99）、エラーレート（5xx/4xx）、 RPS、彩度（CPU/メモリ/GC）、キューラグ。
ビジネスメトリクス：コンバージョン、承認、支払い/成功、平均チェック、ファネルステップによる拒否。

• エラーしきい値（たとえば、error rate canary ≤ baseline+X％）。
• p95レイテンシーはベースラインよりもΔ以上悪くはありません。
• ビジネスのしきい値（例：変換ドロップ
• SLOエラー予算はより速く燃え尽きるべきではありません。

ステップ期間：統計的意義に十分な最小時間（トラフィックによって異なります）。

10）データベースの移行とスキーマの互換性

主なルール：前後のバージョンが互換性がある場合、リリースは安全です。

1.展開：古いバージョンを壊すことなく、新しい列/インデックス/テーブルを追加します。

2.アプリvNextを展開します（新しいスキームを読み取り/書き込みますが、古いスキームを使用する方法を知っています）。

3.データの移行（バックグラウンド/バッチ、idempotent、チェックポイント付き）

4.契約：安定化後に古いフィールド/フィーチャーを削除します。

アンチパターン：Blue-Greenスイッチのポイントで排他的なブロックを必要とする移行。スキームをダウングレードできない。重複排除なしの「二重書き込み」。

11）ロールバックおよび緊急時の計画

青緑：青の即刻のフリップ；緑の背景ジョブの尾を監視します。
カナリア州：重量ロールバック（例えば、25％から5％または0％まで）。アラートの自動中止。
データ：反復/補償（idempotency keys、 「inbox/outbox」パターン、メッセージ重複除外）のよく考えられたポリシー。
Ficheflags：部分的にロールアウトされた機会をシャットダウンするクイックキルスイッチ。

12）状態およびセッションを扱うこと

Sticky sessions for canaries、またはセッションを外部（Redis/Memcached）に保存して、バージョンを交換可能にします。
キャッシュを事前にウォームアップ（グリーンウォームアップ）し、反転時に無効化を考慮します。
バックグラウンドワーカー：バージョン間の「レース」-キュー分離またはバージョン別の「リーダーシップ」を許可しないでください。

13）安全性とコンプライアンス

Green/Canary-by Zero Trustへのアクセス：サービスアカウント、最低限のロール。
秘密と鍵-KMS/Secrets Manager；回転をオンにします。
トラフィック-TLSのみ；エンドポイントのバージョンは明確にマークされています。ルーティングとリリースアクティビティを監査します。

14）コストとパフォーマンス

Blue-Greenは（リリース時または常に）インフラストラクチャを2倍にします-予算。
カナリアはより経済的ですが、自動化には観測ツールとエンジニアリング時間が必要です。
最適化：オートスケーリング、一時的な環境、バージョンの並列存在のウィンドウを短縮します。

15）チェックリスト

リリース前に

• 単一のソースからプロモートされたイメージ/ビルド、検証された署名。
• テストプラン、アラート、SLOゲートが設定されています。
• データベースの移行-拡張モードでは、ダウングレードプランを使用できます。
• ロールバックプラン-ステージング/プロダクションのようにチェックイン。

発売時

• メトリックとログはベースラインと比較されます。
• カナリアの場合、ステップとしきい値は固定されています。Blue-Greenの場合-フリップバック準備。
• on-callコマンドは、フィードバックウィンドウがあります。

リリース後

• SLOはシンクしませんでした。エラー予算は正常です。
• リリース後の移行/クリーンアップが完了しました。
• レトロスペクティブとプレイブックの更新。

16）頻繁なエラーとアンチパターン

メトリクスなしでロールアウト：データなし-管理ソリューションなし。
互換性のないデータベーススキームの混在、ダウングレード戦略の欠如。
ランダムトラフィックのミキシング：粘着性はありません、ユーザーはバージョン間で「ジャンプ」します。
隠されたステートフルな依存関係（ローカルディスク、インメモリキャッシュ）。
長いDNS-TTLは、高速フリップ（ブルーグリーン）に干渉します。
自動化の欠如：手動の「目で」ソリューションが遅くなり、リスクが増加します。

17）組み合わせたアプローチ

Blue-Green+Canary：最初にGreenをロールアウトし、次にGreen内で個別のサービスのためにCanaryをロールアウトします。
Shadow/migrating traffic： Canaryの前に、ミラーリングされたトラフィックを新しいバージョンに実行します。
フィーチャーフラグ（プログレッシブデリバリー）：機能性はセグメントごとに「暗い」フラグによって安定版の上に含まれます。

18）サンプルシナリオ（スケッチ）

1.新しいListener/Ingress用にGreen （v2）を展開します。

2.キャッシュをウォームアップ、読み取りチェック、煙を実行します。

3.重量をグリーン=100％に切り替えます。

4.30-60分のSLOを観察して下さい；すべてがOKなら-Blueをオフにします。

1.canary vNextを展開します（レプリカ5％）。

2.内部アカウント/テストセグメントのトラフィックは5％です。

3.オートゲート：ベースライン≤エラーレート+0。3％、 p95 ≤+20ms。

4.ゲート通過時はN分ごとに10％→25％→50％アップします。

5.私達はすべてのセグメントのためのficheflag 100％を翻訳します；古いバージョンを削除します。

19）異なるアーキテクチャのバリエーション

Monolith： Blue-Greenはより簡単で、カナリアは特徴のinsivisibilityのためにより困難です；ficheflagsを使用します。
マイクロサービス：カナリアは自然です；消費者主導の契約を監視します。
ステートフルサービス：慎重に細工された移行と粘着性でブルーグリーンを好む。

20）簡単な比較（要約）

ロールバック速度：青緑=瞬時；カナリア=高速しかし、重量でプルバック。
インフラのコスト：ブルー・グリーン（Blue-Green）カナリア・↔︎/↓。
ユーザーへのリスク：カナリアはより低いです（シェアを管理しています）。
実装の難しさ：Blue-Greenは起動が簡単です。カナリアは強い観測性と自動化を必要としています。
データ/回路の互換性：両方にとって重要です。expand-migrate-contractを計画します。

21）ボトムライン

ブルーグリーンとカナリアは相互に排他的な戦略ではなく、進歩的な配信の要素です。選択は、コスト制約、観測可能性の成熟度、および変更の性質によって異なります。アプローチにかかわらず、持続可能なリリースは、オートメーション、観測性、後方互換性、高速ロールバックという4つの柱にかかっています。