Resolvemos o erro 429 durante a grande promoção com o gateway do Kubernetes e também economizamos 30% dos custos com servidores.

No último Black Friday, nosso time quase entrou em colapso:13% das solicitações de resolução de endereços dos usuários foram rejeitadas diretamente com o código de erro 429.Após uma longa investigação no backend, descobrimos que as regras de limitação de tráfego definidas anteriormente para cada microserviço eram muito rígidas. Como resultado, o tráfego no módulo de consulta de logística aumentou em três vezes, e os recursos disponíveis não conseguiram ser utilizados devido à sobrecarga.

Antes, sempre pensávamos que o gateway do Kubernetes era um componente complexo usado apenas por grandes empresas. Foi só depois de nos depararmos com esse problema que fomos forçados a implementá-lo, e todo o processo levou menos de uma semana. O resultado foi muito melhor do que esperávamos.

O que exatamente é um gateway do Kubernetes?

Em outras palavras, é a entrada de tráfego unificada para todo o seu cluster Kubernetes. Todos os pedidos externos chegam primeiro a ela e, em seguida, são encaminhados para os serviços backend correspondentes. A versão open-source que usamos consegue suportar 12.000 pedidos por segundo com apenas um único instância, então equipes pequenas não precisam se preocupar com gargalos de desempenho.

Três benefícios reais que recebemos

O primeiro ponto mais óbvio é que as regras de limitação de tráfego finalmente não precisam mais ser configuradas individualmente para cada serviço. Antes, durante as grandes promoções, tínhamos que alterar os valores de limite de tráfego de sete ou oito microserviços, e se falhássemos em modificar um deles, surgiam problemas. Agora, a limitação de tráfego é feita dinamicamente no nível do gateway, e os recursos de servidor disponíveis são automaticamente realocados para os módulos que recebem mais tráfego. Durante a grande promoção de Natal, o número de erros do tipo 429 caiu para zero.

O segundo ponto é a redução de custos. Antes, para suportar os picos de demanda, adicionamos 2 servidores de reserva para cada um dos 3 serviços principais, mas a taxa de utilização dos recursos era de apenas 20% na maioria do tempo. Agora, com o balanceamento de carga automático do gateway, reduzimos o número de servidores para 6, e calculamos que os custos com a nuvem caíram em 30% por mês.

O terceiro ponto é evitar que o backend tenha que modificar repetidamente lógicas gerais relacionadas a cross-domain e autenticação. Antes, sempre que um novo serviço era lançado, o backend precisava escrever o código de verificação JWT novamente. Agora, basta configurar uma regra no nível do gateway, e isso resolve o problema. Com isso, nós, que somos apenas três pessoas no backend, ganhamos pelo menos meia hora por semana para escrever código de negócios.

Não se preocupe apenas com as vantagens; nós já caímos nestes dois problemas de forma bem séria.

O primeiro problema é que a configuração padrão do tempo de espera (timeout) é muito ruim. No primeiro dia de lançamento, descobrimos que 5% dos pedidos de resolução de endereços estavam falhando devido a timeout. Demorou um bom tempo para descobrir que o tempo de espera padrão do gateway era de 30 segundos, mas o nosso serviço de resolução de endereços leva no máximo 40 segundos para ser concluído. Após alterarmos as regras, o problema foi imediatamente resolvido. Antes de lançar o produto, é essencial verificar individualmente os valores dos limites de tempo de espera para cada uma das nossas interfaces de negócios.

O segundo erro é não tentar implementar todas as funcionalidades de uma vez. No início, queríamos ativar simultaneamente as funções de log, limitação de tráfego, WAF (Web Application Firewall) e lançamento em modo cinza (grayscale release), mas cometemos um erro na configuração, o que causou a interrupção do serviço em todo o cluster por 20 minutos. Depois disso, começamos apenas com a roteação de dados (routing) e a limitação de tráfego, e após 3 dias de funcionamento estável, adicionamos as outras funcionalidades gradualmente. Desde então, não tivemos mais problemas.

Devo usá-lo ou não? Os critérios que temos para decidir são muito simples.

Circunstâncias em que é adequado usar:

• Você tem mais de 5 microsserviços, e cada vez que precisa alterar a configuração geral, é necessário modificar vários locais.
• Frequentemente enfrentamos picos de tráfego, e não é possível realizar um escalonamento flexível dos recursos entre os diferentes serviços.
• A equipe de backend tem menos de 5 pessoas e não quer desperdiçar tempo escrevendo lógicas genéricas repetidamente.

Situações em que não vale a pena se dar ao trabalho:

• Você tem apenas 2 microsserviços, e o tráfego é estável o ano todo. Atualmente, o uso do NGINX para redirecionamento não está apresentando nenhum problema.
• Ninguém na equipe entende os fundamentos do Kubernetes; não force a adoção de novas tecnologias apenas por causa disso.

2 dicas reais para equipes pequenas que estão começando pela primeira vez

Não se preocupe em escolher uma solução; equipes pequenas podem usar diretamente os APIs abertos como APISIX ou Kong. Há documentação completa disponível, e se surgirem problemas, geralmente há soluções disponíveis na internet. Não é necessário comprar a versão comercial, pois as funcionalidades da versão gratuita são mais do que suficientes.

Antes de lançar, direcione 10% do tráfego para teste por 24 horas, com foco em verificar se há casos de timeout ou pedidos interceptados incorretamente. Se tudo estiver ok, então transfira todo o tráfego. Não transfira todo o tráfego de uma vez.

Finalmente, uma pergunta que muitos fazem: ninguém havia pesquisado especificamente sobre gateways nos nossos três servidores de backend antes, mas montamos tudo em apenas 2 dias com base nos documentos oficiais. Não é tão complicado quanto você pode pensar.