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

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

29 декабря 2023 г.

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

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

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

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

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

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

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

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

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

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

Давление на большую громкость и низкую задержку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В связи с ростом SPO поставщики 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 используются для управления структурированными и неструктурированными данными. Давайте вспомним ключевые различия между двумя типами баз данных, а также варианты их использования в рекламных технологиях.

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

| Преимущества реляционной базы данных | Преимущества баз данных NoSQL | |----|----| | Высокая надежность | Высокая производительность | | Высокая согласованность данных | Высокая масштабируемость | | Стандартизированная схема | Хранилище, оптимизированное для больших объемов данных | | соответствие требованиям ACID | Высокая гибкость и персонализация |

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

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

Пубматик

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

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

Решение: MySQL

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

AdGreetz

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.

Vova Kyrychenko, CTO at Xenoss, on the impact of an intentional database migration on a high-load project

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A focused cost-to-benefit analysis of managed services helped our client cut operating costs twentyfold.

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

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

р>

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

Review of cloud load balancing by Google Cloud (source)

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

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

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

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

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

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

Using Isolation Forest for anomaly detection (Source: Towards Data Science)

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

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

Итог

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

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

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

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


Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE