Zero Downtime Release: Balanceo de carga sin interrupciones para un sitio web con miles de millones de usuarios
Resumen
-
Los servidores se reinician con frecuencia: actualizaciones, corrección de bugs, parches de seguridad
-
Con la adopción de Continuous Release
→ en el caso de Facebook, pasó de 1 despliegue por semana en 2007 a más de 100 despliegues por semana
→ cientos de miles de servidores se reinician cada día
→ AWS, Atlassian, Yelp, Ebay y Uber están en la misma situación
→ las verificaciones de salud empiezan a fallar de forma intermitente
- Métodos tradicionales de despliegue
- Despliegue Blue/Green (AWS CodeDeploy, Kubernetes): se divide en dos grupos de máquinas y el balanceador transfiere primero el tráfico hacia un lado para actualizar
→ es costoso. No es adecuado para el edge, donde hay una enorme cantidad de máquinas
- Rolling Updates (Envoy, NGINX, Apache, Kubernetes, AWS): se actualiza gradualmente una máquina a la vez mientras el balanceador ajusta el tráfico
→ durante la actualización baja el uso de CPU y la iteración es lenta.
- Hot Restart (HAProxy, Envoy): dentro de una misma máquina se levanta un proceso con la nueva versión, y cuando el tráfico del proceso anterior termina gradualmente, el nuevo proceso recibe el tráfico (SO_REUSEPORT, CMSG, SCM_RIGHTS)
→ solo funciona para TCP y en UDP puede producir enrutamiento incorrecto
"¿Cómo se pueden hacer actualizaciones de release sin downtime, con iteraciones rápidas y sin interrupciones?"
- Infraestructura de tráfico de Facebook
- Edge PoP(L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)
→ se reinicia por capas para evitar interrupciones
→ las máquinas de Edge y Data Center levantan un nuevo ProxyGen respectivamente para hacer "Socket TakeOver"
→ "Downstream Connection Reuse" entre Edge y Data Center
→ para la conexión entre Data Center y App Server se usa "Partial Post Replay"
- Socket Takeover: se levanta un nuevo proceso y se le transfieren los sockets TCP Listening y UDP VIP mediante SCM_RIGHTS y CMSG
→ SCM_RIGHTS: tipo de socket que permite recibir el File Descriptor de otro proceso
→ CMSG: permite enviar mensajes de control entre procesos locales con la función sendmsg()
→ para QUIC, que usa conexiones basadas en UDP, en el caso de conexiones existentes el nuevo proceso le pregunta al proceso anterior por el QUIC ConnectionID y reenvía ese paquete al proceso anterior
- Partial Post Replay (reinicio del servidor de aplicaciones)
→ el servidor de aplicaciones tiene dos tipos de carga de trabajo: llamadas API cortas y llamadas HTTP POST largas (upload)
→ como este servidor de aplicaciones no tiene recursos disponibles, no es posible levantar una nueva instancia y transferir sockets como en Socket Takeover, y además el largo tiempo de upload también es un problema
→ si el servidor de aplicaciones se actualiza en medio de un upload largo, como el proxy no tiene todo el contenido, se interrumpe ese POST y se devuelve al proxy, junto con el código 379, la data recibida hasta ese momento
→ el proxy combina la data recibida del servidor de aplicaciones anterior con la data restante e intenta reenviarla a la nueva máquina
- Ventajas de Zero Downtime Release
→ alrededor de un 20% más de uso de CPU frente a Rolling Update
→ comparado con Hot Restart, que llegó a enrutar mal hasta 20K paquetes QUIC, casi no hay errores de enrutamiento
→ en Facebook, Socket TakeOver se usa desde 2013, y el resto desde 2015
1 comentarios
El contenido anterior es un resumen basado en este video explicativo de 20 minutos: https://dl.acm.org/action/downloadSupplement/…
ProxyGen: la biblioteca HTTP en C++ de Facebook https://github.com/facebook/proxygen