見出し画像

【AWS】 CodeDeployの解説

CodeDeploy

アプリケーションを自動的にデプロイするためのサービス。これにより、EC2インスタンス、オンプレミスサーバー、Lambda関数などに対して、一貫したプロセスでアプリケーションを展開できる。デプロイメントの手動作業を削減し、ヒューマンエラーを減らすとともに、アプリケーションの更新を迅速かつ確実に行うことが可能。また、段階的なデプロイやロールバック機能を備えており、問題が発生した場合には以前のバージョンに迅速に戻すことができる。これにより、システムの可用性を高く保ちながら、安全にデプロイを実行できる。


主コンポーネント

アプリケーション

CodeDeployで管理されるデプロイ対象のソフトウェア。アプリケーションは、デプロイしたいコードやリソースを指すもので、これに対して複数のデプロイグループを設定して異なる環境に展開できる。例えば、同じアプリケーションを開発環境、本番環境、テスト環境にデプロイすることが可能。

アプリケーションの設定項目

  1. アプリケーション名

    • アプリケーションを識別するための名前。CodeDeployで管理する複数のアプリケーションの中から特定のアプリケーションを識別するために使用される。

  2. コンピュータープラットフォーム

    • アプリケーションがデプロイされるプラットフォームを指定する。例えば、EC2/オンプレミス、AWS Lambda、またはAmazon ECSなどが選択肢に含まれる。

  3. デプロイグループ

    • アプリケーションをデプロイする際のターゲットリソースのグループ。1つのアプリケーションに対して複数のデプロイグループを設定できる。各デプロイグループは、デプロイする対象のリソース(例えば、特定のEC2インスタンス、Lambda関数、ECSタスクなど)を指定する。

  4. リビジョンの指定

    • デプロイするアプリケーションのバージョンやアーティファクト(ソースコード、バイナリ、設定ファイルなど)を指定する。リビジョンはS3バケットやGitHubリポジトリなどから取得される。

  5. AppSpecファイル

    • アプリケーションのデプロイメントの具体的な手順や処理を記述する設定ファイル。AppSpecファイルには、デプロイメントの各ステージ(BeforeInstall、Install、AfterInstallなど)で実行するスクリプトやコマンドが記載される。

  6. デプロイ設定の関連付け

    • アプリケーションのデプロイメントに使用するデプロイ設定を指定する。ここでは、インプレースデプロイかBlue/Greenデプロイを選ぶか、またはデプロイの進行に関する詳細な設定(最小稼働インスタンス数やデプロイの順序など)を行う。

  7. タグフィルター(オプション)

    • 特定のタグに基づいてデプロイ対象をフィルタリングする設定。例えば、特定の環境(ステージングやプロダクション)にだけデプロイしたい場合、リソースにタグを設定して、タグに基づいてデプロイ先を絞り込むことができる。

  8. トリガーの設定

    • デプロイメントイベントに基づいてトリガーを設定できる。例えば、デプロイが成功したときや失敗したときにSNS通知を送信する、あるいは特定のLambda関数を実行するような設定が可能。

  9. ロールバック設定

    • デプロイに失敗した場合に、以前の安定したバージョンに自動的に戻す(ロールバック)ための設定。これは、システムの安定性を確保するための重要な機能。


デプロイグループ

ターゲットリソースのグループ。EC2インスタンス、オンプレミスサーバー、AWS Lambda関数、Amazon ECSサービスなどが含まれる。デプロイグループは、特定のサーバーセットや特定のAWSリソースに対して、どうやってデプロイを行うかを指定する役割がある。例えば、本番環境用とテスト環境用に異なるデプロイグループを作成することで、異なるリソースに対して異なるデプロイ戦略を採用できる。

デプロイグループの設定項目

  • アプリケーション: ここでは、デプロイする対象のアプリケーションを指定する。すでにCodeDeployに登録されたアプリケーション名を選択することになる。これにより、デプロイグループがどのアプリケーションに関連付けられているかが決まる。

  • EC2/オンプレミス: デプロイするターゲットリソースのタイプを選択する。EC2インスタンスかオンプレミスサーバーのいずれかを選ぶ。これにより、デプロイメントがAWSクラウド上のEC2リソースに行われるか、またはオンプレミスのサーバーに行われるかが決まる。

  • デプロイグループ名: デプロイグループの識別子として使用される名前を入力する。名前は100文字以内で設定する必要がある。これにより、同じアプリケーションに複数のデプロイグループを設定する場合に、それぞれを区別できる。

  • サービスロール: AWS CodeDeployが指定されたターゲットインスタンスにアクセスするための権限を持つIAMロールを指定する。サービスロールは、CodeDeployがインスタンスにアクセスし、デプロイメントを実行するために必要な権限を提供する。

  • インプレース: 既存のインスタンス上で新しいバージョンに上書きする方法。デプロイ中に各インスタンスが一時的にオフラインになる。

  • Blue/Green: 新しいインスタンスを作成して新しいバージョンをデプロイし、トラフィックを新しいインスタンスに切り替える方法。元のインスタンスはデプロイ後に停止または終了できる。

  • Amazon EC2 Auto Scaling グループ: 自動スケーリングによって管理されるEC2インスタンスのグループを選択する。自動スケーリンググループは、必要に応じてインスタンス数を動的に調整する。

  • Amazon EC2 インスタンス: デプロイする特定のEC2インスタンスを選択する。これにより、どのインスタンスにデプロイメントが行われるかを明確にする。

  • オンプレミスインスタンス: オンプレミス環境のサーバーにデプロイする場合、ここで指定する。

  • デフォルトおよびカスタムデプロイ設定: デプロイの進行方法や速度を制御するためのルールを定義する設定を選択する。例えば、全インスタンスに一度にデプロイする「CodeDeployDefault.AllAtOnce」や、段階的にデプロイするカスタム設定などが含まれる。

  • デプロイ設定の作成: 必要に応じて新しいデプロイ設定を作成し、カスタマイズしたデプロイメント戦略を適用することも可能。

  • ロードバランサーのタイプ: デプロイ中にトラフィックを管理するロードバランサーを選択する。選択肢としては、Application Load Balancer、Network Load Balancer、Classic Load Balancerがある。ロードバランサーを使うことで、デプロイ中のインスタンスへのトラフィックを制御し、デプロイが完了した後にのみトラフィックを再開することができる。

  • トリガーの作成: デプロイメントイベントが発生したときに特定のアクションを実行する設定。例えば、デプロイが成功したときや失敗したときにSNS通知を送信するなどのアクションを設定できる。

  • アラームの追加: デプロイ中に特定の条件(例えばCPU使用率が高すぎるなど)が発生した場合にトリガーされるCloudWatchアラームを設定する。アラームに基づいてデプロイメントを中断したり、ロールバックを実行したりすることができる。

  • アラーム設定を無視する: デプロイプロセス中にアラーム設定を無視するオプション。特定の状況下でデプロイメントを継続するための設定。

  • デプロイが失敗したときにロールバックする: デプロイが失敗した場合に、以前のバージョンに自動的に戻す設定。

  • アラームのしきい値が一致したときにロールバックする: アラームが特定のしきい値を超えた場合にロールバックをトリガーする。

  • ロールバックを無効にする: ロールバック機能をオフにする設定。

  • タグの追加: デプロイグループにタグを追加し、リソースの識別やフィルタリングに役立てる。タグはデプロイグループの管理や整理に便利。


デプロイ設定

AWS CodeDeployにおいて「どうやってデプロイを実行するか」を細かくコントロールするための設定。デプロイタイプの選択から、デプロイの進行方法、システムの可用性管理、問題発生時の対応までを設定する

デプロイのデフォルト設定

  • 1, CodeDeployDefault.AllAtOnce

    • 説明: すべてのインスタンスまたはタスクセットに一度に新しいバージョンをデプロイする。これは最速でデプロイが完了するが、問題が発生した場合には影響が大きいため、リスクが高い場合に使用するのは避けられることが多い。

  • 2, CodeDeployDefault.OneAtATime

    • 説明: 一度に1つのインスタンスまたはタスクにのみデプロイする方法。安全性が高く、問題が発生しても影響が最小限に抑えられるため、ミッション・クリティカルな環境でよく使われる。

  • 3, CodeDeployDefault.HalfAtATime

    • 説明: 半分のインスタンスまたはタスクセットにデプロイし、残り半分をその後にデプロイする方法。リスクと速度のバランスが取れた設定で、安定性を保ちながらデプロイの速度も確保したい場合に適している。

  • 4, CodeDeployDefault.ECSCanary10Percent5Minutes

    • 説明: 最初に10%のトラフィックを新しいタスクセットに移行し、5分後に残りの90%のトラフィックを移行する「カナリアデプロイメント」。最初に少量でテストを行い、その後問題がなければ一気に移行する方法。

  • 5, CodeDeployDefault.ECSLinear10PercentEvery1Minutes

    • 説明: 毎分10%のトラフィックを新しいタスクセットに移行し、すべてのトラフィックが移行されるまで繰り返す「リニアデプロイメント」。トラフィックを段階的に移行するため、問題が発生した場合に早期に検知しやすい。

  • ECSに関する設定(4と5)は、EC2/オンプレミス環境には適用されない。


デプロイの設定項目

デプロイ設定名

  • 内容: デプロイ設定を識別するための名前を指定する。最大100文字まで入力可能。この名前を使って他の設定から参照するため、わかりやすい名前をつけるのが望ましい。

コンピューティングプラットフォーム

  • 内容: デプロイメントを行うプラットフォームを選択する。選択肢には「EC2/オンプレミス」、「AWS Lambda」、「Amazon ECS」がある。選んだプラットフォームによって、次の設定項目が変わる。

EC2/オンプレミスプラットフォームの場合

  • 正常なホストの最小数:

    • 割合 (%) または数値: デプロイ中に常に利用可能であるべき正常なインスタンスの数や割合を指定する。例えば、デプロイ中にサービスが継続できるよう、最小限の稼働インスタンスを定義する。

    • : 1から99の整数を指定し、最低限稼働している必要があるインスタンスの割合を決める。

  • 追加設定 - ゾーン設定:

    • ゾーン設定の有効化: このオプションを有効にすると、AWSリージョン内のアベイラビリティーゾーン(AZ)ごとにデプロイが行われるようになる。一度に1つのゾーンにのみデプロイし、その後他のゾーンへ展開する。これにより、段階的なデプロイが可能になる。


