Uma análise aprofundada da integridade e substituição de tarefas do Amazon ECS

Introdução

O Amazon Elastic Container Service (Amazon ECS) é um serviço de orquestração de contêineres que gerencia o ciclo de vida de bilhões de aplicações em contêineres na AWS toda semana. Um dos principais objetivos do Amazon ECS é eliminar o overhead operacional de gerenciar os contêineres de forma manual. O Amazon ECS monitora seus contêineres de aplicações 24 horas por dia, 7 dias por semana, e pode responder a mudanças inesperadas de forma mais rápida e melhor do que qualquer ser humano. O Amazon ECS reage a mudanças indesejadas, como falhas de aplicações e falhas de hardware, tentando continuamente restaurar suas aplicações em contêineres de volta ao estado desejado. Também existem fatores externos, como picos de tráfego, que podem causar inatividade na aplicação. Isso pode ser mais difícil de lidar. Esta postagem se aprofunda nas mudanças recentes na forma como o Amazon ECS lida com health issues e substituição de tarefas, e como essas mudanças aumentam a disponibilidade de seus contêineres orquestrados pelo Amazon ECS.

Avaliação da integridade da tarefa

O Amazon ECS avalia a integridade de uma tarefa com base em alguns critérios:

1. Primeiro, para que uma tarefa seja íntegra, todos os contêineres marcados como essenciais devem estar em execução. Cada tarefa do Amazon ECS deve ter pelo menos um contêiner essencial. É recomendado que os contêineres executem um único processo de aplicação e, se esse processo terminar devido a um problema critico em tempo de execução, o contêiner é interrompido. Se esse contêiner que foi interrompido estiver marcado como essencial, toda a tarefa será considerada unhealthy e a tarefa deverá ser substituída.
2. Você pode usar a Task Definition do Amazon ECS para configurar um comando opcional de health check interno que o agente do Amazon ECS executa dentro do contêiner periodicamente. Espera-se que esse comando retorne um código de saída zero que indica sucesso. Se ele retornar um código de saída diferente de zero, isso indica falha. O contêiner é considerado unhealthy e com isso faz com que a tarefa também seja considerada unhealthy, o que faz com que o Amazon ECS substitua essa tarefa.
3. Você pode usar o serviço Amazon ECS para anexar outros serviços da AWS juntamente com o contêiner de sua aplicação. Por exemplo, você pode conectar seu contêiner a um Amazon Elastic Load Balancer (ELB) ou ao AWS Cloud Map. Esses serviços realizam suas próprias verificações de health check externo. Por exemplo, o ELB tenta periodicamente abrir uma conexão com seu contêiner e enviar uma solicitação de teste. Se não for possível abrir essa conexão, seu contêiner retornará uma resposta inesperada ou se o contêiner demorar muito para responder, o ELB considerará que o contêiner de destino está unhealthy. O Amazon ECS também considera esse health check externo ao decidir se uma tarefa do Amazon ECS está integra ou não. Uma verificação de integridade unhealthy do ELB faz com que a tarefa seja substituída.

Para que uma tarefa seja healthy, todas as suas dependências devem ser avaliadas como healthy. Se alguma das dependências retornar um status não íntegro, a tarefa do Amazon ECS será considerada unhealthy e será substituída.

Comportamento de substituição de tarefas

A substituição de uma tarefa do Amazon ECS é algo que acontece em duas principais circunstâncias:

1. Durante uma nova implantação acionada pela chamada da API UpdateService. Todas as tarefas existentes que fazem parte da implantação anterior devem ser substituídas por novas tarefas que façam parte da nova implantação.
2. Quando uma tarefa existente dentro de uma implantação ativa esta unhealthy. Elas devem ser substituídas para manter a contagem desejada de tarefas healthy.

Desde o início da história do Amazon ECS, o comportamento da substituição de tarefas durante implantações contínuas era configurável usando duas propriedades do serviço Amazon ECS:

• maximumPercent — Isso controla quantas tarefas adicionais o Amazon ECS pode executar acima da contagem desejada do serviço. Por exemplo, se  maximumPercent for 200% e a contagem desejada para o serviço for oito tarefas, o Amazon ECS poderá iniciar até 16 tarefas adicionais.
• minimumHealthyPercent — Isso controla a porcentagem em que um serviço do Amazon ECS pode ficar abaixo da contagem desejada durante uma implantação. Por exemplo, se minimumHealthyPercent for 75% e a contagem desejada para o serviço for oito tarefas, o Amazon ECS poderá interromper duas tarefas, reduzindo a implantação do serviço para seis tarefas em execução.

