AWS Fargate タスクのリタイア通知による運用の可視性の向上

この記事は Improving operational visibility with AWS Fargate task retirement notifications (記事公開日 : 2023 年 9 月 6 日) の翻訳です。

導入

AWS Fargate は、コンテナワークロードのためのサーバーレスコンピューティングエンジンであり、基盤となるインフラストラクチャの保護やパッチ適用といった、ビジネスに付加価値をもたらさない作業から解放してくれます。この記事では、AWS がインフラストラクチャを安全かつ最新の状態に保つための仕組みの 1 つである Fargate タスクのリタイア通知について深掘りします。

AWS は、Fargate タスクのリタイアプロセスに関する最近のアップデートにおいて、お客様が受け取るリタイアに関する通知を統合し、リタイア通知を受け取ってから実際にタスクがリタイアするまでの時間を制御する仕組みを導入しました。この記事では、これらの変更点を詳しく確認し、リタイア通知を使用してオペレーショナルエクセレンスを実現する例を紹介します。

背景

AWS Fargate 上に Amazon Elastic Container Service (Amazon ECS) タスクをデプロイする際、スタンドアロンタスクを実行する API コールまたは ECS サービスにおいて、プラットフォームバージョンを指定します。プラットフォームバージョンは、カーネルとコンテナランタイムの組み合わせで構成される、ホスト OS のランタイム環境を指します。また、プラットフォームバージョンには、内部的に複数のプラットフォームバージョンリビジョンが存在します。プラットフォームバージョンリビジョンはイミュータブルであり、例えばカーネルのバグ修正やセキュリティアップデートなど、環境の変化に追従してリリースされます。新しいタスクが AWS Fargate にスケジューリングされると、指定されたプラットフォームバージョンの最新リビジョンでタスクが起動します。

AWS は、時間の経過とともに「タスクを実行中の既存のプラットフォームバージョンリビジョンをリタイアさせる必要がある」と判断することがあります。リビジョンがリタイアすると、AWS Fargate はそのリビジョンで実行中のすべてのタスクを終了します。リビジョンをリタイアさせる理由には、セキュリティの脆弱性やパフォーマンスの改善などがあります。AWS Fargate では、これまで月に 1、2 個のプラットフォームバージョンリビジョンをリタイアさせてきましたが、プラットフォームバージョンリビジョンには特に決まったサポート期間は存在しません。プラットフォームバージョンリビジョンのライフサイクルを考慮すると、短命のワークロードを実行している場合には、数週間にわたって実行されるタスクを実行している場合に比べて、リビジョンのリタイアに伴いタスクが終了する可能性は小さくなります。

上図は、AWS Fargate プラットフォームバージョンリビジョンのライフサイクル全体を示します。新しいプラットフォームバージョンリビジョンが利用開始されると、すべての新しいタスクは新しいリビジョンに配置されるようになります。すでに配置され、実行中の既存のタスクは、タスクのライフサイクル全体において最初に配置されたリビジョンに留まり、新しいリビジョンに移行することはありません。ECS サービスの更新や Fargate タスクのリタイアなどの理由でタスクが置き換えられる場合、新しいタスクは、起動時に利用可能な最新のプラットフォームバージョンリビジョンに配置されます。

タスクのリタイア

下図に、Fargate タスクのリタイアプロセスの全体像を示します。

特定のプラットフォームバージョンリビジョンをリタイアさせる必要がある場合、すべての AWS リージョンにおいて、AWS はそのプラットフォームバージョンリビジョンで実行中のすべてのタスクを特定します。その後、リージョンごと、アカウントごとに 1 つの通知を送信し、影響を受けるタスクやサービス、実際にリタイアプロセスが開始する日時を案内します。通知は、AWS アカウントのプライマリメールアドレスおよび AWS Health Dashboard に送信されます。AWS Health Dashboard に送信された通知は、Amazon EventBridge を通じて AWS サービスやサードパーティツールに転送できます。

リタイア通知が送信されてから AWS Fargate が自動的にタスクのリタイアプロセスを開始するまでの正確なタイミングを制御したい場合、タスクのリタイア待機時間と呼ばれる値を設定し、対応するための時間を指定できます。タスクが ECS サービスとして実行されている場合、AWS Fargate は ECS サービスの minimumHealthyPercent を考慮しつつタスクを置き換えます。スタンドアロンタスクの場合、実行中のタスクの状態を監視し、タスクを置き換えるのはお客様の責任です。

Fargate タスクのリタイアの影響を最小化するために、Amazon ECS ベストプラクティスに従ってワークロードをデプロイするべきです。例えば、ウェブサーバーや API サーバーなどのステートレスなアプリケーションを ECS サービスとしてデプロイする場合、タスクの複数のレプリカをデプロイし、minimumHealthyPercent を 100% に設定します。これにより、AWS Fargate がタスクのリタイアを開始した際に、Amazon ECS はまず新しいタスクをスケジューリングし、実行されるのを待ってから、古いタスクを終了します。

タスクのリタイアプロセスの詳細については、AWS Fargate ドキュメントを参照してください。

タスクのリタイア待機時間

タスクのリタイア待機時間の値は、Amazon ECS アカウント設定内の fargateTaskRetirementWaitPeriod で制御できるようになりました。例えば、特定のウィンドウでのみ停止可能なワークロードを実行している場合、タスクのリタイア待機時間を使用して、独自のスケジュールでタスクを終了するように設定できます。

タスクのリタイア待機時間には、以下の表のいずれかの値を設定できます。新しいプラットフォームバージョンリビジョンをより早く適用するために、できる限り待機時間を短く設定することをおすすめします。

日数	アクション
0	通知を送信してすぐに、影響を受けるタスクのリタイアを開始します。
7	通知を送信してから 7 日後に、影響を受けるタスクのリタイアを開始します。
14	通知を送信してから 14 日後に、影響を受けるタスクのリタイアを開始します。

稀に重大なセキュリティアップデートがある場合、AWS Fargate は設定したタスクのリタイア待機時間を上書きし、待機時間無しで対象のタスクをリタイアさせることがあります。この場合、fargateTaskRetirementWaitPeriod を 0 に設定した場合と同じ挙動となります。

現在の fargateTaskRetirementWaitPeriod の値は、aws ecs list-account-settings コマンドで確認できます。

$ aws ecs list-account-settings \
    --name fargateTaskRetirementWaitPeriod \
    --effective-settings
{
    "settings": [
        {
            "name": " fargateTaskRetirementWaitPeriod",
            "value": "14",
            "principalArn": "arn:aws:iam::123456789012:root"
        }
    ]
}

fargateTaskRetirementWaitPeriod を変更したい場合は、aws ecs put-account-setting-default コマンドを使用します。

$ aws ecs put-account-setting-default \
    --name fargateTaskRetirementWaitPeriod \
    --value 14

タスクのリタイア待機時間の詳細については、Amazon ECS ドキュメントと Amazon ECS 開発者ガイドを参照してください。

ソリューション概要 : タスクのリタイア通知を捕捉する

タスクのリタイアが予定されている場合、AWS は AWS Health Dashboard と AWS アカウントのプライマリメールアドレスにタスクのリタイア通知を送信します。AWS Health Dashboard は、Amazon EventBridge を含む多くの AWS サービスと統合されています。Amazon EventBridge を利用することで、ChatOps ツールに通知を転送してリタイアの可視性を高めたり、タスクのリタイア通知への対応を自動化することもできます。

AWS Health Aware は、AWS Health Dashboard のパワーと通知を組織全体に配布する方法を紹介する素晴らしいリソースです。このプロジェクトを参考に、タスクのリタイア通知をチャットアプリケーションである Slack に転送する例を紹介します。このソリューションでは、タスクのリタイア通知は EventBridge ルールによって捕捉され、Event Detail Type が AWS Health Event かつ Event Detail Code が AWS_ECS_TASK_PATCHING_RETIREMENT であるイベントがフィルタリングされます。ルールが通知を捕捉すると、AWS Lambda 関数をトリガーし、影響を受けるリソースのイベントを解析、Slack Incoming Webhook に転送します。

下図に、このソリューションのアーキテクチャを示します。

前提条件

ソリューションのウォークスルーを実施するには、以下の前提条件を満たす必要があります。

Incoming Webhook Slack アプリケーションがインストール、有効化された既存の Slack ワークスペース
Amazon EventBridge ルールと AWS Lambda 関数をデプロイするための権限を持つ AWS アカウント
AWS SAM CLI がインストールされたローカル開発環境

ウォークスルー

このウォークスルーのサンプルコードは GitHub リポジトリで確認できます。まず最初のステップとして、リポジトリをローカル開発環境にクローンします。

$ git clone https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications.git
$ cd capturing-aws-fargate-task-retirement-notifications

次に、AWS SAM テンプレート (cloudformation.yaml) で定義した Lambda 関数と EventBridge ルールをビルド、デプロイします。デプロイウィザードでは、Slack ワークスペース URL や Slack チャンネルなどのパラメータを入力する必要があります。

$ sam build --template cloudformation.yaml 
$ sam deploy --guided
Configuring SAM deploy
======================

     Looking for config file [samconfig.toml] :  Not found

    Setting default arguments for 'sam deploy'
    =========================================
    Stack Name [sam-app]: FargateTaskRetirementNotifications
    AWS Region [eu-west-1]: eu-west-1
    Parameter SlackWorkspaceURL []: https://hooks.slack.com/services/workspace/app/token
    Parameter SlackChannel []: platform-eng
    #Shows you resources changes to be deployed and require a 'Y' to initiate deploy
    Confirm changes before deploy [y/N]: y
    #SAM needs permission to be able to create roles to connect to the resources in your template
    Allow SAM CLI IAM role creation [Y/n]:        
    #Preserves the state of previously provisioned resources when an operation fails
    Disable rollback [y/N]: 
    Save arguments to configuration file [Y/n]: 
    SAM configuration file [samconfig.toml]: 
    SAM configuration environment [default]:

それでは、テストしましょう！ここでは、Amazon EventBridge に 2 つのサンプルイベントを送信し、期待通りに動作することを確認します。AWS Health の通知を再現することはできないので、代わりに EventBridge ルールにマッチする EventBridge イベントを作成して、ワークフローをトリガーします。サンプルリポジトリには、ECS サービスとしてデプロイされたタスク用と、スタンドアロンタスク用の 2 つのイベントが用意されています。

$ aws events put-events --entries file://sample_service_event.json
$ aws events put-events --entries file://sample_task_event.json

Slack ワークスペースにて、テストイベントごとに 1 つ、合わせて 2 つの Slack 通知を確認できるはずです。

後片付け

ウォークスルーで作成したリソースを削除するには、sam delete コマンドで CloudFormation スタックを削除します。

まとめ

この記事では、Fargate タスクのリタイアプロセスについて深堀りし、リタイア通知からタスクのリタイアまでの時間を制御したい場合に、タスクのリタイア待機時間を変更する方法を紹介しました。その後、Amazon EventBridge と AWS Lambda を使用してタスクのリタイア通知を捕捉する方法を紹介しました。Fargate タスクのリタイアの詳細については、AWS Fargate ドキュメントを参照してください。

Amazon Web Services ブログ