Доклады

История сайта авто.ру началась в 1995 году с простой доски объявлений и форума для автомобилистов. За прошедшее время он претерпел множество трансформаций, чтобы оставаться актуальным для пользователей и справляться с высокой нагрузкой.

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

Каждый день на Авито размещаются десятки тысяч объявлений. Их путь от нажатия кнопки «разместить объявление» до появления в поисковой выдаче, проходит через множество сервисов и компонентов, живущих под высокой нагрузкой. В докладе я проведу вас за кулисы происходящего и расскажу об архитектуре платформы подачи, о том, как мы обеспечиваем ее стабильность и наконец - как платформа помогает продуктовым командам снижать ТТМ и запускать десятки фичей каждый день

1) Архитектура ранжирования с помощью моделей и факторов (фичей).
2) Инференс моделей ранжирования в поиске Ozon.
3) Попадание новых моделей ранжирования в прод.
4) Вычисление графа зависимостей между моделями и фичами (входами для моделей).
5) Автоматические проверки перфоманса и качества перед доставкой моделей в продакшн.
6) Пайплайн добавления новых факторов ранжирования в прод.
7) Затрону минусы нашего прошлого решения (https://highload.ru/spb/2023/abstracts/10173) и расскажу, во что feature store превратился.

В докладе разберем как масштабируются разные брокеры сообщений и ответим на следующие вопросы:
- Что будет если просто добавить партиций?
- Как себя поведет брокер при замене диска?
- Что случиться, если добавить новый брокер в кластер?
- Когда уже нет смысла масштабировать существующий кластер и проще создать новый рядом?
Все это я сопровожу примерами масштабирования Apache Kafka и YDB Topics с замерами того, насколько при расширении кластера упала скорость работы.
Закончу доклад сравнением YDB Topics и Apache Kafka и сравнением сценариев, когда использовать один, а когда другой.

Если у вас крупный веб-ресурс - вам важно, чтобы он был всегда доступен и работал быстро из любой точки мира.
В этом помогает геораспределенная инфраструктура, позволяющая приблизить контент к пользователям и отдавать его из оптимальной точки. Как обеспечить выбор этой оптимальной точки и балансировку запросов пользователей по этим точкам? Особенно если вы ограничены возможностями самых стандартных технологий, типовых устройств, браузеров и приложений.
На опыте развития распределенной облачной платформы NGENIX (50+ узлов по всей России и странам СНГ, 7+ Tbps, миллионы RPS) - расскажу о том, как:
· выбирать оптимальные технологии балансировки в интернете от уровня сети до уровня приложений: BGP Anycast, DNS, HTTP и выше
· получать данные, необходимые для принятия правильных решений по балансировке
· объективно мониторить (в т.ч. распределенно) и сравнивать эффективность таких распределенных решений

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

1. Intro. О проекте с большим количеством внешних систем для сбора данных.
2. Решаем, как будем собирать данные и как их обрабатывать.
3. Систематизация и хранение данных: готовые импортозамещенные инструменты.
4. Расскажу и покажу, почему не стоит париться из-за безопасности.
5. Почему бизнесу важно следить за проектом в реальном времени и принимать решения.

Реальный кейс о том, как я собрал такую систему, и в итоге все были счастливы — бизнес, разработчики и я =)

Доклад фокусируется на архитектурных решениях для RAG-систем, где чанкинг становится узким местом при масштабировании. Рассматриваются 10 стратегий оптимизации, их комбинации и интеграция с Weaviate, Qwen и Llama.

Решаемые проблемы:

High latency при индексировании больших данных (PDF, код, таблицы).
Потеря контекста из-за неадаптивного разделения текста.
Сложности балансировки между скоростью (throughput) и точностью (recall).

Ключевые стратегии чанкинга:
Semantic Chunking (на основе Qwen-7B): разделение по смысловым границам.
Recursive Split: иерархическая декомпозиция текста.
Fixed-Size with Overlap: фиксированные окна с перекрытием для сохранения контекста.
Token-Limited Dynamic Chunking: адаптация под лимиты токенов LLM (например, Llama-3).
Rule-Based Chunking: правила для специфичных данных (например, разделение по секциям договоров).
Content-Aware Chunking: анализ типа контента (текст/таблица/код) через Unstructured.io.
Graph-Based Chunking: связь чанков через графы (предотвращение разрывов контекста).
Sliding Window with Threshold: динамическое определение границ на основе эмбеддингов.
Hybrid Approach: комбинация NLTK-статистик и нейросетевых моделей.
Cluster-Driven Chunking: предварительная кластеризация данных для группировки связанных чанков.

Архитектурные инновации:
Интеграция Weaviate как векторной БД с поддержкой мультимодальности и гибридного поиска.
Оптимизация пайплайнов через LangChain и LlamaIndex для работы с Qwen и Llama.
Кэширование чанков и эмбеддингов в Redis для снижения задержек.

Результаты:
Ускорение индексирования в 2 раза (с 10 сек/док до 5 сек/док) при обработке 50K PDF-документов.

Повышение recall на 12% в тестах с медицинскими отчетами.

Снижение стоимости инференса Llama/Qwen за счет уменьшения избыточных чанков.

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

В докладе расскажу:
· Про проблемы крупного монолита при переезде в облако
· Переход от stateful к stateless
· Способы транспорта данных
· Оркестрация применения данных в облаке
· Шардирование сервиса в облаке
· Перевод разработки в облако

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

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

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

В 2ГИС поисковые данные обновляются довольно часто — особо активные сегменты могут обновляться раз в 10 минут. Насколько быстро эти данные начнёт использовать поисковый движок, настолько свежие данные увидит пользователь. Поэтому основная задача — быстро доставить свежие данные до пользователя.

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

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

Про Apache Kafka не слышал только ленивый. Apache Kafka — это высокопроизводительная потоковая платформа, предназначенная для передачи и обработки большие объёмов данных с минимальной задержкой. В каких только системах Kafka сейчас не используется!

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

Начнем с основных концепций, но копнем глубже, выйдя за рамки общеизвестной информации. Так что же внутри черного ящика? Мы погрузимся в детали архитектуры системы хранения данных Kafka, рассмотрим принципы работы Sequential IO vs Random IO, а также изучим подход Zero Copy и оценим его влияние на производительность работы брокера. Рассмотрим файловую структура хранилища.

Далее оценим влияние выбранного типа сериализации на производительность – посмотрим бенчмарки “json vs protobuf” на примере data payload с реальных проектов. В рамках этой части доклада пристально посмотрим и на влияние компрессии (gzip vs snappy).

А что, если хочется еще быстрее? Поднимем тему тонкой настройки Kafka для максимальной оптимизации производительности. Поговорим про тюнинг пакетной обработки и настройку batching, linger.ms. Посмотрим на бенчмарки и оценим влияние этих параметров конфигурации на реальных примерах с ПРОДа.

Не обойдем стороной тему семантик и гарантий доставки данных – at least once, at most once и exactly once. Тут отдельно остановимся на сценариях их применения в реальных системах.

В самом конце, проведем обзор архитектуры большой высоконагруженной информационной системы на примере топологии гео-кластера, построенного на базе Apache Kafka. Разберемся в отличиях stretched vs connected clusters и рассмотрим инструментарий репликации, включая Mirror Maker 2.

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

Брокеры сообщений широко применяются во всем IT, в частности RabbitMQ, однако это далеко не магическая коробка и написать свой код так, чтобы не потерять свои сообщения - крайне нетривиальная задача. RabbitMQ это сложный инструмент, а любой сложный инструмент требует точной настройки. Мы окунемся глубже в архитектуру RabbitMQ, посмотрим, где мы с легкостью можем ошибиться и потерять сообщения, и как себя от этого застраховать. Глянем на 8 практических кейсов работы с RMQ, в которых опишем нюансы работы, хорошие практики и неочевидные сюрпризы, с которыми вы можете столкнуться.

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

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

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

