Meta представила ZGateway: stateless-прокси для ZippyDB с производительностью более 1 млрд операций в секунду

В масштабах современной инфраструктуры Meta поддержание стабильной работы ключевых распределённых систем требует уникальных архитектурных решений. Инженерная команда компании представила ZGateway — специализированный stateless-прокси (прокси-слой без сохранения состояния), размещённый между клиентскими приложениями и ZippyDB. ZippyDB является главным распределённым key-value хранилищем компании, на котором держатся метаданные продуктов, счётчики и глобальные конфигурации сервисов. Проект ZGateway начинался как локальное устранение проблемы взрывного роста сетевых соединений среди более чем миллиона клиентских узлов, однако со временем трансформировался в полноценный управляемый сервис, отвечающий за батчинг (пакетирование) запросов, контроль доступа, кэширование и отказоустойчивость.

Почему распределённое хранилище ZippyDB потребовало выделенного прокси-слоя

При прежней схеме прямого доступа (direct access) каждое клиентское приложение ZippyDB самостоятельно устанавливало соединения со всеми необходимыми узлами базы данных. В условиях Meta один клиент мог обращаться к десяткам тысяч шардов, распределённых по сотням тысяч хостов. В результате как типовой клиентский узел, так и рядовой сервер базы данных вынуждены были постоянно поддерживать десятки тысяч активных TLS-соединений.

Каждое даже простаивающее соединение расходовало оперативную память, вычислительные ресурсы процессора и файловые дескрипторы на обеих сторонах. С появлением новых клиентских сервисов суммарный объем входящих подключений возрастал по экспоненте. Это регулярно приводило к так называемым «штормам переподключений» (reconnection storms), когда малейший сбой вызывал падение серверов из-за исчерпания файловых дескрипторов и нехватки памяти (OOM, Out-Of-Memory).

В качестве примера разработчики приводят инцидент, когда ошибка маршрутизации заставила каждый клиент открыть отдельное соединение для каждого шарда — в результате весь кластер ушёл в бесконечный цикл перезагрузок. Вносить исправления на стороне клиентов было практически невозможно, так как клиентским кодом владеют сотни автономных команд внутри компании.

Что представляет собой ZGateway: архитектура и механизмы работы

ZGateway представляет собой прослойку бессерверных stateless-прокси между клиентскими приложениями ZippyDB и серверами ZServer. По данным Meta, сейчас этот слой обрабатывает более 1 миллиарда операций в секунду и берет на себя порядка 40% всего трафика ZippyDB (с перспективой роста свыше 60%). При этом вычислительные накладные расходы для среднестатистического сценария использования составляют лишь около 6% CPU.

Прокси-слой разворачивается в виде региональных кластеров, обнаружение которых происходит через внутренний service mesh Meta — ServiceRouter. Архитектура поддерживает два режима работы: чистый прокси (pure proxy) и сквозной кэш (read-through cache). В качестве фундамента ZGateway выступает штатный C++ клиент ZippyDB (thick client), оформленный в виде отдельного управляемого микросервиса.

Процесс обработки запроса выглядит следующим образом:

• Клиент отправляет запрос через постоянное (sticky) соединение на ближайший региональный хост ZGateway.
• Хост ZGateway завершает TLS-сессию, выполняет авторизацию по спискам контроля доступа (ACL) конкретного сценария.
• Применяются механизмы лимитирования и шейпинга трафика для каждого тенанта (заказчика).
• Система определяет нужный шард, проверяет наличие данных в локальном кэше (в режиме кэширования) и объединяет запрос в один батч с другими текущими операциями для этого же шарда.
• Сформированный батч перенаправляется на нужные реплики базы данных.

Ответы демультиплексируются обратно клиенту с одновременным сбором метрик, трассировок и отслеживанием лимитов использования ресурсов. TLS-сессии остаются в стеке Thrift/ServiceRouter, а логика выбора конкретной реплики выполняется встроенным клиентом.

Математическая модель сжатия соединений (Fan-In и Fan-Out)

