A arte de dimensionar contêineres: Distribuição
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 na distribuição.
Distribuição
O segredo para dimensionar qualquer coisa sempre dependeu, em parte, de como as solicitações são distribuídas em um conjunto finito de recursos. Nem mesmo a nuvem e seu suprimento aparentemente infinito de computação mudam essa receita. No momento em que uma solicitação é recebida, a lista possível de recursos que podem aceitá-la e processá-la é finita. Período.
A decisão, então, sobre para onde direcionar uma solicitação se torna bastante importante. Envie-o para o recurso errado e o desempenho poderá ser prejudicado. Envie para o recurso certo e o consumidor/funcionário ficará encantado com o resultado.
Nos primeiros dias da escala, essas decisões eram baseadas apenas em algoritmos. Sistema de rodízio. Menos conexões. Resposta mais rápida. Esses mecanismos robustos ainda existem hoje, mas lenta e seguramente se tornaram apenas mais um fator no processo de tomada de decisão, em vez de o único fator.
Isso ocorre porque não dependemos mais exclusivamente de processos de tomada de decisão baseados em conexão (também conhecidos como "balanceamento de carga simples"). Quando o balanceamento de carga era principalmente sobre gerenciar conexões TCP, esquemas de distribuição baseados em conexões faziam sentido. Mas a escala agora é baseada tanto na arquitetura quanto nos algoritmos, e a distribuição de solicitações pode ser um cálculo complexo que envolve muitas variáveis acima (literalmente) e além dos protocolos da camada 4.
O que complica a distribuição é a realidade de que as arquiteturas atuais estão cada vez mais distribuídas. Não apenas entre nuvens, mas também entre contêineres. Várias versões do mesmo aplicativo (ou API) podem estar em serviço ao mesmo tempo. O sistema responsável por distribuir a solicitação deve estar ciente e ser capaz de distingui-las e garantir a entrega ao ponto final correto .
Hoje, as decisões são tomadas com base não apenas na capacidade de conexão, mas cada vez mais nos parâmetros da camada 7 (HTTP). Nomes de host. Métodos de API (também conhecidos como URI). Chaves de API. Cabeçalhos HTTP personalizados com números de versão incorporados. Localização. Dispositivo. Usuário. As solicitações são avaliadas no contexto em que são feitas e as decisões são tomadas em microssegundos.
A distribuição hoje exige uma abordagem arquitetônica em camadas. Quanto mais você se aprofunda na arquitetura do aplicativo, menos granular ele se torna. No momento em que um proxy toma uma decisão de balanceamento de carga entre X clones do mesmo microsserviço, ele pode estar usando nada mais do que equações tradicionais baseadas em algoritmos. Enquanto isso, nas bordas externas do ambiente, os controladores de entrada às vezes tomam decisões complexas com base em variáveis da camada HTTP.
Externamente, a distribuição é impulsionada pela arquitetura . Por dentro, por algoritmos .
Ambos são componentes críticos – os mais críticos, talvez – do dimensionamento de contêineres.
Ambos dependem de informações precisas e em tempo real sobre o status (saúde) dos recursos aos quais podem distribuir solicitações. Falaremos sobre monitoramento nas próximas postagens desta série.