Рекламная платформа не выдерживает всплесков трафика? Что чинить первым и кто может помочь

Если ваша рекламная платформа падает на всплесках трафика, помочь могут те инженеры, которые измеряют её во время реального пика, а затем чинят в заданном порядке. Они останавливают работу, которая закончится после дедлайна, ограничивают повторы и трафик, который принимает платформа, и выносят счётчики бюджета и частоты показов с пути запроса. Затем добавляют мощности до пиков, которые можно предсказать. Код переписывают в последнюю очередь и только там, куда указывают замеры.

Как в рекламной платформе выглядит «не выдерживает всплесков трафика»?

Всплеск трафика проявляется в каждой части рекламной платформы по-своему:

• Биддер. Всё больше ответов приходит после дедлайна биржи, доля запросов со ставкой падает, хотя самих запросов становится больше, а биржа может начать присылать их меньше
• Supply-side платформа (SSP) или биржа. Аукционы закрываются раньше, чем ответят некоторые биддеры, и за каждый показ борется меньше ставок. В header bidding ставки, не уложившиеся в таймаут аукциона на странице, не попадают в вызов ad-сервера
• Ad-сервер. Запросы рекламы обрабатываются медленнее, и часть слотов остаётся пустой
• Пайплайн событий. Цифры показов и кликов приходят с опозданием или расходятся между системами
• Бюджеты и ограничения частоты показов. Кампании перерасходуют бюджет или показывают одно и то же объявление слишком часто, потому что счётчики обновляются уже после решений, которые должны были их учитывать

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

Почему рекламная платформа ломается на пике, если при средней нагрузке работает нормально?

В OpenRTB, протоколе IAB Tech Lab для real-time bidding, биржа может указать дедлайн прямо в запросе: это «максимальное время в миллисекундах, которое биржа отводит на получение ставок, включая задержку интернета, чтобы избежать таймаута». Документация Google Authorized Buyers говорит, что дедлайн обычно составляет от 80 до 1000 мс. Google требует, чтобы 85 процентов ответов укладывались в него с точки зрения торговой локации, и троттлит биддеров, которые не могут стабильно этого добиться. Биддер, который замедляется на пике, теряет аукционы, в которые опоздал, а затем может получать меньше трафика.

Вблизи предела мощности сервис начинает ставить запросы в очередь. В книге Google Site Reliability Engineering (SRE) отмечается, что «запросы в очереди расходуют память и увеличивают задержку», а серверы тратят ресурсы на запросы, которые всё равно пропустят свой дедлайн. Если код не проверяет дедлайн, запрос, прождавший слишком долго, всё равно обрабатывается полностью, а его ответ выбрасывается.

Когда вызов базы данных, кеша или партнёра уходит в таймаут, вызывающая сторона пробует снова, и повторы приходят как раз тогда, когда системе тяжелее всего их переварить. Книга SRE приводит арифметику шторма повторов: «100 QPS повторов в первую секунду приводят к 200 QPS, затем к 300 QPS и так далее».

Биржа или SSP рассылает каждый запрос многим биддерам, и аукцион либо ждёт самого медленного ответа, либо закрывается без него. Jeffrey Dean и Luiz André Barroso из Google посчитали этот эффект в 2013 году в Communications of the ACM. В их примере каждый сервер обычно отвечает за 10 мс, но на одном запросе из ста тратит секунду. Тогда запрос, которому нужно параллельно собрать ответы от 100 таких серверов, в 63 процентах случаев занимает больше секунды. Аукцион столько не ждёт. По тому же расчёту, если каждый из 100 биддеров опаздывает на одном запросе из ста, около 63 процентов аукционов закрываются, не дождавшись хотя бы одного ответа.

Автомасштабирование, которое реагирует на нагрузку, добавляет копии сервиса только после того, как эту нагрузку измерило. Horizontal Pod Autoscaler в Kubernetes, например, по умолчанию проверяет нагрузку раз в 15 секунд и добавляет новые копии ограниченными шагами. Затем каждой новой копии нужно запуститься, пройти проверки и заполнить кеши, а в книге SRE отмечается, что процессы сразу после запуска часто работают медленнее, чем в установившемся режиме. Всплеск длиной в несколько секунд может закончиться раньше, чем новые мощности примут реальный трафик.

Что измерить на пике трафика, прежде чем что-то менять?

