DSP теряет аукционы на таймаутах, а расходы на инфраструктуру растут: что измерять и как проверить, кто может это исправить

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

Почему наша DSP уходит в таймаут на двух подключениях к биржам, а на остальных нет?

В OpenRTB, протоколе IAB Tech Lab для real-time bidding (RTB), биржа может передавать дедлайн в каждом запросе через необязательное поле tmax, и время, проведённое в интернете, входит в этот дедлайн. Когда сбоят только два подключения, начните с того, чем отличаются именно эти два:

• Расстояние съедает часть каждого дедлайна. Документация Google Authorized Buyers называет четыре торговые локации для запросов на ставку — в Северной Вирджинии, районе залива Сан-Франциско, Амстердаме и Сингапуре — и советует биддерам размещать серверы рядом с ними. Биддерам, которые получают много запросов, Google также рекомендует пиринг — прямую связь между их сетью и сетью Google, — чтобы снизить задержку и её разброс
• Дедлайны различаются по биржам и по запросам. В Google дедлайн зависит от формата рекламы и типа аукциона. Биржа, которая передаёт запрос дальше, может ещё и оставить часть времени себе. Например, в спецификации запросов на ставку Equativ сказано, что значение tmax, которое уходит её биддерам, всегда меньше, чтобы оставалось достаточно времени на обработку ответов со ставками
• Некоторые биржи присылают более тяжёлые запросы. OpenRTB позволяет каждой бирже добавлять собственные дополнительные поля и предлагать несколько показов в одном запросе, а в каком виде приходят запросы — обычным JSON, в бинарном формате или в сжатом виде, — согласуют с каждой биржей отдельно. Более крупный запрос дольше принимать и декодировать, а каждый дополнительный показ — это ещё один круг проверки кампаний
• Новые сетевые соединения начинают с меньшим запасом времени. Руководство Google по лучшим практикам для RTB-приложений говорит, что у первого запроса в новом соединении фактический дедлайн короче и он чаще уходит в таймаут, и рекомендует держать простаивающие соединения открытыми 2,5 минуты. Если ваши серверы или балансировщик нагрузки либо прокси перед ними закрывают простаивающие соединения раньше, части запросов приходится ждать, пока внутри их дедлайна откроется новое соединение
• Некоторые шаги выполняются только для определённых запросов. Когда медленно работает обращение за данными пользователя или модель, которая используется для одного формата рекламы, задержка ложится только на те подключения, чьи запросы через них проходят
• Трафик одной биржи может попадать на более загруженные серверы, где запросы ждут в очереди ещё до начала какой-либо работы. Google отмечает, что сетевые соединения, установленные через прокси, со временем могут разбалансироваться, и нагрузка на ваши серверы станет неравномерной

Замедление всего процесса биддера задерживает сразу все подключения. В биддере на Go или Java его может вызвать сборка мусора (GC) — работа рантайма по освобождению памяти, которая больше не нужна программе. Первыми пропускают дедлайны те подключения, у которых после сетевого времени и работы, нужной каждому запросу, остаётся меньше всего запаса. Поэтому сравните дедлайн каждого подключения с его сетевым временем и размером запросов, прежде чем искать причину, которая есть только у этих двух подключений. Статья о паузах GC в Go, ссылка на которую есть выше, показывает, как инженеры разделяют эти причины.

Почему счёт за инфраструктуру растёт быстрее выручки?

Счёт растёт с каждым запросом, который ваши серверы принимают и на который отвечают, а выручка приходит только с выигранных аукционов. Разрыв увеличивается по нескольким причинам:

• Запрос на формат или страну, под которые у вас нет кампаний, всё равно приходится принять и разобрать, а выиграть он не может. Предварительный таргетинг (pretargeting) в Google позволяет биддеру получать только те запросы, которые подходят под его критерии таргетинга. Спросите каждую биржу, какую фильтрацию она предлагает
• Поздние ответы могут ещё и сократить трафик, который вам присылают. Страница справки Google о графиках RTB говорит, что, когда больше 15 процентов ответов недействительны или уходят в таймаут, Google присылает меньше запросов, пока доля ошибок не опустится ниже 15 процентов или поток запросов не упадёт до минимума. Если трафик часто и подолгу троттлится, Google может изменить квоту биддера — максимальное число запросов в секунду, которое он будет присылать, — до уровня, с которым биддер справляется стабильнее. Серверы, рассчитанные на старую квоту, продолжают стоить денег, если никто не пересмотрит их количество
• Серверы, добавленные в том же дата-центре, увеличивают счёт, но не сокращают длинный маршрут до биржи и не мешают простаивающим сетевым соединениям закрываться слишком рано
• Один и тот же показ может прийти к вам через несколько бирж. OpenRTB 2.6 описывает идентификатор транзакции (transaction ID), который должен быть общим для всех участников запроса на ставку, в том числе, возможно, для нескольких бирж, и объект цепочки поставок (supply chain), в котором перечислены компании, участвующие в прямом движении платежа. Там, где биржи заполняют эти поля, по ним видно, что два подключения предлагают вам один и тот же показ, а каждая копия стоит вам серверного времени
• Какой-то запас мощностей необходим. Чтобы поглощать временные перетоки трафика между регионами, Google рекомендует держать запас в 15 процентов между семидневным пиком и числом запросов в секунду, заданным для каждой торговой локации. Под сомнение в первую очередь стоит ставить мощности, добавленные после инцидента без замера, который бы их оправдывал

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

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

Сведите это на одну страницу — по строке на каждое подключение к бирже — за обычную неделю и за её самый нагруженный час:

• Запросы в секунду по биржам и регионам и средний размер запроса
• Разброс дедлайнов в этих запросах: по tmax там, где биржа его присылает, и по её документации там, где не присылает
• По каждому подключению к бирже — время ответа, которое превышает лишь 1 процент ваших самых медленных ответов (99-й перцентиль), с сетевым временем в обе стороны отдельно от времени внутри ваших серверов
• Таймауты, которые сообщает каждая биржа, рядом с их числом по вашим собственным логам. Графики RTB в Google, например, считают запросы, подошедшие под ваш предварительный таргетинг, фактически отправленные запросы, действительные ответы в пределах таймаута, ставки и выигранные аукционы и показывают перцентили задержки по каждому эндпоинту — адресу, на котором ваш биддер принимает запросы. Узнайте, что сообщают остальные биржи
• Сколько новых сетевых соединений открывается в минуту по каждой бирже и где находятся серверы, которые отвечают этой бирже
• Доля запросов со ставкой, доля выигранных аукционов, расход и выручка по каждой бирже
• Затраты на инфраструктуру по каждой бирже в пересчёте на миллион запросов, включая серверы и сетевой трафик

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

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

Эта статья не составляет рейтинг компаний. Действительно ли команда устраняла задержку на пути ставки, видно по доказательствам, которые вы можете проверить сами:

• Биддер или биржа, которые команда построила или починила и которые до сих пор работают в проде, — с названием клиента или причиной, по которой его нельзя назвать
• Инженер этого клиента, готовый поговорить с вами без участия команды
• Цифры «до» и «после» по названным подключениям к биржам, подтверждённые клиентом, например доля таймаутов в подсчёте биржи и стоимость миллиона запросов
• Отчёт о диагностике или план из прежнего проекта, из которого убраны данные клиента

Как проверить, что команда настоящая?

Проведите эти пять проверок по порядку, до того как на пути ставки начнётся какая-либо работа.

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

До любого переписывания попросите письменный план. В нём должно быть сказано:

• Что команда измерит первым и какой доступ ей для этого нужен
• Какие изменения идут первыми, начиная с самых дешёвых, и как откатить каждое из них
• Для каждого из двух подключений к биржам — целевая доля таймаутов по отчётам этой биржи, целевая стоимость миллиона запросов и уровень трафика, при котором будут проверять и то и другое
• Как переделанная часть работает рядом с текущей на копии живого трафика, а затем по одному принимает на себя подключения
• Чего команда не будет трогать

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

