✨ Как мы экономим сотни тысяч CPU-ядер в Рекламе

Рекомендательный движок Яндекса обрабатывает свыше миллиона запросов в секунду. В наших масштабах даже 1% экономии в конкретном сервисе превращается в тысячи процессорных ядер. А за последние три года мы ежегодно высвобождали аж по 200 000 единиц.

На связи Антон Полднев, руководитель инфраструктуры Яндекс Рекламы. Сегодня я расскажу, как нам удалось добиться этого результата и какие решения лежат под капотом нашего движка рекомендаций.

5–6 лет назад наша система была единым монолитом с шардированием по данным. При пиковой нагрузке мы могли только отключать шарды, а это вело к финансовым потерям. Мы оптимизировали код по флеймграфам и внедряли простые ML-модели, чтобы отсекать кандидатов, но достигли локального оптимума. В итоге негибкая архитектура не выдерживала нагрузки.

Тогда мы сформулировали три принципа новой архитектуры:

♋️ Прогноз профита
Лёгкая ML-модель оценивает на старте, может ли пользователя заинтересовать какая-либо реклама. Если нет — мы избегаем сложных вычислений и сохраняем ресурсы.

♋️ Генерация кандидатов
Вместо алгоритмического подбора по ключевым словам мы перешли к методам поиска ближайших соседей. Нейросеть сопоставляет пользователей и объявления в едином векторном пространстве, что повышает и эффективность, и качество.

♋️ Трёхстадийное ранжирование
Сначала кандидатов отфильтровывает лёгкая модель, а потом тяжёлая. Так у нас появляется возможность использовать сложные алгоритмы без роста нагрузки.

Когда мы заявили, что средняя утилизация сервисов в 30–40% — это не предел, а повод для основательной оптимизации, нам не верили. Дескать, при большей нагрузке не избежать серьёзной деградации.

Мы изменили подход:

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

🟢 Избирательное отсечение
С помощью PID-контроллера мы в реальном времени регулируем порог отсечения запросов с низким профитом. Это даёт возможность «прореживать» очередь в пиках и жертвовать 1% качества, чтобы экономить 15% нагрузки.

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

В результате нам удалось поднять утилизацию и изъять 10–20% лишних ресурсов из сервисов.

От Protobuf к собственному формату

Перекладывание данных — тихий убийца производительности. Мы прошли путь от ручной сериализации через Protobuf к FlatBuffers. Однако операции чтения оставались заметно более дорогими по сравнению с чтением полей из простых структур.

Мы создали собственный формат YAFF, который объединил лучшие черты Protobuf (схему) и FlatBuffers (подход к доступу), и оптимизировали его для современных процессоров. В итоге получили двукратное улучшение CPU time, а размер сообщений сократился на треть.

Микросервисы, которые экономят

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

Это улучшило локальность данных и преобразовало CPU-bound-задачу в memory-bound, что в совокупности позволяет экономить CPU.

Наш опыт демонстрирует, что экономия на масштабе — это не только оптимизация алгоритмов. Ещё это:

🟢 Умная деградация, которая позволяет повышать утилизацию
🟢 Борьба с накладными расходами на каждом уровне, особенно при сериализации
🟢 Стратегическое применение микросервисов для улучшения локальности данных
🟢 Постоянный мониторинг с использованием перфоратора, PGO-оптимизация и нагрузочное тестирование

Кстати, с этой темой Антон выступал на конференции «Я про бэкенд». Доклад можно посмотреть на платформах:

➖ Ютуб
➖ VK Видео

Презентацию выступления Антона прикрепляем ниже 🔽

Больше записей докладов с конференции собрали для вас в плейлистах:

➖ Ютуб
➖ VK Видео

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend