Amazon ECS のスロットリングに関する問題を処理する

スロットリングエラーは、同期スロットリングと非同期スロットリングの 2 つの主要なカテゴリに分類されます。

同期スロットリング

同期スロットリングが発生すると、すぐに Amazon ECS からエラーレスポンスが届きます。このカテゴリのスロットリングは通常、タスクの実行中またはサービスの作成中に Amazon ECS API を呼び出すと発生します。影響を受けるスロットリングと関連するスロットリング制限の詳細については、「Amazon ECS API リクエストのスロットリング」を参照してください。

アプリケーションが、AWS CLI、AWS SDK などを使用して API リクエストを開始すると、API スロットリングを修正できます。そのためには、エラーを処理するようにアプリケーションを設計するか、API コールの再試行ロジックを使用してエクスポネンシャルバックオフとジッター戦略を実装します。詳細については、「タイムアウト、リトライ、ジッターによるバックオフ」を参照してください。

AWS SDK を使用する場合、自動再試行ロジックはすでに組み込まれており、設定可能です。

Amazon ECS での非同期スロットリング

非同期スロットリングは、Amazon ECS または AWS CloudFormation がユーザーに代わって API を呼び出してリソースをプロビジョニングする非同期ワークフローが原因で発生する場合があります。Amazon ECS がユーザーに代わって呼び出す AWS API がどれなのかを知ることは重要です。たとえば、CreateNetworkInterface API は awsvpc ネットワークモードを使用するタスクに対して呼び出され、DescribeTargetHealth API はロードバランサーに登録されたタスクのヘルスチェックを実行するときに呼び出されます。

ワークロードがかなり大きくなると、これらの API オペレーションがスロットリングされる可能性があります。つまり、Amazon ECS や呼び出される AWS のサービス による制限を超えるほどスロットリングされる可能性があります。たとえば、数百のサービスをデプロイし、それぞれが awsvpc ネットワークモードを使用する数百のタスクを同時に実行する場合、Amazon ECS は CreateNetworkInterface などの EC2 API 操作および RegisterTarget、DescribeTargetHealth などの Elastic Load Balancing API 操作を呼び出し、それぞれエラスティックネットワーク、ロードバランサーを登録します。これらの API コールが API の制限を超えると、スロットリングエラーが発生する可能性があります。以下は、サービスイベントメッセージに含まれる Elastic Load Balancing スロットリングエラーの例です。

{
   "userIdentity":{
      "arn":"arn:aws:sts::111122223333:assumed-role/AWSServiceRoleForECS/ecs-service-scheduler",
      "eventTime":"2022-03-21T08:11:24Z",
      "eventSource":"elasticloadbalancing.amazonaws.com",
      "eventName":" DescribeTargetHealth ",
      "awsRegion":"us-east-1",
      "sourceIPAddress":"ecs.amazonaws.com",
      "userAgent":"ecs.amazonaws.com",
      "errorCode":"ThrottlingException",
      "errorMessage":"Rate exceeded",
      "eventID":"0aeb38fc-229b-4912-8b0d-2e8315193e9c"
   }
}

これらの API コールがアカウント内の他の API トラフィックと制限を共有している場合、サービスイベントとして送信されても監視が難しい場合があります。

スロットリングを監視する

どの API リクエストがスロットリングされ、誰がリクエストを発行したかを特定することが重要です。AWS CloudTrail を使用すると、スロットリングを監視し、CloudWatch、Amazon Athena、Amazon EventBridge と統合できます。CloudWatch Logs にイベントを送信するように CloudTrail を設定することができます。CloudWatch Logs のログインサイトはイベントを解析して分析します。これにより、呼び出しを行ったユーザーや IAM ロール、行われた API コールの数など、スロットリングイベントの詳細が特定されます。詳細については、「Amazon CloudWatch Logs で CloudTrail ログファイルを監視する」を参照してください。

CloudWatch Logs Insights の詳細および、ログファイルのクエリ方法については、「CloudWatch Logs Insights を使用したログデータの分析」を参照してください。

Amazon Athena では、標準 SQL を使用してクエリを作成し、データを分析できます。たとえば、Athena テーブルを作成して CloudTrail イベントを解析することができます。詳細については、「CloudTrail コンソールを使用して CloudTrail ログ用 Athena テーブルを作成する」を参照してください。

Athena テーブルを作成したら、次のような簡単な SQL クエリを使用して ThrottlingException エラーを調査できます。

select eventname, errorcode,eventsource,awsregion, useragent,COUNT(*) count
FROM cloudtrail-table-name
where errorcode = 'ThrottlingException'
AND eventtime between '2022-01-14T03:00:08Z' and '2022-01-23T07:15:08Z'
group by errorcode, awsregion, eventsource, username, eventname
order by count desc;

Amazon ECS は、Amazon EventBridge にもイベント通知を送信します。リソース状態変更イベントおよびサービスアクションイベントがあります。これらには、ECS_OPERATION_THROTTLED、SERVICE_DISCOVERY_OPERATION_THROTTLED などの API スロットリングイベントが含まれます。詳細については、「Amazon ECS サービスアクションイベント」を参照してください。

これらのイベントは、応答アクションを実行する目的で、AWS Lambda などのサービスによって利用される可能性があります。詳細については、「Amazon ECS イベントの処理」を参照してください。

スタンドアロンタスクを実行する場合、RunTask などの一部の API 操作は非同期となり、再試行操作は自動的に実行されません。このような場合は、EventBridge と統合している AWS Step Functions などのサービスを使用して、スロットリングされた操作や失敗した操作を再試行できます。詳細については、「コンテナタスクの管理 (Amazon ECS、Amazon SNS)」を参照してください。

CloudWatch を使用してスロットリングを監視する

CloudWatch では、[AWS リソース別] で Usage ネームスペースの API 使用状況をモニタリングできます。これらのメトリクスは タイプ [API]、メトリック名 [CallCount] で記録されます。これらのメトリクスが特定のしきい値に達するたびに開始するアラームを作成できます。詳細については、「サービスクォータの視覚化とアラームの設定」を参照してください。

CloudWatch には異常検出機能もあります。この機能は、機械学習を使用して、有効にしたメトリクスの特定の動作に基づいて分析し、ベースラインを確立します。異常な API アクティビティが発生した場合は、この機能を CloudWatch アラームと合わせて使用できます。詳細については、「CloudWatch の異常検出の使用方法」を参照してください。

スロットリングエラーをプロアクティブにモニタリングすることで、AWS Support に連絡することで、関連するスロットリング制限を引き上げたり、アプリケーション固有のニーズに関するガイダンスを受けたりできます。