Escalar contêineres é mais do que simplesmente colocar um proxy na frente de um serviço e achar que está tudo resolvido. A escalabilidade vai além da simples distribuição e, no mundo dinâmico dos contêineres, há cinco recursos distintos necessários para garanti-la: novas tentativas, disjuntores, descoberta, distribuição e monitoramento.
Neste segundo post sobre a arte de escalar contêineres, vamos nos aprofundar nos circuit breakers.
Disjuntores
Thomas Edison, que ficou famoso por inventar milhares de dispositivos que não funcionavam e alguns outros célebres que funcionavam, apresentou o conceito de disjuntor em um pedido de patente de 1879. Sim, as patentes já existiam naquela época. Embora a versão de Edison usasse fusíveis, que precisam ser substituídos (alguns de nós talvez se lembrem de procurá-los desesperadamente em nossos carros antigos), as versões mais modernas são projetadas para “desarmar” e interromper o fluxo de eletricidade. Depois, elas podem ser rearmadas, restabelecendo o fluxo e o funcionamento normais.
No contexto de escalabilidade, os circuit breakers funcionam com base no mesmo princípio. Eles detectam uma “sobrecarga” e interrompem deliberadamente o fluxo para evitar sobrecarregar os serviços na outra ponta da conexão. Eles também podem ser redefinidos, restabelecendo posteriormente o fluxo normal de solicitações e respostas.
Os circuit breakers fazem parte dos proxies de balanceamento de carga há bastante tempo. A premissa é que, se após X tentativas ainda não for possível acessar determinado serviço, ele está fora do ar. Não há motivo para continuar solicitando algo que ele não pode fornecer, pois isso apenas desperdiça recursos do proxy e da rede. Portanto, após um número de falhas (geralmente) configurável, o proxy “abre” o circuito e se recusa a tentar novas conexões.
Isso não é o mesmo que uma nova tentativa, embora o processo pareça semelhante. As novas tentativas partem do princípio de que a solicitação acabará sendo bem-sucedida. Um circuit breaker parte do princípio de que a solicitação falhará e, portanto, deve-se evitar o desperdício de tempo e recursos com novas tentativas.
Depois que o problema for resolvido, o circuit breaker poderá ser “rearmado” e o fluxo normal poderá ser retomado.
No início, esse processo era manual. Um operador precisava realizar a redefinição após confirmar que o serviço de destino estava de fato novamente disponível. Mais recentemente, esse processo foi automatizado por meio do monitoramento de integridade. Isso normalmente inclui tentativas periódicas de acessar o serviço e, quando bem-sucedidas, a redefinição do circuit breaker para permitir que as operações normais sejam retomadas.
Os circuit breakers são particularmente importantes em ambientes conteinerizados e de microsserviços devido ao alto volume de tráfego que flui de e para os serviços e entre eles. Embora algumas falhas possam ser identificadas rapidamente, outras só serão percebidas após um longo tempo limite de TCP, devido a problemas na pilha de rede. Tempos limite geram uma latência indesejável; portanto, o acionamento do circuit breaker e as novas tentativas devem levar em conta a tolerância geral da aplicação à latência (ou a falta dela, conforme o caso). A configuração desses valores precisa considerar os tempos limite e as expectativas da empresa em relação ao desempenho. Uma baixa tolerância à latência pode exigir menos tentativas e um acionamento mais rápido do circuit breaker.
Sobre o autor
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 VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...