Компания Антиплагиат – поисковик, ищущий совпадения в текстовых документах. Нагрузка меняется в течении суток вслед за нормальной активностью пользователей в РФ и странах СНГ, кроме того, есть ярко выраженная сезонность, пиковая нагрузка июня в 10 раз больше пиковой нагрузки в июле. Автомасштабирование сервисов позволяет очень сильно экономить. Я расскажу о том, как это устроено у нас в кубах. Казалось бы, используй спотовые инстансы и будешь экономить 70%, но не все так просто на самом деле. Можно экономить больше, при этом масштабирование будет происходить достаточно быстро, даже с толстыми ML-моделями.
В докладе будет рассказано о практике оптимизации настроек и опыте использования оптимизированных K8S кластеров под управлением deckhouse на прерываемых(спотовых) инстансах в AWS и YC. Текущий суммарный размер K8S: 5500 подов, 3000 ядер, 8 ТБ памяти (в сезонном пике мы ожидаем стандартного увеличения кластера в 3-5раз). Основной упор будет сделан на конкретных решениях позволяющих платить меньше а работать быстрее/надежнее. Расскажу наш практический опыт в настройках, влияющих на скорость масштабирования, скорость работы и доступность сервисов. Пройдемся по особенностям использования compute сервисов облаков позволяющих снизить стоимость эксплуатации при сохранении приемлемого для компании уровня надежности. В компании используется большое количество сервисов на основе ML-моделей, что влечет большой набор данных для первичной инициализации, старта и работы сервиса. Рассмотрим оптимизации, нацеленные на уменьшение времени старта таких сервисов при масштабировании, уменьшении объема межсервисного, служебного и инициализирующего трафика. В докладе будет представлен наш опыт оптимизаций и эксплуатации таких кластеров в двух облачных провайдерах.

Я не верю, что проектировать отказоустойчивые и хорошо масштабируемые энтерпрайзы можно по книжкам. Как показывает мой 5 летний опыт в вузе и 10 летний в профессии, одно и то же решение вы увидите и в best и bad practice, плюс одно может перетекать в другое с течением времени (помните, совсем недавно монолиты были чистым злом?:) ) А все потому что конкретное решение будет хорошим или плохим только в конкретных условиях его применения. Поэтому узнать про архитектурные паттерны и приемы можно из книжек, а вот научиться их применять - только из практики.
СДЭК к вашим услугам:) У нас за 25 лет накопился большой опыт и хороших, и плохих решений. Делали ли мы костыли? Еще как! Изобретали ли велосипеды? Возможно, лучшие в стране! А иногда мы думали, что приносим архитектуру в жертву, а оказывалось, что это было лучшее решение, которое отлично работает спустя годы...
Интересно, сможите ли вы отличить одно от другого? Приходите на мой доклад, и узнайте, сколько баллов наберете в нашем интерактивном тесте. Я буду рассказывать контекст, принятое решение. Дальше вы будете голосовать - костыль/велосипед или best practice получилось? И после этого я расскажу ответ. Практика - критерий истинности, поэтому правильную категорию будем определать по полученным последствиям.

Команда Видеоаналитики Сибура занимается анализом онлайн-видеопотока с более 2000 камер. Потребность в анализе большая, при этом вычислительные ресурсы меньше, чем у IT-гигантов. При разработке решений приходится учитывать такие условия, как географическая распределенность камер (от Твери до Томска), отсутствие GPU и доступа к облакам, а также более 40 различных computer vision моделей.
В докладе я расскажу о том, как разработать гибкую и производительную систему с микросервисной архитектурой, позволяющую извлекать видеопоток с 2000+ камер по RTSP, эффективно применять разные cv-модели при отсутствии GPU для решения различных задач видеоаналитики, и о том, как сделать эту систему удобной для пользователей и для других разработчиков.

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

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

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

Наш продукт для видеоконференций создает более 10 000 записей встреч в день, и пользователи ожидают саммари как можно раньше. SLA на генерацию саммари изначально был 1 час, но это делало функцию малоценной. Дополнительное ограничение, это время подготовки транскрипции, что накладывает дополнительные требования к скорости обработки и получению саммари.

Я расскажу, как мы построили систему, которая выдерживает 10K+ запросов в день и выдает саммари за 5–15 минут. Разберем архитектуру фичи от создания записи до получения саммари, влияние SLA на компоненты системы.

Естественным этапом развития систем серверной виртуализации является виртуализация сети — возможность создавать виртуальные сетевые инфраструктуры «под задачу», не будучи стесненным рамками реальной сетевой инфраструктуры предприятия. Подобный этап развития настал и у проекта zVirt.

Для обеспечения виртуализации сети в нашей системе мы исследовали существующие решения и остановились на интеграции готового SDN — OVN. При интеграции мы столкнулись с различными проблемами, начиная от просадок в производительности при увеличении нагрузки на SDN и заканчивая задачами, связанными с оберткой в продукт.

В докладе расскажу:
* чем отличается интеграция SDN в облако и SDN в систему виртуализации, почему разработка «механизма» сложнее, чем разработка «политики»;
* почему мы остановились на готовом SDN, а не писали сами;
* с какими трудностями столкнулись при попытках сделать универсальное решение;
* компромиссы и их цена: чем пришлось пожертвовать;
* сравним производительность нашей системы со «стоковой».

В процессе проектирования высоконагруженных сервисов появляются вопросы выбора языка программирования, базы данных и других технологий. Мы обсудим, как подступиться к этому выбору и спроектировать долгоживущее высоконагруженное приложение. Пройдёмся по стадиям выбора технологий и проектирования архитектуры и разберём принципы проектирования highload-систем в книжках и в реальной жизни.

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

Миллион мастер реплик в проде? Встречаем сетевой консенсус Ethereum 2.0 - самой децентрализованной базы данных в мире. В действующей сети Ethereum действительно уже больше миллиона активных валидаторов, каждый из которых периодически становится лидером в сетевом консенсусе. И хотя число реальных мастер-серверов сети оценивается в десятки тысяч, сетевой консенсус Ethereum 2.0 на данный момент является самым децентрализованным консенсусом в мире, безопасность которого обеспечивается примерно 100млрд$ замороженных активов и который работает без серьезных сбоев уже несколько лет. Если перекладывать на язык баз данных, то мы имеем БД с мастер-мастер реплицкацией между огромным числом реплик, устойчивую не только к сбоям, но и к сговору большого числа валидаторов. Доклад рассказывает про эту механику репликации, основные алгоритмы, организацию такой сети и ее параметры. Доклад будет интересен всем, кто интересуется отказоустойчивыми распределенными системами и кого задолбали рассказы про майнинг.

При росте популярности приложения растет и нагрузка на сервис. Я расскажу как мы в компании МТС Юрент справлялись с нагрузкой данных от самокатов при росте парка.
В докладе затрону:
* Архитектуру группу сервисов кластера IOT
* Какие сложности были и как решали при росте 10тыс, 50тыс, 100тыс устройств
* С какими ограничениями столкнулись в базе данных MongoDb
* Как Redis помог выдерживать текущие нагрузки

Лидеры рынка СУБД в сегменте крупных предприятий — Oracle, MS SQL, PostgreSQL, несмотря на то, что архитектура этих платформ складывалась больше трёх десятилетий назад. В докладе разберём узкие места этой архитектуры и приёмы, применяемые в современных платформах, которые позволяют значительно увеличить производительность базы данных. А в конце посмотрим, почему же никто так и не подвинул с пьедестала традиционные СУБД.

