🥇Casos de uso de malha de serviço

Observação. trad.: O autor deste artigo (Luc Perkins) é um defensor do desenvolvedor na organização CNCF, que abriga projetos de código aberto como Linkerd, SMI (Service Mesh Interface) e Kuma (a propósito, você também já se perguntou por que o Istio é não está nesta lista? .). Mais uma vez tentando trazer à comunidade DevOps uma melhor compreensão do hype da moda chamado “service mesh”, ele lista 16 capacidades características que tais soluções fornecem.

Hoje malha de serviço ― um dos tópicos mais quentes na área de engenharia de software (e com razão!). Acho que esta tecnologia é incrivelmente promissora e gostaria de vê-la amplamente adotada (quando fizer sentido, é claro). No entanto, ainda está rodeado por uma aura de mistério para a maioria das pessoas. Ao mesmo tempo, mesmo aqueles que bem conhecido com ele, muitas vezes é difícil articular suas vantagens e o que exatamente é (incluindo o seu). Neste artigo tentarei corrigir a situação listando vários casos de uso "malhas de serviço"*.

* Observação trad.: aqui e mais adiante no artigo exatamente esta tradução (“service mesh”) será usada para o ainda novo termo service mesh.

Mas antes quero fazer alguns comentários:

Nunca trabalhei com malhas de serviço ou as utilizei fora de projetos iniciados para minha própria educação. Por outro lado, fui eu quem escreveu um monte de documentação para o service mesh interno do Twitter em 2015 (naquela época nem era chamado de "service mesh") e participei do desenvolvimento do site e da documentação do linkerd, então isso significa alguma coisa.
Minha lista é aproximada e incompleta. Pode muito bem haver casos de uso desconhecidos para mim, e novas opções provavelmente surgirão ao longo do tempo, à medida que a tecnologia se desenvolve e sua popularidade cresce.
Ao mesmo tempo, nem todas as implementações existentes de service mesh suportam todos os casos de uso listados. Portanto, minhas afirmações como “service mesh podem...” devem ser lidas como “individuais, e talvez todas as implementações populares de service mesh possam...”.
A ordem dos exemplos não faz nenhuma diferença.

Lista curta:

descoberta de serviço;
criptografia;
autenticação e autorização;
balanceamento de carga;
interrupção do circuito;
escalonamento automático;
implantações canário;
implantações azul-verde;
exame de saúde;
rejeição de carga;
espelhamento de tráfego;
isolamento;
limitação de taxa de solicitação, novas tentativas e tempos limites;
telemetria;
auditar;
visualização.

1. Descoberta de serviço

TL;DR: Conecte-se a outros serviços na rede usando nomes simples.

Os serviços devem ser capazes de “encontrar-se” automaticamente usando nomes adequados - por exemplo, service.api.production, pets/staging ou cassandra. Os ambientes de nuvem são elásticos e um único nome pode ocultar muitas instâncias de um serviço. É claro que em tal situação é fisicamente impossível codificar todos os endereços IP.

Além disso, quando um serviço encontra outro, ele deve ser capaz de enviar solicitações a esse serviço sem medo de que acabem na entrada de sua instância quebrada. Em outras palavras, a malha de serviço deve monitorar a integridade de todas as instâncias de serviço e manter a lista de hosts o mais atualizada possível.

Cada malha de serviço implementa o mecanismo de descoberta de serviço de maneira diferente. No momento, a forma mais comum é delegar para processos externos como o DNS do Kubernetes. No passado, no Twitter, usávamos um sistema de nomenclatura para esse fim Falsificar. Além disso, a tecnologia service mesh possibilita o surgimento de mecanismos de nomenclatura personalizados (embora eu ainda não tenha visto nenhuma implementação de SM com tal funcionalidade).

2. Criptografia

TL;DR: Livre-se do tráfego não criptografado entre serviços e torne esse processo automatizado e escalonável.

É bom saber que os invasores não conseguem penetrar na sua rede interna. Os firewalls fazem um ótimo trabalho nisso. Mas o que acontece se um hacker entrar? Ele poderá fazer o que quiser com o tráfego intra-serviço? Esperemos que isso não aconteça afinal. Para evitar esse cenário, você deve implementar uma rede de confiança zero na qual todo o tráfego entre serviços seja criptografado. A maioria das malhas de serviços modernas consegue isso através de TLS (TLS mútuo, mTLS). Em alguns casos, o mTLS funciona em nuvens e clusters inteiros (acho que um dia as comunicações interplanetárias serão organizadas de forma semelhante).

