ECS: placement strategies, como as tarefas são distribuídas no cluster

Quando o service do Amazon ECS lança as tasks, alguém decide em qual instância do cluster cada uma vai parar, e essa escolha muda sua disponibilidade e sua fatura. Abaixo, as três estratégias de placement que aparecem na criação do service, com o mesmo cenário de seis tasks para comparar.

A aula é de junho de 2022. Nomes e telas do console podem ter mudado desde então: confira as estratégias vigentes na documentação oficial de task placement do ECS. Lá elas aparecem como os tipos binpack e spread, que podem ser combinados em ordem, e a documentação lembra que a estratégia é de melhor esforço, não garantia.

De onde vem essa escolha

Ao criar o service, o console tem uma seção de placement templates com três estratégias principais: AZ Balanced Spread, AZ Balanced BinPack e BinPack. Elas definem como as tasks são acomodadas nas instâncias do cluster quando o service manda lançá-las.

Este texto não é introdutório. Se cluster, service e task ainda estão confusos, comece por cluster, service, task definition e task e volte aqui.

O cenário das três comparações

Meu cenário é hipotético: um cluster com quatro instâncias EC2, uma na zona A, uma na zona B e duas na zona C. O service pede seis tasks.

Na task definition configurei 300 MB por task. A instância que uso tem 1 GB de memória, precisamente 956 MB disponíveis, então cada instância comporta até três tasks. Esse número é o que faz as estratégias se comportarem de forma diferente. As contagens por zona nas imagens vêm do meu desenho para este cenário, não são uma regra.

AZ Balanced Spread: espalha entre as zonas

Essa estratégia distribui as tasks entre as zonas de disponibilidade da forma mais homogênea possível. A primeira vai para a zona A, a segunda para a B, a terceira para a C, e a quarta, a quinta e a sexta repetem a volta: A, B, C. A sexta cai na instância da zona C que ainda estava vazia.

O ponto a favor é usar de forma mais homogênea o poder computacional que você tem. A desvantagem: se você usa escalabilidade para reduzir instâncias do cluster, a instância da zona C que recebeu a sexta task não sai mais. Aquela task caberia em outra instância, e eu não precisaria ter usado essa.

AZ Balanced BinPack: zonas primeiro, agrupamento depois

Aqui há dois critérios, nesta ordem. O primeiro é o mesmo do Spread: distribuir as tasks entre as zonas. O segundo é agrupar, no padrão por memória: dentro da zona, usar o mínimo de instâncias possível, enchendo cada uma com o máximo de tasks.

Nas zonas A e B só existe uma instância, então ele acomoda ali. A diferença aparece na zona C: em vez de abrir a segunda instância como o Spread fez, ele reaproveita a que já recebeu task, porque o segundo critério manda acomodar o máximo por instância.

A instância que ficou livre pode ser descartada pela sua escalabilidade, e você economiza recurso computacional. Você mantém as tasks espalhadas entre as zonas e ainda assim gasta menos.

BinPack: agrupa e ignora a zona

A terceira estratégia, por padrão, não olha para a zona de disponibilidade. O primeiro critério dela é acomodar o máximo de recurso por instância. Como cada instância minha comporta três tasks, ele enche uma instância antes de passar para a próxima.

Sobram duas instâncias da zona C livres. Se você trabalha com escalabilidade usando um capacity provider no cluster, pode configurá-lo para remover essas instâncias automaticamente. É a que deixa mais instâncias livres neste cenário.

O risco do BinPack

Como o BinPack não olha a zona, ele pode acomodar três tasks numa instância e outras três em outra instância da mesma zona. Você economiza recurso computacional, mas corre o risco de não atender o critério de alta disponibilidade.

Há como contornar: combine o BinPack com a distribuição por zona, configurando no próprio service a zona de disponibilidade como segundo critério. Depois de alocar na zona C, a próxima task não vai mais para a C, e pode ir para a B. É uma quarta estratégia, a combinação das duas ideias.

Como escolher

A aula mostra o trade-off, não uma resposta única:

• AZ Balanced Spread: distribui melhor entre as zonas e usa o poder computacional de forma mais homogênea, mas deixa instâncias ocupadas à toa na hora de reduzir o cluster.
• AZ Balanced BinPack: espalha entre as zonas e agrupa dentro delas, o que libera instâncias para a escalabilidade remover.
• BinPack: economiza mais, mas pode concentrar tudo numa zona e abrir mão da alta disponibilidade.

Checklist

• [ ] Sei onde o service define a estratégia de placement (placement templates, na criação do service).
• [ ] Sei dizer que o AZ Balanced Spread distribui as tasks entre as zonas da forma mais homogênea possível.
• [ ] Sei que o AZ Balanced BinPack distribui entre as zonas e depois agrupa as tasks, por padrão por memória.
• [ ] Sei que o BinPack ignora a zona e pode abrir mão da alta disponibilidade.
• [ ] Sei que combinar BinPack com a zona como segundo critério evita concentrar tudo numa zona.
• [ ] Conferi na documentação oficial se as estratégias continuam as mesmas.

Se quer revisar o seu cluster ECS, a estratégia de placement e o custo das instâncias, o time do Henrylle pode olhar o seu cenário numa conversa.