Умело установленный “точный” индекс может значительно ускорить целое семейство запросов с фильтрацией. Но когда нет возможности создать такой индекс и не остается ничего кроме сканирования всей таблицы, нас может выручить data skipping. С появлением нового колоночного движка в Tarantool в этом появилась острая необходимость, ведь индексы в колоночном хранилище стоят очень дорого. В докладе я расскажу о том, как мы делали максимально гибкий и легковесный data-skipping индекс в реалиях и без того шустрой in-memory СУБД, какие виды таких индексов распространены, и почему мы так полюбили простые логические предикаты.

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

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

Можно ли увеличить latency, добавив слой кеширования? Конечно, да. Ведь в облаках между нашим приложением и Valkey (опенсорсный форк Redis) будет сеть. А если мы решили горизонтально масштабироваться, то где гарантия, что мы выбрали лучший хост для выполнения наших запросов?

Посмотрим, что с этим делать. Обсудим, что случилось в Valkey 8.0 и 8.1 для улучшения latency (и почему это помогает). Разберемся, стоит ли переходить на valkey-only клиенты, если наша цель - минимальные задержки выполнения запросов.

И заодно посмотрим, что нового с точки зрения улучшения latency в высоких перцентилях в rdsync (Open Source тул для улучшения отказоустойчивости Valkey от Yandex Cloud).

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

В 2024 году Ozon полностью перенес свою инфраструктуру объектного хранилища на собственное решение S3-server Lusca. В докладе я раскажу, как мы выбирали хранилища индекса; думали, как реализовать strong consistency на eventual consistency базе; открывали для себя особенности фоновых процессов ScyllaDB и придумывали свои алгоритмы; А еще о том, как боролись с восстанием зомби на Хеллоуин и воскрешали терабайты данных.

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

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

Опыт кастомного подхода к шардированию Postgresql в ядре процессинга заказов Яндекс Такси. Как справляемся с нагрузками и строгими требования к доступности и latency. Как организация данных помогла реализовать простой и надежный механизм решардирования.

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

Мы обсудим:

* как векторный поиск улучшает ответы больших языковых моделей;
* принципы работы векторного поиска и его применение в YDB;
* основные проблемы и сложности при разработке векторного индекса;
* особенности и преимущества глобального синхронного индекса;
* стратегии масштабирования и оптимизации производительности;

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

Часто при работе с графами требуются инструменты для быстрой аналитики, проверки гипотез и прототипирования алгоритмов с высокой производительностью. У таких задач часто нет высоких требований к частоте запросов, но если граф слишком большой для Python, результатом аналитики является сравнимый по размеру граф, а результаты нужны очень быстро, то не всегда и графовая БД является удобным решением. Альтернативой может быть хранить в S3 исходный граф свойств (LPG) и результаты аналитики.

Наша команда анализирует графы крупного размера (~1 млрд вершин, ~50 млрд ребер с историей изменений) в облачной инфраструктуре, мы быстро вычисляем метрики, где необходимо обработать большую часть графа (OLAP и Graphalytics) для фич и и точечных запросов для OLTP-сценариев аналитики. Например, PageRank рассчитываем за 25 минут, Jaccard за 100 минут.

В докладе мы поделимся опытом работы с JanusGraph поверх Cassandra, DuckDB с расширением DuckPGQ и GraphScope. Расскажем о производительности решений для работы с графами в S3. Покажем результаты сравнения форматов хранения LPG: от Parguet и Iceberg до нового GraphAR от Alibaba, с обсуждением их преимуществ и ограничений в сценариях аналитики (OLAP и OLTP).

Доклад будет интересен исследователям и разработчикам Big Data, специалистам по графовой аналитике и архитекторам распределённых систем.

Уже дважды на хайлоаде я рассказывал про наш опыт развёртывания и управления распределённым S3 совместимы хранилищем на базе MinIO. Приятно, что доклады находят своих слушателей и вопросы мне в телеграм продолжают приходить до сих пор. некоторый просят продолжения. Поэтому я решил сделать ещё один доклад на эту тему, тем более что наш опыт растёт вместе с объёмом места, которое занимает информация в нашем хранилище. Сейчас оно размещается в 4 ДЦ, включает в себя 12 нод и 300 дисков.

Итак, коротко о том, о чём я хочу рассказать в этом году

1. Расширение хранилища.
Рано или поздно место заканчивается и приходит время добавлять новые ноды и диски. В прошлый раз я рассказывал, как мы расширялись с 3 до 4 дата-центров, по сути, скопировав все данные, что съело много времени. В этот раз я расскажу, как мы добавляем новые ноды, дисковые полки и диски в них соответственно. С одной стороны казалось бы, тривиальная процедура, с другой она представляет из себя куда более сложный процесс, чем увеличение просто раздела на локальном диске.

2. Эффективность сжатия.
Я уже рассказывал, что MinIO поддерживает сжатие. Но насколько оно эффективно и как быстро работает? Красивые цифры и графики.

3. Быстродействие.
Расскажу, как клиентам удалось под 100% удалось загрузить нам канал в одном из ДЦ, переливая данные с серверов в S3. При том, что для хранения мы используем обычные SAS диски.

4. Стоимость.
Мы используем не просто SAS диски. Мы используем б/у SAS диски небольшого объёма, но в большом количестве. Расскажу, как мы к этому пришли.

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

В процессе развития сервиса мы упирались в несколько проблем — ClickHouse не любит обновления, а для нас это критично. Объемы данных требуют буквальных объемов железа, и даже когда оно есть — мы упираемся в его производительность. Шардирование обратно зависимых таблиц тормозит скорость выдачи, а плагин укладывает БД запросами, когда должен отдавать сравнение исторических данных по товару за секунду.

По роду деятельности мы занимаемся аналитикой товаров на маркетплейсах, собираем очень много данных. Например, на WildBerries размещено 110 млн товаров, для каждого товара мы зайдем в его карточку, запишем данные (как он выглядит, какое у него текстовое описание, сколько остатков, какие были продажи, цвета, поставщик и производитель). Сохраним это в базу данных и повторим раз в сутки. Для четверти товаров мы это будем делать раз в три часа, а для 20-25 млн товаров — каждые 15 минут. Теперь добавим сюда Ozon, где товаров в два раза больше, Яндекс Маркет и параллельные разработки новых партнеров. Все это в сумме весит около 750 ТБ uncompressed-данных в ClickHouse.

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

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

Что слушатель вынесет с доклада?
- Рабочий подход к реализации гео резервирования PostgreSQL. Он успешно работает в продакшене для клиентского MDM у одного из крупнейших заказчиков.
- Пошаговое руководство по настройке Debezium, написанию sink-коннектора и адаптации Java-приложения для работы с несколькими базами.

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

Вопрос только, с какой СУБД это возможно. Требования известны:
- СУБД должна работа с 10К и большим количеством соединений на заурядном серверном оборудовании.
- СУБД должна работать как с диском, так и с данным в памяти.
- Эффективность работы дисковой СУБД с данными из кэша должна быть сравнима с показателями 'in-memory' решений.
- СУБД должна уметь масштабироваться на оборудовании с большим числом ядер.

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

Предлагаем рассмотреть СУБД Сокол в озвученных обстоятельствах в сравнении с другими системами.

СУБД Сокол является дисковой реляционной СУБД. Отличие в том, что все компоненты СУБД Сокол снизу-доверху реализованы на неблокирующих подходах. Цена доступа к данным из кэша СУБД Сокол минимизирована. Соединения обслуживаются в корутинах. Генерация кода SQL и процедур возможна, как в нативном, так и виртуальном наборе инструкций.

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

В докладе я расскажу про наши инструменты и модели, которые мы разработали и используем в Платформе Туту, чтобы планировать затраты на инфраструктуру и оценивать эффективность Платформы. Расскажу про систему внутреннего биллинга и как мы работаем с метриками Infra Cost, Infra Cost per Product.

