ブルーグリーンデプロイメント

Blue-Green Deploymentとは?

Blue-Green Deployment(ブルーグリーンデプロイメント)は、ソフトウェアの新バージョンリリースに伴うダウンタイムを最小化し、リスクを軽減するために設計されたデプロイメント戦略です。「Blue」(現在稼働中)と「Green」(新規または候補)と呼ばれる、2つの独立した、しかし同一の環境を運用します。任意の時点で、1つの環境のみが本番トラフィックを処理します。新バージョンの準備が整うと、アイドル状態の環境(Green)にデプロイし、テストを実施します。検証が完了したら、通常はゼロダウンタイムでBlueからGreenへトラフィックを切り替えます。問題が発生した場合は、即座に切り替えを元に戻すことができます。

主な特徴:

• 2つの同一の本番環境:Blue(アクティブ)とGreen(アイドル/候補)
• 常に1つの環境のみがライブトラフィックを受信
• シームレスな切り替えと即座のロールバックを実現
• ゼロダウンタイムリリースと堅牢なディザスタリカバリをサポート

Blue-Green Deploymentの仕組み

このプロセスは体系的であり、制御された可逆的なリリースを可能にすることでリスクを最小化します。以下に詳細なワークフローを示します。

ステップバイステップのワークフロー

トラフィック切り替えの図:

[ユーザー]
   |        (トラフィック切り替え)
   |------> [Blue環境] -----------|
   |                                     |
   |------> [Green環境] <---------|

重要なポイント:

• 切り替えは通常、ロードバランサー、DNS、またはKubernetes Serviceセレクターによって処理されます
• ロールバックは即座に実行でき、単にトラフィックをリダイレクトするだけです

主要な概念と用語

• Blue環境: 現在アクティブで安定した本番環境
• Green環境: 並行してデプロイされた新しいリリース候補環境、初期状態ではアイドル
• トラフィック切り替え: ユーザートラフィックを1つの環境から別の環境にリダイレクトすること、通常はロードバランサーまたはDNS更新を介して実施
• ロールバック: 問題が発生した場合に、トラフィックを以前の安定した環境に即座に戻すこと
• 同一の本番環境: BlueとGreenの両方が、同等のインフラストラクチャ、構成、依存関係を持つ必要があります
• デプロイメント自動化: CI/CDとInfrastructure as Code(IaC)を活用して、反復可能で手作業不要のデプロイメントとトラフィック切り替えを実現
• 継続的デプロイメント/デリバリー: より迅速で安全なリリースのために、Blue-Green Deploymentを統合した自動化パイプライン
• ディザスタリカバリ: アイドル環境は、壊滅的な障害が発生した場合のホットスタンバイとして機能

Blue-Green Deploymentの利点

Blue-Green Deploymentは、運用、技術、ビジネス面で大きな利点を提供します。

課題と欠点

その強みにもかかわらず、Blue-Green Deploymentには特有の課題があります。

ユースケースと実践例

一般的なユースケース:

• 高可用性アプリケーション: 24時間365日の稼働が必要なEコマース、SaaS、API
• 規制産業: 監査可能で可逆的なデプロイメントが必要な金融、医療、その他のセクター
• ディザスタリカバリ: アイドル環境を即座のフェイルオーバーターゲットとして使用
• パフォーマンステスト: 完全なカットオーバー前に候補環境でベンチマークを実施
• 機能ロールアウトとA/Bテスト: Blue-Greenと段階的なトラフィックシフトを組み合わせて、安全な機能実験を実施
• クラウド移行: オンプレミスのBlueからクラウドベースのGreen環境へトラフィックを切り替え

例:Azure Container AppsでのBlue-Green Deployment

Azure Container Appsは、リビジョン、トラフィック分割、ラベルを介してBlue-Green Deploymentをサポートします。新しいコンテナを「Green」リビジョンとしてデプロイおよびテストし、その後、本番トラフィックをアトミックに再割り当てできます。

az containerapp ingress traffic set \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --label-weight blue=0 green=100

ロールバックは以下のコマンドで実行:

az containerapp ingress traffic set \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --label-weight blue=100 green=0

実装パターン

Kubernetes上での実装

Kubernetesは、宣言的なインフラストラクチャとサービス抽象化により、Blue-Green Deploymentに適しています。

