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, мрежата за услуги на Meta, в два варианта: чисто прокси и кеш с пропускане при четене. Двигателят е дебелият C++ клиент на Meta за ZippyDB, така че 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 то се свежда приблизително до броя на регионите, умножен по плътността на шардовете на хост, независимо от размера и на двата парка.

Възможности, появили се впоследствие

• Безопасна миграция: Конфигурационни флагове, ограничени по услуга и префикс на шарда, осигуряват поетапно увеличаване на процента, филтър по регион и глобален превключвател за изключване.
• Discriminant Load Shedding (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 и не забравяйте да се присъедините към нашия 150k+ ML SubReddit и да се абонирате за нашия бюлетин. Чакайте! В Telegram ли сте? Вече можете да се присъедините към нас и в Telegram.

Имате нужда от партньорство с нас за популяризиране на вашето GitHub хранилище ИЛИ страница в Hugging Face ИЛИ представяне на продукт ИЛИ уебинар и т.н.? Свържете се с нас