Na primeira EnvoyCon em Seattle, EUA, os engenheiros do Pinterest, Yelp e Groupon apresentaram seus casos de uso atuais para o Envoy Proxy. A mensagem geral é que o Envoy parece estar se aproximando da sua visão de fornecer uma "API do plano de dados universal [proxy]" para redes modernas. Grandes organizações comerciais estão confiando no Envoy para gerenciar o tráfego de produção para uma variedade de casos de uso, incluindo gateways de borda, malhas de serviço e pontes de rede híbridas.
No ano passado, a equipe de engenharia do Pinterest migrou de um modelo de "balanceador de carga de perímetro" para um proxy de borda baseado em Envoy, no qual todo o tráfego de borda de produção passa agora pelo Envoy. Derek Argueta, engenheiro de confiabilidade do site de tráfego (SRE) no Pinterest, descreveu como a infraestrutura existente foi implantada na nuvem pública da AWS e usou um Elastic Load Balancer Layer 7 e um cache Varnish para fornecer gerenciamento de tráfego ingresso. Desafios com essa solução incluíam problemas de escalonamento ELB, terminação TLS abaixo do ideal e falta de suporte efetivo para manipulação dinâmica de upstream (por exemplo, atualização do roteamento à medida que novos serviços são implantados ou instâncias antigas são retiradas). Depois de analisar os proxies de rede, atualmente disponíveis, a equipe também descobriu motivações adicionais para migrar para o Envoy, que incluíam a API de extensão, observabilidade mais efetiva e consistência com os planos de malha de serviço.
O esforço inicial de migração do Envoy se concentrou na criação de uma nova solução de borda que oferecesse paridade de recursos com a pilha existente, que incluía implantações A/B, detecção de bot e assinatura de solicitação de CDN. Várias "falhas" foram encontradas durante a migração, incluindo o agressivo circuito padrão do Envoy, a orquestração de reinicialização a quente em contêineres para evitar a queda do tráfego e várias "lêndeas e incompatibilidades" de HTTP (relacionadas à Lei de Hyrum). Assim, a equipe de engenharia investiu pesadamente no desenvolvimento de habilidades para depurar problemas do Envoy. Isso foi um desafio, já que as habilidades existentes na equipe de engenharia de borda geralmente se concentravam em soluções de balanceamento de carga corporativo baseadas em hardware.
Argueta forneceu uma visão geral abrangente de como o Pinterest executa as implantações A/B "baseadas em etapas" com a nova solução de borda com tecnologia Envoy. Isso foi implementado como uma "solução personalizada" devido ao requisito de compatibilidade com o sistema de implantação existente. Durante o lançamento de um novo recurso, várias versões do serviço são implantadas e o roteamento é controlado por meio de uma lista de dados de host, IP e estágio adicionados ao Zookeeper. Esses dados são transmitidos para os Envoys de borda por meio de um plano de controle personalizado que consiste em um processo de sidecar que interage com a API do serviço de descoberta de terminais (EDS).
Em relação à observabilidade, uma série de gráficos e painéis foram criados e iterados, com o objetivo de fornecer uma "alta relação de informação" e ajudar os SREs e outros engenheiros a identificar rapidamente os problemas e as causas subjacentes associadas. Os alertas foram configurados para Envoys de borda que observam o alto uso de recursos, erros de conexão e erros de protocolo. Trabalhos futuros a serem realizados incluem o fornecimento de suporte Thrift e integração do Memcached, adicionando um filtro MySQL e Apache Kafka, movendo a autenticação da API para o Envoy de borda.
A próxima sessão: "Como criar você mesmo um ataque DDOS com o Envoy (e outros horrores da migração)", foi apresentada por Ben Plotnick e John Billings, engenheiro de software e líder técnico do Yelp, respectivamente. Billings começou a conversa afirmando que os desenvolvedores de aplicativos se preocupam principalmente com o envio rápido de código livre de erros para que eles possam resolver os problemas dos clientes; eles não estão tão preocupados com coisas como usar novas tecnologias RPC ou definir valores de tempo limite de comunicação. Assim, em 2014, a equipe de engenharia de infraestrutura do Yelp implementou o que eles chamam de "malha de serviço v1". Isso abstraiu parte do tratamento da comunicação de rede do aplicativo para a infraestrutura, e foi implementado pela execução de uma camada de roteamento HAProxy centralizada (e configurada manualmente). Isso foi um pouco semelhante ao padrão enterprise service bus (ESB) da clássica arquitetura orientada a serviços (SOA).
Embora útil, o recarregamento manual do HAProxy (e esforço de engenharia associado) combinado com problemas de dimensionamento levou a equipe de infraestrutura a implementar o "service mesh v2", que se baseava na solução de descoberta de serviços SmartStack da AirBnb. Essa solução ainda usava o HAProxy, mas muitas tarefas operacionais de rotina foram implementadas e automatizadas, usando processos auxiliares. Isso significava que não havia mais espera dos operadores humanos para implementar as alterações de configuração e não mais problemas de dimensionamento manual.
Embora essa solução tenha funcionado com sucesso por quatro anos, uma pesquisa sobre a "felicidade do desenvolvedor" em 2018 revelou várias áreas de potencial melhoria. Isso inclui a capacidade de implementar o roteamento de solicitações dinâmicas e obter acesso aos canários de produção antes de expô-los ao tráfego do usuário (sem a necessidade do tempo dos engenheiros de operações). Uma avaliação de risco operacional associada foi realizada, e três soluções potenciais exploradas: estender o HAProxy para fornecer essa funcionalidade, já que a equipe de engenharia estava familiarizada com ela; mudar para Envoy, que estava ganhando força com histórias de sucesso da Lyft, Google e IBM; ou mudar para o Linkerd, outra implementação de malha de serviço de código aberto popular. A decisão foi finalmente migrar para uma malha de serviço com tecnologia Envoy, usando o padrão de arquitetura subjacente fornecido pelo SmartStack.
A equipe de engenharia de infraestrutura implementou o "meshd", um plano de controle simples para o Envoy que foi escrito em Python (devido ao conforto da equipe com essa linguagem) e usou arquivos para o carregamento da configuração. Aplicando o princípio do "desenvolvimento incremental", foi identificado um caso de uso restrito, e uma solução usando o meshd implementado de ponta a ponta para verificar essa abordagem. Plotnick discutiu como a identificação de "pontos de corte", que forneceu o impacto máximo (com invasão mínima), levou-os a implementar bibliotecas de thin client para uso pelas equipes de desenvolvimento. A funcionalidade fornecida nesses thin clients incluía: propagação de contexto, definição de cabeçalhos x-envoy-* e empacotamento de dados. As bibliotecas cliente também eram um local ideal para implementar sinalizadores de recursos para permitir a experimentação, alternando o roteamento entre a solução existente e a nova, com tecnologia Envoy.
Os princípios de integração contínua e entrega contínua foram amplamente utilizados durante o desenvolvimento da nova malha Envoy, e testes automatizados de ponta a ponta substituíram a validação manual da solução anterior.
A apresentação foi concluída com um lembrete de que, embora trabalhar com tecnologia emergente como o Envoy seja muito divertido, o foco principal da engenharia deve ser a solução dos problemas dos usuários - afinal, é por isso que a organização e a equipe foram formadas.
Na próxima sessão, Tristan Blease, engenheiro de software da Groupon, e Michael Chang, engenheiro de software sênior da Groupon, apresentaram "Transpondo a lacuna entre on-prem e cloud: uma história sobre Envoy + um limite híbrido". O Groupon atualmente executa a maioria de suas cargas de trabalho de aplicativos nas instalações, mas o plano é, em última análise, executar uma pilha híbrida, com a inclusão de serviços em nuvem pública e contêineres que são implantados no Kubernetes.
A pilha atual usa uma variedade de tecnologias para lidar com tráfego interno e de borda, e a migração planejada criou novos requisitos que precisam ser avaliados: evite processos manuais para configuração, forneça uma "história mais forte" em relação à observabilidade, implemente TLS e controle de acesso para comunicação serviço-a-serviço. A equipe de engenharia experimentou e identificou seus "componentes ideais de arquitetura", um dos quais era o Envoy.
Blease e Chang forneceram uma visão abrangente da arquitetura do sistema atual e planejada, e discutiram os desafios de obter tráfego do local para a nuvem e vice-versa. As instâncias de envio serão implantadas como um nó de proxy de borda e serão responsáveis pelo roteamento de tráfego entre os ambientes. A configuração do Envoy será armazenada principalmente com um banco de dados NoSQL que, com uma pequena quantidade de cola, atuará como o plano de controle, fornecendo dados de host, rotas e terminais para as APIs xDS de gerenciamento Envoy associadas.
Slides dos Decks das palestras podem ser encontrados na página da EnvoyCon Sched, e a gravação de muitas das apresentações pode ser encontrada no canal CNCF no YouTube.