Измерьте это для самых нагруженных минут реального пика:

• Число запросов в секунду, которые вам прислали, и тех, на которые вы ответили, по каждой бирже или партнёру. Разница — это трафик, который вы теряете, а по её форме видно, отбрасываются ли запросы на входе или уходят в таймаут уже после того, как работа сделана
• Таймауты в подсчёте партнёра. Биржа меряет со своей стороны, включая сеть, и в Google Authorized Buyers именно этот подсчёт решает, будет ли биддер затроттлен. Спросите каждую биржу, какими данными о таймаутах она может поделиться
• 99-й перцентиль задержки с разбивкой на время в сети, время в очереди и время на саму работу
• Глубина очереди по каждому сервису. Очередь, которая растёт во время пика и медленно рассасывается после него, указывает на компонент, задающий ваш потолок
• Повторы в секунду в разбивке по вызывающей стороне. Если повторы растут вместе с таймаутами, они — часть нагрузки
• Отставание счётчиков и событий. Насколько на пике счётчики бюджета и логи показов и кликов отстают от реального времени

Сведите эти цифры по последнему большому пику на одну страницу. Это вводные для любого, кого вы наймёте, и точка отсчёта для каждого исправления.

Что чинить первым и в каком порядке?

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

• Останавливайте работу, которая закончится с опозданием. Считывайте дедлайн, когда приходит запрос, вычитайте сетевое время, которое вы измеряете для этого партнёра, и отвечайте быстрым no-bid, когда остаток слишком мал. OpenRTB позволяет биддеру отказаться пустым ответом HTTP 204, и руководство по внедрению OpenRTB называет этот вариант самым экономным по трафику
• Ограничьте входящий поток. Спросите каждую биржу, как ограничить число запросов, которые она вам шлёт. Real-time bidding API Google, например, позволяет биддеру задать для каждого эндпоинта, принимающего его запросы на ставку, «максимальное число запросов в секунду, которое разрешено отправлять на этот сервер». Под лимит, который вы задали сами, проще планировать, чем под троттлинг, наложенный после пропущенных дедлайнов
• Дайте повторам бюджет. Ограничьте число повторов на запрос и выделите каждому серверу бюджет повторов, как советует книга SRE: когда бюджет исчерпан, запрос завершается ошибкой, а не повторяется. В биддинге повтору достаётся только время, оставшееся до дедлайна
• Уберите общие счётчики с пути запроса. Когда каждое решение читает и обновляет счётчики бюджета и частоты показов в одном центральном хранилище, самые активные кампании сами превращаются в очередь. Дайте каждому серверу локальную долю лимитов, сверяйтесь через короткие интервалы и примите взамен небольшой, заранее известный риск перерасхода
• Отделите события от решений. Пишите события показов и кликов в ограниченный буфер, которого запрос не ждёт, и считайте каждое событие, которое буферу приходится отбросить. Тогда пайплайн поглощает пик и потом догоняет, а ключ на каждом событии позволяет ему убирать дубли
• Готовьтесь к пикам, которые можно предсказать. Многие из них есть в календаре, например сезонные распродажи и спортивные трансляции. Масштабируйтесь заранее, прогревайте кеши и соединения и проводите нагрузочное тестирование на копии продакшена генератором, который держит фиксированную пиковую частоту запросов
• Код, который обрабатывает каждый запрос, меняйте в последнюю очередь. Беритесь за него, когда цифры покажут, что причина в самом коде, например паузы сборщика мусора на пути ставки или инференс модели, съедающий дедлайн

Нужно ли переписывать платформу, чтобы она выдерживала пики?

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

Наша рекламная платформа не выдерживает всплесков трафика. Кто поможет её масштабировать?

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

• Ваши собственные инженеры — с более точными замерами. Они знают код, и страница с цифрами пика может подсказать им решение. Их ограничение — время: работа над пиками конкурирует с дорожной картой
• Ваши партнёры — биржи и SSP. Их подсчёт таймаутов включает сеть между вами, которую ваши собственные дашборды не видят. Спросите, какую разбивку они могут дать: по локации, по типу запроса, по часам
• Поддержка вашего облачного провайдера. Полезна в вопросах лимитов сети, балансировщиков нагрузки и инстансов. Логика ставок остаётся за вами
• Компании общего профиля, работающие на аутсорсинге разработки. Они добавляют инженеров, и это помогает, когда вы упираетесь в размер своей команды. Спросите, работали ли люди, которых они выделяют, с системой реального времени под нагрузкой
• Профильные инженерные компании в AdTech и независимые инженеры по производительности. Они помогут, если сами строили или эксплуатировали систему того типа, который падает у вас. Обращайтесь к ним, когда причина неясна или прежние исправления не продержались

