本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 大規模運作 Amazon ECS 當您開始大規模操作 Amazon ECS 時，請考慮 Amazon ECS 的服務配額和 API 調節，以及與 Amazon ECS 整合 AWS 服務 的 可能如何影響您。 **Topics** + [ # Amazon ECS 服務配額與 API 限流限制 ](operating-at-scale-service-quotas-best-practice.md) + [ # 因應 Amazon ECS 限流問題 ](operating-at-scale-dealing-with-throttles.md) # Amazon ECS 服務配額與 API 限流限制 Amazon ECS 與數個 整合 AWS 服務，包括 Elastic Load Balancing AWS Cloud Map和 Amazon EC2。透過這種緊密整合，Amazon ECS 包含數個功能，例如服務負載平衡、服務探索、任務聯網與叢集自動擴展。Amazon ECS 及其與所有維護服務配額和 API 速率限制整合 AWS 服務 的另一個 ECS，以確保一致的效能和使用率。這些服務配額也可防止意外佈建超過所需的資源，並防範可能導致帳單金額增加的惡意行為。 透過熟悉您的服務配額和 AWS API 速率限制，您可以規劃擴展工作負載，而不必擔心意外的效能降低。如需詳細資訊，請參閱 [Amazon ECS 服務配額](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 上擴展工作負載時，請考量下列服務配額。如需如何請求提高服務配額的指示，請參閱《[》中的管理您的 Amazon ECS AWS Fargate 和服務配額 AWS 管理主控台](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas-manage.html)。 + AWS Fargate 具有配額，可限制每個 中並行執行中的任務數量 AWS 區域。Amazon ECS 上的隨需任務與 Fargate Spot 任務都有配額。每個服務配額的計算範圍，亦涵蓋您在 Fargate 上執行的所有 Amazon EKS Pod。如需有關 Fargate 配額的詳細資訊，請參閱 *Amazon Elastic Container Service User Guide for AWS Fargate* 中的 [AWS Fargate service quotas](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 您可以設定 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 時，根據實際使用案例，可能需要申請提高以下項目的配額： + `Targets per Application Load Balancer` 配額，即 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 時，通常建議啟用跨可用區域支援功能，但此功能此功能會對 `Targets per Availability Zone Per Network Load Balancer` 帶來額外的擴展限制，亦即每個 Network Load Balancer 於各可用區域中可容納的目標數量上限將受到規範。如需詳細資訊，請參閱 [Quotas for your Network Load Balancers](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 限流限制的指引。如需有關監控及疑難排解此類限流錯誤的詳細資訊，請參閱[因應限流問題](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)。 ## 彈性網路介面 隨著任務使用 `awsvpc` 網路模式，Amazon ECS 會為每個任務佈建唯一的彈性網路介面 (ENI)。當 Amazon ECS 服務使用 Elastic Load Balancing 負載平衡器時，這些網路介面也會註冊為該服務中定義的對應目標群組的目標。 ### 彈性網路介面服務配額 當您執行使用 `awsvpc` 網路模式的任務時，每個任務都會連接唯一的彈性網路介面。如果必須透過網際網路到達這些任務，請將公有 IP 位址指派給這些任務的彈性網路介面。在擴展 Amazon ECS 工作負載時，請考量這兩個重要的配額： + `Network interfaces per Region` 配額，這是 中 AWS 區域 您帳戶的最大網路介面數量。 + `Elastic IP addresses per Region` 配額，即 AWS 區域中彈性 IP 位址的最大數量。 這兩個服務配額皆可調整，您可以直接透過 Service Quotas 主控台提出調增申請。如需詳細資訊，請參閱 [Amazon VPC service quotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-enis)。 對於託管在 Amazon EC2 執行個體上的 Amazon ECS 工作負載，當執行使用 `awsvpc` 網路模式的任務時，建議考量 `Maximum network interfaces` 服務配額，即每個 Amazon EC2 執行個體的網路執行個體數量上限。此配額會限制可在執行個體上置放的任務數量。此配額無法調整，就業未於 Service Quotas 主控台中提供。如需詳細資訊，請參閱 *Amazon EC2 User Guide* 中的 [IP addresses per network interface per instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)。 雖然您無法變更可連接至 Amazon EC2 執行個體的網路介面數量，但可透過啟用彈性網路介面主幹功能來增加可用網路介面的總數。例如，依預設，`c5.large` 執行個體最多可有 3 個網路介面。執行個體的主要網路介面視為一個配額。因此，您可以將額外的兩個網路介面連接至執行個體。因為每個使用 `awsvpc` 網路模式的任務都需要網路介面，所以通常只能對此執行個體類型執行兩個這類任務。這可能會導致叢集容量的使用率偏低。如果啟用彈性網路介面主幹功能，即可提高網路介面密度，從而在每個執行個體上部署更多任務。啟用主幹功能後，`c5.large` 執行個體最多可有 12 個網路介面。該執行個體本身已具備主要網路介面，而 Amazon ECS 會建立並連接「主幹」網路介面至該執行個體。因此，透過此組態，您可在該執行個體上執行 10 個任務，而非預設的 2 個任務。如需詳細資訊，請參閱[彈性網路介面主幹功能](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-eni.html)。 ### 彈性網路介面 API 限流 在執行使用 `awsvpc` 網路模式的任務時，Amazon ECS 會調用下列 Amazon EC2 API。每個 API 皆設有不同的 API 限流。如需詳細資訊，請參閱 [Request throttling for the 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 APIs 來管理 Amazon ECS 服務的命名空間。如果服務有大量任務，建議考量下列事項。如需詳細資訊，請參閱 [Amazon ECS 服務探索考量事項](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html#service-discovery-considerations)。 ### AWS Cloud Map 服務配額 當 Amazon ECS `Tasks per service` 服務設定為使用服務探索時，服務任務數量上限的配額會受到 AWS Cloud Map `Instances per service`該服務執行個體數量上限的服務配額影響。特別是， AWS Cloud Map 服務配額會將您可以執行的任務量減少到每個服務最多 1，000 個任務。 AWS Cloud Map 配額無法變更。如需更多相關資訊，請參閱 [AWS Cloud Map Service Quotas](https://docs.aws.amazon.com/general/latest/gr/cloud_map.html)。 ### AWS Cloud Map API 限流 Amazon ECS 會代表您呼叫 `ListInstances`、`RegisterInstance`、 `GetInstancesHealthStatus`和 `DeregisterInstance` AWS Cloud Map APIs。這些 API 可用於服務探索，會在您啟動任務時執行運作狀態檢查。當同時使用服務探索與大量任務的多個服務同時部署時，這可能會導致超過 AWS Cloud Map API 限流限制。此時，您可能會在 Amazon ECS 服務事件訊息中看到訊息 (`Operations are being throttled. Will try again later`)，且部署與任務啟動速度會減緩。 AWS Cloud Map 未記錄這些 API 的限流限制。如果您遇到這些調節，您可以聯絡 支援 以取得提高 API 調節限制的指引。如需有關監控及疑難排解此類限流錯誤的更多建議，請參閱[因應限流問題](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)。 # 因應 Amazon ECS 限流問題 限流錯誤分為兩個主要類別：同步限流與非同步限流。 ## 同步限流 發生同步限流時，您會立即收到來自 Amazon ECS 的錯誤回應。如果您在執行任務或建立服務時呼叫 Amazon ECS API，通常會發生此類別錯誤。如需有關所涉限流問題與相關限流限制的詳細資訊，請參閱 [Request throttling for the Amazon ECS API](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html)。 當您的應用程式啟動 API 請求時，例如使用 AWS CLI 或 AWS SDK，您可以修復 API 限流。具體可透過兩種方式實現：一是將應用程式架構設計為可處理這些錯誤，二是為 API 呼叫視作具有重試邏輯的指數退避與抖動策略。如需詳細資訊，請參閱 [Timeouts, retries, and backoff with jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)。 如果您使用 AWS SDK，則自動重試邏輯是內建且可設定的。 ## 非同步限流 非同步限流的發生源於非同步工作流程，在該流程中，Amazon ECS 或 CloudFormation 可能會代表您呼叫 API 來佈建資源。請務必了解 Amazon ECS 代您叫用哪些 AWS APIs。例如，對於使用 `awsvpc` 網路模式的任務，系統會調用 `CreateNetworkInterface` API；而對已註冊至負載平衡器的任務執行運作狀態檢查時，則會調用 `DescribeTargetHealth` API。 當工作負載達到相當大的規模時，這些 API 操作可能會受到限流。也就是說，它們可能會受到足夠限流，違反 Amazon ECS 或正在呼叫 AWS 服務 的 強制執行的限制。例如，若同時部署數百個服務，每個服務都有數百個使用 `awsvpc` 網路模式的任務，Amazon ECS 會分別呼叫 Amazon EC2 的 API 操作 (如 `CreateNetworkInterface`) 以及 Elastic Load Balancing 的 API 操作 (如 `RegisterTarget` 或 `DescribeTargetHealth`)，完成彈性網路介面與負載平衡器的註冊工作。這些 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 整合。您可以設定 CloudTrail 將特定事件傳送至 CloudWatch Logs。CloudWatch Logs 日誌洞察會剖析並分析事件。這可確定限流事件中的詳細資訊，例如進行呼叫的使用者或 IAM 角色，以及進行的 API 呼叫數量。如需詳細資訊，請參閱 [Monitoring CloudTrail log files with CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)。 如需有關使用 CloudWatch Logs Insights 的詳細資訊以及有關如何查詢日誌檔案的說明，請參閱 [Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)。 透過 Amazon Athena，您可以使用標準 SQL 建立查詢並分析資料。例如，您可以建立 Athena 表格來剖析 CloudTrail 事件。如需詳細資訊，請參閱 [Using the CloudTrail console to create an Athena table for CloudTrail logs](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。事件主要分為資源狀態變更事件與服務操作事件兩大類。其中包含 API 限流事件，例如 `ECS_OPERATION_THROTTLED` 與 `SERVICE_DISCOVERY_OPERATION_THROTTLED`。如需詳細資訊，請參閱[Amazon ECS 服務動作事件](ecs_service_events.md)。 這些事件可由 等服務取用 AWS Lambda ，以執行動作來回應。如需詳細資訊，請參閱[因應 Amazon ECS 事件](ecs_cwet_handling.md)。 如果執行獨立任務，某些 API 操作 (例如 `RunTask`) 是非同步的，且不會自動執行重試操作。在這種情況下，您可以使用 等服務 AWS Step Functions 搭配 EventBridge 整合，重試調節或失敗的操作。如需詳細資訊，請參閱 [Manage a container task (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** 記錄。您可以建立警示，在這些指標達到特定閾值時啟動。如需詳細資訊，請參閱 [Visualizing your service quotas and setting alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html)。 CloudWatch 也提供異常偵測功能。此功能使用機器學習，根據您所啟用指標的特定行為進行分析並建立基準。如有異常的 API 活動，您可以將此功能與 CloudWatch 警示搭配使用。如需詳細資訊，請參閱 [Using CloudWatch anomaly detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)。 透過主動監控限流錯誤，您可以聯絡 支援 來提高相關的限流限制，並收到您唯一應用程式需求的指引。