AWS Lambdaのデプロイ設定

  1. Canaryデプロイ

    • 概要: 最初に少量のトラフィックを新しいバージョンに移行し、その後、残りのトラフィックを指定した時間後に移行する方法。これにより、最初に少ない影響で新バージョンをテストでき、問題がなければ残りのトラフィックを移行できる。

    • :

      • CodeDeployDefault.LambdaCanary10Percent5Minutes: 最初にトラフィックの10%を新しいバージョンに移行し、5分後に残りの90%を移行する。

      • CodeDeployDefault.LambdaCanary10Percent15Minutes: 最初に10%を移行し、15分後に残りを移行する。

  2. リニアデプロイ

    • 概要: トラフィックを一定の割合で段階的に新しいバージョンに移行する方法。例えば、毎分10%ずつトラフィックを新しいバージョンに移行することで、段階的にリスクを分散できる。

    • :

      • CodeDeployDefault.LambdaLinear10PercentEvery1Minute: 毎分10%のトラフィックを移行し、すべてのトラフィックが移行されるまで繰り返す。

      • CodeDeployDefault.LambdaLinear10PercentEvery3Minutes: 毎3分ごとに10%のトラフィックを移行。

Amazon ECSのデプロイ設定

Amazon ECSでも、Lambdaと同様にCanaryとリニアのデプロイ方法が利用できる。

  1. Canaryデプロイ

    • 概要: 最初に少量のトラフィックを新しいタスクセットに移行し、残りのトラフィックを指定された時間後に移行する方法。新しいコンテナに問題がないことを確認した後に、残りのトラフィックを移行する。

    • :

      • CodeDeployDefault.ECSCanary10Percent5Minutes: 最初にトラフィックの10%を新しいタスクセットに移行し、5分後に残りの90%を移行する。

      • CodeDeployDefault.ECSCanary10Percent15Minutes: 最初に10%を移行し、15分後に残りを移行する。

  2. リニアデプロイ

    • 概要: トラフィックを一定の割合で段階的に新しいタスクセットに移行する方法。これにより、段階的に移行しながら新しいバージョンの安定性を確認することができる。

    • :

      • CodeDeployDefault.ECSLinear10PercentEvery1Minutes: 毎分10%のトラフィックを移行し、すべてのトラフィックが移行されるまで繰り返す。

      • CodeDeployDefault.ECSLinear10PercentEvery3Minutes: 毎3分ごとに10%のトラフィックを移行。


関係性のまとめ

  • アプリケーションは、デプロイされる対象全体を管理するもので、その中に複数のデプロイグループが存在する。

  • デプロイグループは、アプリケーションをデプロイするリソースや環境を定義し、各デプロイグループごとにデプロイ設定を関連付けることで、具体的なデプロイの方法を指定する。

  • デプロイ設定は、デプロイグループの中でどのようにデプロイを実行するかを細かく制御するための設定。


インプレースデプロイ

既存のインスタンス上でアプリケーションの新しいバージョンをデプロイする際に、基本的にインスタンスが一時的にオフラインになる。ただし、これは必ずしも全体のサービスが完全にダウンするわけではない。

なぜ一時的にオフラインになるのか

インプレースデプロイでは、アプリケーションの旧バージョンを停止し、新しいバージョンをインストールして再起動するプロセスが必要になる。この一連の手順により、デプロイ中にインスタンスが一時的にアプリケーションを提供できない状態になるため、オフライン状態が発生するんだ。

オフライン状態を避ける方法

完全なオフラインを避けるためには、以下のような方法がある:

  1. ロードバランサーとヘルスチェック: デプロイメント中にロードバランサーを利用し、デプロイされるインスタンスからトラフィックを一時的に除外し、デプロイ完了後に再度トラフィックを戻す。これにより、他のインスタンスが引き続きトラフィックを処理できるため、全体としてのサービスのダウンタイムを最小限に抑えることができる。

  2. 一部ずつのデプロイ: インスタンスを一つずつ段階的にデプロイすることで、常に少なくとも一部のインスタンスが稼働している状態を保つことができる。この方法を利用すると、全インスタンスが同時にオフラインになるのを防げる。

  3. Blue/Greenデプロイ:新しいバージョンを既存の環境とは別に用意した新しいインスタンス(または環境)にデプロイする方法。たとえば、「Blue」環境が現在稼働中で、「Green」環境に新しいバージョンをデプロイし、動作確認後、トラフィックを「Blue」から「Green」に切り替える。もし問題が発生した場合、簡単に元の「Blue」環境に戻すことができる。これにより、ダウンタイムをほぼゼロに抑えることができる。








































いいなと思ったら応援しよう!

Ken @ インフラエンジニア
よろしければサポートお願いします!よりいい情報を発信します。