В этом году Saint HighLoad++ снова собирает экспертов индустрии на берегу Невы. А я уже знаю, какие темы вызовут настоящий хайп среди инженеров и разработчиков. Ловите инсайдерскую подборку самых ожидаемых докладов конференции: только практика, реальные факапы и технологические прорывы.

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

ML в продакшне: почему аналитикам и бэкенду сложно договориться

— Лидер голосования аудитории

— Проблема интеграции ML-моделей в production одна из самых острых

— Разбор конкретных кейсов и решений

Сергей Лавров:

Мы приоткроем вам дверцу в самое сердце Авиасейлс — поисковый движок. Поговорим про нашу Cloud Agnostic инфраструктуру и аналитику, углубимся в архитектуру сервиса, которым пользуются миллионы людей.

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

Честно расскажу про свой тернистый путь от идеи внедрения ML-рекомендаций до продакшена. Посмотрим, зачем нам понадобился Real-Time Inference в несколько тысяч RPS, почему тюнинг CGo с CatBoost не оказался достаточно эффективен и насколько больно встраивать новые инструменты в существующий пайплайн, который уже обрабатывает гигабиты данных в секунду от наших партнёров.

Если у вас Kafka (а у кого её сейчас нет), но при росте нагрузки падает производительность, происходят непонятные задержки при отправке сообщений и вы до конца не уверены в правильной конфигурации. CTO компании STM Labs Андрей Комягин приоткроет тайны высоконагруженного проекта, охватывающего всю страну.

Глубокое погружение в архитектуру Kafka: от простых сценариев до геокластера

— Kafka — стандарт для event-driven архитектур

— Ретроспектива от основ до продвинутых сценариев

— Разбор реальных кейсов масштабирования

Андрей Комягин:

Мы погрузимся в анатомию брокера, аспекты применения Sequential IO и технологии Zero Copy для оптимизации операций ввода/вывода для максимальной производительности.

Профессионалов заинтересует тюнинг Kafka для экстремальных нагрузок, включая пакетную обработку, Pipelining и компрессию данных (compression.type) с оценкой влияния параметров batch.size, linger.ms и compression.type на RPS (requests per second).

Архитекторы узнают нюансы построения гео-кластеров. Stretched vs Connected Clusters: в чем фундаментальные различия этих подходов к построению геокластера. Какие сценарии применения, риски и преимущества у каждого из них.

Рассмотрим конкретные сценарии использования Mirror Maker 2 для асинхронной репликации между кластерами, организации DR-решений (Disaster Recovery) и агрегации данных из нескольких источников.

И, вишенка на торте, результаты бенчмаркинга проведённого на боевом production-кластере и анализ влияния различных типов сериализации сообщений «json vs protobuf» на производительность передачи данных. Покажу конкретные цифры RPS (Requests Per Second) и как на них влияют уже упомянутые batch.size, linger.ms и compression.type для разных форматов сериализации. Это те данные, которые помогут принять взвешенное решение в вашем проекте.

Алексей Жиряков, куратор ПК:

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

Как выдерживать высокие нагрузки и соответствовать строгим требованиям по доступности и задержкам? Как реализовать простой и надежный механизм решардирования PostgreSQL? Если вас посещают такие вопросы, доклад руководителя Группы процессинга Техплатформы Городских сервисов Яндекса Игоря Березняка ответит на них.

Как работает шардирование PG в процессинге Яндекс Такси

— Критически важная система с высокими нагрузками

— Подробный разбор имплементации

— Шардирование всё ещё остаётся сложной задачей

Игорь Березняк:

Наше решение задачи шардирования PostgreSQL в высоконагруженной системе обработки заказов Яндекс Такси отличается от общепринятых. В основном, из-за довольно высоких требований к надёжности сервиса и скорости ответа. Мы отказались от решения на основе центрального координатора (как в SPQR), что позволило упростить архитектуру и повысить ее надёжность. Однако, такой подход привнёс новые сложности, такие как согласование схемы шардирования в распределённой системе. В докладе будет рассказ о способах преодоления этих сложностей и способе решардирования такого кластера без деградации уровня обслуживания.

Алексей Рыбак, куратор ПК:

Очень большой проект! Годами пилят своё решение в чём-то похожее на другие, а в чём-то совсем нет — свои грабли, свой опыт, этим и интересно.

