A arte de escalar contêineres: novas tentativas

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Escalar contêineres é mais do que simplesmente colocar um proxy na frente de um serviço e dar o trabalho por encerrado. A escalabilidade vai além da simples distribuição e, no dinâmico mundo dos contêineres, há cinco recursos distintos necessários para garanti-la: novas tentativas, disjuntores, descoberta, distribuição, e monitoramento.

Neste post sobre a arte de escalar contêineres, vamos nos aprofundar nas novas tentativas.

Novas tentativas

Quando você é criança e está jogando, a ideia de tentar de novo é comum em muitos jogos. “De novo!” é algo que se costuma gritar depois de uma derrota, na esperança de que os outros jogadores deixem você tentar mais uma vez. Às vezes, eles deixam. Às vezes, não. Pelo que percebi, isso raramente impede uma criança de continuar tentando.

Ao escalar aplicativos (ou serviços, se preferir), o conceito de nova tentativa é praticamente o mesmo. Depois de escolher um serviço e tentar atender a uma solicitação, um proxy recebe um erro. Em cenários básicos de balanceamento de carga, isso geralmente é determinado pela análise do código de resposta HTTP. Qualquer resposta diferente de “200 OK” é considerada um erro. Isso inclui tempos limite nas camadas de rede e TCP. O balanceador de carga pode simplesmente retornar a resposta com falha para o

solicitante ou, se for inteligente o suficiente, poderá tentar enviar a solicitação novamente, na esperança de que uma tentativa subsequente resulte em uma resposta bem-sucedida.

Isso parece bem básico, mas, no início da era da escalabilidade, não existia essa história de tentar novamente. Se falhasse, falhava, e nós lidávamos com isso — geralmente tentando recarregar a página manualmente pelo navegador. Com o tempo, os proxies ficaram inteligentes o bastante para realizar novas tentativas por conta própria, evitando que as teclas “CTRL” e “R” de muitos teclados se desgastassem.

À primeira vista, este é um exemplo existencial da definição de insanidade. Afinal, se a solicitação falhou na primeira vez, por que esperar que ela seja bem-sucedida na segunda (ou até mesmo na terceira)?

A resposta está no motivo da falha. Ao dimensionar aplicativos, é importante entender o impacto que a capacidade de conexões exerce sobre as falhas. A carga sobre um determinado recurso em um dado momento não é fixa. Conexões são constantemente abertas e fechadas. A plataforma subjacente do aplicativo web — seja Apache ou IIS, um mecanismo node.js ou alguma outra pilha — tem restrições de capacidade definidas. Ela só consegue manter X conexões simultâneas. Quando esse limite é atingido, as tentativas de abrir novas conexões ficam travadas ou falham.

Se essa for a causa de uma falha, então, nos microssegundos que o proxy levou para receber uma resposta de falha, outra conexão pode ter sido encerrada, abrindo assim a possibilidade de uma nova tentativa ser bem-sucedida.

Em alguns casos, a falha é interna à plataforma. O temido “Erro interno do servidor 500”. Esse status costuma ocorrer quando o servidor não está sobrecarregado, mas fez uma chamada para outro serviço (externo) que não respondeu a tempo. Às vezes, isso acontece porque um pool de conexões com o banco de dados atingiu seus limites. A dependência de serviços externos pode resultar em uma sequência de erros em cascata que, assim como uma sobrecarga de conexões, muitas vezes já foi resolvida quando você recebe o erro inicial.

Você também pode se deparar com o erro extremamente útil “503 Serviço Indisponível”. Isso pode ocorrer em resposta a uma sobrecarga, mas, como acontece com todos os códigos de erro HTTP, eles nem sempre indicam com precisão o que realmente está dando errado. Esse erro pode aparecer em resposta a uma falha de DNS ou, no caso de IIS e ASP, quando a fila está cheia. As possibilidades são realmente muito variadas. E, novamente, o problema pode já ter sido resolvido quando você receber o erro, portanto, tentar novamente deve definitivamente ser sua primeira reação.

É claro que você não pode simplesmente continuar tentando indefinidamente. Assim como ocorre com as consequências não intencionais da retransmissão TCP — que pode sobrecarregar as redes e os receptores —, as novas tentativas acabam se tornando inúteis. Não há uma regra rígida sobre quantas vezes você deve tentar novamente antes de desistir, mas o comum é fazer entre 3 e 5 tentativas.

Nesse ponto, é hora de informar ao solicitante que a requisição não pôde ser atendida e acionar um circuit breaker. Vamos explorar esse recurso em nosso próximo post.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie