Escalonamento automático e balanceamento de carga de serviços do ECS

Uma contagem desejada fixa em um serviço ECS não consegue responder às flutuações de tráfego: ou o provisionamento fica excessivo (desperdiçando dinheiro) ou insuficiente (degradando o desempenho). O Auto Scaling de serviços ECS ajusta automaticamente a contagem desejada de tarefas em resposta às métricas do CloudWatch. Internamente, ele usa o serviço Application Auto Scaling — a mesma estrutura usada pelo DynamoDB, Aurora e ElastiCache. O auto scaling de serviços ECS é compatível com políticas de acompanhamento de destino, ajuste em etapas e ajuste programado.

Antes de adicionar políticas de ajuste, registre o serviço ECS como um destino escalável no Application Auto Scaling. Especifique as contagens mínima e máxima de tarefas, o nome do cluster e o nome do serviço como ID do recurso. Isso cria os limites dentro dos quais o auto scaling funcionará. A contagem mínima garante que você sempre tenha capacidade básica; a máxima evita que o ajuste descontrolado esgote a capacidade do Fargate ou das instâncias do EC2.

O acompanhamento de destino é a política de auto scaling recomendada para a maioria dos serviços ECS. A métrica de destino mais comum é ECSServiceAverageCPUUtilization: defina um destino de 50 a 70%, e o ECS adicionará ou removerá tarefas para manter esse nível de CPU. Outra métrica poderosa é ALBRequestCountPerTarget: acompanhe o número de solicitações do ALB por tarefa e ajuste a escala para manter uma taxa de solicitações desejada por instância. O AWS gerencia automaticamente o aumento e a redução da escala, usando períodos de espera apropriados.

Anexar um Application Load Balancer (ALB) a um serviço ECS distribui o tráfego HTTP/HTTPS entre todas as tarefas em execução. O grupo de destinos do ALB registra o IP de cada tarefa (para Fargate/awsvpc) ou a porta do contêiner (para o modo bridge). O ECS registra automaticamente as novas tarefas no grupo de destinos quando elas são iniciadas e cancela o registro quando elas são interrompidas. O ALB realiza verificações de integridade em cada tarefa; as tarefas não íntegras são drenadas (as conexões são fechadas de forma ordenada) antes de o serviço encerrá-las.

Um padrão muito útil é encaminhar diferentes caminhos de URL para diferentes serviços ECS usando o roteamento baseado em caminho do ALB. Um único ALB com um listener HTTPS pode encaminhar: /api/orders/* para o serviço ECS Orders, /api/users/* para o serviço ECS Users e /api/products/* para o serviço ECS Products — cada um apoiado por seu próprio serviço ECS, com ajuste de escala independente. Isso elimina a necessidade de balanceadores de carga separados para cada microsserviço, reduzindo custos e simplificando o gerenciamento de DNS.

Quando uma tarefa ECS está sendo encerrada (durante a redução da escala ou uma implantação), o ALB a marca como em drenagem e deixa de encaminhar novas solicitações para ela, permitindo que as solicitações em andamento sejam concluídas. O atraso no cancelamento do registro (300 segundos por padrão, configurável de 0 a 3600 segundos) é o tempo que o ALB aguarda antes de fechar as conexões à força. Para ECS com solicitações de curta duração, defina um atraso menor no cancelamento do registro (30 a 60 segundos) para acelerar as implantações e as operações de redução da escala. Para conexões longas (WebSocket, carregamentos de arquivos), mantenha um atraso maior.

Além de CPU e memória, publique métricas personalizadas do CloudWatch a partir da sua aplicação (profundidade da fila, sessões ativas, KPIs de negócio) e use-as para orientar o ajuste de escala. Por exemplo, se cada tarefa ECS puder processar simultaneamente 50 mensagens da fila, publique a profundidade da fila SQS como métrica personalizada e crie uma política de acompanhamento de destino que tenha como objetivo 50 mensagens por tarefa. Isso cria um ajuste de escala orientado diretamente pela lógica de negócio, em vez de depender de métricas de infraestrutura que podem não ter correlação com a carga da aplicação.

Assim como o Auto Scaling do EC2, o ECS é compatível com a proteção de tarefas contra redução da escala. Uma tarefa em execução pode definir seu próprio sinalizador de proteção contra redução da escala por meio da API do ECS, impedindo que seja encerrada durante a redução da escala enquanto processa um trabalho crítico. Isso é útil para tarefas ECS que atuam como trabalhadoras do SQS: uma trabalhadora que acabou de retirar um trabalho longo da fila pode proteger-se, concluir o trabalho e depois remover a proteção. Sem isso, a redução da escala pode encerrar uma tarefa no meio do processamento, causando duplicação do trabalho ou perda de dados.

Escolha sua métrica de ajuste com cuidado. A utilização de CPU é o padrão e funciona para cargas de trabalho limitadas pelo processamento. A utilização de memória (ECSServiceAverageMemoryUtilization) é útil para aplicações limitadas pela memória, mas aumentar a memória exige adicionar tarefas; se sua tarefa estiver limitada pela memória por tarefa, e não pelo processamento simultâneo, talvez seja melhor corrigir a alocação de memória na definição da tarefa. ALBRequestCountPerTarget tem correlação direta com a experiência do usuário e é a métrica mais prática para APIs Web: ajuste a escala com base na taxa real de solicitações por tarefa.

O Disjuntor de implantação do ECS detecta automaticamente implantações com falha e reverte para a última versão estável. Sem ele, uma implantação incorreta (um contêiner que falha nas verificações de integridade) faria o ECS tentar iniciar novas tarefas indefinidamente. Com o disjuntor ativado, se uma determinada porcentagem das tarefas recém-iniciadas falhar nas verificações de integridade dentro de uma janela de detecção, o ECS marcará a implantação como FAILED e reverterá automaticamente para a revisão anterior da definição da tarefa. Isso evita uma degradação prolongada do serviço causada por implantações incorretas.

Uma arquitetura de API Web conteinerizada pronta para produção: o Route 53 resolve o domínio para um nome DNS do ALB; o ALB encerra o HTTPS (certificado ACM), aplica regras do WAF e encaminha as solicitações para um grupo de destinos do serviço ECS; tarefas do Fargate em sub-redes privadas distribuídas por 3 AZs processam as solicitações; o Auto Scaling de serviços ECS, com acompanhamento de destino em ALBRequestCountPerTarget, ajusta a contagem de tarefas de 2 a 50; as tarefas conectam-se ao RDS Aurora e ao ElastiCache em sub-redes privadas. Todos os registros são enviados para o CloudWatch Logs; as métricas alimentam painéis e alarmes do CloudWatch.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que o Auto Scaling de serviços ECS usa o Application Auto Scaling com acompanhamento de destino (CPU, solicitações do ALB ou métricas personalizadas) para ajustar a contagem de tarefas entre os limites mínimo e máximo configurados; o roteamento baseado em caminho do ALB permite que um único balanceador de carga atenda a vários microsserviços ECS, encaminhando caminhos de URL para diferentes grupos de destinos; e o Disjuntor de implantação reverte automaticamente as implantações com falha antes que causem uma degradação prolongada do serviço. Isso conclui o módulo sobre ECS e contêineres; a seguir, exploraremos o Amazon EKS para Kubernetes no AWS.