Argo RolloutsのCanaryリリースとBlue-Greenリリースの違いと簡単な実践

本記事では、Kubernetes上でArgo Rolloutsを使って実装できるデプロイ戦略のうち、CanaryリリースとBlue-Greenリリースについて解説します。さらに、nginxを用いてCanaryリリースを試してみます。

1. Argo Rolloutsとは

Argo Rolloutsは、KubernetesのカスタムコントローラとCRD(Custom Resource Definition)を利用して、より柔軟なデプロイ戦略を実現するツールです。Kubernetesの標準的なDeploymentでは難しい以下機能をサポートしております。

  • Canaryリリース（段階的トラフィックシフト）
  • Blue-Greenリリース（本番環境の一括切り替え）
  • Progressive Delivery（メトリクス分析に基づく自動ロールバックなど）
  • Analysis（PrometheusやGrafanaなどとの連携による動的評価）

Argo Rolloutsの中心となるリソースはRolloutです。spec.strategy.canaryまたはspec.strategy.blueGreenを設定することで、どの手法を用いてデプロイを行うかを宣言的に制御します。

今回は以前プライベートレポジトリからArgo Rolloutsをクラスターにデプロイした記事を書いておりますのでその環境を使ってみようと思います。

2. Canaryリリースとは

Canaryリリースは、新しいバージョンのアプリケーションを徐々に本番トラフィックに適用していく手法です。具体的には、最初はユーザーの一部(例：10%)だけを新バージョンへ誘導し、問題が起きなければ20%、50%、最終的には100%といった具合に段階的に切り替えます。

このリリース戦略の利点は、万が一不具合があった際も被害範囲を最小化できる点にあります。一方で、トラフィックの重み付けや不具合を検知・検証するための詳細なモニタリング・ロギングが必要になります。

3. Blue-Greenリリースとは

Blue-Greenリリースは、本番環境(Blue)と新バージョン環境(Green)を並行して用意し、切り替えのタイミングでサービスのルーティングを一気に新環境(Green)へ移行する手法です。

  • Blue: 現在稼働中の本番バージョン
  • Green: 新バージョンをデプロイし、検証しておく環境

本番切り替えが非常に早く、ロールバックも簡単(古い環境に戻すだけ)というメリットがあります。ただし、Canaryのような「段階的テスト」は難しく、問題があれば影響度の高い障害になるデメリットがあります。また、本番用と新バージョン用の2つの環境を維持するためのインフラコストが高くなる傾向があります。

（障害ダウンタイムは長くなりますが、切り替えた後問題なければ旧バージョン用はすぐデプロイできるようにしておけば環境削除してコストカットしたらダメなのかなとは思いました）

4. Argo RolloutsでCanaryリリース実践(with nginx)

ここでは、Argo RolloutsでnginxをCanaryリリースでデプロイして、コンテナイメージアップデート時の動きなどを見てみます。

デプロイするとpodが4つ起動します。最初まだ旧バージョンもデプロイされていないのでCanaryリリースは動かず、最初に起動したpodをstableとして扱います。

サンプルYAML

以下レポジトリをそのままargocdに追加するか自分のレポジトリにコピペしてargocdに追加してください。

GitHub - 0ni4/nginx-rollout
Contribute to 0ni4/nginx-rollout development by creating an account on GitHub.
github.com
 
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx-rollout
  labels:
    app: nginx-rollout
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx-rollout
  template:
    metadata:
      labels:
        app: nginx-rollout
    spec:
      containers:
      - name: nginx
        image: nginx:1.27.3-perl  
        ports:
        - containerPort: 80

  strategy:
    canary:
      canaryService: nginx-canary
      stableService: nginx-stable
      steps:
        - setWeight: 0
        - pause: { duration: 10 }  # 10秒待ってから次へ (手動承認にしたい場合はdurationを省略してpauseだけ)
        - setWeight: 20
        - pause: { duration: 10 }
        - setWeight: 50
        - pause: { duration: 10 }
        - setWeight: 100
  • setWeight: Canaryに割り当てるpodの割合を20% → 50% → 100%と徐々に増やしています。
  • pause: 一定時間あるいは手動で停止し、エラー率やログを確認して問題なければ次のステップへ進みます。ここでは10秒にしています。

5.動作確認

さきほどのレポジトリをargocdに追加しnginxをデプロイすると以下のようになります。

rollout.yamlのimageのバージョンを変更してみます。

再度nginxをsyncすると先ほどのバージョン変更を確認してCanaryリリースが動きます。

rolloutのレプリカセットが複製され、新しいnginxのpodが生成されています。

完全に切り替わると以下のようになります。

無事にCanaryリリースの動作確認ができました。

6. CanaryとBlue-Greenの主な違い

観点 Canaryリリース Blue-Greenリリース
リリース方法 部分的・段階的に新バージョンを展開 2つの環境を用意し、一発で本番を切り替え
トラフィック制御 NGINX, Istioなどによる重み付け Service切り替え (Active/Preview) で一括移行
ロールバック 重みを旧バージョンに戻す、段階的に再度シフト 旧バージョンの環境(Blue)に切り戻すだけ
運用コスト 複数バージョンのPodを同時稼働、監視の高度化が必要 本番用・プレビュー用で2つの環境が必要
障害発生時は影響が大きい
リリース速度 段階的で時間がかかる 一気に切り替え、ほぼ瞬時
向いているケース 未知の不具合リスクが高く、少しずつ様子を見たい場合 ダウンタイムを最小化したい、大規模リリースを一括で行いたい場合

7. まとめ

以上簡単なCanaryリリースとBGリリースの説明、Canaryリリースの例を紹介しました。

今度は実際にwordpressなどをデプロイしてみてトラフィックの重みづけなどをしてみようと思います。

タイトルとURLをコピーしました