Почему и как мы пишем на Rust новые утилиты массовой асинхронно-неблокирующей работы с AWS совместимыми облаками для Яндекс Облака и VK Cloud. Расскажем, как мы реплицируем события бакета s3 и как мы удалили несколько петабайт и миллиарды файлов на Rust, активно используя асинхронные сокеты и аллокатор jemalloc. Поделимся опытом, как правильно и быстро писать полезные утилиты, работающие с AWS совместимым API и как быстро прокачать стеку асихронного Rust разработчиков других стеков: Python, Java, PHP, JavaScript.

Т‑Банк успешно применяет Cluster API для управления жизненным циклом Kubernetes‑кластеров в гибридной инфраструктуре. С помощью множества существующих инфраструктурных провайдеров Cluster API можно применять в различных средах: GCP, bare metal, vSphere. Но мы столкнулись с проблемой отсутствия провайдера для Яндекс Облака и решили создать его с нуля, а затем выложить в open-source. Расскажу как он устроен, что должен уметь и на что обратить внимание при разработке.

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

Доклад для тех, кто задумывается или уже решился на интеграцию системы единого входа (SSO) в свою инфраструктуру.

Расскажу о текущих вариантах интеграции с сервисами машинного обучения - Airflow, MLFlow, Superset. Как сервисы поддерживают OpenID Connect, как разделяется авторизация пользователей и авторизация сервисов. Как внедрить решение в рамках платформы работающей в multitenant режиме.

Также обсудим интеграцию с сервисами мониторинга. Рассмотрим изоляцию пользователей Grafana по организациям при помощи Keycloak. И как внедрить Keycloak для сервисов, которые не поддерживают OAuth.

Строим платформу аутентификации

Сбор требований
Внутренние пользователи
Внешние пользователи
Выбираем решение
Почему keycloak?
Выбор источника правды для данных (IDM система)
Отказоустойчивость
Мультицод
Холодный и горячий резерв
Управление As a Code
Всё как код
Почему Pulumi
Создаём Self Service

Каждая ДЗО имеет свой стек технологий, и уровень зрелости IT-ландшафта. Но при этом, необходимость взаимодействия между друг другом никуда не делась. Как взаимодействовать, если с одной стороны REST, а с другой Kafka? Или RabbitMQ и Kafka? Под каждый поток данных писать адаптер? Расскажу, как мы в команде Integration Platform решили эту проблему с помощью Event Mesh. Теперь пользователю достаточно сформировать манифест взаимодействия, описать поток данных при помощи Json Schema и все. Система поднимет валидатор, коннектор, контролер… Упорядочит потоки, сформирует артефакты гарантированной доставки и запустит поток.

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

SaluteEye - платформа продуктовой аналитики. Собираем события с умных устройств Сбера и других источников, обрабатываем и предоставляем для аналитики и мониторинга технических показателей продуктов. Сегодня мы собираем и обрабатываем более 5 млрд событий в день и храним в быстром доступе аналитиков более 200 Тб, но так было не всегда...
В докладе поделюсь историей эволюции нашей системы и опытом внедрения ClickHouse для аналитики около реального времени. Зачем мы это делали, с какими вызовами столкнулись и что не учли, как контролируем рост и масштабируемся.

Мы расскажем о том, как мы 8 лет делаем AdGuard DNS — один из самых крупных в мире DNS-сервисов. В цифрах это 5 млн RPS, 100 млн активных пользователей и 10 ПБ трафика в месяц.

Рассказ будет включать историю от первых наивных попыток на Java, до масштабных решений сотней серверов, Anycast BGP и самописным сервером.

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

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

В докладе мы поделимся не только техническими деталями, но и историями, которые сделали наш сервис таким, какой он есть сегодня.

Для тех кто уже понял “Что такое SLI/SLO?” теперь станет понятно как это реализовать на практике.

Представь, ты инициативный разработчик или инженер. Ты уже узнал какая классная штука SLO и как оно помогает поддерживать работу сервисов и не замедлять разработку. Ты уже продал это руководству и команде - все жаждут увидеть это в дейтсвии. Ты полон энтузиазма и уверенности, что все быстро сделаешь, ведь, кажется, это делали много раз в разных комапниях, следуя заветам книг Google. Ты начинаешь искать готовый вариант, чтобы сделать первый MVP как можно быстрее. И понимаешь, что готового рецепта нет. Ты начинаешь поиск источников о практиках других компаний, инструментов для реализации и находишь частичные данные, но ты не знаешь насколько этот айсберг велик. А хочется по горячему, пока интерес не остыл, показать хоть что-то команде и принести пользу.

Поделюсь нашим опытом и наработкам. Я бы хотел все это знать и иметь в самом начала работы с SLO.

Какие механизмы беспарольной аутентификации можно встроить в PAM-систему: FIDO2, WebAuthn, одноразовые токены, биометрия, сертификаты. В чем риски безопасности и неудобство для пользователей паролей. Механизмы Passwordless (FIDO2/WebAuthn (аппаратные ключи), TOTP/push-токены, биометрия, сертификаты PKI). Реализация в PAM системах: протоколы (SAML, OAuth), гибридные сценарии, управление жизненным циклом. Кейсы: банки (FIDO2), DevOps (сертификаты), корпорации (биометрия + TOTP).

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

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

Вторая часть доклада будет посвящена выявлению и предотвращению скрап-атак. Расскажу о комплексных решениях защиты, потенциале AI в этой сфере и поделюсь несколькими кейсами достойной защиты – как простыми (коды и CAPTCHA), так и сложными (rate limiting и внедрение системы детекции аномалий).

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

До встречи!

Перевод платформы партнёрских отношений МТС с устаревшего внутреннего SDK и агента (покрывавшего все аспекты безопасности) на современный стек, когда есть 10+ сценариев аутентификации (в т.ч. Oauth2). Расскажу зачем и как:
- смотреть cheat sheet-ы от OWASP
- выбирать между client-side и server-side клиентом OAuth2
- применять шлюзы типа Spring Cloud Gateway или YARP и подобные
- писать аутентификационные фильтры для Spring Security
- писать аутентификационные фильтры для Spring Cloud Gateway
- проектировать структуру внутреннего токена и данных сессии
- планировать этапы перехода
Тезисы:
- опыт OWASP помогает и направляет
- легаси зерно незазорно повторить
- MSA накройте шлюзюм
- как правило, вам нужен server-side клиент OAuth2

Современный SOC (Security Operation Center) в BigTech-компании – это сотни систем, миллионы событий и десятки гигабайт событий в секунду. Не каждая SIEM-система способна выдержать такую нагрузку и легко масштабироваться под новые требования растущего бизнеса.

Расскажем, как нам удалось пересобрать систему, чтобы обрабатывать больше 2 млн событий в секунду и хранить суммарно больше 10 петабайт данных в сжатом виде, как мы пришли к идее создания потокового коррелятора на базе Apache Flink, как разработали DSL для написания правил на базе библиотеки Flink CEP и почему отказались от Flink SQL.

Рассмотрим несколько живых актуальных CVE
Будут примеры реальных свежих CVE от момента ресерча до их эксплуатации
Рассмотрим пример эксплуатации CVE без эксплоита (когда его нет в паблике)
Рассмотрим как оценивать CVE и какие параметры учитывать
Рассмотрим ресурсы и сканеры которые помогут выявить CVE
Напоследок пример 0DAY

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

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

Но главное, обсудим - возможно ли сделать не взламываемые системы имея свою аппаратную платформу?

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

Тема с Supply Chain уже который год не на слуху, закономерно развиваются и меры предотвращения таких атак. Одним из популярных фреймворков является SLSA, однако он достаточно абстрактен и не учитывает некоторые виды атак.

В докладе вы узнаете про фреймворк OSC&R, мы сравним его с SLSA и разберемся, какие конкретно атаки нам угрожают и что с этим делать.

