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 no monitoramento.
Monitoramento. Em uma era em que tudo parece estar ouvindo e/ou observando tudo, desde a velocidade com que dirigimos até o que está na nossa geladeira, a palavra deixa um gosto ruim na boca de muitas pessoas. Podemos usar – e frequentemente o fazemos – a palavra “visibilidade” em vez disso, mas esse sofisma semântico não muda o que estamos fazendo – estamos observando de perto.
Tudo sobre escala depende do monitoramento; de conhecer o estado dos recursos entre os quais você está distribuindo solicitações. Enviar uma solicitação para uma "zona morta" porque o recurso caiu ou foi desligado recentemente é semelhante a entrar em uma rua sem saída, sem saídas. É uma perda de tempo.
O monitoramento tem muitas opções. Há o monitoramento "posso falar com você" de um ping na camada de rede. Há o monitoramento “você está em casa” de uma conexão TCP. E há o "você está atendendo a porta" de uma solicitação HTTP. Depois, há o monitoramento “você já tomou seu café”, que determina se o serviço está respondendo corretamente ou não.
Além de verificar a integridade e a execução de um serviço, vem o monitoramento de desempenho. A rapidez com que o serviço respondeu é essencial se você estiver distribuindo solicitações com base nos tempos de resposta. Mudanças repentinas no desempenho podem indicar problemas, o que significa que são dados historicamente significativos que também precisam ser monitorados.
Há monitoramento ativo (deixe-me enviar uma solicitação real!), monitoramento sintético (deixe-me enviar uma solicitação fictícia) e monitoramento passivo (vou apenas sentar aqui e observar o que acontece com uma solicitação real). Cada um tem prós e contras, e todos são métodos válidos de monitoramento. A chave é que o proxy é capaz de determinar o status – está ativo? Está inativo? Saiu do prédio junto com Elvis?
Acessibilidade, disponibilidade e desempenho são aspectos do monitoramento e necessários para garantir a escalabilidade. O que significa que não se trata apenas de monitoramento, mas de garantir que os proxies de balanceamento de carga tenham informações atualizadas sobre o status de cada recurso para o qual podem direcionar uma solicitação.
Se você pensar na natureza dos contêineres e na propensão de combiná-los com uma arquitetura baseada em microsserviços, verá que o monitoramento rapidamente se torna uma proposta de pesadelo. Isso ocorre porque o modelo mais popular de balanceamento de carga dentro de ambientes de contêiner são os proxies de encaminhamento (e sidecar). Ambos exigem que cada nó saiba sobre a saúde e o bem-estar de cada recurso para o qual pode ser necessário enviar uma solicitação. Isso significa monitorar praticamente todos os recursos.
Você pode imaginar que não é realmente eficiente para um determinado recurso gastar seus próprios recursos limitados respondendo a quinze ou vinte proxies avançados quanto ao seu status. O monitoramento nesse modelo tem um efeito significativamente negativo tanto no desempenho quanto na capacidade, o que torna a escala ainda mais difícil.
O monitoramento nunca teve um impacto tão significativo na escala como estamos vendo com os contêineres.
E ainda assim é crítico – como observado acima – porque não queremos perder tempo com recursos “sem saída”, se pudermos evitá-lo.
Os desafios do monitoramento necessário são uma das razões pelas quais a malha de serviços continua ganhando popularidade (e força) como o futuro modelo de escala em ambientes de contêiner.
Porque o monitoramento não é opcional, mas também não deve ser um fardo.