Доклады секции "Архитектура"

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

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

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

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

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

Работаете с высоконагруженными брокерами сообщений? Планируете масштабироваться или уже наступали на грабли при расширении? Этот доклад — для всех, кто хочет увидеть как по-разному масштабируются два мощных брокера сообщений: Apache Kafka и YDB Topics.

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

Закончу доклад сравнением YDB Topics и Apache Kafka и сравнением сценариев, когда использовать один, а когда другой.

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

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

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

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

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

В своем докладе я опишу опыт внедрения распространения данных по паттерну EventStreaming для наполнения DataLake в ecom.tech. А именно:
* почему мы в целом пошли в эту историю и какие проблемы решали;
* как мы подошли к задаче в первый раз, почему отказались от общепринятого CDC (Postgres WAL / Debezium), какие инструменты были выбраны и почему;
* где и по какому принципу хранили сначала, храним сейчас и согласуем схемы данных;
* как организовывали кросс-ДЦ-распространение схем и данных;
* почему далеко не все продуктовые команды в восторге от внедрения похода, и как мы адаптировали подход после сбора критики;
* почему EventStreaming может быть не лучшим вариантом для вашего продукта, какие есть стратегии мягкого внедрения или замещения в целом.

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

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

Ключевые стратегии чанкинга:
- Fixed-Size: делит текст на чанки фиксированного размера (например, 4 слова);
- Sentence-Based: разбивает текст на чанки по предложениям;
- Semantic-Based: группирует предложения по семантической схожести, объединяя их в чанки;
- Recursive: делит документ на чанки, рекурсивно разбивая их до выполнения условий (например, минимальный размер);
- Sliding Window: создает чанки с перекрытием, сдвигая окно на заданный шаг;
- Hierarchical: организует чанки по иерархической структуре документа (например, заголовки, абзацы);
- Topic-Based: группирует предложения в чанки на основе тем, определенных с помощью тематического моделирования;
- Modality-Specific: разбивает документ на чанки в зависимости от типа контента (текст, изображения, таблицы);
- Agentic: использует агента для принятия решений о стратегии разбиения и создания чанков;
- Hybrid Approach: комбинация NLTK-статистик и нейросетевых моделей.

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

Результаты:
- ускорение индексирования в 2 раза (с 10 сек./док. до 5 сек./док.) при обработке 50K PDF-документов;
- повышение recall на 12% в тестах с медицинскими отчетами;
- снижение стоимости инференса Llama/Qwen за счет уменьшения избыточных чанков.

AsyncAPI — это как Swagger, только для асинхронного мира событий, очередей и сообщений. И если вы работаете с Kafka, Websockets или любыми другими event-driven-системами, этот стандарт может помочь вам в описаниях этих взаимодействий.

В докладе разберем практическое применения AsyncAPI, какие есть инструменты для работы с ним и как применить подход APIFirst.

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

В докладе расскажу про:
* проблемы крупного монолита при переезде в облако;
* переход от stateful к stateless;
* способы транспорта данных;
* оркестрацию применения данных в облаке;
* шардирование сервиса в облаке.

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

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

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

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

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

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

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

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

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

Погрузимся в тему тюнинга Kafka для экстремальных нагрузок. Поговорим про пакетную обработку, pipelining, компрессию данных (compression.type).

Далее оценим влияние типа сериализации на производительность передачи данных. На основе результатов бенчмаркинга «json vs protobuf», полученных с реального прод-кластера, оценим влияние параметров batch.size, linger.ms и compression.type на RPS.

В самом конце проведем обзор архитектуры большой высоконагруженной информационной системы на примере топологии геокластера, построенного на базе 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-моделей.

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

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

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

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

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

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

В сетях ЦОД и в Интернет часто используется Anycast-маршрутизация трафика для распределения нагрузки на уровне сети, это удобно и масштабируемо, позволяет экономнее расходовать IPv4-адреса.

Сервисы для B2B-клиентов/партнеров VK Tech, размещаемые в ЦОД, имеют дело с конфиденциальной информацией (например, перс. данные), которую нужно защищать по закону. Требования ИБ «закрываются» шифрованием с применением туннелей на базе российских ГОСТ-алгоритмов. И тут нас подстерегает проблема совместимости Anycast и VPN-криптошлюзов.

Архитекторы и сетевые инженеры вынуждены чем-то жертвовать и, как результат, страдает масштабируемость, неоптимальная утилизация производительности, «растянутые» между ЦОД кластеры и/или ручная схема обеспечения отказоустойчивости.

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

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

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

В рамках доклада я разберу реальный архитектурный путь от сбора и постановки требований до работающей системы. На конкретном примере покажу, как приложение обрастает бизнес-функционалом. Как новые требования доказывают правильность выбранных решений и влияют на поиск и выбор новых. Как одно техническое ограничение создает «паттерн», влияющий на всю архитектуру. Последовательно будут разобраны: паттерн SAGA и шаблон Event Sourcing'а, изоляция асинхронного сбора данных и планировщик отложенных задач. Подсвечу особенность работы с Кафкой под нагрузкой и почему оркестраторов много не бывает.

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

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

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

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

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

Миллион мастер-реплик в проде? Встречаем сетевой консенсус Ethereum 2.0 — самой децентрализованной базы данных в мире.

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

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

При росте популярности приложения растет и нагрузка на сервис. Я расскажу, как мы в компании МТС Юрент справлялись с нагрузкой данных от самокатов при росте парка.

В докладе затрону:
* архитектуру группу сервисов кластера IоT;
* какие сложности были, и какие принимали решения при росте 10 тыс., 50 тыс., 100 тыс. устройств;
* с какими ограничениями столкнулись в базе данных MongoDb;
* как Redis помог выдерживать текущие нагрузки.