O maximumPercent e o minimumHealthyPercent funcionaram por muitos anos como controles eficientes para ajustar o comportamento das implantações contínuas ao executar tarefas do Amazon ECS em Amazon Elastic Compute Cloud (Amazon EC2). No entanto, esses controles de implantação não fazem muito sentido em um mundo em que cada vez mais usuários do Amazon ECS estão escolhendo utilizar o modelo serverless da AWS Fargate. Na maioria dos casos, as aplicações modernas não exigem que o Amazon ECS fique abaixo da contagem desejada de tarefas em execução durante uma implantação contínua nem reduza o número de tarefas adicionais lançadas durante uma implantação contínua, porque a utilização do AWS Fargate não é limitada pela quantidade de instâncias subjacentes do Amazon EC2 que você registrou em seu cluster.

Além disso, os controles maximumPercent e minimumHealthyPercent foram originalmente ignorados quando se tratava de substituir tarefas unhealthy. Se as tarefas ficarem unhealthy, a contagem desejada do seu serviço poderá cair bem abaixo do limite definido por minimumHealthyPercent. Por exemplo, se você estivesse executando oito tarefas e quatro delas se tornassem unhealthy, o Amazon ECS encerraria as quatro tarefas unhealthy e lançaria quatro tarefas substitutas. O número de tarefas em execução cairia temporariamente para 50% da contagem desejada.

Atualizações sobre como o Amazon ECS substitui tarefas unhealthy

A partir de 20 de outubro de 2023, o Amazon ECS agora usa sua maximumPercent sempre que possível ao substituir tarefas unhealthy. Vamos dar uma olhada em alguns cenários para entender como isso funciona:

Tarefas com falha

Você está executando um serviço com uma contagem desejada de oito tarefas e uma porcentagem máxima de 200%. Quatro de suas oito tarefas encontram-se com falha. O Amazon ECS observa que quatro das oito tarefas não funcionaram porque seu contêiner essencial apresentou falha. Infelizmente, o Amazon ECS não pode evitar que a porcentagem saudável caia abaixo de 100% porque o contêiner unhealthy travou. A contagem de tarefas em execução cai brevemente para 50% da contagem desejada, mas o Amazon ECS lança quatro tarefas de substituição o mais rápido possível para trazer o número de tarefas em execução de volta à contagem desejada de oito tarefas.

Tarefas congeladas

Você está executando um serviço com uma contagem desejada de oito tarefas e uma porcentagem máxima de 200%. Por causa de um loop infinito em seu código, quatro de suas oito tarefas congelam, mas os processos continuam em execução. O balanceador de carga conectado as suas tarefas, está enviando solicitações de health check para o serviço e observa que o contêiner de destino não responde mais às solicitações de health check e, portanto, marca o destino como unhealthy. O Amazon ECS considera essas quatro tarefas congeladas unhealthy. A porcentagem máxima do serviço permite que ele execute até 16 tarefas. O Amazon ECS lança quatro tarefas de substituição adicionais para as quatro tarefas unhealthy, totalizando 12 tarefas em execução. Depois que as quatro tarefas adicionais se tornam healthy, o Amazon ECS interrompe as quatro tarefas unhealthy, o que reduz a contagem de tarefas em execução para a contagem desejada de oito tarefas.

Tarefas sobrecarregadas

Você está executando um serviço com uma contagem desejada de oito tarefas e uma porcentagem máxima de 150%. O serviço tem regras de autoscaling automático associadas a ele. Ele também tem um balanceador de carga conectado a ele, e um grande pico de tráfego chega por meio do balanceador de carga. O pico de tráfego é tão grande que o tempo de resposta da tarefa aumenta drasticamente. Como resultado do alto tempo de resposta, o health check do balanceador de carga falha e o ELB marca todas as oito tarefas como unhealthy. O ELB falha na abertura e continua distribuindo tráfego para todos os destinos, pois não há tarefas healthy no balanceador de carga.

O Amazon ECS observa que todas as oito tarefas estão unhealthy. Como resultado, o Amazon ECS irá substituir essas tarefas unhealthy. A porcentagem máxima de 150% permite que o serviço execute até 12 tarefas. Portanto, o Amazon ECS evita interromper imediatamente as tarefas unhealthy em execução. Em vez disso, ele lança quatro tarefas de substituição em paralelo com as oito tarefas unhealthy existentes. Felizmente, essas quatro tarefas adicionais dão ao ELB mais autonomia para distribuir o tráfego, e todas as 12 tarefas em execução se estabilizam em integridade, pois agora são capazes de lidar com o tráfego de entrada sem receber timeout. O Amazon ECS observa que agora existem 12 tarefas em execução healthy.

Simultaneamente, uma regra do Application Auto Scaling entrou em vigor com base na alta utilização da CPU pelas oito tarefas originais em execução. A regra atualizou a contagem desejada para o serviço Amazon ECS de oito tarefas em execução para 10 tarefas em execução. Portanto, o Amazon ECS interrompe apenas duas das 12 tarefas em execução íntegra, o que reduz a contagem de tarefas até a contagem atual desejada de 10 tarefas em execução.

Porcentagem máxima limitada

Você está executando um serviço com uma contagem desejada de oito tarefas e, devido aos limites posteriores ou às restrições de infraestrutura, você definiu uma porcentagem máxima de 100%. Isso não permite que o Amazon ECS lance nenhuma tarefa adicional em paralelo com suas oito tarefas em execução. Se uma tarefa dessa implantação congelar ou ficar sobrecarregada e começar a falhar no health check, o Amazon ECS precisará substituí-la. O Amazon ECS interrompe primeiro a tarefa unhealthy e, em seguida, inicia uma tarefa de substituição depois que a tarefa unhealthy é interrompida. Isso significa que a contagem de tarefas em execução ainda está temporariamente abaixo da contagem desejada.

A tarefa falha no health check durante uma implantação contínua

Você está executando um serviço com uma contagem desejada de oito tarefas e uma porcentagem máxima de 150%. Você está fazendo uma implantação contínua para atualizar suas tarefas em execução com base em uma nova Task Definition. Como a porcentagem máxima é de 150%, isso permite que o Amazon ECS lance tarefas adicionais em paralelo com suas tarefas atualmente em execução. A implantação contínua já iniciou o lançamentos de quatro tarefas adicionais. Atualmente, o serviço tem 12 tarefas em execução: oito tarefas antigas e quatro novas tarefas.

Durante essa implantação contínua, algumas das tarefas antigas começam a falhar no no health check devido a um bug inesperado. Como há uma implantação contínua ativa em andamento, o Amazon ECS recorre ao encerramento imediato das tarefas unhealthy e à substitui por novas tarefas o mais rápido possível. Durante uma implantação contínua, o Amazon ECS sempre tenta substituir tarefas com falha por tarefas da nova implantação ativa.

Falhas contínuas de tarefas devido a fatores externos

Você está executando um serviço com uma contagem desejada de oito tarefas e uma porcentagem máxima de 150%. Uma das dependências do seu código começa a retornar uma resposta inesperada, e isso faz com que seu código comece a falhar no processo de health check. O Amazon ECS vê que as oito tarefas estão unhealthy e precisam ser substituídas, então ele lança quatro tarefas de substituição adicionais em paralelo com as oito tarefas iniciais. Neste ponto, há doze tarefas em execução: oito tarefas originais e quatro tarefas de substituição. Infelizmente, todas as doze tarefas estão unhealthy porque as tarefas de substituição ainda dependem do mesmo serviço downstream não confiável das tarefas originais.

Como as tarefas de substituição não se estabilizaram e o ECS vê que o número de tarefas unhealthy é maior do que a contagem desejada para o serviço, o ECS interromperá quatro das tarefas unhealthy aleatoriamente, a fim de reduzir o número de tarefas unhealthy à contagem desejada. O ECS não mantém um conhecimento detalhado de quais tarefas unhealthy eram “originais” e quais eram “substitutas”. Quando um número suficiente de tarefas unhealthy em excesso for interrompido e houver espaço para tarefas adicionais, o ECS tentará iniciar as tarefas de substituição novamente. Isso continuará indefinidamente até que o serviço downstream se torne confiável novamente ou você faça uma chamada à API UpdateService para implementar uma atualização de código que trate a condição de falha com mais facilidade.

