344-AWS SAP AWS 「理論・実践・一問道場」変更セット

type

status

date

slug

summary

理論

1. CI/CDパイプライン

*CI（継続的インテグレーション）とCD（継続的デリバリー/デプロイメント）**は、ソフトウェア開発における自動化されたプロセスで、コードの変更が迅速かつ確実に本番環境に反映されるようにします。

CI: コードの統合とビルドを自動化するプロセス。コードがリポジトリにプッシュされるたびに、ビルドとテストが自動で実行されます。

CD: テストが成功したコードを自動的に本番環境にデプロイするプロセス。これにより、変更がすぐに本番環境で反映され、迅速に機能追加やバグ修正を行えます。

2. AWS CloudFormation

CloudFormationは、AWSリソースをコードで定義するためのサービスです。インフラストラクチャをテンプレートとして管理し、テンプレートに基づいてリソースを自動的に作成・更新できます。

リソースの依存関係: CloudFormationは、リソース間の依存関係を自動的に解決し、適切な順序でリソースを作成します。しかし、変更の際に適切な評価を行わないと、予期しないダウンタイムが発生することがあります。

3. 変更セット（Change Sets）

変更セットは、CloudFormationでリソースを変更する際に、新しい変更がどのように既存のリソースに影響を与えるかを事前に確認する機能です。これを使用することで、デプロイ前にリソースの変更を検証し、誤った変更が本番環境に影響を及ぼさないようにできます。

4. Blue/Greenデプロイメント

Blue/Greenデプロイメントは、アプリケーションの新しいバージョンを安全に展開する方法です。2つの環境（青と緑）を用意し、青環境が現在の本番環境、緑環境が新しいバージョンをホストします。

青環境（Blue）: 現在稼働している本番環境
緑環境（Green）: 新しいバージョンを展開した環境

新しいバージョンが緑環境でテストされ、問題がなければトラフィックを緑環境に切り替えます。問題が発生した場合は、即座に青環境にロールバックできます。この手法はダウンタイムを最小化し、リスクを軽減します。

5. AWS CodeDeploy

AWS CodeDeployは、アプリケーションの自動デプロイを管理するサービスで、EC2インスタンス、オンプレミスサーバ、Lambda関数、さらにはECS（コンテナ）のデプロイにも対応しています。Blue/Greenデプロイメントやローリングデプロイメントなど、さまざまなデプロイメント戦略をサポートしています。

Blue/Greenデプロイメントパターンでは、新しいバージョンを一度に全てのインスタンスに展開するのではなく、特定のインスタンスにだけ展開し、テストを行いながら本番環境に反映させることができます。

6. 自動テストとステージング環境

自動テスト: CI/CDパイプラインの一環として、コードが本番環境にデプロイされる前に自動テストを実行することは、エラーや不具合を早期に発見するために非常に重要です。

ステージング環境: 本番環境とほぼ同じ設定の環境でテストを実施することにより、本番環境での問題を事前に検出できます。特にCloudFormationのようなインフラ構成管理ツールを使用している場合、リソースが実際に作成される前に仮想環境で変更の影響を確認できます。

7. 監視とロギング

Amazon CloudWatch: AWSサービスの監視とロギングを行い、CI/CDパイプラインにおけるデプロイの状態やアプリケーションの動作をリアルタイムで追跡します。問題が発生した場合には、CloudWatchアラームで通知を受け取ることができます。

結論

CI/CDパイプラインにおける変更のリスク管理や安全なデプロイメントには、CloudFormationテンプレートの適切な管理、テスト環境での事前検証、そしてBlue/Greenデプロイメントなどの戦略を活用することが重要です。これらを組み合わせることで、予期しないダウンタイムを減らし、効率的かつ安全にアプリケーションの更新を行うことができます。

実践

略

一問道場

質問 #344

ある企業は、アプリケーションのCI/CDにAWS CodePipelineを使用しています。すべてのAWSリソースはAWS CloudFormationテンプレートで定義されており、アプリケーションのアーティファクトはAmazon S3バケットに格納され、インスタンスのユーザーデータスクリプトを使用してAuto Scalingグループにデプロイされています。アプリケーションが複雑になるにつれて、CloudFormationテンプレートのリソース変更が原因で予定外のダウンタイムが発生しています。

テンプレートの変更がダウンタイムを引き起こす可能性を減らすために、ソリューションアーキテクトはCI/CDパイプラインをどのように改善すべきでしょうか？

A. デプロイスクリプトを適応させて、デプロイ時にCloudFormationのエラー条件を検出し、報告できるようにする。変更を本番環境に承認する前に、テストチームが非本番環境でテスト計画を実行するようにする。

B. AWS CodeBuildを使用してテスト環境で自動化テストを実行する。CloudFormation変更セットを使用して、デプロイ前に変更を評価する。AWS CodeDeployを使用して、評価と変更の取り消しが可能な青/緑デプロイメントパターンを活用する。

C. 統合開発環境（IDE）用のプラグインを使用してテンプレートのエラーをチェックし、AWS CLIを使用してテンプレートが正しいかどうかを検証する。デプロイコードを適応させて、エラー条件をチェックし、エラー時に通知を生成する。テスト環境にデプロイして手動テスト計画を実行し、本番環境への変更を承認する。

D. AWS CodeDeployと青/緑デプロイメントパターンを使用して、CloudFormationでユーザーデータデプロイスクリプトを置き換える。オペレーターが実行中のインスタンスにログインし、アプリケーションが期待通りに動作しているかを手動で確認する。

解説

この問題は、CI/CDパイプラインの改善方法についての質問です。特に、CloudFormationテンプレートの変更が原因で発生した計画外のダウンタイムを減らす方法を問われています。

シナリオの概要

CI/CDツール: AWS CodePipeline

インフラ: EC2 Auto Scalingグループにデプロイ

リソース管理: すべてAWS CloudFormationテンプレートで管理

アプリケーションのアーティファクト: Amazon S3に格納、EC2インスタンスのユーザーデータスクリプトを使用してAuto Scalingグループにデプロイ

問題: アプリケーションが複雑化する中で、CloudFormationテンプレートの変更により予期せぬダウンタイムが発生している

問題の本質

CloudFormationテンプレートに変更が加わると、それに基づいたリソースの作成・変更が自動で行われます。この自動化の過程で、リソースの依存関係や変更が正しく処理されない場合、ダウンタイムが発生するリスクがあります。

目指すべき改善点

テンプレート変更によるリスクを最小化し、ダウンタイムを減らすためには、テンプレートの変更を事前に評価し、テストを実施し、問題があればすぐに回避できる仕組みを作ることが必要です。

各選択肢の解説

A. テスト計画の作成とエラーチェック

選択肢Aでは、デプロイスクリプトを修正してCloudFormationのエラーを検出し、テストチームに事前にテストを行ってもらうという方法です。これも有効ですが、手動での検証が必要なため、完全な自動化には不十分です。

B. 自動テストとCloudFormation変更セット、AWS CodeDeployの利用

選択肢Bは、AWS CodeBuildで自動テストを行い、CloudFormation変更セットを使用して事前に変更を評価し、AWS CodeDeployを使ったBlue/Greenデプロイメントを導入する方法です。これにより、変更が本番環境に影響を与える前にテストでき、問題があれば簡単にロールバックできるため、ダウンタイムを減らすことができます。