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

Інженерна команда Meta представила ZGateway — проксі-рівень, який тепер розташований між клієнтськими застосунками та ZippyDB, найпоширенішим у Meta сховищем ключ-значення. ZippyDB забезпечує роботу метаданих продуктів, лічильників і конфігурацій із мільярдами операцій за секунду. ZGateway починався як рішення проблеми надмірної кількості з’єднань на понад мільйоні клієнтських хостів, а згодом став місцем для пакетної обробки, контролю допуску, кешування та перемикання після відмов.

Чому ZippyDB знадобився проксі

За прямого доступу кожен клієнт ZippyDB підключався до кожного потрібного йому хоста бази даних. Один клієнт міг звертатися до десятків тисяч сегментів на сотнях тисяч хостів, тому і типовий клієнт, і типовий хост бази даних мали по десятках тисяч TLS-з’єднань. Кожне неактивне з’єднання споживало пам’ять, процесорний час і файловий дескриптор на обох кінцях, а кількість вхідних з’єднань зростала з кожною групою клієнтів. Шторми повторного підключення спричиняли збої через вичерпання файлових дескрипторів і OOM; під час одного інциденту помилка маршрутизації змусила кожен клієнт відкривати по одному з’єднанню для кожного сегмента, і весь парк систем увійшов у цикл перезавантажень. Виправлення на боці клієнтів були непрактичними, оскільки за клієнтський парк відповідають сотні команд.

Що таке ZGateway

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

Він працює як регіональні рівні, які виявляються через ServiceRouter, сервісну mesh-мережу Meta, у двох варіантах: звичайний проксі та кеш із наскрізним читанням. Ядром системи є товстий C++-клієнт Meta для ZippyDB, тож фактично ZGateway — це клієнт ZippyDB, запущений як керований сервіс.

Клієнт надсилає запити через sticky-з’єднання до регіонального хоста ZGateway, який завершує TLS, авторизує запит відповідно до ACL сценарію використання, застосовує контроль допуску й формування навантаження для кожного клієнта, визначає сегмент, перевіряє локальний кеш на рівнях із кешуванням, об’єднує запит з іншими запитами в обробці для цього сегмента та пересилає його до правильних реплік. Відповіді демультиплексуються назад, а для кожного сценарію використання фіксуються метрики, трасування та використання квот. TLS залишається у стеку Thrift/ServiceRouter, а вибір реплік — у вбудованому клієнті.

Математика об’єднання та розподілу навантаження

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

Можливості, що з’явилися згодом

• Безпечна міграція: прапорці конфігурації, визначені для кожного сервісу та префікса сегмента, забезпечують поетапне збільшення відсотка трафіку, фільтр регіонів і глобальний перемикач вимкнення.
• Вибіркове скидання навантаження (DLS): запити зіставляються з кошиками для кожного клієнта, розділеними за пріоритетом і спорожнюваними за принципом round-robin, тому клієнт, який створює надмірне навантаження, заповнює лише власний кошик. Під час контрольованого перевантаження за завантаження процесора понад 90% приблизно серед 1 350 кошиків клієнтів лише 6 шумних сусідів скидали навантаження, решта виконали 99,9% запитів без жодного відхилення, корисна пропускна здатність залишалася на рівні близько 97–98%, а ця система споживала приблизно 8% процесорного часу.
• Кешування читання: рівні кешу обслуговують популярні операції читання в процесі, під час промахів блокують заповнення для окремого ключа та залишаються актуальними завдяки подіям захоплення змін даних у межах контракту обмеженої застарілості.
• Балансування навантаження: рівні поєднують хости приблизно від 26 до 126 ядер, тому балансувальник площини керування змінює вагу кожного хоста в ServiceRouter у напрямку, протилежному його недавньому навантаженню на процесор.
• Відмовостійкість між регіонами: глобальна маршрутизація, мегарегіони та кільця дають змогу перевести навантаження із перенасиченого регіонального рівня на доступні потужності поблизу.
• Транзакції: ведення обліку на боці клієнта перенесли до шлюзу та консолідували у дев’ять етапів для 100% транзакційного трафіку без погіршення надійності.

Основні висновки

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

---

Ознайомтеся з дописом в інженерному блозі Meta та оголошенням у X. Уся подяка належить досліднику цього проєкту. Також не забудьте підписатися на нас у Twitter, приєднатися до нашого сабреддіту про машинне навчання зі 150 тисячами+ учасників і підписатися на нашу розсилку. Стривайте! Ви в Telegram? Тепер ви також можете приєднатися до нас у Telegram.

Потрібно співпрацювати з нами для просування вашого репозиторію GitHub, сторінки Hugging Face, випуску продукту, вебінару тощо? Зв’яжіться з нами