Un article sur la méthode de release sans downtime de Facebook

Zero Downtime Release: répartition de charge sans interruption pour un site web de plusieurs milliards d’utilisateurs

Résumé

• Les serveurs redémarrent souvent : mises à niveau, correctifs de bugs, correctifs de sécurité

• Avec l’introduction du Continuous Release

→ dans le cas de Facebook, on est passé d’un déploiement par semaine en 2007 à plus de 100 déploiements par semaine

→ des millions de serveurs redémarrent chaque jour

→ AWS, Atlassian, Yelp, eBay et Uber sont dans le même cas

→ les health checks finissent par échouer de manière intermittente

• Méthodes de déploiement traditionnelles

1. Déploiement Blue/Green (AWS CodeDeploy, Kubernetes) : on divise en deux groupes de machines et le load balancer bascule d’abord le trafic vers un côté mis à jour

→ coûteux. Peu adapté à l’Edge où il y a un très grand nombre de machines

2. Rolling Updates (Envoy, NGINX, Apache, Kubernetes, AWS) : mise à jour progressive machine par machine pendant que le load balancer ajuste le trafic

→ baisse de l’utilisation CPU pendant la période de mise à jour, itérations lentes.

3. Hot Restart (HAProxy, Envoy) : sur une même machine, on lance un processus d’une nouvelle version et, à mesure que le trafic de l’ancien processus s’éteint, le nouveau processus prend le trafic (SO_REUSEPORT, CMSG, SCM_RIGHTS)

→ possible uniquement avec TCP, et peut provoquer un mauvais routage avec UDP

"Comment effectuer des mises à jour de release sans downtime, avec des itérations rapides et sans interruption ?"

• L’infrastructure de trafic de Facebook

• Edge PoP(L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)

→ redémarrage par couche pour éviter les interruptions

→ les machines Edge et Data Center lancent chacune un nouveau ProxyGen pour faire un "Socket TakeOver"

→ "Downstream Connection Reuse" entre Edge et Data Center

→ pour les connexions entre Data Center et App Server, "Partial Post Replay"

• Socket Takeover : on lance un nouveau processus, puis on lui transmet les sockets TCP Listening et UDP VIP via SCM_RIGHTS et CMSG

→ SCM_RIGHTS : type de socket qui permet de transmettre le file descriptor d’un autre processus

→ CMSG : permet d’envoyer des messages de contrôle entre processus locaux via la fonction sendmsg()

→ pour QUIC, qui repose sur UDP, dans le cas des connexions existantes, le nouveau processus demande au processus existant le QUIC ConnectionID puis lui transfère le paquet correspondant

• Partial Post Replay (redémarrage des serveurs d’applications)

→ Les serveurs d’applications ont deux types de charge : appels API courts et longs appels HTTP POST (upload)

→ comme ces serveurs n’ont pas de ressources disponibles, il est impossible de lancer une nouvelle instance et de lui transférer les sockets comme avec Socket Takeover, et la longue durée des uploads pose aussi problème

→ si le serveur d’applications est mis à jour au milieu d’un long upload, le proxy ne possède pas l’intégralité du contenu ; il interrompt donc ce POST et renvoie au proxy les données reçues jusqu’ici avec le code 379

→ le proxy combine alors les données reçues de l’ancien serveur d’applications avec les données restantes, puis tente de les renvoyer vers la nouvelle machine

• Avantages de Zero Downtime Release

→ utilisation CPU environ 20 % plus élevée que Rolling Update

→ presque aucun mauvais routage, alors que Hot Restart pouvait mal router jusqu’à 20K paquets QUIC

→ chez Facebook, Socket TakeOver est utilisé depuis 2013, et le reste depuis 2015

[xguru]

Le contenu ci-dessus est un résumé basé sur cette vidéo explicative de 20 minutes https://dl.acm.org/action/downloadSupplement/…

ProxyGen : la bibliothèque HTTP C++ de Facebook https://github.com/facebook/proxygen