Фаззинг API веб-приложений позволяет выявлять уязвимости, которые могут оставаться незамеченными при проведении статического анализа кода (SAST) или ручного анализа. В докладе будет рассмотрен наглядный пример.
Главная проблема фаззинга - это сбор данных. Для того чтобы выявить уязвимость, нужно собрать как можно больше входных точек, параметров запросов и самое главное поддерживать согласованность типов значений для этих параметров. В докладе рассмотрим различные источники, откуда можно добыть данные:
1) Openapi спецификации
2) Postman коллекции
3) Proxy (BurpSuite, proxify)
4) Логи (Elasticsearch)
5) Данные команд нагрузочного тестирования (ammo для yandex-tank)
В качестве движка сканирования рассмотрим open source инструмент от команды Project Discovery - nuclei, который поддерживает фаззинг и имеет community фаззинг шаблоны. Рассмотрим как конвертировать данные из упомянутых выше источников в формат, подходящий для nuclei, и запустить фаззинг.

Открываем SLA и видим... две девятки! три девятки! даже четыре девятки! лучше, конечно, пять девяток.

А что они значат?
Вот даёт один дата-центр SLA в пять девяток, а второй - "всего" четыре. Значит, первый лучше?
А если питание в ДЦ упадёт на десять секунд - сколько составит ваш простой?
А если сеть "моргнула" - за сколько ваше приложение сможет это понять?

Давайте разбираться (с)

Как варить Nginx, чтобы не только узнать о том, что прилетел DDoS, но и выдержать его.
- Что вообще можно поменять в systemctl и зачем?
- Мониторинг Nginx: почему VTS - это круто, но медленно, зачем нужен angie и какие ещё есть модули.
- Способы сбора access log.
- По каким ключам рейтлимитить? JA4 - что это за зверь?
- Кэш как таблетка от DDoS (но не серебряная пуля).

Мониторинг и телеметрия — неотъемлемая часть работы с высоконагруженными сервисами. Но что делать, когда готовые решения не подходят, а нагрузка растет? В этом докладе я расскажу, как мы выстраивали систему наблюдаемости в крупном e-commerce, используя OpenTelemetry и опенсорс-решения Qryn и Coroot.

Разберем наш путь:
• Почему отказались от Elastic APM и почему Grafana Tempo не справился с нагрузкой.
• Как MinIO не выдержал объема данных, переход на S3 привел к потере трейсов, а Qryn с ClickHouse помог решить проблему хранения.
• Как мы научились превращать трейсы в метрики с помощью VictoriaMetrics, построили дашборды в Grafana и вывели мониторинг на новый уровень.
• Как Coroot помог нам анализировать аномалии и быстрее разбираться с инцидентами.

Надеюсь, доклад будет интересен SRE и DevOps-инженерам, backend-разработчикам и техлидам.

Postmortem-анализ ключевой процесс для понимания причин сбоев и предотвращения их повторения на ИТ-ландшафте. ИТ-Системы становятся сложнее за счет потребления сервисов друг друга (особенно это критично в экосистеме). Ручной анализ сбоев таких систем требует все больше времени и ресурсов, и перестает соответствовать ожиданиям бизнеса: быстрое восстановление + глубокий анализ для предотвращения повторения.
В своем докладе поделюсь эволюцией этой практики у нас в компании: формализация подхода для экосистемы; уход от табличек Exсel/Word в пользу удобных инструментов; автоматизация простейших действий.
Все это позволило нам ускорить процесс анализа критичных инцидентов (с 4 – 6 часов до 1 -2 часов) за счет автоматизации рутинных действий. А введенный контроль качества проведенного анализа критичных инцидентов позволили продуктовым командам быстрее восстанавливать работу критически важных систем (на 26% год к году).
Сейчас, мы с уверенностью смотрим в сторону полной автоматизации PostMortem c использованием ML-инструментов, где автоматизация разбора инцидента будет дополняется экспертной оценкой наших инженеров.

Инфраструктура Екома и Райдтеха обеспечивает работу Яндекс Такси, Еды, Лавки и Доставки. Расскажу про структуру диагностического дашборда микросервиса в ней: что является наиболее полезным для диагностики, какие решения помогают расследовать инциденты, а какие нет.

Я работаю в команде сопровождения DataGrid (Apache Ignite Sber Edition).
Мы сопровождаем все кластеры DataGrid в Сбере, которых более 200, а High Season 2024 прошли "без единого разрыва".
За время работы мы исправили много прикольных проблем на проме и не только.
В докладе представлю postmortem наиболее интересных.
Расскажу, как мы находим корневые причины проблем, какую фактуру собираем для разбора проблем сложного Java-приложения.
Также поделюсь опытом и приемами по решению инцидентов и снижению влияния.

Будет практика. Настоятельно рекомендуем взять ноутбук.

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

Всегда хотели вжух-вжух и дебажить сети в этих ваших куберах и докерах, но не знали с чего начать? Приходите — покажем, расскажем и научим основополагающим вещам в этом нелегком деле!

На нашем workshop мы разберем те кирпичики, из которых построены все сети как под K8s, так и под стандартными облаками. Проведем лабораторные работы и выдадим домашнее задание по следующим темам:
* набор утилит iproute2 как основной способ взаимодействия с сетевым стеком linux;
* устройство сетевых namespace в ядре linux;
* виртуальные сетевые интерфейсы: виды, особенности, применение;
* OpenVSwitch: лучший сетевой швейцарский нож.

Мы в МТС давно поняли, что мониторинг отдельных хостов, приложений или баз данных не дает полного представления о качестве сервиса для пользователей и не прозрачен для менеджмента. Но переход к мониторингу полноценных бизнес-сценариев в масштабах 400+ продуктов оказался непростым и полным сюрпризов.

В докладе мы поговорим о том, как нам удалось описать ключевые сценарии использования наших продуктов с помощью 3500 индикаторов качества SLI и установить для них разумные целевые значения SLO. Поделимся опытом создания единого дашборд здоровья продуктов для менеджмента и собственного интерфейса для настройки расчета индикаторов на базе VictoriaMetrics и PromQL. Расскажем о том, как мы преодолели не только технические, но и организационные трудностях при внедрения нашего подхода в МТС.

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

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

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

Ни для кого не секрет, что современные архитектурные решения для ML, помимо мощностей ЦПУ, задействуют ресурсы тензорных или графических ускорителей. В итоге производительность упирается в пропускную способность шины, и не всегда перенос вычислений на ускоритель стоит свеч. Обсудим, каким образом эта проблема может быть решена в процессорах на базе архитектуры RISC-V и почему многие эксперты считают ее будущим для ML-приложений.
Но, чтобы будущее наступило, необходимы не только процессоры, но и работающая на них программная экосистема. Покажем, как удалось не только портировать на RISC-V важную составляющую ML-фреймворков — высокопроизводительную open source-библиотеку линейной алгебры Eigen, но и «малой кровью» оптимизировать ее под векторное расширение RISC-V RVV.

Посмотрим, что дает «ручная» векторизация на RISC-V и Arm, на примере двух широко используемых высокопроизводительных open source-библиотек линейной алгебры — Eigen и OpenBLAS. Поймем, почему автовекторизации не хватает для ускорения приложений AI/ML, AR/VR, CV, HPC. На графиках производительности увидим, далеко ли до roofline и где прячутся compute-bound и memory-bound алгоритмы.
Если вы
* не понимаете, зачем программисты продолжают оптимизировать руками в век стремительно умнеющих компиляторов, то вам сюда;
* находитесь в противоборствующем лагере и не отдаете производительность целиком на откуп компилятору, то вам тоже сюда;
* вообще никогда не задумывались о каких-то оптимизациях и не понимаете, из-за чего весь сыр-бор, то тоже приходите!
Даже если вы не знаете, кто такая линейная алгебра, больно не будет.

