Meta déploie ZGateway pour sécuriser et désengorger sa base ZippyDB

À l'échelle de Meta, la base clé-valeur (système de stockage associant une clé à une valeur) ZippyDB traite plusieurs milliards d'opérations par seconde. Historiquement, chaque client — parmi une flotte de plus d'un million de hôtes — se connectait directement à chaque serveur de base de données nécessaire. Cette approche par accès direct générait un maillage dense de connexions TLS (Transport Layer Security, le protocole de chiffrement des échanges réseau). Chaque hôte devait maintenir des dizaines de milliers de connexions dormantes, consommant de la mémoire vive et des descripteurs de fichiers (identifiants système attribués aux connexions ouvertes). Lors de redémarrages massifs, des tempêtes de reconnexion entraînaient des pannes par OOM (Out Of Memory, épuisement de la mémoire disponible) et le blocage de serveurs.

Un proxy intermédiaire pour stopper l'explosion des connexions

Pour rompre cette dépendance directe, Meta a développé ZGateway, une couche de proxy (serveur intermédiaire sans état) située entre les applications clientes et la flotte de serveurs ZippyDB (ZServer). ZGateway gère désormais plus de 40 % du trafic global de ZippyDB (avec une projection à plus de 60 %) et absorbe plus d'un milliard d'opérations par seconde avec un surcoût processeur d'à peine 6 %.

Grâce à ZGateway, le fan-in (le nombre de connexions entrantes reçues par un serveur de base de données) ne dépend plus du nombre de clients applicatifs, mais uniquement du nombre de régions et de serveurs proxy. Les équipes de Meta ont mesuré une réduction globale d'environ 19 fois du nombre total de connexions persistantes, et une chute de 97 à 98 % des connexions gérées par chaque serveur de base de données.

Mutualisation et fusion des requêtes entre clients distincts

L'un des apports majeurs de ZGateway réside dans sa capacité à réaliser du batching (regroupement de requêtes en un seul envoi) et du coalescing (fusion de requêtes identiques simultanées) à travers des clients applicatifs distincts, ce qu'aucune bibliothèque côté client ne pouvait faire isolément.

• Le batching multi-clients : ZGateway regroupe les demandes destinées au même shard (fragment physique de base de données) dans un unique appel RPC (Remote Procedure Call, appel de méthode à distance) via le protocole Thrift (cadre de communication binaire inter-services).
• Le coalescing des clés très demandées : Si plusieurs clients demandent la même clé au même instant, ZGateway n'effectue qu'une seule lecture en base et redistribue le résultat aux appelants, évitant les verrous et surcharges.

« Un proxy crée un point de contrôle unique : c'est le seul endroit d'où l'on peut observer l'ensemble de la charge et modifier le comportement en quelques minutes au lieu d'attendre le déploiement d'un million de binaires clients. »

Protection contre la surcharge et déploiement progressif

Pour empêcher qu'un client défaillant ne pénalise les autres sur cette infrastructure mutualisée, ZGateway intègre un mécanisme appelé DLS (Discriminant Load Shedding, ou délestage sélectif de charge). Chaque application dispose d'un panier de requêtes traité au tour par tour. Lors d'un test de surcharge à plus de 90 % de processeur sur environ 1 350 applications clientes, seuls 6 clients fautifs ont vu leurs requêtes rejetées, tandis que les 1 344 autres conservaient un taux d'exécution de 99,9 %.

Le basculement vers ZGateway s'effectue sans modification du code applicatif, grâce à des drapeaux de configuration réseau pilotables dynamiquement :

{
  "service_name": "user_profile_service",
  "target_shard_prefix": "user_cfg_",
  "zgateway_traffic_percentage": 50,
  "global_kill_switch": false
}

Cette architecture démontre qu'à très grande échelle, déplacer la gestion des connexions et la résilience réseau dans une couche intermédiaire dédiée s'avère bien plus efficace que de faire reposer ces responsabilités sur des bibliothèques intégrées aux applications.