Как полностью убрать ручные ребалансировки и снизить фон отказов на узле в пике нагрузки с десятков процентов до десятых долей процента за секунду? А может быть даже повторить этот фокус у себя в инфре. Бэкенд-разработчик Яндекс 360 Никита Звонарев поделится решением этой задачи.

Балансировка нагрузки в Яндекс Мессенджере (Яндекс 360)

— Решение для миллионов одновременных соединений

— Современные подходы к балансировке

— Применимо во многих highload-проектах

Никита Звонарев:

В Яндекс Мессенджере, который держит нагрузку 300К+ RPS за обработку отправленных сообщений и чтение истории чата отвечает stateful-сервис с собственной системой шардирования нагрузки. Балансировка такой системы — нетривиальная задача, и наша команда, столкнувшись с проблемой перегрузки отдельных узлов, смогла в несколько итераций улучшить алгоритм балансировки. И пусть каждое изменение оказалось достаточно легко запрограммировать, но над реализацией пришлось хорошо подумать.

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

Как в реальном времени собрать продакшен-трафик с микросервисов, чтобы превратить его в данные для проверки системы? Тимлид в Ozon Евгений Кузышин проведёт вас на «внутреннюю кухню» подготовки тестовых данных и расскажет про развитие архитектуры.

Архитектура сбора продакшн-трафика для нагрузочного тестирования: 10 000 микросервисов и 30 млрд запросов в Ozon

— Рост в 1000 раз — мечта и кошмар любого архитектора

— Редкий опыт таких масштабов

— Паттерны можно использовать в проектах поменьше

Евгений Кузышин:

Разберём подготовку тестовых данных в Ozon. Начнём с первой версии архитектуры, как она устроена и как привела к крупному инциденту.

После проследим за развитием системы вплоть до актуальной версии, выдерживающей 1 500 000 запросов на запись в секунду.

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

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

Хотите попрактиковаться в распиле монолита? Разработчик из Wildberries & Russ Алексей Лосев проведёт супер практичное обучение, только не забудьте подготовиться и выполнить домашнее задание: https://miro.com/app/board/uXjVLu2Sjdg=/ Password: YANDEXGO

Мастер-класс «Распилим монолит»

— Вечная проблема: Актуальна для 80% компаний

— Формат мастер-класса: Максимально практично

— Ошибки и решения: Разбор реальных кейсов

Алексей Лосев:

Не скажу, что интересное, скорее полезное. Когда читаешь про какой-то подход, то появляется куча вопросов, а как вот это, а как то, а можно ли вот так. И впадаешь в некоторый ступор. Мастер-класс позволяет в режиме реального времени применить идеи из Domain-Driven Design для распила монолита: потренировать реальные шаги, которые можно сделать в своём проекте.

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

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

Глобальная балансировка веб-ресурсов по геораспределённой инфраструктуре

— Тренд на глобальные сервисы

— Перформанс и отказоустойчивость: ключевые метрики

— Разбор геораспределённых решений

Дмитрий Криков:

Мой доклад даст понимание применения основных технологий: BGP, DNS, HTTP в распределённой балансировке в интернете. Я расскажу про то, как оптимально выбирать и сочетать эти технологии, пройдусь по самым важным особенностям их применения. Постараюсь развеять связанные с ними распространенные опасения и покажу, как снизить вероятные риски.

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

Георгий Меликов, куратор ПК:

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

Как проектировать сложные структуры данных, учитывая особенности архитектуры Scylla? Руководитель отдела Object Storage в Ozon tech Максим Харитонов поделится своим опытом, который может послужить кейсом по проектированию высоконагруженных систем.

Собственный S3-совместимый storage: проблемы построения стабильного хранилища на нестабильном основании

— Построение отказоустойчивого хранилища

— Альтернатива облачным решениям

— Полный цикл от разработки до production

Максим Харитонов:

Несколько лет назад перед Ozon и нашей командой стояла амбициозная задача — создать объектное хранилище, превосходящее по производительности Ceph, решение с многолетней историей и сотнями внедрений. Ключевой проблемой было проектирование индекса своего хранилища. Для решения этой задачи мы выбрали ScyllaDB: маркетинговые материалы обещали устойчивую работу под нагрузкой в миллиарды запросов в секунду, это выглядело идеальным решением для highload-сценариев. На тот момент в команде не было опыта работы с Eventual Consistency базами, а в компании отсутствовали выделенные DBA, способные помочь.

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

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

Топ-статей Saint HighLoad++ 2025