В 2019 году мы начали предлагать в аренду клиентам выделенные серверы на базе десктопных процессоров Intel Core i9-9900K. И через некоторое время столкнулись с тем, что процессоры сильно перегреваются в 1U корпусе и серверы выходят из строя. Стандартное воздушное охлаждение не справлялось. Увеличивать размеры корпусов мы не хотели — теряли в плотности размещения серверов в стойке, а, как следствие, деньги. Это заставило нас искать нестандартные решения в направлении жидкостного охлаждения.

Путь оказался тернистым. Первые решения от поставщиков с кастомной СЖО, казалось, решили проблему, но на самом деле только отсрочили ее. Через пару лет серверы стали массово выходить из строя. Это привело к длительным простоям оборудования и необходимости замены клиентских серверов. Самостоятельные попытки решить вопрос также не приводили к успеху. Все это подтолкнуло нас к более глубокому изучению вопроса: разобрали по “косточкам” всю систему охлаждения, проанализировали конструктивные особенности, технические ошибки, изучили опыт геймеров и кастомеров, и в итоге создали собственную систему — надёжную в использовании и простую в обслуживании.

В докладе расскажем:
Зачем мы начали ставить десктопные процессоры в клиентские серверы, в то время, как конкуренты нас осуждали
Как решали проблемы с СЖО, чем нам помогли и помешали поставщики
На какие «грабли» наступили и что нужно было делать по-другому
Happy end или очередной этап развития: как дело обстоит сейчас и что мы планируем делать дальше

Представьте: 30+ устройств как отечественных, так и зарубежных, с разной архитектурой и форм-фактором — IP-камеры, электросчётчики, планшеты, одноплатные компьютеры и т.д. Все они разбросаны по офису словно детали пазла, из которых не складывается единая картинка. Как превратить это в цельную тестовую лабораторию с удалённым управлением, Wi-Fi и автотестами?
Мой доклад — это история инженера-новичка, который за год собрал (не имея опыта) стенд-трансформер, переживший миграцию устройств из Москвы в Томск, победил «сетевой адресный апокалипсис» и подключил их к единой тестовой межрегиональной инфраструктуре.
Расскажу, как создать «умную» инфраструктуру с нуля, даже если вы, как и я, также больше тестировщик, чем сетевик. Поделюсь реальным опытом того, как обуздать хаос и перевести его в структуру, способную эффективно решать задачи по тестированию ПО из любого офиса компании.

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

Многим разработчикам приходится решать задачи по оптимизации различных бизнес процессов. В данном докладе спикер расскажет как ускорить вставку и обновление данных при помощи популярного фреймворка Spring и одной из самых популярных БД PostrgeSQL.

Разногласие в дефолтных настройках TCP и CNI может приводить к различным сайд-эффектам в трафике системы и приводить к ошибкам в приложении в kubernetes-кластере. Но есть случае, когда сайд-эффект встречается редко и приводит к даунтайму приложения.
Расскажу про инцидент с зависанием на 15 минут в нашей системе. Какие особенности работы TCP, gRPC Keepalive мы подчернули для проверки статуса соедиения. В чем именно нам не помог ServiceMesh, на который мы рассчитывали.
И какую еще настройку стоит подкрутить у вас в микросервисах или все же использовать ServiceMesh

Как мы разработали систему OTA обновления прошивок на 30000 устройств

1. Введение:
- Необходимость собственной системы обновления прошивок складских устройств.
- Требования к системе: риски и ограничения при работе в закрытом контуре
- Готовые варианты "из коробки", и почему мы пришли к самописному решению.

2. Выбор стэка и подготовка к разработке
- Почему мы выбрали Python
- Кеширование в Redis
- S3 (CEPH) для хранения файлов прошивок
- Микросервис или монолит

3. Архитектура системы:
- Структура микросервиса по заветам дядюшки Боба. Чистая архитектура, и с чем её едят
- Redis, Postgres и S3, взаимодействие, и при чем тут паттерн Repository
- React Admin для быстрой админ консоли. Когда бэкендер пишет фронт, история успеха
- Контракты между бэкендом и приложением на устройстве

4. Релизный цикл
- Построение релизного цикла
- Как мы настроили выкатку канареечных релизов
- A/B тесты
- Откат прошивки в случае критического бага

5. Масштабирование и нагрузка
- Как мы разработали очередь обновления для устройств
- Как мы разнесли систему обновления на два датацентра
- От десятка устройств к нескольким тысячам, от ручного контроля к автоматизации управления
- Сложности доступа в закрытый контур, находим общий язык с конечным пользователем

6. Заключение.
- Чему мы научились пока разрабатывали систему OTA обновления прошивок
- От Системы обновления прошивок, к собственной экосистеме.

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

В своем докладе я расскажу про:

- Первую версию архитектуры, державшую нагрузку в тысячи раз меньше текущей;
- Сложности, с которыми мы столкнулись. В частности - как положили kafka для части сервисов;
- Развитие архитектуры, вплоть до текущей версии, выдерживающий 1 500 000 RPS;
- Как мы ежедневно записываем 20 терабайт трафика;
- Зачем мы это делаем.

– Информационная безопасность и конфиденциальность данных: похожие понятия, но разные акценты;

– Защита данных во время использования: централизованный и децентрализованные подходы;

– Разные судьбы яиц, сложенных в одну корзину, или основные проблемы централизации;

– Децентрализация: как делать математику с числами, не глядя на сами числа, или Multi-Party Computation (MPC, совместные конфиденциальные вычисления);

– Пример применения MPC: как Bloomtech сделал первую в РФ (а, может, и в мире) межбанковскую платформу конфиденциальных вычислений, которая работает на проде;

– Цена конфиденциальности: проблемы технологии совместных конфиденциальных вычислений вчера и сегодня;

– Перспективы технологии: MPC как неотъемлемая часть цифровой инфраструктуры и стандарт для информационных коллабораций;

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

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

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

Система дополнена комплексными процессами и командой специалистов, которые используют распределенную карту для создания HD-карт высокого разрешения. Эти карты играют ключевую роль в модуле планирования, помогая автономным транспортным средствам выполнять точные и безопасные маневры.

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

В мир развития технологий в космосе поход с обработкой данных на Земле уже устарел. Пользователям нужна информация с минутными задержками, а не ждать сутки. Законы физики не позволяют это сделать, так как для обработки данных надо передавать огромные массивы по нестабильным каналам связи, да ещё и на ограниченный по периодам наблюдений наземный сегмент. Я расскажу про то, как трансформируется индустрия космических датацентров, при чём тут лазеры, реален ли ЦОД в космосе и надо ли охлаждать сервера если в космосе очень холодно. Конечно же мы обсудим какие страны какие проекты делают, российские космические ЦОДы и что могут делать энтузиасты для космических вычислений.

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

Отдельное внимание уделим процессу разработки высоконагруженных систем в автомобилях, от анализа рынка до тестирования на реальных примерах. В частности, мы погрузимся в проблематику того, как 17 различных высоконагруженных систем уживаются в одном автомобиле на примере адаптивного круиз-контроля. Несмотря на то, что пользователю могут быть важны всего 2-3 функции, он получает много дополнительных возможностей, что создает сложности в их восприятии и использовании.

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

Определение параметров устройств в большой системе становится все сложнее - браузеры перестают отправлять всю информацию в стандартных заголовках (борьба с трекингом пользователей), нужная информация не специфицирована и требует постоянного обновления, новые модели телефонов выпускаются постоянно

В докладе расскажу про то:
- Какие источники данных сейчас мы используем и как с ними работать по стандарту
- Как мы в Яндексе решаем эту задачу на миллионах RPS (алгоритмы и их архитектурное применение)
- Обсудим технические тонкости: оптимизации алгоритмов, негоциацию параметров в установлении TCP сессии и почему это не работает, особенности кэширования в разных точках применения
- Как мы поддерживаем актуальное состояние информации об устройствах