Позвоните клиенту, для которого команда построила или починила биддер или биржу и у которого эта система до сих пор работает. Поговорите с инженерами этого клиента без участия команды и спросите:

• Что команда измерила, прежде чем что-то менять?
• Какие цифры сдвинулись, на каких подключениях к биржам и кто их измерял?
• Кто сегодня эксплуатирует и меняет этот код?
• Что пошло не так в ходе работы и что команда с этим сделала?

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

Условия владения читайте последними. Код должен с первого дня лежать в ваших репозиториях и быть письменно передан вашей компании. Всё, что команда оставляет за собой, должно быть перечислено поимённо, с лицензией, позволяющей использовать и изменять это после окончания работы, а биддер должен работать без серверов и лицензионных ключей команды.

Какие компании могут построить или перестроить биддер DSP силами выделенной команды внутри нашей платформы?

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

Бриф, в котором просят низкую задержку, отсутствие пауз GC и высокий QPS, должен пояснять, что значит каждая из этих формулировок:

• «Низкая задержка» означает ответы в пределах дедлайна каждой биржи на 99-м перцентиле, на ваших собственных подключениях. Среднее по всему биддеру может скрыть два подключения, которые не справляются
• «Без пауз GC» — это про сборку мусора, то есть требование к языку, на котором написан биддер, и к его рантайму. В книге по Rust сказано, что Rust управляет памятью через «систему владения с набором правил, которые проверяет компилятор», поэтому в биддере на Rust нет сборщика, который мог бы его приостановить. У биддеров на Go и Java сборщик есть, и его можно настраивать. Длинный сетевой маршрут или очередь всё равно могут заставить опоздать любой биддер
• «Высокий QPS», то есть много запросов в секунду, мало что значит без размера запроса и числа активных кампаний за этой цифрой. Спросите, получена ли цифра в проде или на тесте и на чьём трафике

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

Какие тревожные сигналы стоит замечать, нанимая команду для работы над путём ставки?

• Переписывание или новый язык предлагают раньше, чем кто-то увидел ваши цифры по подключениям
• Цифру задержки или экономию на счёте обещают уже на первом созвоне
• В качестве доказательства предлагают бенчмарк на собственном железе команды с её собственными запросами
• Биддер будет работать на серверах команды или по её лицензии, хотя вы просили команду внутри своей платформы
• Ни один клиент не соглашается на звонок, и показать работающий биддер или биржу нельзя
• Каждое исправление в предложении добавляет серверы

Где здесь место amBrain?

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

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

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

amBrain делает софт с 2019 года. amBrain построил для клиента RTBBidder — demand-side платформу.

Эта статья — не кейс. Она не описывает эту платформу (её устройство, язык или производительность) и не утверждает, что amBrain диагностировал или устранял задержку на пути ставки для какого-либо клиента. Цен и сроков она не приводит.

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

Частые вопросы

• Нужен ли биддер в каждом регионе, откуда присылает запросы биржа? Не всегда. Google старается направлять каждый запрос в торговую локацию, ближайшую к пользователю, но не гарантирует этого, поэтому, чтобы получать все его показы, нужны серверы, доступные из всех четырёх локаций. Руководство Google по тестированию добавляет, что принимать показы из нескольких торговых локаций обычно означает держать серверы для ставок в каждом регионе. Если вам нужна только часть трафика, по словам Google, может хватить серверов в некоторых из локаций, поэтому выбирайте регионы по тому, где покупают ваши кампании
• Не потеряем ли мы выигрыши, если ограничим запросы, которые присылает нам биржа? Зависит от того, какие запросы биржа придерживает. В Google, когда запросов, подходящих под предварительный таргетинг биддера, больше, чем позволяет его квота, избыток троттлится, а запросам, на которые биддер, скорее всего, ответит, иногда отдаётся приоритет с учётом его недавней истории ставок. Другие биржи могут решать иначе, поэтому спросите каждую