Как проверить компанию, которая предлагает масштабировать нашу рекламную платформу?

Задайте эти вопросы до подписания договора. Ответы помогают понять, делала ли компания такую работу:

• Что вам нужно от нас в первую очередь? Хороший ответ называет замеры: таймауты по каждому партнёру, перцентили, глубину очереди, самые нагруженные минуты последнего пика
• Как мы поймём, что работа сделана? Ждите измеримую цель, согласованную заранее и проверенную на реальном или воспроизведённом пике: какой партнёр, какой перцентиль, какой запас относительно дедлайна, при какой частоте запросов
• Что вы измените до нашего следующего предсказуемого пика, а что — после него? Ждите, что сначала пойдут дешёвые исправления и у каждого изменения будет способ его отключить
• Что из этого вы строили: биддер, SSP или биржу, ad-сервер, пайплайн событий? Спросите о том, что ближе всего к вашей проблеме, и о том, что в нём ломалось
• У кого после работы останутся код, дашборды и нагрузочные тесты? Они должны остаться в ваших аккаунтах

Может ли amBrain помочь с рекламной платформой, которая падает под нагрузкой?

amBrain — инженерная компания из Еревана, Армения: строим low latency торговые платформы, matching engine и системы real-time bidding на Rust.

amBrain диагностирует медленные системы в трейдинге, беттинге и AdTech: работающую платформу замеряют от начала до конца, и в отчёте названо, куда уходит время. amBrain берёт на себя проекты, застрявшие у другой команды, и доводит их до продакшена.

В AdTech amBrain занимается разработкой DSP, платформ real-time bidding и рекламных бирж.

amBrain строит supply-side платформы (SSP) для паблишеров. amBrain строит ad-серверы: таргетинг, ограничение частоты показов и отчётность. amBrain строит пайплайны событийной аналитики для AdTech: сбор и обработка событий показов и кликов и отчётность по ним. amBrain делает ML-инференс внутри биддера: модель определяет ставку в пределах окна аукциона.

amBrain построил для клиента RTBBidder — demand-side платформу. amBrain работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды. Клиент сохраняет полное владение продуктом и кодом, кроме переиспользуемых компонентов amBrain.

Эта статья — не кейс. Она не утверждает, что amBrain устранял сбои при пиковом трафике на рекламной платформе какого-либо клиента, и не приводит ни цифр о RTBBidder, ни цен, ни сроков.

Если ваша платформа упала на последнем пике, начните с одной страницы замеров с этого пика. Отправьте её каждой компании, которую рассматриваете, включая amBrain, и сравните, как каждая предлагает ею распорядиться.

Частые вопросы о рекламных платформах на пиках трафика

• Решат ли дополнительные серверы проблему сбоев на пиках? Иногда: когда на пике платформе не хватает вычислительной мощности, а в остальном всё в порядке. Когда таймауты вызваны штормами повторов, центральным хранилищем счётчиков или медленным партнёром, лишние серверы увеличивают счёт и оставляют причину на месте. А при центральном хранилище счётчиков они ещё и добавляют нагрузку на ту часть, которая и так упирается в предел
• Наша SSP упирается в таймауты, дожидаясь биддеров. Что делать? Дайте каждому биддеру таймаут внутри собственного дедлайна аукциона и оставьте запас до момента, когда нужно ответить паблишеру. Для паблишеров, у которых Prebid.js работает с Prebid Server, Prebid пишет, что серверный таймаут «вероятно, должен быть в пределах 50–75% от таймаута аукциона» в зависимости от сетевой задержки пользователя, чтобы ставки сервера успели вернуться в браузер к вызову ad-сервера
• Нужен ли Rust, чтобы выдерживать пики? Нет. Язык важен, когда замеры показывают, что причина в рантайме, например паузы сборщика мусора на пути ставки. С очередями, повторами, общими счётчиками и мощностями разбираются без смены языка