Как выглядят исходные данные со спутников и какую обработку им необходимо пройти до их публикации на Яндекс.Картах?
Почему нам приходится по пикселям пересобирать спутниковые снимки? И как в этом помогает рельеф земли?
Посмотрим на такие технологии как: Cloud Optimized GeoTIFF, Pansharpening, RPC-трансформации. Разберём возникающие проблемы и как мы их решаем.

- Мир шоссейно-кольцевых гонок
- Суть дисциплины
- Суть мотоспорта: сочетание технической подготовки мотоцикла и скилла пилота
- Техническая часть. Чем гоночный мотоцикл отличается от обычного (спойлер: почти всем)
- Пилот и умение управлять мотоциклом. Из чего складывается пилотирование.
- К чему приводят критические ошибки при пилотировании, помимо ухудшения времени круга. Самые распространенные виды падений
- Данные не врут. В отличие от пилотов мотогонок 😃
- Необъективность ощущений пилотов. Как мы оцифровываем скиллы.
- Датчики, которые мы ставим
- Метрики, которые мы собираем
- Примеры графиков, основанных на реальных данных
- Разбор телеметрии. Что мы видим на графиках, и как картинки на экране приводят к победе в чемпионате
- Пример 1. Закрытие газа
- Пример 2. Улучшение техники торможения, сдвиг точки торможения (1 поворот трассы Igora Drive)
- Пример 3. Изменение траектории и увеличение скорости прохождения поворота (4 поворот трассы Moscow Raceway)
- Заключение. Мотоспорт и снимаемые метрики как метафора реальному бизнесу

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

Low-code и no-code решения привлекают своей простотой, вроде как устраняющей нужду в отладке, трассировке, профилировании и других инструментах "классического" программирования. Но в масштабах реальных промышленных проектов без них оказывается трудно, ведь иначе как понять, что делает та или иная low-code конструкция под капотом? И, что особенно важно, как она ведёт себя под нагрузкой?

В докладе мы посмотрим на имплементацию этих функций на примере российской IoT-платформы AggreGate, где встроенный язык выражений был наделён средствами трассировки и визуализации, позволяющими low-code разработчикам видеть ход и результаты выполнения их команд на всех этапах от редактора до production. Особый акцент сделаем на производительности:
построение/слияние/кэширование деревьев разбора, ленивая загрузка результатов, троттлинг вычислений – словом, всё, что позволяет сохранить сервер живым, а отладку – пригодной даже при сотнях тысяч RPS.

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

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

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

Бонус: алгоритмы на графах: быстрый алгоритм в один поток на процессоре против отлично параллелящегося, но медленного алгоритма на видеокарте, а также data race, который не влияет на ответ.

Как оценивается эффективность адаптивного стриминга в VK Видео? Каково при этом визуальное качество видео? Насколько нагревается устройство при просмотре видео? На эти и многие другие вопросы поможет ответить Лаборатория качества VK, которую мы создали на базе одной из крупнейших видеоплатформ России.
В докладе я расскажу, чем занимается Лаборатория и какие подходы применяются для оценки качества работы VK Видео. Подробнее остановимся на следующих моментах:
- познакомимся с основными метриками перформанса клиентских приложений и методиками их оценки;
- посмотрим на видео через метрики, способные измерить качество картинки;
- узнаем, как контролировать потребление батареи мобильных устройств с учетом высокого энергопотребления во время воспроизведения видео.

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

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

Мы делаем Low code-решения, импортозамещающие иностранные инструменты - Hasura, Firebase, Supabase, Strapi и так далее. Инструмент позволяет генерировать GraphQL-сервис на основе существующей базы данных или создать новую, объединять уже существующие схемы, применять правила безопасности.
В докладе расскажем про путь, который мы прошли, в аспекте ключевой истории - эффективного использования GraphQL.
Почему это может быть полезно как разработчикам, так и бизнесу.

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

Также в докладе будет погружение в две важнейших и сложнейших темы - управление транзакциями (оптимистичные и пессимистичные блокировки) и безопасность - RBAC, ABAC и OpenID.

Завершение доклада будет посвящено федерации GraphQL (объединение и выравнивание микросервисов по спецификации) и AI-помощнику.

В рамках доклада расскажу:

1. Вредные советы по работе с ClickHouse — поделюсь полученными на собственном опыте знаниями, распространёнными ошибками при создании и разработки на CH-кластере. Расскажу, к каким последствиям приводят ошибки и как их избежать.

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

3. Результаты первого квартала – раскрою, как мы вышли на стабильность кластера в 99,9% и разделили большой кластер между аналитическими командами.

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

В 2018 году в Авито появилось in-house решение для автоматизации A/B-экспериментов. За несколько лет платформа выросла в зрелый продукт, с помощью которого производятся почти все релизы нового функционала Авито — это 4000+ экспериментов в год.

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

* Каждый день в Авито активны сотни экспериментов
* Объем сырых данных (кликстрим и тд) исчисляется миллиардами строк
* В одном эксперименте — до 30 тыс. метрико-разрезов
* На выходе имеем около полу-миллиарда рассчитанных стат. тестов (дисперсии, p-value и тд)

При этом весь compute мы успеваем провести за несколько часов на относительно небольшом (в масштабах Авито) кластере Trino. Расскажу об основных способах оптимизации, которые позволяют эффективно утилизировать вычислительные ресурсы.

Отношения между Spark и Parquet (и другими колоночными форматами) можно вкратце описать так:
– Мама, можно нам домой doExecuteColumnar?
– У нас есть дома doExecuteColumnar.
*doExecuteColumnar дома: ColumnarToRowExec.*

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

Чтобы понять причины такого поведения и выяснить, можем ли мы его контролировать, нам надо сделать шаг назад и разобрать текущую модель вычислений в Spark: данные (строки, колонки, партиции, JVM-объекты, внутренние структуры и типы даных Spark, Arrow) и их обработка (Columnar Execution, WholeStageCodeGeneration), связав эти понятия в единую картину. Рассмотрим, как из примитивных конструкций формируются распределенные коллекции, и как нам их приручить, чтобы писать более оптимальные приложения. Обсудим нюансы и детали связанных концепций: кеширование, шаффл, некоторые трансформы. В конце проведем небольшое сравнение архитектуры Spark и смежных фреймворков: Databricks Photon, Apache Comet, Apache Gluten.

Стриминг активно используется платформой ОК уже более 10 лет, и за это время используемый нами фреймворк успел значительно вырасти и измениться.
В этом докладе я расскажу о том, как устроен стриминг в ОК, а также о всех патчах и фейлах, возникших в процессе обновления стримингового фреймворка 10-летней давности: об отсутствии обратной совместимости, проблемах с партиционированием, сложностях во взаимодействии с Apache Kafka, Apache Hadoop YARN и о том, как с этим боролись.

1. Использование Debezium и kafka-connect для репликации
- Использование Kafka-Connect для доставки изменений из базы данных в топик Kafka

2. Роль Heartbeat, и как он решает проблему отставания слота репликации
- Heartbeat облегчает мониторинг Debezium.
- Решение проблемы отставания в PostgreSQL при чтении части таблиц.

3. Сигналы в Debezium: новый уровень управления снепшотами
- Современный подход к созданию снепшотов.
- Снижение нагрузки на БД при их использовании.
- Гибкость управления: запуск, пауза, отмена.
- Прозрачный мониторинг снепшотов

Тезисы:
География X5 Group – вся Россия: от Калининграда до Владивостока. 30 000 объектов (магазины, дарксторы, постаматы 5post, курьеры) завязаны на 80 распределительных центров (РЦ) в 8 федеральных округах.

Задача – интеграция данных из WMS (системы управления РЦ) в дата-платформу с учетом ключевых требований:

