Проектирование RTB-инфраструктуры на 100K QPS

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

Не уложились в срок — показ потерян. Повторной попытки нет. При 100 000+ QPS даже 1% таймаутов — это 1 000 упущенных возможностей в секунду.

Размещать биддеры рядом с биржами, чтобы вернуть время на оценку

Сетевая задержка между биддером и ad exchange напрямую съедает время на оценку ставки. Биддер, удалённый от биржи на 50ms по сети, проиграл ещё до того, как его код запустился.

Команды разработки DSP, которые ставят биддеры в co-location с крупными биржами, отыгрывают критичные миллисекунды:

• Развёртывание в 6-8 дата-центрах по миру возвращает 5-15ms времени на оценку каждого запроса по сравнению с централизованным развёртыванием
• Группы автомасштабирования в каждом регионе реагируют на паттерны трафика: US East на пике в рабочие часы, пока APAC сворачивается
• Региональные инстансы биддера держат локальные копии данных таргетинга кампаний, синхронизируемые каждые 5-10 секунд из центрального хранилища
• Оптические каналы между дата-центрами несут трафик синхронизации, но путь оценки ставки никогда не пересекает границы регионов

Убрать выделение памяти с горячего пути оценки ставки

При 100K QPS паттерны выделения памяти определяют, уложится ли система в бюджет задержки. Паузы сборщика мусора, незаметные при 100 QPS, в масштабе становятся катастрофой.

Путь оценки ставки использует конкретные техники:

• Заранее рассчитанные таблицы поиска по критериям таргетинга кампаний, ограничениям частоты показов и бюджетным лимитам — обновляются асинхронно каждые 5-10 секунд из основного хранилища кампаний
• Пулы объектов и арена-аллокация, полностью исключающие выделение памяти в куче на каждый запрос
• Безблокировочные структуры данных для общего состояния — фильтры Блума для frequency capping, атомарные счётчики для распределения бюджета
• Предпостроенные деревья решений для оценки таргетинга — построение дерева стоит секунды, его вычисление — микросекунды

Нулевые аллокации на горячем пути — не оптимизация. При 100K QPS это требование.

Выполнять инференс ML-модели быстрее чем за 3 ms на ставку

Модели прогноза CTR и вероятности конверсии должны отрабатывать инференс за 2-3 мс внутри общего конвейера оценки ставки. Каждая миллисекунда инференса отнимается у остальной логики ставки.

ONNX Runtime с квантованными INT8-моделями даёт лучший баланс задержки и точности:

• Извлечение признаков из bid request быстрее 0.5ms с помощью предрассчитанных feature store с сигналами пользователя и контекста
• Инференс модели за 1-2ms через батчевое вычисление ONNX с закреплением потоков за ядрами — без переключения контекста во время скоринга
• Калибровка скоринга и расчёт цены ставки менее чем за 0.5 мс по предвычисленным ценовым кривым для каждого уровня кампании
• Обновления модели выкатываются по схеме blue-green — новая модель загружается в shadow-режиме, сверяется с продовыми прогнозами, затем переключается атомарно

Мониторьте в масштабе, не добавляя накладных расходов на путь биддинга

Традиционное логирование при 100K QPS создаёт больше нагрузки, чем сама логика биддинга. Стек мониторинга должен быть так же требователен к производительности, как и приложение:

• Сбор метрик на основе сэмплирования: подробно логируется 1 запрос из 1 000, остальные агрегируются в счётчики и гистограммы с атомарным обновлением
• Отслеживание перцентилей p50, p95 и p99 в реальном времени по регионам, ad exchange и уровням кампаний
• Автоматические circuit breakers, выводящие инстанс биддера из ротации, когда его p99 времени ответа превышает таймаут биржи
• Детекция аномалий по падению bid rate, изменению win rate и отклонениям скорости расхода бюджета — ловит устаревшие модели и деградацию сети быстрее, чем мониторинг доли ошибок

Закрыть сторону SSP в уравнении аукциона

У supply-side платформы зеркальная задача. Она рассылает bid requests десяткам биддеров, собирает ответы, проверяет floor prices, проводит аукцион и возвращает победителя — и всё это внутри собственного жёсткого таймаута.

Команды, разрабатывающие SSP, сталкиваются с дополнительной сложностью:

• Header bidding означает несколько параллельных аукционов — таймаут каждого биддера и есть бюджет задержки SSP
• Оптимизация floor price на ML-моделях должна укладываться в то же окно аукциона и не добавлять задержки
• Производительная логика аукциона оценивает 20-50 ответов со ставками на каждый показ и выбирает победителя менее чем за 1ms

Programmatic-реклама на масштабе требует, чтобы обе стороны аукциона непрерывно оптимизировались под low latency.

Адаптировать биддинг-инфраструктуру под мобильные приложения и in-app-инвентарь

In-app bid-запросы несут иные сигналы, чем веб-запросы. Идентификаторы уровня устройства (там, где они доступны), контекст приложения и viewability, сообщаемая SDK, заменяют сигналы на основе cookie.

CTR-модели, обученные на веб-инвентаре, требуют переобучения для in-app-контекстов, где паттерны взаимодействия пользователей существенно отличаются.

• Моделирование атрибуции для мобильных требует server-to-server интеграции постбэков с MMP
• Дедупликация по нескольким окнам атрибуции исключает двойной учёт конверсий
• Вероятностное и детерминированное сопоставление идентификаторов идёт асинхронно — результаты возвращаются в bidding-модель в течение 24 часов