A Arte de Escalar Contêineres: Tentativas

Escalar contêineres é mais do que simplesmente colocar um proxy na frente de um serviço e ir embora. A escala envolve mais do que apenas distribuição e, no mundo acelerado dos contêineres, há cinco recursos distintos necessários para garantir a escala: novas tentativas, disjuntores, descoberta , distribuição e monitoramento.

Nesta postagem sobre a arte de dimensionar contêineres, vamos nos aprofundar nas tentativas.

Tentativas

Quando você é criança e está jogando, o conceito de nova tentativa é comum a muitos jogos. “Faça de novo!” é comumente gritado após uma falha, na esperança de que os outros jogadores deixem você tentar novamente. Às vezes sim. Às vezes não. Percebi que isso raramente impede uma criança de tentar. 

Ao dimensionar aplicativos (ou serviços, se preferir), o conceito de nova tentativa é praticamente o mesmo. Um proxy, ao escolher um serviço e tentar atender a uma solicitação, recebe um erro. Em cenários básicos de balanceamento de carga, isso normalmente é determinado examinando o código de resposta HTTP. Qualquer coisa diferente de “200 OK” é um erro. Isso inclui tempos limite de rede e de camada TCP. O balanceador de carga pode retornar cegamente a resposta com falha para o 

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

Isso parece bem básico, mas no começo da escala não existia isso de nova tentativa. Se falhou, falhou e nós lidamos com isso. Geralmente, tentando recarregar manualmente a partir do navegador. Com o tempo, os proxies se tornaram inteligentes o suficiente para executar novas tentativas por conta própria, poupando muitos teclados de desgastar os botões “CTRL” e “R”.

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

A resposta está no motivo do fracasso. Ao dimensionar aplicativos, é importante entender o impacto que a capacidade de conexão tem nas falhas. A carga sobre um determinado recurso em um determinado momento não é fixa. Conexões estão constantemente sendo abertas e fechadas. A plataforma de aplicativo da web subjacente – seja Apache ou IIS, um mecanismo node.js ou alguma outra pilha – tem restrições definidas em termos de capacidade. Ele só pode manter X número de conexões simultâneas. Quando esse limite for atingido, as tentativas de abrir novas conexões travarão ou falharão.

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

Em alguns casos, uma falha é interna à plataforma. O temido “ Erro Interno do Servidor 500 ”. Esse status geralmente é visto 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 é resultado de um pool de conexões de banco de dados atingindo seus limites. A dependência de serviços externos pode resultar em uma cadeia de erros em cascata que, como uma sobrecarga de conexão, geralmente é resolvida no momento em que você recebe o erro inicial.

Você também pode ver o erro muito útil “ 503 Serviço Indisponível ”. Isso pode ser uma resposta a uma sobrecarga, mas, como acontece com todos os códigos de erro HTTP, eles nem sempre são bons indicadores do que realmente está errado. Você pode ver isso em resposta a uma falha de DNS ou, no caso do IIS e ASP, uma fila cheia. As possibilidades são realmente muito variadas. E, novamente, eles podem ser resolvidos quando você receber o erro, então uma nova tentativa deve ser definitivamente sua primeira resposta.

É claro que você não pode simplesmente tentar novamente até que tudo dê certo. Assim como as consequências não intencionais da retransmissão TCP – que pode sobrecarregar redes e sobrecarregar 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 entre 3 e 5 é o comum.

Nesse ponto, é hora de enviar desculpas ao solicitante e iniciar um disjuntor. Vamos nos aprofundar nessa capacidade em nossa próxima postagem.