1️⃣ Минимальная латентность – секунды/минуты для оперативных дашбордов и интеллектуального алертинга (уведомления о сбоях в процессах).
2️⃣ Гибкость интеграции – потоки данных должны автоматически адаптироваться к изменениям модели данных источника.
3️⃣ Надежность – временные сбои в сети и недоступность БД РЦ не должны приводить к потере данных.
4️⃣ Минимальная нагрузка на источники – без доработки ИТ-инфраструктуры РЦ.
5️⃣ Легкое тиражирование – подключение новых РЦ без участия дата-инженеров.
6️⃣ Open Source – только технологии с открытыми лицензиями.

Решение – интеграционный механизм на базе Debezium, Flink, Kafka, с построением NRT-витрин в S3 (Iceberg) через Trino.

Что расскажем на докладе:
🔹 Поиск оптимальной архитектуры
🔹 Результаты нагрузочных тестов и пилотов
🔹 Унификация решения для масштабирования на все РЦ (включая новые)

Data Lake является хранилищем сырых данных в Аналитической платформе X5 . Уже много лет данные в него загружается самописным фреймворком при помощи Sqoop. Это крайне простая и удобная утилита, отлично справляющаяся со своими задачами. Мы даже её портировали на Hadoop3, хотя для него нет готовых сборок, но она больше не развивается и уже морально устарела.
Было принято решение найти ему замену, но как оказалось Sqoop не оставил приемников.
Конечно же есть универсальный швейцарский нож Spark который справится с любыми задачами. Но после использования элементарной утилиты не хотелось утяжелять решение.

Решением ситуации для нас было использовать Trino. Он активно используется в Big Data стеке для построения как распределенынй SQL движок, но и отлично подходит для достаточно простых задач интеграции. Это конечно не консольная утилита для загруки, но ключевым приемущестовом стала настройка интеграции при помощи SQL.

В докладе расскажу вам о нашем опыте применения Trino для загрузки данных из других источников

Мы в Сбере разрабатываем платформу для построения рекомендательных сценариев для всех компаний экосистемы начиная от онлайн-кинотеатров до мира e-commerce. За прошедшие годы мы разработали универсальные подходы для создания персонализированных рекомендаций. И в докладе поделюсь аспектами MLOps-архитектуры для запуска рекомендательных сценариев:

- Как выглядит cloud-native платформа для построения production-ready рекомендательных сценариев и почему это важно
- Какие MLOps инструменты нужны для быстрого запуска достаточно сложных рекомендательные сценарии (от инструментов для обработки больших данных до Feature Store и онлайн моделей)

Осенью этого года мы запустили одну из самых сильных языковых моделей, говорящих на русском - GigaChat MAX
Эта модель - синтез самых современных технологий распределенного обучения и качественных данных.
Мы много работали над качеством обучения, его скоростью и стабильностью и хотим поделиться результатами: мы расскажем об оптимизациях NCCL, технологиях распредленного обучения и тренировке модели в пониженной точности

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

Ключевая проблема:
Как гарантировать работодателям увеличение просмотров вакансий в 3–10 раз (платный KPI), не нарушая релевантность выдачи для пользователей, если:

Просмотры зависят от позиции, но нет формулы «позиция → клики»;

Статические бусты приводят к перегреву/исчезновению вакансий.

Решение:
PID-регулятор, заимствованный из инженерных систем (температура, круиз-контроль), адаптированный для ранжирования в реальном времени.

Технические компоненты:
A/B-тест для измерения «ненаблюдаемого»:
5% трафика (контроль) → базовый уровень просмотров для каждой вакансии.
Цель для платных тарифов: Базовый уровень × 3 (или 10).

PID-логика:
P (ошибка «цель vs факт»), I (история дефицита), D (предсказание перебуста).
Формула коэффициента: U(t) = K_p × e(t) + K_i × ∫e(t)dt + K_d × de(t)/dt.

Архитектура:

Нормирование релевантности (скоры → [0,1]), фичстор (история просмотров, PID-параметры), стартовый буст для новых вакансий через сигмоиду.

Результаты для highload-систем:

KPI для бизнеса:
89% вакансий на тарифе ×3 и 94% на ×10 выполнили цели.

Для пользователей:
CTR +1.5%, время отклика ↗7% (более релевантный выбор).

Применимость подхода:

Класс задач: Динамическое ранжирование с бизнес-ограничениями (просмотры, конверсии, доход).

Стек: Высоконагруженные поисковые системы, где требуется баланс между монетизацией и UX.

Ограничения: Требует A/B-тестов для калибровки и точного измерения «ненаблюдаемых» метрик.


Почему это будет в докладе:

Реальные кейсы «танцующих» вакансий в выдаче (графики + логика PID).
Архитектурные решения для работы в реальном времени.

Сравнение PID vs ML: когда что выбрать.


Ключевой вывод:
PID-регулятор — интерпретируемый и ресурсоэффективный способ балансировки в highload, не требующий глубокого ML. Но гибрид «PID + прогнозирование» — следующий шаг.

В докладе я расскажу, что такое состязательные суффиксы, почему любая LLM им подвержена, как самостоятельно создать такой суффикс и почему OpenAI не считает это угрозой безопасности. Также я поделюсь результатами исследования о переносимости суффиксов между различными моделями и дам советы по тестированию ИИ-приложений на основе LLM.

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

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

Зачем бизнесу нужна автоматизация измерений габаритов и веса товаров? Как точные и быстрые измерения помогают сократить затраты и оптимизировать логистику.

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

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

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

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

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

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

На воркшопе мы рассмотрим различные виды эмбеддингов и применим их для построения векторного поиска и простой системы рекомендаций.

Классификация эмбеддингов(Текстовые, Звуковые, Изображения, Составные эмбеддинги)

Операции с эмбеддингами:
Суммирование и кластеризация для выявления групп и схожести данных.

Эмбеддинге в поиске:
Делаем векторный поиск на коленке на базе Qdrant

Рекомендательные системы:
Векторная рекомендательная система за 5 минут

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

В докладе я расскажу, как мы создали трейдер-бот для управления тысячами рекламных кампаний на основе data-driven подхода с целью максимизации ключевых бизнес метрик на платформе Телеграм. Бот в режиме реального времени заменяет собой 100% функционал множества людей, или может быть использован в качества "цифрового консультанта". В основе лежит комплексная архитектура со своими контурами хранения, мощным ML движком и интеграция с Telegram Ads API.

В рекомендациях Wildberries большое количество DS-ов (200+ сотрудников), много команд и широкий спектр задач: LLM, NLP, Computer Vision и другие. Поэтому необходимо унифицированное решение, чтобы дата саентисты могли в автоматизированном режиме работать с какой-либо платформой: ставить модели на обучение, на инференс и так далее. За основу для MLOps-платформы был взят Airflow в связке с Kubernetes.
В докладе будут рассказано с какими "боттлнеками" приходится сталкиваться при разработке масштабируемой платформы, а также подробно будут рассмотрены решения двух важных задач:
— Масштабируемый способ хранения в сложной топологии секретов Vault и подключение их в Kubernetes поды задач Airflow.
— Защищенный способ реализации запуска задач в нескольких кластерах Kubernetes

Основные задачи, которые нужно решать полноценной стриминговой платформе - это хранение событий, доставка этих событий до хранилища, ну и конечно обработка c возможность хранения состояния(так называемый stateful processing). Разберём как может выглядеть архитектура потоковой обработки данных на референсах от AWS и Microsoft. И построим свою архитектуру из open-source компонент, таких как Kafka Connect, Apache Kafka и Apache Flink.

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

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

Что спрятано под кнопкой "Я согласен", которую многие нажимают не читая, когда обращаются к AI-помощникам?
В докладе планирую рассказать о том, кому обычно принадлежат права на код, написанный самостоятельно, и разобрать важные моменты принадлежности авторских прав на код, написанный с помощью искусственного интеллекта.

Основано на лицензионных соглашениях ChatGPT, GigaChat, Copilot, Codeium, CodeWhisperer, Gemini.
Путей обхода - не будет.
Подводные камни - будут.