Utilizamos um gateway nativo da nuvem para economizar 38% dos custos de processamento de tráfego, mas quase estragamos a cadeia de distribuição de produtos frescos na Europa durante o Black Friday.

A reunião de análise do grande evento promocional do Black Friday da semana passada acabou de terminar, e nosso pequeno time de três pessoas responsável pelo backend de entrega de produtos frescos na Europa ainda está preocupado: no dia da pré-venda, 17% dos pedidos de cadeia de frio foram rejeitados, resultando em 429 casos; o número de reclamações dos usuários aumentou em três vezes, e quase estragamos o grande evento promocional anual que tínhamos preparado durante três meses.

O problema surgiu devido ao uso de um gateway API tradicional por dois anos: definimos um limite de taxa de solicitações unificado para duas interfaces essenciais, a resolução de endereços e o agendamento da cadeia de frio. No dia do Black Friday, as solicitações de resolução de endereços explodiram, ocupando completamente a capacidade do gateway, e as solicitações de agendamento subsequentes não conseguiram ser processadas. Antes, sempre pensávamos que a troca de gateway era algo que apenas equipes grandes precisariam considerar. Foi só depois de enfrentar esse problema que percebemos que, para equipes menores, um gateway nativo da nuvem pode ser uma opção mais econômica e eficiente.

O que exatamente é um gateway nativo da nuvem?

Em uma palavra: é a entrada de tráfego que opera dentro de um cluster K8s, sem a necessidade de você alugar servidores separadamente para sua implementação.Você só precisa cuidar das regras de roteamento e das estratégias de limitação de tráfego; o restante, como a elasticidade dos recursos e as atualizações de operação e manutenção, é todo gerido pelo fornecedor de cloud.A versão que estamos usando agora consegue suportar 20.000 solicitações por segundo em um único instância, sem a necessidade de planejar a capacidade com antecedência.

Os três benefícios reais que obtivemos após a tradução são:

Após o problema no dia da pré-venda, levamos 3 dias para migrar para o gateway nativo da nuvem. No dia do evento principal do Black Friday, não houve mais nenhum problema de bloqueio excessivo de tráfego. Além disso, houve três benefícios além do esperado:

• O custo diminuiu diretamente: antes, alugávamos dois servidores 8G de 4 núcleos separados para executar gateways tradicionais, além de uma operação e manutenção gastando 8 horas por mês para atualizar a versão, calculando o custo mensal de 1200 euros. Agora, o gateway nativo na nuvem paga de acordo com o volume de chamadas, e custa apenas 740 euros por mês.Economizou diretamente 38% dos custos de processamento de tráfego.
• Finalmente entendi a estratégia de limitação de tráfego: o gateway anterior só podia definir um limiar de limitação de tráfego para todas as interfaces de forma global, mas agora podemos estabelecer regras independentes para diferentes cenários de negócios — por exemplo, a interface de resolução de endereços pode receber no máximo 5000 solicitações por segundo. Mesmo que ela seja sobrecarregada, isso não afetará os links de pagamento ou reserva subsequentes.
• O tempo de handshake do HTTPS foi reduzido pela metade: antes, nosso certificado SSL estava localizado em um servidor de gateway próprio, o que causava atrasos de até 200 ms no handshake para usuários em diferentes regiões da Europa. Agora, os fornecedores de cloud armazenam o certificado em nós de borda (edge nodes), e a maioria dos pedidos consegue ter um tempo de handshake inferior a 80 ms.

Não se apresse em entrar no carro, nós já passamos por esses dois problemas.

Não é que todos os gateways nativos da nuvem sejam apenas vantagens; durante o processo de migração, também encontramos dois problemas que quase nos fizeram ter que refazer o trabalho:

O primeiro problema é o atraso no inicialização a frio. Após o primeiro dia de teste de carga, observamos que, após 10 minutos sem solicitações, o tempo de resposta para o primeiro pedido aumentou repentinamente para mais de 300 ms. Mais tarde descobrimos que as instâncias elásticas do fornecedor de nuvem são iniciadas conforme necessário, e é necessário definir um número mínimo de instâncias reservadas para as interfaces principais; caso contrário, o aumento súbito de tráfego em tempos de baixa atividade pode facilmente causar timeouts.

O segundo ponto são as restrições dos plugins personalizados. Antes, escrevemos um plugin para verificar a assinatura das solicitações e o executamos em um gateway tradicional. Somente quando mudamos para o gateway nativo da nuvem percebemos que este suportava apenas plugins no formato WebAssembly. Levamos dois dias para modificar o código para que funcionasse corretamente. Se você tiver muita lógica personalizada, é melhor verificar primeiro quais plugins o fornecedor suporta.

Devo realmente trocar? Basta olhar para esses dois critérios de julgamento.

A situação em que você deveria trocar é:

• A equipe tem menos de 5 desenvolvedores de backend e não possui um profissional de operações e manutenção dedicado; não queremos gastar tempo com a manutenção e atualização dos servidores de gateway.
• Flutuações significativas no tráfego, como durante promoções, onde o volume de acesso pode chegar de 3 a 10 vezes o normal. Não queremos alugar um grande número de servidores com antecedência, pois isso significaria desperdício de dinheiro com equipamentos que ficariam ociosos na maioria do tempo.

Circunstâncias em que você não deveria trocar:

• As exigências de conformidade são particularmente rigorosas; todo o tráfego deve passar por servidores que você mesmo controle, e não pelos nós públicos dos fornecedores de cloud.
• Seu gateway possui muita lógica personalizada e especial que não é suportada pelos gateways nativos da nuvem disponíveis no mercado. Alterá-lo sozinho custaria mais do que a manutenção do próprio gateway.

Três pequenos conselhos para quem está começando

• Não é necessário fazer a migração completa de todo o tráfego de uma vez; primeiro, direcione 10% do tráfego para o gateway nativo da nuvem por uma semana. Após monitorar e não encontrar nenhum problema, então realize a migração gradualmente. No início, começamos com a migração da interface de resolução de endereços, e só depois de confirmar que não havia problemas é que transferimos todo o tráfego.
• As interfaces principais devem ter um número mínimo de instâncias configuradas. Não economize nesse dinheiro; agora, reservamos 2 instâncias permanentes para cada uma das interfaces principais de reserva e pagamento da cadeia de frio, e nunca mais tivemos problemas de tempo de inicialização excessivamente longo.
• Não é necessário comprar a versão mais avançada; para a maioria das pequenas e médias empresas, as funcionalidades da versão básica são mais do que suficientes. A versão básica que estamos usando atualmente não requer pagamento para um volume de tráfego inferior a 20.000 QPS.

A última resposta à pergunta mais frequente feita pela equipe interna: Será que o produto ficará vinculado a um fornecedor de nuvem?

Nossa conclusão é: para equipes de desenvolvimento de back-end com menos de 10 pessoas,A melhoria na eficiência trazida pela vinculação com os fornecedores de cloud é muito maior do que o custo de desenvolver todos os componentes do zero.Quando realmente chegar o dia de trocar de fornecedor de nuvem e você tiver a energia suficiente para realizar a migração, então não se preocupe com isso agora.