ブルーグリーンとカナリアの展開

ブルーグリーンとカナリアの展開

1）チャレンジとキーアイデア

• Blue-Green： 2つのパラレルバージョン（Blue-アクティブ、Green-new）を保持し、トラフィックをアトミックに切り替えます。クイックロールバック→即座にブルーを返します。
• カナリア：新しいバージョンを段階的にオンにします（1％→5％→25％→50％→100％）。

一般的な原則は「、アーティファクト・デリバリー」と「トラフィック・インクルージョン」を分離し、オブザビリティ+ロールバックを自動化することです。

2）いつ選ぶべきか

• 即刻の切換え（堅いRTO）、簡単な状態なしのサービスを必要とします；
• 厳密な解放/凍結の窓および明確な煙の点検があります；
• 長い二重容量を保持するのは高価ですが、短時間でも可能です。

• 複雑な変更、実際のトラフィックに対するステップバイステップの検証が必要です。
• 成熟したテレメトリー（SLO、ビジネスメトリック）、自動停止機能があります。
• ダメージの半径（fintech/iGamingストリーム）を極端に制限します。

コンボパターン：グリーンをロールアウトし、カナリアステージ（フレームとしてのブルーグリーン、トラフィックを運ぶ方法としてのカナリア）を介してそれに切り替えます。

3）トラフィックルーティングアーキテクチャ

1.L4/L7 balancer （ALB/NLB、 Cloud Load Balancer）-重み付けされたターゲットグループ。

2.API ゲートウェイ/WAF-バージョン、ヘッダー、クッキー、リージョンによるルート/重量。

3.サービスメッシュ（Istio/Linkerd/Consul）-パーセント分布、障害注入、タイムアウト/リトレイ/制限ハンドル。

4.Ingress/NGINX/Envoy-上流の重みと属性ルーティング。

5.Argo Rollouts/Flagger-オペレータコントローラ、自動進行、Prometheus/New Relic/Datadogとの統合。

4） Kubernetes： 実用的なテンプレート

4.1ブルーグリーン（サービスセレクター経由）

デプロイメント：'app-blue'→'app-green'。
One Service 'app-svc'と、必要な'バージョン'のセレクターがあります。

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: app-green, labels: { app: app, version: green } }
spec:
replicas: 4 selector: { matchLabels: { app: app, version: green } }
template:
metadata: { labels: { app: app, version: green } }
spec:
containers:
- name: app image: ghcr. io/org/app:1. 8. 0 apiVersion: v1 kind: Service metadata: { name: app-svc }
spec:
selector: {app: app, version: blue} # ← switch to green - change ports: [{port: 80, targetPort: 8080}]

スイッチング-制御されたドレインを持つセレクタ（またはラベル）の原子的変化。

4.2カナリア島（イスティオ・バーチャルサービス）

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: app }
spec:
hosts: ["app. example. com"]
http:
- route:
- destination: { host: app. blue. svc. cluster. local, subset: v1 }
weight: 90
- destination: { host: app. green. svc. cluster. local, subset: v2 }
weight: 10

「重量」を段階的に変更します。DestinationRuleにretry、 timeout、 outlier-detectorを追加します。

4.3アルゴロールアウト（Auto Canary Run）

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: app }
spec:
replicas: 6 strategy:
canary:
canaryService: app-canary stableService: app-stable steps:
- setWeight: 5
- pause: {duration: 300} # 5 min observation
- analysis:
templates:
- templateName: slo-guard
- setWeight: 25
- pause: { duration: 600 }
- analysis:
templates: [{ templateName: slo-guard }]
- setWeight: 50
- pause: {}
trafficRouting:
istio:
virtualService:
name: app routes: ["http-route"]

テンプレート解析はメトリックに関連付けられています（以下を参照）。

5） SLOのゲートおよび自動ロールバック

• テクニカル：'p95_latency'、 '5xx_rate'、 'error_budget_burn'、 'CPU/メモリのスロットリング'。
• 食料品：「CR（デポジット）」「、支払いの成功」「、スコア詐欺」「、ARPPU」（冷たい窓）。

• 新しいバージョンの'5xx_rate'が>0の場合。10分間5％-一時停止とロールバック。
• 'p95_latency'の場合、ベースの20％-ロールバック。
• カナリアプロモーションが進むが予算のSLOが焼かれた場合>2％/時間-ホールド。

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: slo-guard }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

6）データと互換性（痛みの最も一般的な原因）

• 展開：新しいnullableカラム/インデックスを追加し、両方のスキームをサポートします。
• マイグレート：二重書き込み/読み取り、バックフィル。
• 契約：トラフィックの100％を終了した後、古いフィールド/コードを削除します。
• Event/queues： version payload （v1/v2）、 idempotencyをサポートします。
• キャッシュ/セッション：バージョンキー；フォーマットの互換性を確認します。

7） CI/CDおよびGitOpsとの統合