Для оценки эффективности прокси-слоя инженеры Meta смоделировали работу кластера по принципу размещения шаров по корзинам. При наличии B шардов и H хостов вероятность попадания на конкретный хост описывается формулой:

E(H, B) = H * (1 - e^(-B / H))

Если взять гипотетическую модель из 20 регионов, 500 000 хостов базы данных, 30 000 хостов прокси, 1 000 000 клиентов и 50 000 шардов на клиента, внедрение ZGateway сокращает количество соединений на один хост базы данных примерно на 97–98%. Общее количество постоянных соединений в системе снижается ориентировочно в 19 раз.

Однако главное фундаментальное преимущество заключается в изменении принципа масштабирования: при прямом доступе веерное объединение (fan-in) росло линейно вместе с числом клиентов. С ZGateway коэффициент fan-in сводится к произведению количества регионов на плотность шардов на хосте и больше не зависит от объема клиентского флота.

Ключевые инженерные возможности ZGateway

Создание промежуточного слоя позволило инженерам реализовать ряд важных функций, недоступных при прямой клиент-серверной архитектуре.

Безопасный процесс миграции

Внедрение прокси происходит с помощью гибких флагов конфигурации, сфокусированных на конкретных сервисах и префиксах шардов. Это позволяет выполнять поэтапный рампап (процентное руление трафика), применять региональные фильтры и при необходимости задействовать глобальный аварийный выключатель (kill switch).

Дискриминантный сброс нагрузки (Discriminant Load Shedding, DLS)

Все поступающие запросы распределяются по изолированным корзинам тенантов с учетом приоритетов и опустошаются по алгоритму Round-Robin. Если один тенант генерирует аномальный всплеск трафика, он переполняет только свою корзину, не затрагивая соседей. При тестировании управляемой перегрузки (более 90% CPU на ~1350 корзинах тенантов) система сбросила нагрузку всего 6 «шумных» клиентов. Все остальные клиенты успешно выполнили 99,9% запросов без отказов, полезная пропускная способность (goodput) удерживалась на уровне 97–98%, а затраты процессора на работу самого механизма DLS составили лишь 8% CPU.

Кэширование операций чтения

Кэширующие узлы ZGateway обрабатывают горячие операции чтения прямо в памяти процесса. При промахе кэша (cache miss) захватывается блокировка наполнения по конкретному ключу (per-key fill lock), исключающая повторные дублирующие запросы к БД. Актуальность данных поддерживается с помощью событий Change Data Capture (CDC) в рамках модели ограниченной рассинхронизации (bounded-staleness contract).

Динамическая балансировка нагрузки

Кластер включает сервера разной мощности (от 26 до 126 процессорных ядер). Специальный балансировщик на уровне Control Plane динамически скорректировал веса хостов в ServiceRouter в обратной пропорции к их текущей загрузке CPU, предотвращая перегрузку отдельных серверов.

Межрегиональная отказоустойчивость и проведение транзакций

Благодаря глобальной маршрутизации, мега-регионам и кольцевой структуре резервирования, при переполнении регионального прокси-слоя трафик автоматически перенаправляется на здоровые мощности в соседних регионах. Кроме того, всю клиентскую логику учета транзакций перенесли непосредственно в ZGateway. Процесс миграции транзакционного трафика прошел в 9 этапов и успешно перевел 100% операций без потери надежности.

Главные выводы и значение архитектуры ZGateway

Опыт Meta показывает, как грамотно спроектированный бессерверный прокси-слой способен кардинально повысить надежность сверхнагруженной инфраструктуры. ZGateway не просто обрабатывает свыше 1 миллиарда операций в секунду с минимальными издержками в 6% CPU, он полностью меняет математику сетевых соединений в масштабах всей компании. Агрегация запросов и предотвращение кэш-штормов позволили отказаться от сложной и хрупкой клиентской логики. И хотя ZGateway является проприетарной внутренней разработкой Meta, описанные архитектурные паттерны служат отличным ориентиром для каждого, кто проектирует высоконагруженные базы данных и распределенные системы.

Источник: www.marktechpost.com