# Operação do Amazon ECS em grande escala
Ao começar a operar o Amazon ECS em grande escala, considere como as cotas de serviço e os controles de utilização de API do Amazon ECS e os Serviços da AWS que se integram ao Amazon ECS podem afetar você.
**Topics**
+ [
# Controles de utilização de API e cotas de serviço do Amazon ECS
](operating-at-scale-service-quotas-best-practice.md)
+ [
# Lidar com problemas de controle de utilização do Amazon ECS
](operating-at-scale-dealing-with-throttles.md)
# Controles de utilização de API e cotas de serviço do Amazon ECS
O Amazon ECS se integra a vários Serviços da AWS, incluindo o Elastic Load Balancing, o AWS Cloud Map e o Amazon EC2. Com essa forte integração, o Amazon ECS inclui vários recursos, como balanceamento de carga do serviço, descoberta de serviços, rede de tarefas e ajuste de escala automático de clusters. O Amazon ECS e os outros Serviços da AWS que ele integra mantêm cotas de serviço e limites de taxa de API para garantir desempenho e utilização consistentes. As cotas de serviço também evitam o provisionamento acidental de mais recursos do que o necessário e protegem contra ações maliciosas que possam aumentar sua fatura.
Ao se familiarizar com as cotas de serviço e os limites de taxa de API da AWS, você pode planejar a escalabilidade das workloads sem se preocupar com a degradação inesperada do desempenho. Para obter mais informações, consulte [Cotas de serviço do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html) e [Request throttling for the Amazon ECS API](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html).
Ao escalar as workloads no Amazon ECS, considere a cota de serviço a seguir. Para instruções sobre como solicitar um aumento de cota de serviço, consulte [Gerenciar cotas de serviço do Amazon ECS e do AWS Fargate no Console de gerenciamento da AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas-manage.html).
+ O AWS Fargate tem cotas que limitam o número de tarefas em execução simultânea em cada Região da AWS. Há cotas para tarefas sob demanda e do Fargate Spot no Amazon ECS. Cada cota de serviço também inclui todos os pods do Amazon EKS executados no Fargate. Para obter mais informações sobre cotas do Fargate, consulte [Cotas de serviço do AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/service-quotas.html#service-quotas-fargate) no *Guia do usuário do Amazon Elastic Container Service para AWS Fargate*.
+ Em tarefas executadas nas instâncias do Amazon EC2, o número máximo de instâncias do Amazon EC2 que você pode registrar em cada cluster é 5 mil. Caso use o ajuste de escala automático de cluster do Amazon ECS com um provedor de capacidade de grupo do Auto Scaling, ou caso gerencie instâncias do Amazon EC2 para o cluster sem ajuda, essa cota pode virar um gargalo de implantação. Se precisar de mais capacidade, você pode criar mais clusters ou solicitar um aumento na cota de serviço.
+ Se você usa o ajuste de escala automático de cluster do Amazon ECS com um provedor de capacidade de grupo do Auto Scaling, considere a cota `Tasks in the PROVISIONING state per cluster` ao escalar os serviços. Essa cota é o número máximo de tarefas no estado `PROVISIONING` de cada cluster para as quais os provedores de capacidade podem aumentar a capacidade. Ao executar um grande número de tarefas ao mesmo tempo, você pode facilmente atingir essa cota. Um exemplo é se você implantar simultaneamente dezenas de serviços, cada um com centenas de tarefas. Quando isso acontece, o provedor de capacidade precisa executar novas instâncias de contêiner para posicionar as tarefas quando o cluster não tem capacidade suficiente. Enquanto o provedor de capacidade executa instâncias adicionais do Amazon EC2, é provável que o programador de serviços do Amazon ECS continue executando tarefas em paralelo. No entanto, essa atividade pode ter controle de utilização devido à capacidade insuficiente do cluster. O programador de serviços do Amazon ECS implementa uma estratégia de recuo e controle de utilização exponencial para repetir o posicionamento de tarefas à medida que novas instâncias de contêineres são executadas. Como resultado, você pode enfrentar tempos de implantação ou de aumento horizontal de escala mais lentos. Para evitar essa situação, você pode planejar as implantações de serviços em uma das opções a seguir. Implemente um grande número de tarefas que não exijam um aumento da capacidade de clusters, ou mantenha uma capacidade disponível de clusters para a inicialização de novas tarefas.
Além de considerar a cota de serviços do Amazon ECS ao escalar as workloads, considere também a cota de serviço dos outros Serviços da AWS integrados ao Amazon ECS. A seção a seguir aborda detalhadamente os principais limites de taxas de cada serviço e fornece recomendações para lidar com possíveis problemas de controle de utilização.
## Elastic Load Balancing
Você pode configurar os serviços do Amazon ECS para usar o Elastic Load Balancing para distribuir o tráfego uniformemente entre as tarefas. Para obter mais informações sobre como escolher um balanceador de carga, consulte [Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html).
### Cotas de serviço do Elastic Load Balancing
Ao escalar as workloads, considere as cotas de serviço do Elastic Load Balancing a seguir. A maioria das cotas de serviço do Elastic Load Balancing é ajustável, e você pode solicitar um aumento no console do Service Quotas.
**Application Load Balancer**
Ao usar um Application Load Balancer, dependendo do seu caso de uso, pode ser necessário solicitar um aumento de cota para:
+ A cota de `Targets per Application Load Balancer`, que é o número de destinos por trás do Application Load Balancer.
+ A cota de `Targets per Target Group per Region`, que é o número de destinos por trás dos grupos de destino.
Para obter mais informações, consulte [Quotas for your Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html).
**Network Load Balancer**
Há limitações mais rígidas no número de destinos que você pode registrar com um Network Load Balancer. Ao usar um Network Load Balancer, talvez você queira habilitar o suporte entre zonas, que vem com limitações adicionais de escalabilidade no `Targets per Availability Zone Per Network Load Balancer`, o número máximo de destinos por zona de disponibilidade para cada Network Load Balancer. Para obter mais informações, consulte [Quotas for your Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-limits.html).
### Controle de utilização da API do Elastic Load Balancing
Ao configurar um serviço do Amazon ECS para usar um balanceador de carga, as verificações de integridade do grupo de destino devem ser aprovadas para que o serviço seja considerado íntegro. Para realizar essas verificações de integridade, o Amazon ECS invoca as operações de API do Elastic Load Balancing em seu nome. Caso tenha um grande número de serviços configurados com balanceadores de carga na conta, você pode tornar as implantações de serviços mais lentas devido ao possível controle de utilização específico das operações das APIs `RegisterTarget`, `DeregisterTarget` e `DescribeTargetHealth` do Elastic Load Balancing. Quando ocorre o controle de utilização, ocorrem erros de controle de utilização nas mensagens de eventos do serviço do Amazon ECS.
Caso enfrente problemas de controle de utilização na API do AWS Cloud Map, entre em contato com o Suporte para obter orientação sobre como aumentar os limites de controle de utilização na API do AWS Cloud Map. Para obter mais informações sobre como monitorar e solucionar problemas, como erros de controle de utilização, consulte [Lidar com problemas de controle de utilização](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html).
## Interfaces de rede elástica
Quando as tarefas usam o modo de rede `awsvpc`, o Amazon ECS provisiona uma interface de rede elástica (ENI) exclusiva para cada tarefa. Quando os serviços do Amazon ECS usam um balanceador de carga do Elastic Load Balancing, essas interfaces de rede também são registradas como destinos no grupo de destino apropriado definido no serviço.
### Cotas de serviço da interface de rede elástica
Ao executar tarefas que usam o modo de rede `awsvpc`, uma interface de rede elástica exclusiva é anexada a cada tarefa. Caso essas tarefas precisem ser acessadas pela Internet, atribua um endereço IP público à interface de rede elástica dessas tarefas. Ao escalar as workloads do Amazon ECS, considere estas duas cotas importantes:
+ A cota de `Network interfaces per Region`, que é o número máximo de interfaces de rede em uma Região da AWS para sua conta.
+ A cota de `Elastic IP addresses per Region`, que é o número máximo de endereços IP elásticos em uma Região da AWS.
Ambas as cotas de serviço são ajustáveis e você pode solicitar um aumento delas no console do Service Quotas. Para obter mais informações, consulte [Cotas de serviço da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-enis).
Em workloads do Amazon ECS hospedadas em instâncias do Amazon EC2, ao executar tarefas que usam o modo de rede `awsvpc`, considere a cota de serviço `Maximum network interfaces`, o número máximo de instâncias de rede para cada instância do Amazon EC2. Essa cota limita o número de tarefas que você pode posicionar em uma instância. Não é possível ajustar a cota e ela não está disponível no console do Service Quotas. Para obter mais informações, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) no *Guia do usuário do Amazon EC2*.
Embora você não possa alterar o número de interfaces de rede que podem ser anexadas a uma instância do Amazon EC2, é possível usar o recurso de truncamento da interface de rede elástica para aumentar o número de interfaces de rede disponíveis. Por exemplo, por padrão, uma instância `c5.large` pode ter até três interfaces de rede. A interface de rede primária da instância conta como uma. Portanto, é possível anexar mais duas interfaces de rede à instância. Como cada tarefa que usa o modo de rede `awsvpc` requer uma interface de rede, normalmente só é possível executar duas dessas tarefas nesse tipo de instância. Isso pode levar à subutilização da capacidade do cluster. Se você habilitar o truncamento da interface de rede elástica, poderá aumentar a densidade da interface de rede para posicionar um número maior de tarefas em cada instância. Com o truncamento ativado, uma instância `c5.large` pode ter até 12 interfaces de rede. A instância tem a interface de rede primária e o Amazon ECS cria e anexa uma interface de rede de “truncamento” à instância. Como resultado, com essa configuração, você pode executar dez tarefas na instância em vez das duas tarefas padrão. Para obter mais informações, consulte [Elastic network interface trunking](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-eni.html).
### Controle de utilização da API de interface de rede elástica
Ao executar tarefas que usam o modo de rede `awsvpc`, o Amazon ECS depende das APIs do Amazon EC2 mencionadas a seguir. Cada uma dessas APIs tem controles de utilização de API diferentes. Para obter mais informações, consulte [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
Se as chamadas de API do Amazon EC2 receberem controle de utilização durante os fluxos de trabalho de provisionamento da interface de rede elástica, o programador de serviços do Amazon ECS repete automaticamente com recuos exponenciais. Às vezes, essas repetições automáticas podem levar a um atraso na inicialização de tarefas, resultando em velocidades de implantação mais lentas. Quando ocorrer o controle de utilização da API, você verá a mensagem `Operations are being throttled. Will try again later.` nas mensagens de eventos do serviço. Caso atenda consistentemente aos controle de utilização de API do Amazon EC2, entre em contato com o Suporte para obter orientações sobre como aumentar os limites de controle de utilização da API. Para obter mais informações sobre como monitorar e solucionar problemas de controle de utilização, consulte [Handling throttling issues](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html).
## AWS Cloud Map
A descoberta de serviços do Amazon ECS usa APIs do AWS Cloud Map para gerenciar namespaces dos serviços do Amazon ECS. Se os serviços tiverem um grande número de tarefas, considere as recomendações a seguir. Para obter mais informações, consulte [Considerações sobre descoberta de serviços do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html#service-discovery-considerations).
### Cotas de serviço do AWS Cloud Map
Quando os serviços do Amazon ECS são configurados para usar a descoberta de serviços, a cota de `Tasks per service`, que é o número máximo de tarefas do serviço, é afetada pela cota de serviço de `Instances per service` do AWS Cloud Map, que é o número máximo de instâncias desse serviço. Em particular, a cota de serviço do AWS Cloud Map diminui a quantidade de tarefas que você pode executar para, no máximo, mil tarefas por serviço. Não é possível alterar a cota do AWS Cloud Map. Para obter mais informações, consulte as [Service Quotas do AWS Cloud Map](https://docs.aws.amazon.com/general/latest/gr/cloud_map.html).
### Controle de utilização da API do AWS Cloud Map
O Amazon ECS chama as APIs `ListInstances`, `GetInstancesHealthStatus`, `RegisterInstance` e `DeregisterInstance` do AWS Cloud Map em seu nome. Elas ajudam na descoberta de serviços e realizam verificações de integridade ao executar uma tarefa. Quando vários serviços que usam a descoberta de serviços com um grande número de tarefas são implantados ao mesmo tempo, isso pode resultar na ultrapassagem dos limites de controle de utilização da API do AWS Cloud Map. Quando isso acontecer, é provável que surja a mensagem `Operations are being throttled. Will try again later` nas mensagens de eventos do serviço do Amazon ECS e que a velocidade de implantação e execução de tarefas fique mais lenta. O AWS Cloud Map não documenta os limites de controle de utilização dessas APIs. Caso enfrente problemas de controle de utilização, entre em contato com o Suporte para obter orientações sobre como aumentar os limites de controle de utilização da API. Para obter mais recomendações sobre como monitorar e solucionar problemas, como erros de controle de utilização, consulte [Lidar com problemas de controle de utilização](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html).
# Lidar com problemas de controle de utilização do Amazon ECS
Os erros de controle de utilização se enquadram em duas categorias principais: controle de utilização síncrono e controle de utilização assíncrono.
## Controle de utilização síncrono
Quando ocorre o controle de utilização síncrono, você recebe imediatamente uma resposta de erro do Amazon ECS. Essa categoria costuma ocorrer quando você chama as APIs do Amazon ECS enquanto executa tarefas ou cria serviços. Para obter mais informações sobre o controle de utilização envolvido e os limites relevantes do controle de utilização, consulte [Request throttling for the Amazon ECS API](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html).
Quando a aplicação inicia solicitações de API, por exemplo, usando a AWS CLI ou um AWS SDK, você pode corrigir o controle de utilização da API. Isso pode ser feito arquitetando a aplicação para lidar com os erros ou implementando uma estratégia de recuo exponencial e variação de sinal com lógica de repetição para as chamadas de API. Para obter mais informações, consulte [Tempos limite, novas tentativas e recuo com variação de sinal](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/).
Caso use um AWS SDK, a lógica de repetição automática está incorporada e é configurável.
## Controle de utilização assíncrono
O controle de utilização assíncrono ocorre devido a fluxos de trabalho assíncronos em que o Amazon ECS ou o CloudFormation podem estar chamando APIs em seu nome para provisionar recursos. É importante saber quais APIs da AWS o Amazon ECS invoca em seu nome. Por exemplo, a API `CreateNetworkInterface` é invocada em tarefas que usam o modo de rede `awsvpc`, e a API `DescribeTargetHealth` é invocada ao realizar verificações de integridade em tarefas registradas em um balanceador de carga.
Quando as workloads atingem uma escala considerável, o controle de utilização pode ser aplicado nessas operações de API. Ou seja, elas podem receber controle de utilização o suficiente para violar os limites impostos pelo Amazon ECS ou pelo AWS service (Serviço da AWS) que está sendo chamado. Por exemplo, se você implantar centenas de serviços, cada um com centenas de tarefas simultaneamente que usam o modo de rede `awsvpc`, o Amazon ECS invoca operações de API do Amazon EC2, como `CreateNetworkInterface`, e operações de API do Elastic Load Balancing, como `RegisterTarget` ou `DescribeTargetHealth`, para registrar a interface de rede elástica e o balanceador de carga, respectivamente. Essas chamadas de API podem exceder os limites da API, resultando em erros de controle de utilização. Veja a seguir um exemplo de erro de controle de utilização do Elastic Load Balancing incluído na mensagem de evento do serviço.
```
{
"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"
}
}
```
Quando essas chamadas de API compartilham limites com outros tráfegos de API na conta, pode ser difícil monitorá-las, mesmo que sejam emitidas como eventos de serviço.
## Monitorar o controle de utilização
É importante identificar quais solicitações de API recebem controle de utilização e quem as emite. Você pode usar o AWS CloudTrail, que monitora o controle de utilização e se integra ao CloudWatch, Amazon Athena e Amazon EventBridge. É possível configurar o CloudTrail para enviar eventos específicos para o CloudWatch Logs. Os insights de log do CloudWatch Logs investigam e analisam os eventos. Isso identifica detalhes em eventos de controle de utilização, como o usuário ou o perfil do IAM que fez a chamada e o número de chamadas de API que foram feitas. Para obter mais informações, consulte [Monitoring CloudTrail log files with CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html).
Para obter mais informações sobre o CloudWatch Logs Insights e instruções sobre como consultar arquivos de log, consulte [Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html).
Com o Amazon Athena, você pode criar consultas e analisar dados usando o SQL padrão. Por exemplo, é possível criar uma tabela do Athena para analisar eventos do CloudTrail. Para obter mais informações, consulte [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).
Depois de criar uma tabela do Athena, você pode usar consultas SQL, como o exemplo a seguir, para investigar erros de `ThrottlingException`.
Substitua os valores das *user-input* pelos seus.
```
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;
```
O Amazon ECS também emite notificações de eventos para o Amazon EventBridge. Há eventos de mudança de estado do recurso e eventos de ação do serviço. Eles incluem eventos de controle de utilização de API, como `ECS_OPERATION_THROTTLED` e `SERVICE_DISCOVERY_OPERATION_THROTTLED`. Para obter mais informações, consulte [Eventos de ação do serviço do Amazon ECS](ecs_service_events.md).
Esses eventos podem ser consumidos por um serviço, como o AWS Lambda, para realizar ações em resposta. Para obter mais informações, consulte [Processo de eventos do Amazon ECS](ecs_cwet_handling.md).
Se você executar tarefas autônomas, algumas operações de API, como `RunTask`, serão assíncronas, e as operações de repetição não serão executadas automaticamente. Nesses casos, você pode usar serviços, como o AWS Step Functions, com a integração do EventBridge para repetir operações de controle de utilização ou com falha. Para obter mais informações, consulte [Manage a container task (Amazon ECS, Amazon SNS)](https://docs.aws.amazon.com/step-functions/latest/dg/sample-project-container-task-notification.html).
## Usar o CloudWatch para monitorar controle de utilização
O CloudWatch oferece monitoramento de uso da API no namespace `Usage` em **Por recurso da AWS**. Essas métricas são registradas em log com o tipo **API** e o nome da métrica **CallCount**. Você pode criar alarmes para iniciar sempre que essas métricas atingirem um determinado limite. Para obter mais informações, consulte [Visualizar as Service Quotas e definir alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html).
O CloudWatch também oferece detecção de anomalias. Esse recurso usa machine learning para analisar e estabelecer linhas de base de acordo com o comportamento específico da métrica na qual você o habilitou. Se houver uma atividade incomum na API, você poderá usar esse recurso com os alarmes do CloudWatch. Para obter mais informações, consulte [Usar a detecção de anomalias do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html).
Ao monitorar proativamente os erros de controle de utilização, você pode entrar em contato com o Suporte para aumentar os limites relevantes de controle de utilização e receber orientação para as necessidades exclusivas da sua aplicação.