こんにちは！エンタープライズクラウド部技術2課の日高です。
本日は、AWS CodeDeploy（今後は CodeDeploy と表記）を使い始めたいという方に向けて、デプロイグループを構築するうえで設定が必要なパラメータについて、概要を理解していただけるようにブログを書きたいと思います！
AWS CodeDeployの概要
AWS CodeDeployは、アプリケーションを自動的にデプロイ（展開）するためのサービスです。
このサービスは、Amazon EC2インスタンスやオンプレミスのサーバー、Amazon Lambda、Amazon ECS（コンテナサービス）などに対してアプリケーションデプロイを自動化します。
以下に、CodeDeployの主な特徴を記載します。
デプロイできるもの
- コードやプログラム
- サーバーレスのLambda関数（特定の動作をする小さなプログラムのこと）
- ウェブの内容や設定ファイル
- 実行可能なファイル
- アプリのパッケージ
- スクリプトや自動動作するコード
- マルチメディアファイル（画像や動画など）
どこからデプロイできるか
- Amazon S3
- コード保存場所（例：GitHubやBitbucket、AWS CodeCommitなど）
どんな利点があるか
- 新しい機能をすぐにリリースできる
- Lambda関数のバージョンを簡単に更新できる
- デプロイ時にサービスが止まることを防ぐ
- 手動でのアップロードミスなどを避けられる
- 小さいサービスから大きなサービスまで、スケールに応じて使える
AWS CodeDeployのデプロイグループ パラメータ一覧
デプロイグループの詳細
デプロイタイプ(Deployment type)
CodeDeploy ではインプレースデプロイ（現環境の更新）とBlue/Greenデプロイ（新環境を作成して置き換え）の2つのデプロイ方法があります。
しかし下記画像のように使用するプラットフォームにより使用できるデプロイ方法が違うので注意が必要です。
インプレースデプロイ
稼働中のインスタンスに対して直接新しいアプリケーションを配置、再起動する方法です。
デプロイの流れとしては以下です。
デプロイグループの各インスタンス上のアプリケーションを停止→最新のアプリケーションのインストール→新バージョンのアプリケーションの開始・検証
上記のようにインプレースデプロイを利用すると、「デプロイにかかる時間＋再起動にかかる時間」がダウンタイムとしてかかりますが、コストは後述のBlue/Greenデプロイに比べると低価格です。
また、ALBなどのロードバランサーを使用することでダウンタイムを最小化することができます。
ロードバランサーを使用することで、デプロイ中はインスタンスが登録解除され、デプロイ完了後にサービスに復元されるように設定できます。
Blue/Greenデプロイ
稼働中の環境とは別に最新のバージョンの環境を構築しておき、トラフィックを稼働中の環境から最新の環境に切り替えることでダウンタイム無しで環境を切り替えるデプロイ方法です。
特徴としてはダウンタイムはなしでデプロイすることができますが、古い環境と新しい環境が同時に混在する時間があるので、その時間は通常時の2倍のコストがかかってしまいます。
デプロイ設定(Deployffyment configuration)
どのようにデプロイするか（デプロイするスピードなど）を定義する設定になります。
AWSが用意している設定以外にも、独自のデプロイ設定を作成することも可能になっています。
今回は、AWSが用意しているデプロイ設定を見ていきますが、用意されている設定はコンピューティングプラットフォームにより変わります。
EC2/オンプレミス
AllAtOnce、HalfAtATime、OneAtATimeの３つから選択することができます。
- AllAtOnce
- 新しいバージョンのアプリケーションを同時にすべてのインスタンスにデプロイする設定です。
- つまり、一度に全てのインスタンスが更新されます。
- これは最も早くデプロイを完了できる方法ですが、デプロイ中はアプリケーションが利用できなくなることがあるため、ダウンタイムが許容されないアプリケーションには適していません。
- HalfAtATime:
- 2段階に分けてデプロイする設定です。
- まずはインスタンスの半分に新しいバージョンをデプロイし、それが成功したら残り半分にデプロイします。
- この方法では、いくつかのインスタンスは常に稼働しているため、デプロイ中も一部のサービスが利用できます。
- しかし、一部のインスタンスが更新中であるため、全体的なパフォーマンスは低下します。
- OneAtATime:
- 新しいバージョンを1つのインスタンスずつにデプロイする設定です。
- 各インスタンスへのデプロイが成功したら次に進みます。
- もし何か問題が発生すればすぐに影響を受けるのは1つのインスタンスだけです。
- しかし、この方法はデプロイに最も時間がかかるため、大規模な環境では適していない場合があります。
AWS Lambda/Amazon ECS
主にAllAtOnce、Canary、Linearの３種類の中からデプロイ方式を選択することができます。
- AllAtOnce
- EC2/オンプレミスのものと同様に全てのリソースに対して一度に新しいバージョンをデプロイする設定です。
- デプロイにかかる時間は他のものと比べ最も短いですが、もし何か問題があった場合、全てのリソースに影響を及ぼす可能性があります。
- Canary
- 2段階に分けてデプロイする設定です。
- まずは、全体の一部のリソース（例：全体の10%）に対して最初に新しいバージョンをデプロイします。
- その後、特定の時間（例：10分後）に残りのリソース（例：残りの90%）にデプロイします。
- このようなデプロイ設定のため、問題が発生した場合に影響を受けるのは全体の一部だけというメリットがあります。
- Linear
- 全体を等分に分けて一定間隔（例：10分ごと）に新しいバージョンをデプロイする設定です。
- 例えば、全体を10等分にして10分ごとにデプロイを行った場合、全体のデプロイが完了するまでに約100分かかります。
- 問題が発生した場合でも、すぐにデプロイを停止して影響を最小限に抑えることが可能です。
ロールバック(Rollback)
新しいバージョンのデプロイに問題が発生した場合に、旧バージョン（以前の安定したバージョン）に戻す設定になります。
CodeDeployでは手動ロールバックと自動ロールバックの２種類をサポートしています。
CodeDeployの画面で設定するロールバックは自動ロールバックを指しています。
下記の画像の２パターンに当てはまる際に自動的にロールバックするように、デプロイグループまたはデプロイを設定できます。
- デプロイが失敗したときにロールバックする。
- パラメータ値の言葉通り、デプロイ失敗した際に、以前の安定したバージョンを再デプロイします。
- アラームのしきい値が一致したときにロールバックする。
- 後述の「アラーム」を追加した場合、指定されたアラームが 1 つ以上アクティブになったときに、以前の安定したバージョンを再デプロイします。
トリガー(Triggers)
指定したイベント（デプロイメントのライフサイクルイベント）が起こった際にAmazon SNSに通知することができます。
これにより、デプロイメントの開始、成功、失敗などのイベントをAmazon SNSに通知し把握することができます。
上記画像（マネジメントコンソールの画面）にも記載されていますが、１つのデプロイグループに対して10個までのトリガーを作成できます。
また、Amazon SNSに通知を送信する前に、CodeDeploy に付与されているIAMロールへAmazon SNSへのアクセス許可を付与する必要があります。
※詳しくは以下をご覧ください。
通知できるイベントは現在下記の10種類存在しています。
- デプロイの開始
- デプロイの成功
- デプロイの失敗
- デプロイの停止
- デプロイの準備が整いました
- デプロイのロールバック
- インスタンスの開始
- インスタンスの成功
- インスタンスの失敗
- インスタンスの準備が整いました
アラーム(Alarms)
CodeDeployとCloudWatchを連携させることで、デプロイのプロセス中に問題が生じていないかをで監視する設定になります。
そして、何か問題が発生した場合はデプロイを自動的に停止することで問題の拡大を防ぐことができます。
CloudWatch アラームは、AWSの特定のメトリクス（例：CPU使用率やエラーの発生回数など）を監視して、設定した閾値を超えたり下回ったりしたときに通知やアクションを行う機能です。
※CloudWatch アラームについて、詳しくは以下をご覧ください。
CodeDeployでは、CloudWatchと連携することで下記の監視ができます。
- EC2のデプロイ: CodeDeployでデプロイする際のEC2インスタンスや、EC2 Auto Scalingグループの動作を監視するためのアラームを作成可能です。
- LambdaやECSのデプロイ: Lambdaでのエラーや、ECSの動作に関してもアラームを介して監視できます。
もし、設定した基準をメトリクスが下回った、または超えた場合、アラームがトリガーされ、デプロイは自動的に停止します。
これにより、不具合の影響を最小限に抑えることができます。
追加オプションとしては下記を選択できます。
- アラーム設定を無視する： 一時的にアラームの反応を無視したい場合、このオプションを有効にすることでAmazon CloudWatch アラームを確認するステップを省略できます。
- アラームの状態が利用できない場合でも、デプロイを続行する: CloudWatchからアラームの状態が取得できなくても、デプロイを進行させるためのオプションです。
まとめ
AWS CodeDeployを使い始めたいという方に向けて、必ず設定するであろうデプロイグループの設定に必要なパラメータについて説明してみました。
いかがだったでしょうか。
本記事が誰かの助けになれば幸いです。
日高 僚太(執筆記事の一覧)
EC部ソリューションアーキテクト2課 / AWS認定資格 12冠
2022年IT未経験で新卒入社しました。
最近はダーツとサウナが気になっています！
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp
