Booking.com corta custos de Node.js em 38% com Watt

O resultado em números

A Booking.com publicou um estudo de caso sobre a operação de Node.js em larga escala usando o Watt, ferramenta da Platformatic, afirmando uma redução de 38% nos custos de computação do serviço. Ao reconfigurar seu principal serviço de renderização em Node.js, a empresa passou a rodar 30% menos pods, reduziu em 20% o uso de memória de cada pod restante e diminuiu a latência em até 10% nos percentis p75, p99 e p99.9. A migração não exigiu hardware novo e nenhuma linha do código do serviço foi alterada.

De pm2 para Watt: por que a mudança importa

O autor do texto, que também é criador da ferramenta, costumava dizer que "amigos não deixam amigos usar pm2". A mudança técnica relevante está na passagem do cluster module do pm2 para o worker threads do Watt. Com o Watt, cada worker aceita conexões diretamente do kernel via SO_REUSEPORT, em vez de fazer todas as requisições passarem por um supervisor via IPC. Isso elimina um salto no caminho da requisição, e o benefício aparece sob carga: em testes com cargas mistas, o serviço passou a lidar com 40% a 50% mais requisições mantendo os mesmos objetivos de latência (SLO).

O problema de balanceamento e a solução

Havia um detalhe delicado no balanceamento de carga. Quando o SO_REUSEPORT é usado, o sistema define qual worker recebe a conexão por meio de hash dos endereços e portas. Como o tcp_tw_reuse permite reutilizar conexões de loopback, o hash tende a cair sempre no mesmo worker, distribuindo o trabalho de forma desigual - os threads mais ocupados chegavam a estar até 40% mais carregados que os menos ocupados, com variação conforme o fluxo de trabalho.

A solução da Booking.com, descrita como elegante, foi não brigar com o kernel: cada worker passou a escutar em sua própria porta, e o nginx, que já estava em uso, assumiu o balanceamento na frente deles. O round robin funcionou bem e, em um serviço, os endpoints que exigem renderização intensiva e os leves foram separados em workers distintos (configuração 4+1) usando least_conn para ganhar alguns pontos percentuais na cauda. Esse modo de operação é suportado pelo Watt pela configuração portAssignment com perWorkerIncrement.

Recuperação automática e teste honesto

O texto destaca ainda que o Watt monitora automaticamente os threads e reinicia qualquer um que esteja bloqueando o event loop. O comportamento projetado por ele foi: quando um worker deixa de responder, deve ser reiniciado em vez de apenas ser observado, e esse reinício deve ficar visível sem precisar olhar o dashboard.

A Booking.com conduziu o experimento como um teste A/B de produção: duas instalações completas rodaram lado a lado, com o mesmo número de pods e os mesmos recursos, com o tráfego dividido no nível de roteamento. O headroom extra foi usado para ajustar o garbage collector do V8. O autor classifica esse método como uma forma completa e honesta de validar a migração, do tipo de cuidado de engenharia que faz valer a pena um estudo de caso.

Conclusão

A migração do pm2 para o Watt, sem tocar no código do serviço, entregou menos pods, menos memória, menor latência e maior capacidade sob carga. O autor encerra convidando quem quiser saber mais a responder ao e-mail ou contatá-lo em [email protected].