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

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

Зачем ZippyDB понадобился прокси

При прямом доступе каждый клиент ZippyDB подключался ко всем необходимым ему хостам баз данных. Один клиент мог обращаться к десяткам тысяч шардов на сотнях тысяч хостов, поэтому и обычный клиент, и обычный хост базы данных поддерживали десятки тысяч TLS-подключений. Каждое неактивное подключение потребляло память, ресурсы CPU и файловый дескриптор с обеих сторон, а число входящих подключений росло с каждой клиентской группой. Шторма переподключений приводили к сбоям из-за исчерпания файловых дескрипторов и OOM; во время одного инцидента ошибка маршрутизации заставила каждого клиента открыть по подключению на каждый шард, и весь парк хостов зашёл в цикл перезагрузок. Исправления на стороне клиентов были непрактичны, поскольку за парк клиентов отвечают сотни команд.

Что такое ZGateway

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

Он работает как региональные уровни, обнаруживаемые через ServiceRouter — сервисную сетку Meta, — в двух вариантах: обычный прокси и кэш с чтением через него. Движком служит толстый C++-клиент ZippyDB от Meta, поэтому фактически ZGateway представляет собой клиент ZippyDB, работающий как управляемый сервис.

Клиент отправляет запросы по постоянному подключению к региональному хосту ZGateway, который завершает TLS-соединение, проверяет права доступа в соответствии со списками ACL конкретного сценария использования, применяет контроль допуска и формирование нагрузки для каждого арендатора, определяет шард, проверяет локальный кэш на уровнях кэширования, объединяет запрос с другими выполняющимися запросами к этому шарду и перенаправляет его на нужные реплики. Ответы демультиплексируются обратно, при этом записываются метрики и трассировки для каждого сценария использования, а также сведения об использовании квот. TLS остаётся в стеке Thrift/ServiceRouter, а выбор реплик — во встроенном клиенте.

Математика объединения и распределения

Meta моделирует парк хостов как шары, бросаемые в ячейки: при наличии B шардов и H хостов вероятность попадания на хост составляет . Согласно условным данным — 20 регионов, 500 000 хостов баз данных, 30 000 прокси-хостов, 1 000 000 клиентов и 50 000 шардов на клиента — количество подключений на один хост сокращается примерно на 97–98%, а общее число постоянных подключений уменьшается примерно в 19 раз. Более существенный выигрыш связан с масштабированием: при прямом доступе объединение подключений растёт линейно с числом клиентов, тогда как у ZGateway оно сокращается примерно до произведения числа регионов на плотность шардов на хост, независимо от размеров обоих парков.

Появившиеся возможности

• Безопасная миграция: флаги конфигурации, заданные для каждого сервиса и префикса шарда, обеспечивают поэтапное включение с заданным процентом, фильтрацию по регионам и глобальный переключатель отключения.
• Сброс нагрузки по дискриминанту (DLS): запросы распределяются по корзинам для каждого арендатора, разделённым по приоритету и опустошаемым по кругу, поэтому перегружающий систему арендатор заполняет только собственную корзину. При контролируемой перегрузке выше 90% CPU и примерно 1 350 корзинах арендаторов нагрузка была сброшена только для 6 шумных соседей; остальные выполнили 99,9% запросов без единого отклонения, полезная пропускная способность оставалась на уровне около 97–98%, а механизм потреблял около 8% CPU.
• Кэширование чтения: уровни кэширования обслуживают часто запрашиваемые данные в процессе, устанавливают блокировку заполнения для каждого ключа при промахах и поддерживают актуальность посредством событий захвата изменений данных в рамках соглашения об ограниченной устарелости.
• Балансировка нагрузки: на уровнях используются хосты примерно от 26 до 126 ядер, поэтому балансировщик плоскости управления корректирует вес ServiceRouter каждого хоста в направлении, противоположном его недавней загрузке CPU.
• Отказоустойчивость между регионами: глобальная маршрутизация, мегарегионы и кольца позволяют перегруженному региональному уровню переключаться на доступные здоровые мощности поблизости.
• Транзакции: ведение служебных данных на стороне клиента было перенесено в шлюз и консолидировано в девяти фазах до охвата 100% транзакционного трафика без снижения надёжности.

Основные выводы

• ZGateway обрабатывает более 1 млрд операций в секунду и передаёт около 40% трафика ZippyDB при накладных расходах примерно в 6%.
• Прокси превращает объединение подключений к базам данных из величины, линейно зависящей от числа клиентов, в ограниченное число, контролируемое Meta.
• Пакетная обработка и объединение запросов между клиентами устраняют лавинообразные запросы к горячим ключам и позволяют отказаться от хрупких клиентских библиотек.
• DLS изолировал 6 шумных арендаторов из примерно 1 350 при загрузке CPU выше 90%, сохранив полезную пропускную способность на уровне 97–98%.
• Решение нельзя развернуть за пределами Meta; ценность заключается в применённых подходах, а не в готовом пакете.

---

Ознакомьтесь с публикацией в блоге Meta Engineering и объявлением в X. Все заслуги принадлежат исследователю этого проекта. Также подписывайтесь на нас в Twitter и не забудьте присоединиться к нашему сабреддиту о машинном обучении с более чем 150 тыс. участников и подписаться на нашу рассылку. Стоп! Вы пользуетесь Telegram? теперь вы также можете присоединиться к нам в Telegram.

Хотите стать нашим партнёром для продвижения вашего репозитория на GitHub, страницы на Hugging Face, релиза продукта, вебинара и т. д.? Свяжитесь с нами