Tráfego interno: do "aeroporto central" a sidecar, mTLS e Istio

01 · CONTEXTO

Um aeroporto caótico por dentro do Fury

O tráfego interno do Fury, no relato da equipe de engenharia do Mercado Livre, lembrava um aeroporto caótico, com milhões de passageiros viajando para milhares de destinos. Nesse aeroporto, todos viajavam sem passaportes, sem controles de imigração e sem fiscalização alfandegária.

Nos picos de acesso, o tráfego interno sozinho passa de 400M por minuto, com mais de 30k aplicações divididas em mais de 75k grupos de instâncias. Por isso, qualquer solução ou mudança precisa considerar essa escala.

1. O diagrama mostra o acesso à plataforma entrando por uma camada de tráfego central, e uma seta de saída da aplicação A voltando para essa mesma camada.

2. O acesso entra pela camada de tráfego central, que roteia a requisição para a aplicação de destino.

3. Quando uma aplicação precisa falar com outra, ela envia uma nova requisição de saída pela mesma camada, que a encaminha ao destino.

4. A fonte descreve esse aeroporto central como o ponto de convergência de todos os voos.

5. Do ponto de vista do destino, todos os voos parecem vir da mesma origem.

02 · IDENTIDADE

Sem passaporte e sem imigração

Muitas aplicações operavam sem autenticação adequada, então não era possível verificar a autenticidade da origem. Isso permitia que qualquer um dentro da plataforma usasse qualquer API sem nenhuma forma de controle.

Sem identidade também não havia como criar regras de acesso por cliente específico, porque não era possível identificá-los de forma única.

03 · ROTAS

Um caderno central e todos os caminhos levando a Roma

Toda rota e todo destino existente estavam escritos em um único lugar, o caderno central. Adicionar, remover ou alterar um destino exigia mudar esse mesmo caderno, e a fonte fala em mais de 100K rotas definidas.

A comunicação também era centralizada: mesmo entre aeroportos próximos, os passageiros faziam escala no aeroporto central antes de chegar ao destino. Para quem recebia, todos os voos pareciam vir da mesma origem.

04 · SIDECAR

Aeroportos locais: sidecar, certificados e mTLS

O primeiro passo foi aliviar o aeroporto central distribuindo os novos controles de segurança para aeroportos locais. Cada aeroporto local é um sidecar de tráfego que roda ao lado da aplicação, atuando como proxy reverso na entrada e como proxy transparente na saída.

O sidecar deu presença em todas as aplicações do ecossistema Fury e foi o pontapé para ter melhor controle, observabilidade e governança do tráfego. Na palestra da QCon SF, a equipe também cita o Traffic Middleware entre os sidecars da plataforma.

1. O diagrama mostra um sidecar ao lado de cada aplicação, com a autoridade certificadora e o Traffic Authorization ligados aos sidecars.

2. O sidecar roda ao lado da aplicação, como proxy reverso para o tráfego de entrada e proxy transparente para o de saída.

3. A autoridade certificadora gera os certificados na criação dos serviços ou escopos e os renova a cada deploy.

4. Todo o tráfego é carimbado na origem e validado no destino.

5. Na terceira versão da identidade, o mTLS é resolvido pelo sidecar e protege a comunicação nos dois sentidos.

6. O Traffic Authorization guarda o que cada aplicação pode acessar, e o sidecar do destino aplica essas regras com filtros RBAC do Envoy.

Para identificar os passageiros, a equipe implantou uma autoridade certificadora que gera os certificados, os passaportes, na criação dos serviços ou escopos e os renova a cada deploy. O tráfego é carimbado na origem e validado no destino. A identidade passou por três versões:

05 · AUTORIZAÇÃO

Imigração e rotas por equipe

Confirmada a identidade, entra a autorização. O Traffic Authorization permite que as equipes especifiquem os endpoints, métodos e domínios acessíveis em uma aplicação, bem como os necessários para interagir com outras. Com isso, o tráfego interno foi catalogado e é possível rastrear a origem e o destino de cada voo.

As regras começaram como validações personalizadas no destino, com Nginx, Lua e customizações em Golang. Na migração do sidecar de Nginx para Envoy, a equipe aproveitou para padronizar o processo e passou a usar filtros RBAC do Envoy.

No lado das rotas, o Traffic Routes dá a cada equipe de desenvolvimento um domínio próprio, onde ela mapeia caminhos para destinos. As equipes podem definir condições por cabeçalhos da requisição, parâmetros de consulta ou métodos HTTP, e testar as rotas antes de ir para produção.

06 · SERVICE MESH

A torre de controle: Istio

A fonte afirma que o service mesh reduz os congestionamentos, por exemplo removendo o balanceador e a camada de tráfego centralizada da equação, e que sem ele não teriam conseguido descentralizar todo o tráfego. No papel de torre de controle, o mesh direciona os voos por rotas seguras ou menos congestionadas.

Depois de analisar várias opções, inclusive desenvolvimento próprio, a equipe escolheu o plano de controle do Istio, entre outros fatores por ser uma solução madura e de código aberto com os recursos de que precisavam. A integração ao ecossistema Fury incluiu os processos de criação e deploy, os controles de segurança e a troca de informações de roteamento com o Traffic Routes.

1. O diagrama mostra um sidecar ao lado de cada aplicação, com o plano de controle do mesh ligado aos sidecars e o Traffic Routes ligado ao plano de controle.

2. O acesso à plataforma continua começando pela camada de tráfego centralizada.

3. A requisição é interceptada pelo sidecar, que a repassa à aplicação.

4. Na comunicação entre aplicações, a requisição de saída é interceptada pelo sidecar e roteada direto ao próximo destino.

5. O mesh faz o papel da torre de controle, direcionando os voos por rotas seguras ou menos congestionadas.

6. A integração do Istio ao Fury inclui a troca de informações de roteamento com o Traffic Routes.