CI：ビルド1回、イメージ署名、SBOM、テスト。
CD：環境を通じたアーティファクト・プロモーション；ブルーグリーン/カナリアはマニフェストによって管理されています。
GitOps： MR→コントローラ（Argo CD/Flux）は重み/セレクターを適用します。
Environments/Approvals：本番ステップ-手動ゲート+監査の意思決定。

8） NGINX/EnvoyおよびCloud LB： クイック例

8.1 NGINX（上流重量）

nginx upstream app_upstream {
server app-blue:8080 weight=90;
server app-green:8080 weight=10;
}
server {
location / { proxy_pass http://app_upstream; }
}

8.2 AWS ALB（加重ターゲットグループ）

TG-Blue： 90、 TG-Green： 10→IaC/CLIによる重量変更。
CloudWatchアラートをリンクして自動スクリプトをロールバックします（重量を0/100に変更）。

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

バージョン間のゼロ信頼：暗号化の秘密/ローリングキーを区別します。
Policy-as-Code：署名されていないイメージの展開を拒否します。'no latest'。
バージョンのアーティファクトとしての秘密と構成；ロールバックには、configsのロールバックが含まれます。
監査：誰、彼は重量を持ち上げたとき/セレクターを切り替えました、どのようなチケットで。

10）費用および容量

Blue-Greenは、リリース期間の2倍の電力を必要とします→ウィンドウを計画します。
カナリアは長持ちすることができます→テレメトリ/監視のコスト、2つのバージョンの並列コンテンツ。
最適化：HPA/VPAによる自動スケーリング、短いBlue-Greenウィンドウ、「heavy」サービスのナイトリリース。

11） Runbooks

1.プロモーションを一時停止します。
2.緑の重量を0％（カナリア）に減らし、青（青緑）にセレクターを戻します。
3.Check：エラー/レイテンシーが基本的なドレイン接続に戻りました。
4.インシデントを開き、アーティファクト（ログ、トラック、メトリックの比較）を収集します。
5.ステージに固定/再プロッド、煙を駆動、進行を再起動します。

12）アンチパターン

ステージとプロッドの間にアーティファクトを再構築する（「ビルド1回」違反）。
SLO/メトリクスのない「耳が聞こえない」カナリアは形式的であり、防御ではありません。
機能フラグの欠如：リリースは一度に行動100％を含めることを余儀なくされています。
非働く健康点検/liveness→「粘着性がある」底および偽の安定性。
データベース互換性「at random」：スイッチング時にコントラクトが壊れます。
prodのmutable image tags/' latest'。

13）実装チェックリスト（0-45日）

0-10日

B/G、カナリア、または組み合わせたサービスの戦略を選択してください。
画像署名、ヘルスチェック、readiness-samples、 'no latest'を有効にします。
SLOダッシュボード（レイテンシ/エラー率/ビジネスメトリック）を準備します。

11-25日

重みを自動化（Istio/Argo Rollouts/ALB-weights）。
解析テンプレート、アラート、自動ロールバックを構成します。
テンプレートマニフェスト（Helm/Kustomize）、 GitOpsと統合。

26-45日

データベースのexpand-migrate-contract戦略を実装します。
重要なキルスイッチフラグをカバーします。
「ゲームの日」を過ごす：ロールバックとインシデントをシミュレートします。

14）成熟度の指標

Blue-Green/Canaryによるリリースの％（目標>90％）。
平均スイッチオーバー/ロールバック時間（ターゲット<3分）。
SLO自動停止（およびインシデントなし）でのリリースの共有。
テレメトリー（トレース/ログ/メトリック）によるサービスカバレッジ>95％。
expand-migrate-contractスキームによるDB移行のシェアは90％以上です。

15）添付ファイル： ポリシーとパイプラインテンプレート

OPA（無印の画像を禁止）

rego package admission. image

deny[msg] {
input. request. kind. kind == "Deployment"
some c img:= input. request. object. spec. template. spec. containers[c].image not startswith(img, "ghcr. io/org/")
msg:= sprintf("Image not from trusted registry: %v", [img])
}

カナリアのヘルム値（簡略化）

yaml canary:
enabled: true steps:
- weight: 5 pause: 300
- weight: 25 pause: 600
- weight: 50 pause: 900 sloGuards:
max5xxPct: 0. 5 maxP95IncreasePct: 20

GitHubアクション-重量プロモーション（擬似）

yaml
- name: Promote canary to 25%
run: kubectl patch virtualservice app \
--type=json \
-p='[{"op":"replace","path":"/spec/http/0/route/1/weight","value":25}]'

16）結論

ブルーグリーンとカナリアは相互に排他的ではなく、補完的な戦略である。署名されたアーティファクト、SLO観測、自動ゲート、GitOpsコントロールの上にそれらを構築します。インクルージョンから別の配信、迅速なロールバックと移行の規律を維持-リリースは予測可能、安全、迅速になります。