Claro, para malha de serviço mTLS opcional. Cada serviço pode cuidar de seu próprio TLS, mas isso significa que você precisará encontrar uma maneira de gerar certificados, distribuí-los entre hosts de serviço e incluir código no aplicativo que carregará esses certificados a partir de arquivos. Sim, não se esqueça de renovar esses certificados em intervalos regulares. As malhas de serviço automatizam o mTLS com sistemas como SPIFFE, que, por sua vez, automatiza o processo de emissão e rotação de certificados.

3. Autenticação e Autorização

TL;DR: Estabeleça quem é o solicitante e defina o que ele pode fazer antes mesmo que a solicitação chegue ao serviço.

Os serviços muitas vezes querem saber que realiza a solicitação (autenticação) e, a partir dessas informações, decide que uma determinada entidade está autorizada a fazer (autorização). Neste caso, o pronome “quem” pode ocultar:

Outros serviços. Isso é chamado de "autenticação" par" Por exemplo, serviço web quer acessar o serviço db. As malhas de serviço geralmente resolvem esses problemas usando mTLS: os certificados, neste caso, atuam como o identificador necessário.
Alguns usuários humanos. Isso é chamado de "autenticação" pedido" Por exemplo, usuário haxor69 quer comprar uma lâmpada nova. As malhas de serviço fornecem vários mecanismos, por ex. Tokens da Web JSON.
Muitos de nós fizemos isso no código do aplicativo. Chega um pedido, olhamos a mesa users, encontre o usuário e compare a senha e verifique a coluna permissions etc. No caso de uma malha de serviço, isso acontece antes mesmo da solicitação chegar ao serviço.

Depois de estabelecermos de quem veio a solicitação, precisamos determinar o que essa entidade está autorizada a fazer. Algumas malhas de serviço permitem definir políticas básicas (sobre quem pode fazer o quê) como arquivos YAML ou na linha de comando, enquanto outras oferecem integração com estruturas como Agente de política aberta. O objetivo final é que seus serviços aceitem qualquer solicitação, assumindo com segurança que ela vem de uma fonte confiável и esta ação é permitida.

4. Balanceamento de carga

TL;DR: Distribua a carga entre instâncias de serviço de acordo com um padrão específico.

Um “Serviço” dentro de uma seção de serviço geralmente consiste em muitas instâncias idênticas. Por exemplo, hoje o serviço cache consiste em 5 exemplares, e amanhã seu número poderá aumentar para 11. Solicitações enviadas para cache, devem ser distribuídos de acordo com uma finalidade específica. Por exemplo, minimize a latência ou maximize a probabilidade de chegar a uma instância em funcionamento. O algoritmo mais comumente usado é o Round-robin, mas existem muitos outros - por exemplo, o método ponderado (pesada) consultas (você pode selecionar alvos preferidos), tocar (anel) hashing (usando hashing consistente em hosts upstream) ou método de menor solicitação (é dada preferência à instância com o menor número de solicitações).

Os balanceadores clássicos têm outras funções, como cache HTTP e proteção DDoS, mas não são muito relevantes para o tráfego leste-oeste (ou seja, para o tráfego que flui dentro de um data center - tradução aproximada) (escopo típico da malha de serviço). Obviamente, não é necessário usar uma malha de serviço para balanceamento de carga, mas ela permite definir e controlar políticas de balanceamento para cada serviço a partir de uma camada de controle centralizada, eliminando assim a necessidade de executar e configurar balanceadores de carga separados na pilha de rede. .

5. Interrupção de circuito

TL;DR: Interrompa o tráfego para o serviço problemático e controle os danos nos piores cenários.

