El equipo de ingeniería de Meta presentó ZGateway, un nivel de proxy que ahora se encuentra entre las aplicaciones cliente y ZippyDB, el almacén de valores clave más utilizado de Meta. ZippyDB respalda los metadatos, los contadores y la configuración del producto en miles de millones de operaciones por segundo. ZGateway comenzó como una solución para la expansión de conexiones en más de un millón de hosts de clientes y creció hasta convertirse en el hogar de procesamiento por lotes, control de admisión, almacenamiento en caché y conmutación por error.
Por qué ZippyDB necesitaba un proxy
Bajo acceso directo, cada cliente ZippyDB se conectaba a cada host de base de datos que necesitaba. Un solo cliente podría tocar decenas de miles de fragmentos en cientos de miles de hosts, por lo que tanto un cliente típico como un host de base de datos típico llevaban decenas de miles de conexiones TLS. Cada conexión inactiva consumía memoria, CPU y un descriptor de archivo en ambos extremos, y los recuentos entrantes crecían con cada cohorte de clientes. Las tormentas de reconexión causaron fallas por agotamiento de los descriptores de archivos y OOM; En un incidente, un error de enrutamiento hizo que cada cliente abriera una conexión por fragmento y la flota cayó en un ciclo de reinicio. Las correcciones del lado del cliente no eran prácticas porque cientos de equipos poseen la flota de clientes.
¿Qué es ZGateway?
ZGateway es un nivel de proxy sin estado entre los clientes ZippyDB y la flota de bases de datos ZServer. Por Meta, maneja más de mil millones de operaciones por segundo y transporta alrededor del 40% del tráfico de ZippyDB, y se prevé que supere el 60%, con aproximadamente un 6% de sobrecarga computacional para un caso de uso promedio.
Se ejecuta como niveles regionales descubiertos a través de ServiceRouter, la malla de servicios de Meta, en dos versiones: un proxy puro y un caché de lectura. El motor es el cliente ZippyDB C++ de Meta, por lo que ZGateway es efectivamente un cliente ZippyDB que se ejecuta como un servicio administrado.
Un cliente envía solicitudes a través de una conexión fija a un host ZGateway regional, que finaliza TLS, autoriza contra las ACL del caso de uso, aplica control y configuración de admisión por inquilino, resuelve el fragmento, verifica el caché local en los niveles de almacenamiento en caché, agrupa la solicitud con otro trabajo en curso para ese fragmento y la reenvía a las réplicas correctas. Las respuestas se demultiplexan con métricas, seguimientos y uso de cuotas por caso de uso registrados. TLS permanece en la pila Thrift/ServiceRouter y la selección de réplicas permanece en el cliente integrado.
Las matemáticas de entrada y salida
Meta modela la flota como bolas arrojadas a contenedores: con B fragmentos y H hosts, un host es golpeado con probabilidad E(H,B)=H(1−e−B/h)E(H,B) = H\left(1 – e^{-B/h}\right). Con cifras simuladas de 20 regiones, 500.000 hosts de bases de datos, 30.000 hosts proxy, 1.000.000 de clientes y 50.000 fragmentos por cliente, el recuento de conexiones por host colapsa aproximadamente entre un 97% y un 98% y el total de conexiones persistentes se reduce aproximadamente 19 veces. La ventaja más importante es la escalabilidad: la fan-in de acceso directo crece linealmente con los clientes, mientras que la fan-in de ZGateway se reduce a aproximadamente regiones multiplicada por la densidad de fragmentos por host, independientemente de ambas flotas.
Capacidades que siguieron
Migración segura: los indicadores de configuración con alcance por servicio y prefijo de fragmento proporcionan una rampa porcentual, un filtro de región y un interruptor de apagado global. Deslastre de carga discriminante (DLS): las solicitudes se asignan a depósitos por inquilino divididos por prioridad que drenan por turnos, de modo que un inquilino que se inunda solo llena su propio depósito. En una sobrecarga controlada por encima del 90 % de la CPU en aproximadamente 1350 grupos de inquilinos, solo 6 vecinos ruidosos perdieron carga, el resto ejecutó el 99,9 % de las solicitudes sin rechazos, el buen rendimiento se mantuvo entre el 97 y el 98 % y la maquinaria costó aproximadamente el 8 % de la CPU. Almacenamiento en caché de lectura: los niveles de caché ofrecen lecturas en caliente durante el proceso, realizan un bloqueo de llenado por clave en caso de errores y se mantienen actualizados a través de eventos de captura de datos modificados bajo un contrato de obsolescencia limitada. Equilibrio de carga: los niveles combinan aproximadamente hosts de 26 a 126 núcleos, por lo que un equilibrador del plano de control empuja el peso del ServiceRouter de cada host en sentido opuesto a su carga reciente de CPU. Resiliencia entre regiones: el enrutamiento global, las megaregiones y los anillos permiten que un nivel regional saturado conmute a una capacidad saludable cercana. Transacciones: la contabilidad del lado del cliente se trasladó a la puerta de enlace, se consolidó en nueve fases hasta el 100 % del tráfico de transacciones sin regresión de confiabilidad.