363-AWS SAP AWS 「理論・実践・一問道場」ブルー/グリーンデプロイメント
理論
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構成はどれか？
選択肢:
A.
CodePipelineにデプロイステージを設定し、AWS CodeDeployを使用したインプレースデプロイメントを構成する。
新しくデプロイされたコードを監視し、問題があれば別のコード更新をプッシュする。
B.
CodePipelineにデプロイステージを設定し、AWS CodeDeployを使用したブルー/グリーンデプロイメントを構成する。
新しくデプロイされたコードを監視し、問題があればCodeDeployを使用して手動でロールバックをトリガーする。
C.
CodePipelineにデプロイステージを設定し、AWS CloudFormationを使用してテストと本番スタック用のパイプラインを作成する。
新しくデプロイされたコードを監視し、問題があれば別のコード更新をプッシュする。
D.
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と連携でき、既存の環境を活かしながら要件を満たす理想的な手法である。
- Author:minami
- URL:https://www.minami.ac.cn/private-license/178d7ae8-88e2-804f-863d-efd8e0b92c06
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
