Zero Downtime Release: Balanceamento de carga sem interrupções em um site com bilhões de usuários
Resumo
-
Servidores são reiniciados com frequência: upgrades, correções de bugs, patches de segurança
-
Com a adoção de Continuous Release
→ no caso do Facebook, em 2007 era 1 vez por semana, e passou para mais de 100 deploys por semana
→ centenas de milhares de servidores são reiniciados todos os dias
→ AWS, Atlassian, Yelp, Ebay e Uber estão na mesma situação
→ health checks passam a falhar de forma intermitente
- Métodos tradicionais de deploy
- Deploy Blue/Green (AWS CodeDeploy, Kubernetes): divide em dois grupos de máquinas e o load balancer migra primeiro o tráfego para um dos lados após a atualização
→ custo alto. Inadequado para edges com muitas máquinas
- Rolling Updates (Envoy, NGINX, Apache, Kubernetes, AWS): atualiza gradualmente uma máquina por vez enquanto o load balancer ajusta o tráfego
→ menor uso de CPU durante o período de atualização e iteração lenta.
- Hot Restart (HAProxy, Envoy): inicia um processo da nova versão na mesma máquina, e conforme o tráfego do processo antigo vai sendo encerrado, o novo processo passa a receber o tráfego (SO_REUSEPORT, CMSG, SCM_RIGHTS)
→ só funciona para TCP, e em UDP pode ocorrer roteamento incorreto
"Como fazer atualizações de release sem downtime, com iteração rápida e sem interrupções?"
- Infraestrutura de tráfego do Facebook
- Edge PoP(L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)
→ reinício por camada para evitar interrupções
→ as máquinas de Edge e Data Center iniciam um novo ProxyGen cada uma para fazer "Socket TakeOver"
→ "Downstream Connection Reuse" entre Edge e Data Center
→ "Partial Post Replay" para as conexões entre Data Center e App Server
- Socket Takeover: inicia um novo processo e transfere os sockets de escuta TCP e os sockets UDP VIP via SCM_RIGHTS e CMSG
→ SCM_RIGHTS: tipo de socket que permite receber o File Descriptor de outro processo
→ CMSG: permite enviar mensagens de controle entre processos locais com a função sendmsg()
→ para o QUIC, que é baseado em conexões UDP, no caso de conexões existentes o novo processo consulta o processo antigo pelo QUIC ConnectionID e encaminha o pacote correspondente para o processo antigo
- Partial Post Replay ( reinício do App Server )
→ o App Server tem dois tipos de workload: chamadas curtas de API e chamadas longas de HTTP POST (upload)
→ como esse app server não tem recursos disponíveis, não é possível iniciar uma nova instância e transferir os sockets como no Socket Takeover, e o longo tempo de upload também é um problema
→ se o app server for atualizado no meio de um upload longo, como o proxy não tem todo o conteúdo, ele interrompe esse POST e, junto com o código 379, retorna ao proxy os dados recebidos até aquele momento
→ o proxy junta os dados recebidos do app server antigo com os dados restantes e tenta reenviar para a nova máquina
- Vantagens do Zero Downtime Release
→ uso de CPU cerca de 20% maior em comparação com Rolling Update
→ em comparação com o Hot Restart, que fazia misrouting de até 20K pacotes QUIC, quase não há misrouting
→ no Facebook, o Socket TakeOver é usado desde 2013, e os demais desde 2015
1 comentários
O conteúdo acima é um resumo baseado neste vídeo explicativo de 20 minutos: https://dl.acm.org/action/downloadSupplement/…
ProxyGen: biblioteca HTTP em C++ do Facebook https://github.com/facebook/proxygen