363-AWS SAP AWS 「理論・実践・一問道場」ブルー/グリーンデプロイメント

type

status

date

slug

summary

理論

CI/CDにおけるブルー/グリーンデプロイメントの概要と利点

1. ブルー/グリーンデプロイメントとは？

ブルー/グリーンデプロイメントは、現在稼働中の環境（ブルー）と新しいバージョンの環境（グリーン）を並行して用意し、トラフィックを段階的に切り替える手法です。以下の特徴があります。

リスク軽減: 新しいバージョンに問題があれば、旧バージョン（ブルー）に迅速に切り戻せます。

ダウンタイムの最小化: ユーザーへの影響をほぼゼロにできます。

段階的移行: トラフィックを部分的に切り替えることで、新しい環境を安全にテストできます。

2. 利用するAWSサービス

AWS CodeDeploy:

ブルー/グリーンデプロイメントをサポート。
ロールバック機能を備え、エラー発生時に旧バージョンに切り戻しが可能。

AWS CodePipeline:

CI/CDパイプライン全体を自動化。
ソースコード（GitHubなど）からビルド、テスト、デプロイまでを統合的に管理。

Application Load Balancer (ALB):

トラフィックを新旧環境に柔軟に振り分け可能。

3. メリットと注意点

メリット:

アップデート中のユーザー影響を抑制。
問題発生時にすぐに旧バージョンに戻せる。
本番環境と同じ設定で新しいバージョンをテスト可能。

注意点:

新しい環境のリソース（EC2インスタンスやコンテナ）が追加で必要。
コストが一時的に増加する可能性がある。

4. 適用例

ウェブアプリケーションのアップデート:

トラフィックの一部を新しいバージョンにルーティングし、安定性を確認。

迅速なセキュリティパッチ適用:

新しい環境でパッチを適用後、すぐに本番トラフィックを移行。

段階的リリース:

全ユーザーにリリースする前に、少数のユーザーで新機能を試験運用。

この手法は、高可用性を求めるサービスや継続的なデリバリーが求められる環境で特に有効です。

AWS OpsWorks とは？

AWS OpsWorks は、サーバー構成管理とアプリケーションデプロイの自動化を提供するサービスです。Chef や Puppet を利用して、サーバー設定をコードで管理し、一貫性のある環境を構築できます。

主な特徴

構成管理: Chef/Puppet でサーバーを自動設定。

アプリケーションデプロイ: サーバーに自動的にアプリをデプロイ。

動的スケーリング: トラフィックに応じて EC2 インスタンスを自動スケール。

クロスプラットフォーム: Linux/Windows サポート。

ユースケース

一貫性のある環境構築と設定管理。

アクセス量に応じたインフラの自動スケーリング。

複数環境（開発/本番）への簡単なデプロイ。

メリット

柔軟な構成管理（Chef/Puppet 対応）。

アプリケーションとインフラの一元管理。

他サービスとの違い

特徴	AWS OpsWorks	AWS CodeDeploy
用途	構成管理＋デプロイ	デプロイのみ
構成管理ツール	Chef/Puppet 対応	なし

OpsWorks は構成管理が必要なケースに最適ですが、シンプルなデプロイには CodeDeploy のほうが適しています。

実践

略

一問道場

Question #363

ある企業のCISO（最高情報セキュリティ責任者）が、現在のCI/CD（継続的インテグレーション/継続的デプロイメント）プロセスを再設計するようソリューションアーキテクトに依頼しました。

目的:

脆弱性が発見された場合、アプリケーションのパッチデプロイメントを可能な限り迅速に行う。

ダウンタイムを最小限に抑える。

エラーが発生した場合には、迅速にロールバックできる。

現在の状況:

ウェブアプリケーションは、Application Load Balancerの背後に配置されたAmazon EC2インスタンス群でホストされている。

アプリケーションのソースコードはGitHubにホストされている。

AWS CodeBuildプロジェクトを使用してアプリケーションをビルドしている。

AWS CodePipelineを使用してGitHubのコミットからビルドをトリガーし、既存のCodeBuildプロジェクトを利用する予定。

要件をすべて満たすCI/CD構成はどれか？

選択肢:

CodePipelineにデプロイステージを設定し、AWS CodeDeployを使用したインプレースデプロイメントを構成する。

新しくデプロイされたコードを監視し、問題があれば別のコード更新をプッシュする。

CodePipelineにデプロイステージを設定し、AWS CodeDeployを使用したブルー/グリーンデプロイメントを構成する。

新しくデプロイされたコードを監視し、問題があればCodeDeployを使用して手動でロールバックをトリガーする。

CodePipelineにデプロイステージを設定し、AWS CloudFormationを使用してテストと本番スタック用のパイプラインを作成する。

新しくデプロイされたコードを監視し、問題があれば別のコード更新をプッシュする。

CodePipelineにデプロイステージを設定し、AWS OpsWorksとインプレースデプロイメントを使用する。

新しくデプロイされたコードを監視し、問題があれば別のコード更新をプッシュする。

解説

この問題では、CI/CDパイプラインの構成で、以下の要件を満たすことが求められています。

迅速なパッチデプロイメント: アプリケーションに脆弱性が発見された場合、できるだけ早くデプロイできること。

ダウンタイムの最小化: アプリケーションをアップデートする際、ユーザーに影響を与えない。

迅速なロールバック: 問題が発生した場合、迅速に以前のバージョンに戻せること。

選択肢の分析

A. インプレースデプロイメントを使用したCodeDeploy

メリット: 現在のインスタンスをその場で更新するため、リソース消費が少ない。

デメリット: デプロイ中にサービスが停止するリスクがある（ダウンタイムが発生する可能性がある）。

結論: ダウンタイムを最小化する要件を満たさないため不適切。

B. ブルー/グリーンデプロイメントを使用したCodeDeploy

メリット:

新しいコードを「ブルー」（現在稼働中の環境）から「グリーン」（新しい環境）に切り替える手法を使用する。
ダウンタイムをほぼゼロに抑えることが可能。
問題が発生した場合、簡単にブルー環境に切り戻す（ロールバック）ことができる。

結論: ダウンタイムの最小化と迅速なロールバックの要件を満たすため、最適な解答。

C. AWS CloudFormationを使用したスタックデプロイ

メリット: インフラ全体をコード化して管理できる。

デメリット: アプリケーションのデプロイにおけるダウンタイムやロールバック手法が具体的に述べられていない。

結論: ダウンタイムやロールバックの要件が曖昧なため不適切。

D. AWS OpsWorksを使用したデプロイ

メリット: アプリケーションの設定管理に適している。

デメリット: OpsWorksは主にChefを使用した設定管理に特化しており、CI/CDパイプライン全体の効率的なデプロイには向いていない。

結論: CI/CDソリューションとして適切ではない。

正解

B. CodeDeployを使用したブルー/グリーンデプロイメント

理由

ブルー/グリーンデプロイメントは、ダウンタイムを最小化しつつ、問題発生時に迅速なロールバックを可能にする。

AWS CodeDeployは、GitHubやCodePipelineと連携でき、既存の環境を活かしながら要件を満たす理想的な手法である。