🚀 Argo Rollouts デプロイ戦略完全ガイド：無停止デプロイのすべて

Kubernetes環境でサービスを中断することなく、安全にデプロイすることは、すべてのエンジニアの夢です。今日は、その夢を現実にする強力なツール、Argo Rolloutsの核となる戦略を深く掘り下げていきます。

単なる理論を超えて、実務でどの戦略を選択すべきかのガイドラインまで用意しましたので、10分だけ集中してください！ 🚀

Kubernetesの基本的なDeploymentリソースは「RollingUpdate」という素晴らしい機能を提供しますが、トラフィック制御や詳細な検証には限界があります。Argo Rolloutsはこれを補完し、大規模なサービスでも安心してデプロイできる多様な戦略を提供します。

---

1. Blue-Green デプロイ：完璧な切り替えと即時ロールバック 🔵🟢

ブルーグリーンデプロイは、旧バージョン（Blue）と新バージョン（Green）の環境を同時に立ち上げ、トラフィックを一気に切り替える方式です。

• 動作方式：新しいバージョンがすべて準備できたら、サービス（Service）のセレクターを更新してトラフィックをGreenに切り替えます。
• 長所：ロールバックが非常に速いです（セレクターを元に戻すだけ）。
• 短所：リソースが一時的に2倍必要になります。

📝 Blue-Green 実践コード

YAML

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 4
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
  strategy:
    blueGreen: 
      # 新バージョンにトラフィックを切り替える前にアクティブ化されるサービス名
      activeService: rollout-bluegreen-active
      # 新バージョンが作成されるときに接続されるプレビューサービス
      previewService: rollout-bluegreen-preview
      # デプロイ後に手動承認を待つかどうか（自動化可能）
      autoPromotionEnabled: false

---

2. Canary デプロイ：リスクを最小限に抑える段階的デプロイ 🐤

カナリアデプロイは、炭鉱のカナリアのように、新しいバージョンを一部のユーザーにのみ先行公開して安定性を検証した後、段階的に拡大する方式です。

• 動作方式：10% → 30% → 50% → 100%のようにトラフィックの割合を増やします。
• 長所：潜在的なバグが全ユーザーに影響を与えるのを防ぎます。
• 短所：デプロイプロセスが長くなる可能性があります。

📝 Canary 実践コード（基本ステップ設定）

YAML

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-canary
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 10 # トラフィックの10%のみを新バージョンに送信
      - pause: {duration: 1h} # 1時間監視して待機
      - setWeight: 30 # 問題がなければ30%に拡大
      - pause: {} # ユーザーが手動で承認するまで無限に待機（手動一時停止）
      - setWeight: 70
      - pause: {duration: 10m}

---

3. Advanced Canary: Service Mesh 連携戦略 🌐

基本的なカナリアは「レプリカ数」でトラフィックを調整しますが、IstioやLinkerd、Nginx Ingressを使用すると、はるかにきめ細やかな制御が可能です。

• 特徴：たった1つの新バージョンPodを立ち上げるだけで、仮想サービス（Virtual Service）を通じて正確に1%のトラフィックだけを送信できます。
• ヘッダーベースルーティング：特定のヘッダー（debug=true）を持つリクエストや特定の地域のユーザーのみを新バージョンに誘導できます。

📝 Istio 連携例

YAML

  strategy:
    canary:
      trafficRouting:
        istio:
          virtualService:
            name: my-vsvc # Istio仮想サービス名
            routes:
            - primary # メインルート設定
      steps:
      - setWeight: 5 # Istioレベルで5%のみ調整
      - pause: {duration: 10m}

---

4. Progressive Delivery: 分析（Analysis）ベースの自動デプロイ 📈

単に時間を待つだけでなく、メトリクスを見てデプロイの進行を決定することをProgressive Deliveryと呼びます。

• 動作：Prometheusからエラー率（Error Rate）を照会し、5%以上であれば自動的にロールバックし、正常であれば次の段階に昇格（Promote）します。

📝 Analysis 連携コード

YAML

  strategy:
    canary:
      analysis:
        templates:
        - templateName: success-rate-check # 事前定義された分析テンプレートを参照
        startingStep: 1 # 2番目のステップ（インデックス1）から分析を開始
      steps:
      - setWeight: 20
      - pause: {duration: 5m}

---

5. どの戦略を選択すべきでしょうか？ 🎯

状況	推奨戦略	理由
—	—	—
迅速なロールバックが最優先	Blue-Green	セレクターを変更するだけで即時復旧
ユーザーへの影響を最小限に抑えたい場合	Canary	一部にのみ公開してリスクを分散
リソース（CPU/MEM）が不足している場合	Canary	段階的に置き換えるため、余裕のあるリソースが少なくても可能
データ整合性が非常に重要な場合	Blue-Green	2つのバージョンが混在してリクエストを受ける期間がない
自動化された安定性検証が必要な場合	Progressive	メトリクスベースの自動ロールバックで夜間デプロイも安心

—

🏁 終わりに

Argo Rolloutsは、Kubernetesデプロイを単なる「置き換え」から「戦略的運用」へと格上げします。最初はシンプルなCanaryから始めて、徐々にAnalysisを導入し、人の介入なしに完全自動化された安全なデプロイシステムを構築することをお勧めします。

あなたの環境にはどの戦略が最も魅力的ですか？ 🛠️