Пять способов сократить расходы на инфраструктуру в высоконагруженных системах: пример AdTech

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

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

При обсуждении затрат на инфраструктуру основное внимание уделяется системам с высокой нагрузкой: вряд ли существует более гибкая и дешевая альтернатива облаку для небольших компаний.

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

Как компания-разработчик программного обеспечения, специализирующаяся на создании и оптимизации высоконагруженных систем для рекламных технологий, мы изучили несколько практик, которые команды используют для предотвращения резкого роста затрат на инфраструктуру. Обладая более чем 15-летним опытом, Xenoss помогал поддерживать такие проекты, как Activision Blizzard, Verve Group, Smartly, Voodoo, Inmar Intelligence и другие, для создания надежных, но гибких инфраструктур.

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

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

Платформы AdTech – пример высоконагруженных систем

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

Давайте кратко повторим, почему платформы AdTech (SSP, DSP и т. д.) являются отличным инструментом для изучения оптимизации затрат на инфраструктуру .

Давление для большого объема и низкой задержки

Платформы AdTech находятся в постоянном перетягивании каната между необходимостью большого объема трафика и низкой задержкой.

С одной стороны, им необходимо справиться с огромным объемом трафика, генерируемого онлайн-рекламой (который, по словам Уэйна Бладвелла , генерального директора TPA Digital, составляет 950 миллиардов показов в день).

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

Высокая задержка на платформах AdTech, то есть задержка между запросом ставки и ответом, приводит к тому, что рекламодатели упускают высококачественный инвентарь, поскольку их ставки не обрабатываются вовремя.

Высокая задержка создает трудности с заполнением рекламных мест для издателей, что в долгосрочной перспективе приводит к снижению доходов.

Стандартный срок обработки заявок колеблется в пределах 80–120 мс — это средний срок, в течение которого работает отрасль.

Принятие решений в режиме реального времени

Обработка данных в режиме реального времени является еще одной постоянной проблемой для проектов AdTech из-за следующих проблем:

Необходимо быстро получать данные (менее 100 мс) для принятия решений в режиме реального времени, например, для моделирования цены предложения.

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

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

Ролик ниже иллюстрирует сложность и критические операции анализа данных в реальном времени.

https://www.youtube.com/watch?v=uaRzovqK3t0

Требования к масштабируемости

Индустрия AdTech циклична: периоды экономических подъемов и спадов приводят к колебаниям спроса на рекламные услуги. Рост рынка вынуждает платформы AdTech реализовывать возможности динамического масштабирования.

В связи с ростом SPO поставщики AdTech чувствуют необходимость надежно корректировать свои мощности в сторону увеличения или уменьшения в ответ на изменения спроса. Таким образом, им нужны возможности и ресурсы для обработки пикового трафика без ущерба для производительности или надежности (а также для его уменьшения, чтобы приспособиться к колебаниям рынка).

Сбор необработанных и агрегированных данных

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

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

Лучшие практики, которые Xenoss использует для оптимизации затрат на инфраструктуру в высоконагруженных системах

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

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

Вот список нескольких методов сокращения инфраструктуры, которые технические команды Xenoss используют, чтобы помочь нашим клиентам добиться более экономичной инфраструктуры.

Изучение преимуществ гибридной облачной инфраструктуры

На ранних стадиях проектов проектированию оптимальной облачной инфраструктуры уделяется мало внимания. Технические команды обычно выбирают один из двух путей;

• Поставщики общедоступных облачных услуг , такие как AWS, Google Cloud или Microsoft Azure. Хотя полагаться на поставщика облачных услуг на ранних этапах процесса разработки вполне понятно, мы хотели бы предостеречь технических лидеров от использования управляемых сервисов, если в этом нет острой необходимости. Со временем эти инструменты могут значительно увеличить счета за инфраструктуру проекта — один из наших клиентов обратился к нам, когда счета за инфраструктуру составили 2,5 миллиона долларов.
• Локальная инфраструктура поддерживается собственной командой . В наши дни обслуживание локальных центров обработки данных не так распространено для проектов на ранней стадии из-за того, что для этого требуются первоначальные инвестиции и рабочая сила. Стоит отметить, что локальная инфраструктура имеет свои преимущества, такие как больший контроль и более строгая безопасность.

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

В Xenoss мы осознаем преимущества обеих инфраструктур, поэтому используем обе в клиентских проектах. Комбинацию облака и локальной среды часто называют «гибридным облаком», хотя под этот термин подходят и другие комбинации. Объединение общедоступного и частного облака или двух публичных облаков (также известных как мультиоблако) также соответствует этой концепции.

Согласно отчету Data Pipelines, опубликованному DZone , 33% опрошенных организаций используют комбинацию облачной и локальной инфраструктуры. Если учитывать только предприятия (более 1000 сотрудников), эта цифра достигает 42%.

Гибридная модель предлагает командам AdTech более высокую финансовую гибкость, позволяя платформам AdTech объединить контроль над локальными установками с динамической масштабируемостью облачных платформ.

Безопасность – еще одно существенное преимущество; проекты могут поддерживать строгие стандарты защиты данных, храня конфиденциальные данные локально и используя облако для менее важных задач.

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

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

Некоторые задачи в AdTech, такие как назначение ставок в режиме реального времени или операции с данными, ограниченные строгими региональными требованиями, лучше подходят для локального выполнения.

В то же время другие рабочие процессы (аналитика кампаний, распределенный хостинг рекламного контента или совместный дизайн рекламы) можно легко перенести в облако.

Оптимизация хранения данных

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

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

Теперь давайте посмотрим на базы данных ведущих платформ AdTech и их подходы к хранению данных.

Как поставщики рекламных технологий используют базы данных SQL для работы с большими объемами данных

Пубматик

Pubmatic SSP помогает издателям охватить широкую аудиторию и максимизировать доходы от рекламы с помощью уникальных партнерских отношений со спросом, расширенной аналитики и инструментов креативной оптимизации.

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

Решение: MySQL

Воздействие. Команда качества рекламы PubMatic использует MySQL в качестве основного источника данных. В базе данных платформы хранится до ста миллионов записей. MySQL, известная своей надежностью и надежностью, позволяет PubMatic обрабатывать миллионы объявлений в день и поддерживать загрузку данных в 2–10 раз.

АдГритц

AdGreetz — это платформа персонализации, которая распространяет адаптированные рекламные материалы по нескольким каналам: социальные сети, CTV/OTT, приложения и т. д.

Задача: рабочие процессы организации требуют больших объемов данных и требуют решений по управлению базами данных, поддерживающих миллионы пользовательских записей.

Выбранная база данных: ClickHouse.

Результат: для команды инженеров AdGreetz Clickhouse оказался экономичным и высокопроизводительным решением. Компании удалось сократить время запроса с секунд до долей секунды на небольших вычислениях.

Как проекты AdTech используют базы данных NoSQL

Пчелиный воск

Beeswax — это управляемая платформа RTB, которая позволяет рекламодателям оптимизировать программные операции. Компания предлагает решение «Bidder-as-a-Service», которое обрабатывает миллионы запросов в секунду и потребляет 125 ГБ данных каждую минуту.

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

Выбранная база данных NoSQL: Aerospike, работающая на Amazon EC2.

Воздействие: Beeswax может обрабатывать миллионы запросов в секунду с задержкой чтения в 2 миллисекунды.

ЖвачкаЖевательная резинка

GumGum предлагает платформу для контекстного таргетинга на основе собственной платформы машинного обучения Verity.

Задача: компания хотела обрабатывать большие объемы данных, связанных с рекламой (показы, просмотры, клики, конверсии), с минимальной задержкой — хотя данные не обрабатывались в режиме реального времени, целью было свести разрыв к минимуму.

Выбранная база данных NoSQL: ScyllaDB.

Влияние:

• Снижение нагрузки на инженерные ресурсы
• Увеличение объема на 75%
• Упрощение масштабируемости благодаря предоставлению ресурсов по требованию.

Молоко

Moloco — это платформа для мобильной аудитории, которая помогает рекламодателям приобретать, привлекать и продавать мобильную аудиторию. Платформа в значительной степени полагается на модели машинного обучения для оптимизации кампаний и прогнозной аналитики.

Задача: необходимость обрабатывать миллионы запросов ставок в секунду со строгим ограничением задержки (менее 100 мс).

Выбранная база данных NoSQL: Google Cloud BigTable.

Влияние:

• Увеличено количество обрабатываемых запросов с 500 тысяч до 5 миллионов в секунду.
• Низкая задержка
• Управляемая инфраструктура позволила компании перераспределить ресурсы разработки программного обеспечения и сосредоточиться на других задачах.

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

Иногда переключение между двумя базами данных NoSQL может иметь большое значение. GumGum, описанный выше, до перехода на ScyllaDB использовал Cassandra. Мы наблюдали значительное снижение эксплуатационных расходов в случае клиента (мобильного DSP) после перехода с MongoDB на Aerospike.

Другие способы оптимизации хранения данных

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

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

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

Холодное хранилище — это экономичный способ хранения редко используемых данных (старых показателей кампании) без ущерба для производительности.

Выбор премиальных услуг, предлагаемых поставщиком инфраструктуры

Использование облачных сервисов требует разумного выбора. Если вы не обратите внимания, легко использовать пакеты услуг, которые увеличивают затраты на инфраструктуру, но не приносят пользы платформе.

В ролике ниже технический директор Xenoss Вова Кириченко объясняет, как «ловушка свободных денег» может привести к высоким затратам на инфраструктуру по мере масштабирования платформ AdTech.

https://www.youtube.com/watch?v=q_57WdKDJI0

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

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

Следить за сторонними проектами или проектами с открытым исходным кодом — еще одна альтернатива дорогим управляемым предложениям. Бесплатные или недорогие платформы могут предложить более высокую производительность, чем основные поставщики облачных услуг.

Применив этот подход в клиентском проекте, инженеры Xenoss помогли снизить затраты на инфраструктуру в 20 раз.

В инфографике ниже мы иллюстрируем старую инфраструктуру клиента и модернизированную версию, разработанную нашими архитекторами.

Балансировка трафика и нагрузки

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

Поскольку инженеры Xenoss считают, что эффективная балансировка трафика и нагрузки является обязательным условием для систем AdTech, давайте углубимся в эти концепции.

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

Отдавая приоритет этим процессам, мы защищаем жизненно важные операции от потенциальных замедлений или сбоев.

Разработка механизма раннего обнаружения угроз

Известная поговорка гласит: «Неудача — это часть каждого плана», и она кратко предупреждает команды разработчиков AdTech о необходимости следить за угрозами и простоями.

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

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

Мы снова предлагаем использовать рекуррентные нейронные сети с длинной краткосрочной памятью для анализа данных временных рядов.

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

Нижняя линия

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

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

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

Сохранение гибкости и информированности в этой области — это мера экономии и конкурентное преимущество в динамичной среде рекламных технологий.