# Amazon ECS を大規模に運用する
Amazon ECS を大規模に運用し始める際には、Amazon ECS および Amazon ECS と統合する AWS のサービス のサービスクォータと API スロットリングがどのように影響するかを検討します。
**Topics**
+ [
# Amazon ECS Service Quotas と API スロットリング制限
](operating-at-scale-service-quotas-best-practice.md)
+ [
# Amazon ECS のスロットリングに関する問題を処理する
](operating-at-scale-dealing-with-throttles.md)
# Amazon ECS Service Quotas と API スロットリング制限
Amazon ECS は、Elastic Load Balancing、AWS Cloud Map、Amazon EC2 など、いくつかの AWS のサービス と統合されています。この緊密な統合により、Amazon ECS ではサービスのロードバランシング、サービス検出、タスクネットワーク、クラスターの自動スケーリングなどのいくつかの機能を利用できます。Amazon ECS および、統合されているその他の AWS のサービス はすべて、一貫したパフォーマンスと利用率を確保するために、サービスクォータと API レート制限を維持します。また、これらのサービスクォータは、必要以上のリソースを誤ってプロビジョニングすることを防ぎ、請求額を増やす可能性のある悪意のある行為からも保護します。
サービスクォータと AWS API のレート制限をよく理解しておけば、予期しないパフォーマンスの低下を心配することなく、ワークロードのスケーリングを計画できます。詳細については、「[Amazon ECS の Service Quotas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html)」「[Request throttling for the Amazon ECS API](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html)」を参照してください。
Amazon ECS でワークロードをスケーリングする場合は、次のサービスクォータを検討します。サービスクォータの引き上げをリクエストする方法については、「[AWS マネジメントコンソール での Amazon ECS と AWS Fargate サービスクォータの管理](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas-manage.html)」を参照してください。
+ AWS Fargate には、各 AWS リージョン のタスクで同時に実行できるタスクの数を制限するクォータがあります。Amazon ECS では、オンデマンドタスクと Fargate Spot タスクの両方にクォータが設定されています。各サービスクォータには、Fargate で実行するすべての Amazon EKS ポッドも含まれます。Fargate クォータの詳細については、「*AWS Fargate の Amazon Elastic Container Service ユーザーガイド*」にある「[AWS Fargate サービスクォータ](https://docs.aws.amazon.com/AmazonECS/latest/userguide/service-quotas.html#service-quotas-fargate)」を参照してください。
+ Amazon EC2 インスタンスで実行されるタスクの場合、各クラスターに登録できる Amazon EC2 インスタンスの最大数は 5,000 です。Auto Scaling グループの容量プロバイダーで Amazon ECS クラスターの自動スケーリングを使用する場合、またはクラスターの Amazon EC2 インスタンスを自分で管理する場合、このクォータがデプロイのボトルネックになる可能性があります。さらに容量が必要な場合は、クラスターをさらに作成するか、サービスクォータの引き上げをリクエストすることができます。
+ Auto Scaling グループのキャパシティプロバイダーで Amazon ECS クラスターの自動スケーリングを使用する場合は、サービスをスケーリングする際に `Tasks in the PROVISIONING state per cluster` クォータを考慮してください。このクォータは、キャパシティプロバイダーがキャパシティを増やすことができる各クラスターの `PROVISIONING` 状態にあるタスクの最大数です。多数のタスクを同時に起動すると、すぐにこのクォータに達してしまいます。たとえば、それぞれ数百のタスクを含む数十のサービスを同時にデプロイする場合です。この場合、クラスターのキャパシティが不足すると、キャパシティープロバイダーは新しいコンテナインスタンスを起動してタスクを配置する必要があります。キャパシティープロバイダーが追加の Amazon EC2 インスタンスを起動している間、Amazon ECS サービススケジューラーは引き続きタスクを並行して起動する可能性があります。ただし、クラスターのキャパシティが不十分なため、このアクティビティが抑制される可能性があります。Amazon ECS サービススケジューラは、新しいコンテナインスタンスが起動したときにタスク配置を再試行するためのバックオフおよびエクスポネンシャルスロットリング戦略を実装しています。その結果、デプロイやスケールアウトに時間がかかる可能性があります。このような状況を回避するために、以下のいずれかの方法でサービスのデプロイを計画できます。クラスターの容量を増やす必要のないタスクを大量に展開するか、新しいタスクの起動に備えて余剰のクラスター容量を確保しておくかのどちらかです。
ワークロードをスケーリングする際には Amazon ECS サービスクォータを考慮することに加えて、Amazon ECS と統合されている他の AWS のサービス 用のサービスクォータも考慮してください。次のセクションでは、各サービスの主要なレート制限について詳しく説明し、スロットリングの潜在的な問題に対処するための推奨事項を提供します。
## Elastic Load Balancing
Fargate の Amazon ECS サービスは、Elastic Load Balancing を使用してタスク間でトラフィックを均等に分散するように設定できます。ロードバランサーを選択する方法の詳細については、「[ロードバランサーを使用して Amazon ECS サービストラフィックを分散する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html)」を参照してください。
### Elastic Load Balancing のサービスクォータ
ワークロードをスケーリングするときは、以下の Elastic Load Balancing のサービスクォータを考慮してください。Elastic Load Balancing のサービスクォータのうち、ほとんどは調整可能で、Service Quotas コンソールでリクエストできます。
**Application Load Balancer**
Application Load Balancer を使用する際、ユースケースによっては、以下のクォータ増加をリクエストする必要がある場合があります。
+ Application Load Balancer の背後にあるターゲットの数である `Targets per Application Load Balancer` クォータ。
+ ターゲットグループの背後にあるターゲットの数である `Targets per Target Group per Region` クォータ。
詳細については、「[Quotas for your Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html)」を参照してください。
**Network Load Balancer**
Network Load Balancer に登録できるターゲットの数には、より厳しい制限があります。Network Load Balancer を使用する場合、クロスゾーンサポートを有効にする必要があることがよくあります。これには、各 Network Load Balancer のアベイラビリティーゾーンあたりの `Targets per Availability Zone Per Network Load Balancer` 最大ターゲット数に対する追加のスケーリング制限が伴います。詳細については、「[Network Load Balancer のクォータ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-limits.html)」を参照してください。
### Elastic Load Balancing API のスロットリング
ロードバランサーを使用するように Amazon ECS サービスを設定する場合、サービスが正常であると見なされるには、ターゲットグループのヘルスチェックに合格する必要があります。これらのヘルスチェックを実行するために、Amazon ECS はユーザーに代わって Elastic Load Balancing API 操作を呼び出します。アカウントにロードバランサーが設定されたサービスが多数ある場合、特に `RegisterTarget`、`DeregisterTarget`、`DescribeTargetHealth` Elastic Load Balancing API 操作に関してスロットリングが発生する可能性があるため、サービスのデプロイが遅くなる可能性があります。スロットリングが発生すると、Amazon ECS サービスのイベントメッセージにスロットリングエラーが発生します。
AWS Cloud Map API でスロットリングが発生した場合は、AWS Cloud Map API のスロットリング制限を引き上げる方法について サポート までお問い合わせください。スロットリングエラーの監視とトラブルシューティングの詳細については、「[Handling throttling issues](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)」を参照してください。
## Elastic Network Interface
タスクで `awsvpc` ネットワークモードを使用する場合、Amazon ECS はタスクごとに独自の Elastic Network Interface (ENI) をプロビジョニングします。Amazon ECS サービスが Elastic Load Balancing ロードバランサーを使用する場合、これらのネットワークインターフェイスは、サービスで定義された適切なターゲットグループのターゲットとしても登録されます。
### Elastic Network Interface のサービスクォータ
`awsvpc` ネットワークモードを使用するタスクを実行すると、固有のエラスティックネットワークインターフェイスが各タスクにアタッチされます。インターネット経由でこれらのタスクにアクセスする必要がある場合は、タスクのエラスティックネットワークインターフェイスにパブリック IP アドレスを割り当てます。Amazon ECS ワークロードをスケーリングするときは、次の 2 つの重要なクォータを考慮してください。
+ アカウントの AWS リージョン におけるネットワークインターフェイスの最大数である `Network interfaces per Region` クォータ。
+ AWS リージョン に含まれる Elastic IP アドレスの最大数である `Elastic IP addresses per Region` クォータ。
これらのサービスクォータは両方とも調整可能で、Service Quotas コンソールから増加をリクエストできます。詳細については、「[Amazon VPC サービスクォータ](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-enis)」を参照してください。
Amazon EC2 インスタンスでホストされている Amazon ECS ワークロードの場合、`awsvpc` ネットワークモードを使用するタスクを実行するときは、各 Amazon EC2 インスタンスの最大ネットワークインスタンスの数である `Maximum network interfaces` サービスクォータを考慮してください。このクォータは、1 つのインスタンスに配置できるタスクの数を制限します。クォータを調整することはできず、Service Quotas コンソールでは使用できません。詳細については、「*Amazon EC2 ユーザーガイド*」の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)」を参照してください。
Amazon EC2 インスタンスにアタッチできるネットワークインターフェイスの数は変更できませんが、エラスティックネットワークインターフェイスのトランキング機能を使用して利用可能なネットワークインターフェイスの数を増やすことができます。たとえば `c5.large` インスタンスにはデフォルトでネットワークインターフェイスを最大 3 つアタッチできます。このインスタンスのプライマリネットワークインターフェイスも、1 個としてカウントされます。そのため、このインスタンスに追加で 2 個のネットワークインターフェイスをアタッチできます。`awsvpc` ネットワークモードを使用する各タスクにはネットワークインターフェイスが必要なため、通常このインスタンスタイプでは、これらのタスクを 2 つのみ実行できます。これにより、クラスターの容量が十分に活用されない可能性があります。エラスティックネットワークインターフェイスでトランキングを有効にすると、ネットワークインターフェイスの密度を上げて、各インスタンスにより多くのタスクを配置できます。トランキングをオンにすると、1 つの `c5.large` インスタンスに最大 12 のネットワークインターフェースを設定できます。インスタンスはプライマリネットワークインターフェイスを持ち、Amazon ECS は「トランク」ネットワークインターフェイスを作成し、アタッチします。その結果、この構成では、デフォルトの 2 つのタスクではなく、10 のタスクをインスタンスで実行できます。詳細については、「[Elastic network interface trunking](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-eni.html)」を参照してください。
### エラスティックネットワークインターフェイス API のスロットリング
`awsvpc` ネットワークモードを使用するタスクを実行する場合、Amazon ECS は次の Amazon EC2 API に依存します。これらの API にはそれぞれ異なる API スロットリングがあります。詳細については、「[Amazon EC2 API のリクエストスロットリング](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html)」を参照してください。
+ CreateNetworkInterface
+ AttachNetworkInterface
+ DetachNetworkInterface
+ DeleteNetworkInterface
+ DescribeNetworkInterfaces
+ DescribeVpcs
+ DescribeSubnets
+ DescribeSecurityGroups
+ DescribeInstances
エラスティックネットワークインターフェイスのプロビジョニングワークフロー中に Amazon EC2 API コールがスロットリングされた場合、Amazon ECS サービススケジューラは自動的にエクスポネンシャルバックオフを行って再試行します。これらの自動廃止により、タスクの起動が遅れ、デプロイ速度が遅くなることがあります。API スロットリングが発生すると、サービスイベントメッセージにメッセージ `Operations are being throttled. Will try again later.` が表示されます。Amazon EC2 API でスロットリングが継続的に発生する場合は、API のスロットリング制限を引き上げる方法について サポート までお問い合わせください。スロットリングエラーの監視とトラブルシューティングの詳細については、「[スロットリング問題の処理](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)」を参照してください。
## AWS Cloud Map
Amazon ECS サービス検出では、AWS Cloud Map API を使用して Amazon ECS サービスの名前空間を管理します。サービスに多数のタスクがある場合は、以下の推奨事項を考慮してください。詳細については、「[Amazon ECS サービス検出に関する考慮事項](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html#service-discovery-considerations)」を参照してください。
### AWS Cloud Map Service Quotas
Amazon ECS サービスがサービス検出を使用するように設定されている場合、サービスの最大タスク数である `Tasks per service` クォータは、そのサービスの最大インスタンス数である AWS Cloud Map `Instances per service` サービスクォータの影響を受けます。特に、AWS Cloud Map サービスクォータにより、実行できるタスクの数は、サービスあたり最大 1,000 タスクに減少します。AWS Cloud Map のクォータは変更できません。詳細については、「[AWS Cloud Map サービスクォータ](https://docs.aws.amazon.com/general/latest/gr/cloud_map.html)」を参照してください。
### AWS Cloud Map API スロットリング
Amazon ECS はユーザーに代わって`ListInstances`、`GetInstancesHealthStatus`、`RegisterInstance`、および `DeregisterInstance` AWS Cloud Map API を呼び出します。これらはサービス検出を支援し、タスクを起動するとヘルスチェックを実行します。多数のタスクを伴うサービス検出を使用する複数のサービスを同時にデプロイすると、AWS Cloud Map API のスロットリング制限を超える可能性があります。この場合、Amazon ECS サービスのイベントメッセージに次のようなメッセージが表示される場合があります: Amazon ECS サービスイベントで `Operations are being throttled. Will try again later` が発生しました。デプロイとタスクの起動速度が遅くなっています。AWS Cloud Map には、これらの API のスロットリング制限は記録されていません。これらのスロットリングが発生した場合は、API のスロットリング制限を引き上げる方法について サポート までお問い合わせください。このようなスロットリングエラーの監視とトラブルシューティングの詳細については、「[Handling throttling issues](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)」を参照してください。
# Amazon ECS のスロットリングに関する問題を処理する
スロットリングエラーは、同期スロットリングと非同期スロットリングの 2 つの主要なカテゴリに分類されます。
## 同期スロットリング
同期スロットリングが発生すると、すぐに Amazon ECS からエラーレスポンスが届きます。このカテゴリは通常、タスクの実行中またはサービスの作成中に Amazon ECS API を呼び出すと発生します。影響を受けるスロットリングと関連するスロットリング制限の詳細については、「[Amazon ECS API リクエストのスロットリング](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html)」を参照してください。
アプリケーションが、AWS CLI、AWS SDK などを使用して API リクエストを開始すると、API スロットリングを修正できます。そのためには、エラーを処理するようにアプリケーションを設計するか、API コールの再試行ロジックを使用してエクスポネンシャルバックオフとジッター戦略を実装します。詳細については、「[タイムアウト、リトライ、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)」を参照してください。
AWS SDK を使用する場合、自動再試行ロジックは組み込まれており、設定可能です。
## 非同期スロットリング
非同期スロットリングは、Amazon ECS または 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 ログファイルを監視する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)」を参照してください。
CloudWatch Logs Insights の詳細および、ログファイルのクエリ方法については、「[CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)」を参照してください。
Amazon Athena では、標準 SQL を使用してクエリを作成し、データを分析できます。たとえば、Athena テーブルを作成して CloudTrail イベントを解析することができます。詳細については、「[CloudTrail コンソールを使用して CloudTrail ログ用 Athena テーブルを作成する](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#create-cloudtrail-table-ct)」を参照してください。
Athena テーブルを作成すると、次のような SQL クエリを使用して `ThrottlingException` エラーを調査できます。
*user-input* を独自の値に置き換えます。
```
select eventname, errorcode,eventsource,awsregion, useragent,COUNT(*) count
FROM cloudtrail_table-name
where errorcode = 'ThrottlingException'
AND eventtime between '2024-09-24T00:00:08Z' and '2024-09-23T23:15:08Z'
group by errorcode, awsregion, eventsource, useragent, eventname
order by count desc;
```
Amazon ECS は、Amazon EventBridge にもイベント通知を送信します。リソース状態変更イベントおよびサービスアクションイベントがあります。これらには、`ECS_OPERATION_THROTTLED`、`SERVICE_DISCOVERY_OPERATION_THROTTLED` などの API スロットリングイベントが含まれます。詳細については、「[Amazon ECS サービスアクションイベント](ecs_service_events.md)」を参照してください。
これらのイベントは、応答アクションを実行する目的で、AWS Lambda などのサービスによって利用される可能性があります。詳細については、「[Amazon ECS イベントの処理](ecs_cwet_handling.md)」を参照してください。
スタンドアロンタスクを実行する場合、`RunTask` などの一部の API 操作は非同期となり、再試行操作は自動的に実行されません。このような場合は、EventBridge と統合している AWS Step Functions などのサービスを使用して、スロットリングされた操作や失敗した操作を再試行できます。詳細については、「[コンテナタスクの管理 (Amazon ECS、Amazon SNS)](https://docs.aws.amazon.com/step-functions/latest/dg/sample-project-container-task-notification.html)」を参照してください。
## CloudWatch を使用してスロットリングを監視する
CloudWatch では、**[AWS リソース別]** で `Usage` ネームスペースの API 使用状況をモニタリングできます。これらのメトリクスは タイプ **[API]**、メトリック名 **[CallCount]** で記録されます。これらのメトリクスが特定のしきい値に達するたびに開始するアラームを作成できます。詳細については、「[サービスクォータの視覚化とアラームの設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html)」を参照してください。
CloudWatch には異常検出機能もあります。この機能は、機械学習を使用して、有効にしたメトリクスの特定の動作に基づいて分析し、ベースラインを確立します。異常な API アクティビティが発生した場合は、この機能を CloudWatch アラームと合わせて使用できます。詳細については、「[CloudWatch の異常検出の使用方法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)」を参照してください。
スロットリングエラーをプロアクティブにモニタリングすることで、サポート に連絡することで、関連するスロットリング制限を引き上げたり、アプリケーション固有のニーズに関するガイダンスを受けたりできます。