Бэкенд бренд директор за работой

Провели в пятницу второй внешний айтипаб. Обычно он проходит в офисе, но летом попробовали сделать в настоящем баре и нам понравилось 🥂

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

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

У меня под конец года кончились силы на командировки и даже на вылазки в своем городе, но ради такого дела пришлось собраться. Летел как обычно самолетом, на пути обратно уложился в 4 часа ровно от отеля до квартиры, туда - минут на 10 дольше.

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

Отдельное спасибо Насте Черненковой и всей команде за организацию ❤️

Полезное для диалогов о брендах

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

https://t.me/addstickers/kontorapidarasov
https://t.me/addstickers/kontorapidarasov2
https://t.me/addstickers/wankersinc
https://t.me/addstickers/kontorapidarasovIV

✨ Как мы экономим сотни тысяч 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

Жареный апельсин от Чиверса

Предпоследняя неделя декабря, уже решили по новогоднему столу? Если нет, то предлагаю нестареющую классику, авторский рецепт. Осторожно, в ролике много яркой многоплановой лексики.

С наступающим! 🎅🎄

Давайте созваниваться и встречаться не то что допустим по имейлу, но и за рубежом 🥂