• Namespace: BlueとGreenのデプロイメントを別々のNamespaceで分離
• Deployment: 各バージョンは個別のDeploymentリソース
• Service: 検証後、ServiceセレクターをGreen Deploymentを指すように切り替え
• Ingress/Service Mesh: 外部または内部でアクティブな環境へトラフィックをルーティング

Kubernetes YAMLの例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  # blue version spec

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  # green version spec

---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp-green # myapp-blueからmyapp-greenに切り替え

クラウドプラットフォーム上での実装

• AWS: AWSは、Elastic Load BalancingとCodeDeployを使用してBlue-Green Deploymentを実現し、トラフィックシフトとヘルスチェックを調整
• Azure: Azure Container Appsは、リビジョンとトラフィックウェイトを利用してBlue-Green戦略を管理
• Google Cloud: Google Cloud Platformは、Cloud RunとTraffic Splittingを通じてBlue-Green Deploymentをサポート

Infrastructure as Code(IaC)での実装

Terraform、AWS CloudFormation、Ansibleなどのツールにより、BlueとGreen環境の再現可能で自動化されたプロビジョニングと切り替えが可能になります。

データベースに関する考慮事項

データベースの課題

アプリケーション環境は複製できますが、ほとんどのBlue-Green Deploymentは単一の本番データベースを共有するため、いくつかのリスクと制約が生じます。

AWS RDS Blue/Green Deployments

• Green環境は本番環境のクローンで、物理または論理レプリケーションを介して同期を維持
• 利点: 変更を独立してテストし、1分未満のダウンタイムとデータ損失なしで切り替え可能
• 制限事項:
  • 一部の機能(例:RDS Proxy、クロスリージョンレプリカ)はサポートされていません
  • スキーマ変更は後方互換性が必要
  • 論理レプリケーションは、ログなしテーブルや特定のPostgres機能をサポートしない場合があります
  • スイッチオーバーには慎重なリソースとスロット管理が必要。リソースが不足している場合、レプリケーションラグが発生する可能性があります

一般的なベストプラクティス

• 後方互換性のある移行: カラム/テーブルを追加しますが、すべての環境が移行されるまで削除/名前変更は行わない
• 機能トグル: データベースとコードの変更を分離
• データベースバージョニング: Liquibaseなどのツールを使用して、スキーマ移行とロールバックを自動化

ベストプラクティス

他のデプロイメント戦略との比較

関連用語集

• トラフィック切り替え: デプロイメント中にライブリクエストを1つの環境から別の環境にリダイレクトすること
• デプロイメント自動化: デプロイメントプロセスから手動介入を排除するためのスクリプトとツールの使用
• 継続的デプロイメント: 自動テストに合格したすべてのコード変更を自動的にデプロイすること
• ディザスタリカバリ: 障害後にサービスを迅速に復旧するための手順とインフラストラクチャ
• 同一の本番環境: 構成、依存関係、インフラストラクチャが可能な限り一致する環境
• ロールバック: 以前の安定した状態/バージョンに戻すプロセス
• Infrastructure as Code(IaC): マシン可読な定義ファイルを通じてコンピューティングリソースを管理およびプロビジョニングすること
• 段階的なトラフィックシフト: 一度にすべてを切り替えるのではなく、新しい環境に向けられるトラフィックの割合を段階的に増やすこと
• ロードバランサー: 複数のサーバー/環境に着信トラフィックを分散するハードウェアまたはソフトウェア

参考文献

• Martin Fowler: BlueGreenDeployment
• AWS Whitepapers: Overview of Deployment Options on AWS
• AWS: What Is Blue/Green Deployment?
• Azure Container Apps: Blue-Green Deployment
• Azure Container Apps: Revisions
• Azure Container Apps: Traffic Splitting
• Google Cloud: Traffic Migration and Splitting Concepts
• Kubernetes Documentation: Deployments
• Liquibase: Blue-Green Deployments
• AWS RDS: Blue/Green Deployments Overview
• AWS RDS: Blue/Green Deployment Considerations
• Terraform Documentation
• Spinnaker: Continuous Delivery Platform
• AWS CodeDeploy Documentation
• Prometheus Monitoring
• Grafana Observability Platform
• Datadog Monitoring and Analytics