Se por algum motivo o serviço não conseguir lidar com o tráfego, a malha de serviço oferece várias opções para resolver esse problema (outras serão discutidas nas seções apropriadas). A interrupção do circuito é a opção mais severa para desconectar um serviço do tráfego. No entanto, por si só não faz sentido - é necessário um plano de backup. A contrapressão pode ser fornecida (contrapressão) para serviços que fazem solicitações (só não esqueça de configurar seu service mesh para isso!), ou, por exemplo, colorir a página de status de vermelho e redirecionar os usuários para outra versão da página com uma “baleia caindo” (“Twitter é abaixo").

As malhas de serviço não apenas permitem definir quando o o desligamento seguirá e que isso se seguirá. Neste caso, “quando” pode incluir qualquer combinação de parâmetros especificados: o número total de solicitações durante um determinado período, o número de conexões paralelas, solicitações pendentes, novas tentativas ativas, etc.

Você provavelmente não quer abusar da interrupção do circuito, mas é bom saber que você tem um plano reserva em caso de emergência.

6. Escalonamento automático

TL;DR: Aumente ou diminua o número de instâncias de serviço dependendo dos critérios especificados.

As malhas de serviço não são agendadores, portanto não levar a cabo escalando a si mesmo. No entanto, eles podem fornecer informações nas quais os planejadores basearão suas decisões. Como as malhas de serviço têm acesso a todo o tráfego entre serviços, elas possuem informações extensas sobre o que está acontecendo: quais serviços estão com problemas, quais serviços estão pouco carregados (a capacidade alocada a eles é desperdiçada), etc.

Por exemplo, o Kubernetes dimensiona serviços com base no uso de CPU e memória dos pods (veja nosso relatório "Escalonamento automático e gerenciamento de recursos no Kubernetes"- Aproximadamente. trad.), mas se decidir escalar com base em qualquer outra métrica (no nosso caso, relacionada ao tráfego), você precisará de uma métrica especial. Gerenciamento assim mostra como fazer isso com Enviado, Istio и Prometeu, mas o processo em si é bastante complicado. Gostaríamos que a malha de serviço simplificasse isso, permitindo-nos simplesmente definir condições como “aumentar o número de instâncias de serviço auth, se o número de solicitações pendentes exceder o limite em um minuto."

7. Implantações canário

DR: teste novos recursos ou versões de serviço em um subconjunto de usuários.

Digamos que você esteja desenvolvendo um produto SaaS e pretenda lançar uma nova versão interessante dele. Você testou na preparação e funcionou muito bem. Mas ainda existem certas preocupações sobre o seu comportamento em condições reais. Em outras palavras, você precisa testar a nova versão em problemas reais sem arriscar a confiança do usuário. As implantações Canary são ótimas para isso. Eles permitem demonstrar um novo recurso para um subconjunto de usuários. Esse subconjunto pode ser composto pelos usuários mais fiéis ou que trabalham com a versão gratuita do produto, ou por usuários que manifestaram o desejo de serem “cobaias”.

As malhas de serviço implementam isso permitindo que você especifique critérios que determinam quem verá qual versão do aplicativo e roteará o tráfego de acordo. No entanto, nada muda para os serviços em si. A versão 1.0 do serviço acredita que todas as solicitações vêm de usuários que deveriam vê-lo, e a versão 1.1 acredita o mesmo para seus usuários. Enquanto isso, você pode alterar a porcentagem de tráfego entre as versões antiga e nova, redirecionando um número crescente de usuários para a nova se ela funcionar de forma estável e suas “cobaias” derem sinal verde.

8. Implantações azul-verde

DR: Lance um novo recurso interessante, mas esteja preparado para retirar tudo imediatamente.

Significado implantações azul-verde é lançar um novo serviço “azul”, lançando-o em paralelo com o antigo serviço “verde”. Se tudo correr bem e o novo serviço funcionar bem, o antigo poderá ser desativado gradualmente. (Infelizmente, algum dia este novo serviço “azul” repetirá o destino do serviço “verde” e desaparecerá...) As implantações azul-verde diferem das implantações canário porque a nova função cobre tudo de uma vez usuários (não fazem parte); A questão aqui é ter um “porto seguro” pronto para o caso de algo dar errado.

As malhas de serviço oferecem uma maneira muito conveniente de testar um serviço “azul” e mudar instantaneamente para um serviço “verde” funcional em caso de problemas. Sem falar que ao longo do caminho fornecem muitas informações (veja “Telemetria” abaixo) sobre o funcionamento do “azul”, o que ajuda a entender se ele está pronto para pleno funcionamento.

Observação. trad.: Você pode ler mais sobre diferentes estratégias de implantação no Kubernetes (incluindo o mencionado canário, azul/verde e outros) em Este artigo.

9. Exame de saúde

TL;DR: acompanhe quais instâncias de serviço estão funcionais e responda àquelas que não estão mais funcionais.

Exame de saúde (exame de saúde) ajuda a decidir se as instâncias de serviço estão prontas para aceitar e processar tráfego. Por exemplo, no caso de serviços HTTP, uma verificação de integridade pode parecer uma solicitação GET para o terminal /health... Responder 200 OK significará que a instância está íntegra, qualquer outro - que não está pronta para receber tráfego. As malhas de serviço permitem especificar a forma como a funcionalidade será verificada e a frequência com que essa verificação será realizada. Essas informações podem então ser usadas para outros fins – por exemplo, para balanceamento de carga e interrupção de circuito.

Assim, a verificação de integridade não é um caso de uso independente, mas geralmente é usada para atingir outros objetivos. Além disso, dependendo dos resultados das verificações de integridade, podem ser necessárias ações externas a outros destinos da malha de serviço: por exemplo, atualizar a página de status, criar um problema no GitHub ou preencher um tíquete JIRA. E a service mesh oferece um mecanismo conveniente para automatizar tudo isso.

10. Rejeição de carga

TL;DR: redireciona o tráfego em resposta a um aumento temporário no uso.

Se um determinado serviço estiver sobrecarregado com tráfego, você poderá redirecionar temporariamente parte desse tráfego para outro local (ou seja, “despejo”, “transferência” (cabana) ele lá). Por exemplo, para um serviço de backup ou data center, ou para um local permanente imprensa tema. Como resultado, o serviço continuará a processar algumas solicitações em vez de travar e parar de processar tudo por completo. A rejeição de carga é preferível à interrupção do circuito, mas ainda assim não é aconselhável abusar dela. Ajuda a evitar falhas em cascata que causam falhas nos serviços downstream.

11. Paralelização/espelhamento de tráfego

TL;DR: Envie uma solicitação para vários lugares ao mesmo tempo.

Às vezes é necessário enviar uma solicitação (ou uma determinada seleção de solicitações) para vários serviços ao mesmo tempo. Um exemplo típico é o envio de parte do tráfego de produção para um serviço de teste. O servidor web de produção principal envia uma solicitação ao serviço downstream products.production e só para ele. E a malha de serviço copia de forma inteligente essa solicitação e a envia para products.staging, do qual o servidor web nem sequer tem conhecimento.

Outro caso de uso de service mesh relacionado que pode ser implementado além da paralelização de tráfego é teste de regressão. Envolve enviar as mesmas solicitações para diferentes versões do serviço e verificar se todas as versões se comportam da mesma forma. Ainda não encontrei uma implementação de service mesh com um sistema integrado de teste de regressão como Difícil, mas a ideia em si parece promissora.

12. Isolamento

TL;DR: divida sua malha de serviço em minirredes.

Também conhecido como segmentaçãoIsolamento é a arte de dividir uma malha de serviço em segmentos logicamente distintos que nada sabem uns dos outros. O isolamento é um pouco como criar redes privadas virtuais. A diferença fundamental é que você ainda pode aproveitar todos os benefícios de uma malha de serviço (como descoberta de serviço), mas com segurança adicional. Por exemplo, se um invasor conseguir penetrar um serviço em uma sub-rede, ele não conseguirá ver quais serviços estão sendo executados em outras sub-redes ou interceptar seu tráfego.

Além disso, os benefícios também podem ser organizacionais. Você pode querer subdividir seus serviços com base na estrutura da sua empresa e aliviar os desenvolvedores da carga cognitiva de ter que manter toda a malha de serviço em mente.

13. Limitação de taxa de solicitação, novas tentativas e tempos limite

DR: Você não precisa mais incluir as tarefas essenciais de gerenciamento de solicitações em sua base de código.

Todas essas coisas poderiam ser consideradas casos de uso separados, mas decidi combiná-las devido a um recurso comum: elas assumem as tarefas de gerenciamento do ciclo de vida de solicitações normalmente executadas por bibliotecas de aplicativos. Se você estiver desenvolvendo um servidor web em Ruby on Rails (não integrado a uma malha de serviço) que faz solicitações para serviços de back-end via gRPC, o aplicativo terá que decidir o que fazer se N solicitações falharem. Você também terá que descobrir quanto tráfego esses serviços serão capazes de processar e codificar esses parâmetros usando uma biblioteca especial. Além disso, o aplicativo terá que decidir quando é hora de desistir e deixar a solicitação fracassar (com base no tempo limite). E para alterar qualquer um dos parâmetros acima, o servidor web deverá ser interrompido, reconfigurado e reiniciado.

Transferir essas tarefas para uma malha de serviço não significa apenas que os desenvolvedores de serviços não terão que pensar nelas, mas também que elas poderão ser visualizadas de uma forma mais global. Se for utilizada uma cadeia complexa de serviços, digamos A -> B -> C -> D -> E, todo o ciclo de vida da solicitação deverá ser levado em consideração. Se a tarefa é estender os tempos limite no serviço C, é lógico fazer isso tudo de uma vez, e não em partes: atualizando o código do serviço e aguardando até que a solicitação pull seja aceita e o sistema de CI implemente o serviço atualizado.

14. Telemetria

TL; DR: Colete todas as informações necessárias (e não exatamente) dos serviços.

Telemetria é um termo geral que inclui métricas, rastreamento distribuído e logs. As malhas de serviço oferecem mecanismos para coletar e processar todos os três tipos de dados. É aqui que as coisas ficam um pouco confusas porque o número de opções possíveis é muito grande. Para coletar métricas há Prometeu e outras ferramentas que podem ser usadas para coletar registros fluente, Loki, vetor etc (por exemplo ClickHouse com nosso casa de toras para K8s - aprox. trad.), para rastreamento distribuído há Jaeger e assim por diante. Cada service mesh pode suportar algumas ferramentas e não outras. Será interessante ver se o projeto pode Telemetria aberta fornecer alguma convergência.

Neste caso, a vantagem da tecnologia service mesh é que os contentores sidecar podem, em princípio, recolher todos os dados acima mencionados dos seus serviços. Ou seja, você tem à sua disposição um único sistema de coleta de telemetria, e o service mesh pode processar todas essas informações de diversas maneiras. Por exemplo:

logs finais de um determinado serviço na CLI;
monitorar o volume de solicitações do painel do service mesh;
coletar rastreamentos distribuídos e encaminhá-los para um sistema como o Jaeger.

Atenção, julgamento subjetivo: De modo geral, a telemetria é uma área na qual é indesejável uma forte interferência da malha de serviço. Coletar informações básicas e rastrear dinamicamente algumas métricas de ouro, como taxa de sucesso de solicitação e latência, é bom, mas esperemos que não vejamos o surgimento de pilhas de Frankenstein que tentam substituir sistemas especializados, alguns dos quais já provaram seu valor e foram bem estudados .

15. Auditoria

TL;DR: Aqueles que esquecem as lições da história estão fadados a repeti-las.

Auditoria é a arte de observar eventos importantes em um sistema. No caso de uma malha de serviço, isso pode significar rastrear quem fez solicitações a endpoints específicos para serviços específicos ou quantas vezes ocorreu algum evento relacionado à segurança no último mês.

É claro que a auditoria está intimamente relacionada com a telemetria. A diferença é que a telemetria está normalmente associada a coisas como produtividade e integridade técnica, enquanto a auditoria pode estar relacionada com questões jurídicas e outras que vão além da esfera estritamente técnica (por exemplo, conformidade com o GDPR – o Regulamento Geral da UE sobre proteção de dados).

16. Visualização

DR: Vida longa ao React.js - uma fonte inesgotável de interfaces sofisticadas.

Pode haver um termo melhor, mas não o conheço. Quero simplesmente dizer uma representação gráfica de uma malha de serviço ou de alguns de seus componentes. Essas visualizações podem incluir indicadores como latências médias, informações de configuração secundária, resultados de verificações de integridade e alertas.

Trabalhar em um ambiente orientado a serviços envolve uma carga cognitiva muito maior em comparação com Sua Majestade, o Monólito. Portanto, a pressão cognitiva deve ser reduzida a todo custo. Uma interface gráfica simples para um service mesh com a possibilidade de clicar em um botão e obter o resultado desejado pode ser decisiva para o crescimento da popularidade desta tecnologia.

Não foram incluídos na lista

Originalmente, eu pretendia incluir mais alguns casos de uso na lista, mas decidi não fazê-lo. Aqui estão eles, junto com os motivos da minha decisão:

Multidata center. Na minha opinião, este não é tanto um caso de uso, mas uma área restrita e específica de aplicação de malhas de serviço ou algum conjunto de funções como descoberta de serviço.
Entrada e saída. Esta é uma área relacionada, mas me limitei (talvez artificialmente) ao caso de uso "tráfego leste-oeste". A entrada e a saída merecem um artigo separado.

Conclusão

É tudo por agora! Novamente, esta lista é muito arbitrária e provavelmente incompleta. Se você acha que perdi alguma coisa ou entendi algo errado, entre em contato comigo no Twitter (@luckerkins). Por favor, respeite as regras de decência.

PS do tradutor

A ilustração do título do artigo é baseada em uma imagem do artigo “O que é Service Mesh (e quando usá-lo)?"(por Gregory MacKinnon). Ele mostra como algumas funcionalidades dos aplicativos (em verde) foram movidas para uma malha de serviço que fornece interconexões entre eles (em azul).