Health checks e absorção responsiva de picos de carga de trabalho

Anteriormente, o Amazon ECS sempre parava primeiro as tarefas unhealthy e depois lançava tarefas substitutas. Esse comportamento fazia sentido em um mundo em que as tarefas eram compactadas densamente em um cluster de tamanho estático de instâncias do Amazon EC2 que não tinha espaço para iniciar uma tarefa substituta sem interromper uma tarefa existente. Porém, cargas de trabalho de contêineres mais modernas agora estão sendo executadas usando a capacidade serverless do AWS Fargate. Não há necessidade de interromper uma tarefa em execução unhealthy para abrir espaço para sua substituição, pois o AWS Fargate pode fornecer a capacidade de contêineres on demand. Além disso, muitos clientes do Amazon ECS no Amazon EC2 agora estão usando o capacity provider do Amazon ECS para lançar instâncias adicionais do Amazon EC2 sob demanda, em vez de implantá-las em clusters de tamanho estático. Portanto, o Amazon ECS agora prioriza o uso do maximumPercent para um serviço e, sempre que possível, mantém as tarefas unhealthy em execução até que suas substituições se tornem íntegras.

Além disso, o novo comportamento de substituição de tarefas do Amazon ECS ajuda a evitar o encerramento descontrolado de tarefas. Em alguns casos, um grande pico na carga de trabalho pode fazer com que algumas tarefas da implantação fiquem unhealthy, o que desencadeia sua substituição. No entanto, quando o Amazon ECS interrompe tarefas unhealthy para iniciar uma substituição, o balanceador de carga transferia mais carga de trabalho para as tarefas healthy restantes, o que fazia com que elas ficassem unhealthy. Em uma rápida sucessão, todas as tarefas healthy ficariam sobrecarregadas com uma carga de trabalho que causava uma cascata de falhas descontroladas no health check até que todas as tarefas ficassem unhealthy.

Eventualmente, as regras do Application Auto Scaling entrariam em vigor e ampliariam a implantação para um tamanho grande o suficiente para lidar com a carga de trabalho. Mas, na maioria dos casos, um pico de tráfego faz com que os health checks do balanceador de carga falhem antes de acionar o escalonamento automático baseado no consumo de recursos agregados. As regras de escalonamento automático precisam observar pelo menos um minuto de alta média de utilização de recursos antes de reagirem escalando a implantação do contêiner. No entanto, uma tarefa sobrecarregada pode começar a falhar imediatamente no health check do balanceador de carga.

No cenário em que suas tarefas estão unhealthy porque estão lidando com um grande pico de carga de trabalho recebida, o novo comportamento de substituição de tarefas do Amazon ECS melhora drasticamente a disponibilidade e a confiabilidade do seu serviço. O Amazon ECS detecta falha no health check e lança proativamente uma tarefa de substituição paralela que pode ajudar a absorver o pico da carga de trabalho recebida antes mesmo das regras de escalonamento automático serem acionadas. Depois que as regras de escalonamento automático são acionadas, a tarefa de substituição e a tarefa original são mantidas, se ambas estiverem healthy e se atenderem à contagem atual de tarefas desejadas do serviço.

Conclusão

Neste post, explicamos o novo comportamento do Amazon ECS ao lidar com tarefas unhealthy. À medida que mais clientes adotam o Amazon ECS para suas aplicações de missão crítica, estamos sempre felizes em vivenciar novos desafios de orquestração em grande escala. Esse comportamento atualizado de substituição de tarefas foi projetado para ajudar a atender às necessidades de clientes pequenos e grandes. Ele ajuda a manter suas implantações de contêineres on-line e disponíveis, mesmo em circunstâncias adversas, como falhas de aplicações ou picos de tráfego.

Visite o roadmap público do Amazon ECS para obter mais informações sobre nova features para o Amazon ECS ou para criar sua própria issue e solicitar uma mudança ou um novo recurso.

Para obter mais informações sobre o comportamento do programador do Amazon ECS, consulte a documentação oficial, em Conceitos do Programador de Serviços.