Доклады

UUID — отличный кандидат на Primary Key в новой сущности вашего сервиса. Множество систем его используют, но он имеет свои недостатки, которые должны быть решены в версиях 7 и 8, RFC для которых почти принят. При реализации этого RFC для PostgreSQL я погрузился в детали, которыми хочу поделиться.

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

Начнем с того, почему мы пришли к этому, расскажем немного теории о резервном копировании MongoDB.

Далее расскажем, с чем мы по пути столкнулись, какие проблемы мы решали, как писали Wal-G. Также расскажем о неожиданных последствиях физических бэкапов и том, как это нам позволило реализовать резервное копирование (и восстановление) шардированных кластеров MongoDB.

Stateless Postgres Query Router — система шардирования PostgreSQL-кластера с открытым исходным кодом. Роутер, главный ее компонент, по запросу понимает, на каком конкретном PostgreSQL-кластере надо выполнить транзакцию или запрос.

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

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

Рассматриваются базовые проблемы ненадёжной передачи данных и способы борьбы с ними: повторы и дедупликация. Далее на примере паттернов микропроцессорной архитектуры иллюстрируются гарантии доставки: at-most-once, at-least-once, exactly-once.

В заключение на примере двух брокеров очередей сообщений — Kafka и YDB Topics — показываются детали реализации гарантий доставки.

Мы расскажем, как интегрировали ClickHouse в ядро нашей BI-платформы Visiology для использования в кейсах Self-Service-аналитики и ad-hoc-запросов, где пользователи могут самостоятельно загружать и анализировать большие объемы данных, не привлекая разработчиков. Такой сценарий работы пользователей потребовал от нас разработки автоматизированной системы управления ClickHouse.

Будут рассмотрены:
* архитектура платформы и архитектурные решения;
* процесс загрузки данных в ClickHouse: автоматизация подбора индексов и движков, преобразование исходных данных для эффективной обработки ad-hoc-запросов;
* разработка транспайлера запросов аналитического движка DAX (Microsoft) в ClickHouse SQL;
* алгоритмы оптимизации SQL с учетом специфики ClickHouse.

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

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

В рамках доклада мы рассмотрим три основных варианта развертывания:
* Redis Standalone,
* Redis Sentinel,
* Redis Cluster.

Остановимся на особенностях работы Redis для каждой топологии и поговорим об отличиях при работе с Redis Standalone и Redis Cluster со стороны приложения.

При проектировании высоконагруженных систем нельзя просто взять и пройти мимо темы отказоустойчивости кластера Redis и его внутреннего устройства.

Говоря про хранение данных в Redis, важно поговорить и про сами данные. Сделаем обзор поддерживаемых типов данных, особое внимание уделим интересным структурам данных — Streams, Sorted Set, HyperLogLog, Bitmap. На реальных примерах из жизни посмотрим, как эти структуры данных можно эффективно использовать для решения задач.

Также затронем паттерны и антипаттерны использования Redis, особенно в части использования SCAN, KEYS, DEL, EXPIRE и влияния на производительность. Приоткроем завесу тайны и узнаем, какие removal policy реализованы в Redis.

Поговорим про механизмы восстановления данных на базе RDB и AOF и влияние на производительность. Какой выбрать для вашего конкретного проекта и в какой конфигурации?

Поднимем тему тюнинга как в части параметров ОС, так и в части тонкой настройки самого Redis, например, maxmemory, maxmemory-policy, lfu-decay-time. Коснемся политик вытеснения (noeviction, lru, lfu, random, ttl), которые реализует Redis.
Проведем сравнение с конкурентными продуктами, которые позиционируют себя как drop-in replacement, на примере Dragonfly и оценим его готовность к промышленному применению.

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

В 2021 году мы начали разработку собственного Software-Defined Storage (SDS) для публичного облака с нуля. За два года мы сделали решение, которое успешно вывели в production платформы Evolution Cloud.ru и которое хранит петабайты пользовательских данных. Наш SDS предоставляет собой блочное, объектное и файловое хранилище. В этом докладе мы поговорим про архитектуру самого нижнего блочного слоя и с какими сложностями мы столкнулись при его разработке.

В докладе я расскажу:
* из каких компонентов состоит публичное облако и зачем там SDS;
* как архитектурно устроен наш блочный SDS;
* как сетевые диски подключаются к виртуальным машинам пользователя;
* с какими проблемами мы столкнулись при использовании Erasure Coding для кодирования данных и как мы решили эти проблемы.

Одной из ключевых характеристик системы хранения данных является величина задержек при работе с данными, так как эти задержки могут напрямую влиять на производительность клиентских приложений: гипервизоров, файловых хранилищ, бизнес-приложений. Для сокращения задержек СХД оснащаются большими объемами DRAM-памяти, отведенной под кэш пользовательских данных.

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

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

Объемы обрабатываемой информации неуклонно растут, и распределенными системами уже сложно кого-либо удивить. В мир СУБД этот тренд проник с небольшим опозданием, но распределенных СУБД на рынке уже немало.

Отличаются они друг от друга почти всем, но в первую очередь нас интересует два основных компонента — это движок локального хранилища и кластер-менеджер. Так, например, в CockroachDB локальным движком выступает RocksDB, а консистентность кластера обеспечивает алгоритм Raft. В Cassandra ставка сделана на eventual consistency.

Команда Picodata долгое время разрабатывала и внедряла решения на основе Tarantool, а теперь мы переосмыслили его в cluster-first-парадигме. В докладе я расскажу о продуктовых и архитектурных решениях, которые этому сопутствовали:
* кластер-менеджер мы построили на Raft без использования внешнего state provider и объединили в нем хранение топологии и хранение схемы данных;
* для хранения данных мы используем глобальные и шардированные таблицы, а доступ к ним реализуем посредством языка SQL;
* за компанию реализовали близкие к стандарту средства управления доступом;
* а для расширения функциональности предоставляем Plugin API.

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

Мы в МТС используем для этих целей агент telegraf и большой кластер Victoria Metrics, принимающий 10+ млн сэмплов в секунду. В докладе я расскажу, как мы реализовали возможность централизованного управления конфигурацией агентов, удобный интерфейс для настройки алертинга и правил сбора метрик. Рассмотрим, как менялась архитектура нашего решения с ростом нагрузки, как мы боролись с отставанием и потерей данных. Обсудим, как это позволило нам собрать все метрики в единое хранилище и построить дашборды здоровья по ключевым продуктам.

Vault — стандартный инструмент для хранения секретов. Но он имеет ряд недостатков by design.

Я хочу рассказать о том, с какими проблемами «ванильного» вольта мы сталкивались. Какие из них нам удалось решить внешними инструментами — как написанными самостоятельно, так и предлагаемыми сообществом. Какие проблемы потребовали залезать в код вольта и почему нам пришлось его форкнуть.

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

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

Что произойдет, если тысяча разработчиков одновременно смержат свой код любимым gitlab в main-ветку и будут ждать деплоя в прод? Хайлоад из кода, багов и крупнейшего фича-поезда, которому не суждено доехать до прода.

Поговорим о том, как мы ВКонтакте решали задачу «индусских поездов» в продакшн, попутно предлагая фичи observability, предсказуемости и сокращения TTD.

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

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

На эти вопросы я постараюсь ответить в своем докладе. Расскажу, как мы в VK Звонках построили автоматизированный стенд для измерения качества аудио и видео с физическими устройствами: мобильными телефонами и ноутбуками. Покажу результаты измерений, а также результаты сравнения по качеству видео и звука с западными сервисами.

Ozon уже более 3 лет кратно растет и будет продолжать расти по ключевым бизнес-показателям: заказы, купленные товары, GMV. Для поддержания роста бизнеса нужно увеличивать число серверов, которые выливаются в многомиллионные бюджеты для закупки. Нам важно поддерживать баланс распределения общего бюджета, чтобы максимизировать инвестиции в масштабирование бизнеса и при этом иметь «железо», которое выдержит эту нагрузку.

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

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

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

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

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

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

В данном докладе мы поговорим о бизнес-ориентированном подходе к ИБ.
* О том, почему стоит строить безопасность именно от бизнеса, а не от продуктов.
* О целеполагании: как ставить действительно важные и достижимые цели. И о том как правильно отвечать на вопросы:
«От чего именно я защищаюсь», «Чего я хочу этим добиться?».
* О приоритизации расходов на ИБ. Одни компании тратят многомиллионные бюджеты на средства защиты, а потом еще столько же на выкуп операторам шифровальщиков. Дорого не значит хорошо! Бюджет не отражает зрелость.

В финале опишем универсальный «короткий путь» к зрелой ИБ и дадим универсальный чек-лист самооценки.

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

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

Более подробный перечень:
1) уязвимости в образах и зависимостях;
2) уязвимости контейнерных сборок;
3) уязвимости интеграций микросервисов со службами;
4) уязвимости инфраструктуры подхода IaC;
5) уязвимости окружения продакшна.

По каждому классу приведу реальные кейсы и методы борьбы с ними.
Рассмотрим стек ASP.NET, Python, Java, Go.

У Shift left security и DevSecOps чувствуется привкус хайпа и решений, не оправдывающих инвестиций.

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

Apache Spark — замечательный инструмент дата-инженеров, который поддерживает языки Scala, Java, Python и другие. Но что бы ни было выбрано, вам неминуемо понадобится установить клиент, подключить библиотеки, настроить окружение. И для сложных расчётов это оправдано, их удобнее писать с кофе в какой-нибудь полюбившейся IDE. Однако иногда хочется оперативно выполнить SELECT на пару строчек, проверив гипотезу, и продолжить заниматься своими делами.

Именно для этой цели в YTsaurus развивается модуль Query Tracker, позволяющий прямо в браузере запускать SQL-like-запросы на разных движках: полноценном MapReduce, Clickhouse или Spark.

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

МТС в режиме реального времени получает большие объёмы данных от своих абонентов по различным протоколам, в многочисленных физических и логических форматах данных. Эти данные можно использовать для рекламных кампаний, формируя триггеры на основе сценариев абонентов. Многие из этих данных актуальны лишь небольшой промежуток времени, а значит, эти данные нужно как можно быстрее обработать, чтобы получить из них максимальную выгоду. Лучший способ это сделать — применить streaming processing.

В этом докладе я расскажу, как мы в МТС реализовали триггерную систему на основе потоковой обработки данных в условиях BigData (~10 млн событий в секунду) с помощью Java, K8s, PostgreSQL, Aerospike, Kafka и без использования популярных фреймворков (Spark, Flink, Samza, NiFi и т.п.).

Мы пишем и продаем коробочное on-premises ПО, и клиенты не рассказывают нам, как они им пользуются.

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

В докладе расскажу, почему нужно делиться данными с авторами ПО, как сделать людям лучше от включенной телеметрии и как продакт-менеджер пользуется телеметрией для изменения курса развития софта.

Моя команда разрабатывает централизованную промышленную инфраструктуру MLOps в Альфа-банке, а также управляет процессами внедрения и поддержки моделей.
> 300 моделей в бою, > 150 DS постоянно пользуются платформой.
Реализовали среду разработки моделей с гибким распределением гарантированных вычислительных ресурсов пользователям.
Более чем в 2 раза ускорили внедрение моделей за счет оптимизации пайплайнов и процесса внедрения.
Поддерживаем модели на уровне Mission Critical.
Автоматизировали переобучение моделей и внедряем AutoML.

Что, если бизнесу нужны сложные аналитические витрины с актуальностью данных в минуты, а выходить в стриминговую обработку на CEP-движках, таких как Flink, дорого и overkill по скорости поставки данных? Есть ли компромиссное решение, не требующее полного разворота на 180 градусов от ETL-процессов, реализованных на SQL-диалекте? И, конечно, это решение должно быть масштабируемым до cотен ТБ. Поэтому это не PostreSQL.

«И оно есть у нас».
Триплет технологий YTsaurus + YQL + динамические таблицы позволили найти архитектуру поставок данных, повторяющую подход к обработке данных, заложенный в стриминге, но упрощающий реализации. Это дало нам достаточную скорость обработки данных в минуты, помноженную на технологии с невысоким входом и прозрачную для потребителя структуру промежуточных и конечных данных. И — вишенкой на торте — такие поставки интегрированы по данным классическим с T-1-поставками и их можно легко пересчитывать.

Деталями этой реализации на примере расчета быстрой Юнит Экономики в Яндекс Маркете мы и хотим поделиться.

Опыт замены Оркестратора и ELT-инструмента на высоконагруженном DWH.

Вводные на старте проекта:
* Хранилище эксплуатируют 10+ доменных команд разработки.
* Ежедневно выполняется 6000+ регламентных расчетов.
* Хранилище играет ключевую роль в процессах работы компании.
* Сохранение текущих строгих SLA подготовки данных.
* Продолжение развития хранилища в период миграции.

Расскажем, какой путь прошли во время миграции с вендорного SAS DI на OpenSource-экосистему из Airflow + dbt.

Что первое приходит на ум, когда вы слышите фразу «банковское взыскание»? Незамолкающий телефон? Стук в дверь? Примитивные методы, основанные на примитивной логике?

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

Расскажем, как мы применяем data science в погоне за мечтой о взаимности:
1. розничное взыскание — крайний, но не последней по значимости этап жизни кредита;
2. данные для Collection: что собираем и как агрегируем;
3. автоматизация: как и с помощью каких инструментов мы организуем процессы, почему без слаженного взаимодействия
нам никак;
4. водопад моделей Collection от предварительного скоринга до выездной работы:
4.1. модели Precollection: как мы помогаем клиенту не забыть о платеже и сохранить хорошую кредитную историю,
оставаясь ненавязчивыми;
4.2. модели реструктуризации в связке с ранним скорингом: как мы предсказываем возникающие у клиента сложности и
заранее протягиваем руку помощи, подбирая оптимальное предложение и коммуникацию;
4.3. модели средней просрочки и эмоциональные технологии: что такое Персональный Ассистент, как он может
«чувствовать» клиентов и операторов, что мы с этим делаем сейчас и планируем делать в будущем;
4.4. глубокая просрочка. Если все же необходимо выезжать, то как мы определяем, к кому стоит ехать, а для кого это
станет лишь усугубляющим фактором.

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

Apache Spark Streaming лучше подойдёт, если у вас нет потребности в real time и миллисекундных задержках. Для sub-second-задержек лучше подойдёт Apache Flink. Но не Spark и Flink едиными. Есть, например, Apache Storm, у которого сейчас довольно мало контрибуций, но при этом он всё ещё релизится. Или Apache Samza, о которой есть доклад разработчиков из Одноклассников. Мне кажется, что и её будущее предрешено, учитывая мизерное количество новых коммитов. Можно ещё попробовать Kafka Streams, но тогда управление ресурсами — это уже ваша задача.

А как обстоят дела с решением реальных задач? Кейсы, которые часто решают на стриминговой платформе — объединение (join) двух потоков. Spark и Flink справятся с этой задачей, но сделают это по-разному.

Это и не только обсудим на докладе.

До 2022 года в Ozon была практика переезда из одного кластера Hadoop в другой при смене дата-центра примерно раз в год-два.
А это значит заново создать всю инфраструктуру, переносить данные и клиентов, их код и согласовать это с тысячами интеграций, завязанных на прошлый кластер. Это было очень дорого и долго.

Долго, потому что в Ozon около 25 команд разработки использующих Hadoop. И поэтому дорого. В основном, это data-science-ребята, которые месяц занимались операционкой переезда.

Мы решили больше не проводить своих DE, DS и аналитиков через эти трудности и решили попробовать то, что все гайды по Hadoop категорически не рекомендуют, а именно, растянуть Hadoop на 3 DC.

В докладе расскажу:
* зачем нам вообще Hadoop;
* почему не 3 Hadoop-кластера, а один растянутый. PnL;
* какие у нас были вводные по железу, по данным и клиентам;
* как распределить данные. Репликация и шардирование;
* как раскидать потребителей YARN;
* какие результаты мы получили;
* планы. Своя BlockPlacementPolicy. 3+ DC.

В докладе рассмотрим новые виды атак на чат-боты, использующие LLM. Разберем, как обходят safety layer моделей, как работают prompt injection и разные виды jailbreak. Разберем виды и классификации атак по разным фреймворкам. Обсудим, почему OWASP создали 3 отдельных гайда по LLM Security. На докладе будет представлен чек-лист, которым можно пользоваться перед запуском приложений в прод.

Виды атак, которые будут изучены: adversarial атаки с суффиксами, конкатенация промптов, отравление обучающей выборки, уязвимости библиотек и supply chain, уязвимости AI-фреймворков.

Диалоговый агент на базе ChatGPT — это сейчас одно из наиболее эффективных средств автоматизации общения в практически любых бизнес-процессах, где это общение возникает, будь то деловая переписка, модерация контента в интернет-магазине или анализ диалогов в контакт-центре. А если общение — это не только текст, а ещё и, например, картинки (в духе «глянь, подходящий ли стиль у этой картинки для новогодней рекламы» или «эй, посмотри, на этой фотке точно нет запрещёнки»), то здесь поможет ChatGPT Vision.

Но в текущих реалиях далеко не всегда есть доступ к серверам OpenAI, на которых работает ChatGPT Vision. Также не всегда оправдана отправка данных на сторонние сервера по соображениям безопасности или экономики. Таких вот «не всегда» очень много. И что же делать в этом случае? Делать свою мультимодальную LLM!

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

Я расскажу о пайплайне из 10+ моделей, который позволяет находить нужный фрагмент по произвольному описанию, по произнесенной фразе, цветовой палитре, лицу или действию в кадре.

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

Мы немного коснемся архитектуры на основе Dagster, Celery, живущих в Kubernetes и кейсах у заказчиков.

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

Мы рассмотрим:
1. Основные этапы процесса создания музыкального хита.
2. Наши подходы к созданию полноценных музыкальных треков (музыкальная композиция, вокал, аранжировка).
3. Нейросетевая композиция — сложности и вызовы.
4. Особенности реализации синтеза пения по произвольному тексту.
5. Автоматизированный саунд-дизайн и рендеринг в реальном времени.
6. Результаты и примеры использования.

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

Я расскажу о том, как на протяжении нескольких лет помогаю превращать результаты научных исследований Университета ИТМО в открытые библиотеки и фреймворки (разберем фреймворк автоматического обучения FEDOT в качестве примера такого проекта). Обсудим как технические аспекты вывода ИИ-решений в Open Source, так и нюансы развития сообщества открытого кода в академической среде.

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

Хотели бы вы управлять устройствами на расстоянии, не используя пульт, голос, касание? Мы расскажем вам, как вы можете сами сделать управление жестами, используя только камеру. Как с помощью всего двух статичных картинок можно предсказать движение. Зачем мы балансировали между качеством, объемом, уникальностью и расовой принадлежности при сборе данных. Как небольшое исследование внутри российской компании стали использовать большие мировые корпорации (Intel, Google). Полученные State-of-the-Art-решения в области распознавания жестов находят применение в любом устройстве: от кофеварки и настольного девайса до сложных систем в робототехнике и автоиндустрии.

В этом докладе расскажем, как мы разрабатывали наш движок для запуска ML-моделей в web-браузере на примере видеоконференций SberJazz. Подробно обсудим мотивацию делать свой движок вместо использования открытых решений, покажем, как построить эффективный Inference моделей, используя возможности WebGL.

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

Вы часто слышите, что квантовый компьютер взломает RSA и это только дело времени. Некоторые пробовали написать программу на Qiskit и ждут, когда это можно будет запускать на реальном квантовом железе. Наша небольшая группа из подразделения R&D занимается вопросом, может ли быть полезен квантовый компьютер для бизнеса в близкой перспективе. Но мы используем эмуляторы квантовых вычислений, развернутые в облаке Cloud.ru.

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

0. Введение:
* немного про логические и бинарные бэкапы;
* в MongoDB Community убрали возможность физических бэкапов;
* следовательно, нужно добавить её обратно.

1. Про движок MongoDB — WiredTiger:
* немного про MMapV1 — предшественника WiredTiger;
* общая архитектура WiredTiger.

2. Как бэкапить WiredTiger:
* низкоуровневая организация хранения данных в WiredTger;
* как уплотняются данные;
* курсоры — способ доступа к данным (и не только);
* WT_CURSOR_BACKUP — способ создания резервных копий;
* что, если скопировать WT_CURSOR_BACKUP?

3. Применяем знания на практике:
* пишем новые стадии агрегации, чтобы соответствовать интерфейсу MongoDB Enterprise и PSMDB;
* $backupCursor и $backupCursorExtend — описание;
* $backupCursor и $backupCursorExtend — реализация;
* как воспользоваться ими для снятия бэкапа.

Доклад посвящён паттерну запуска задач по расписанию на бэкенде.

Мы подробно рассмотрим сам паттерн, какие проблемы он решает и варианты его реализации на Go, Python и Java. Самые часто возникающие ситуации — это пакетная обработка большого количества запросов и ретраи. Я выделяю как минимум четыре разных подхода к реализации: в памяти, персистентный, встроенный во фреймворки и внешний.

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

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

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

Все мы знаем, что для эффективной балансировки необходим хороший алгоритм. Современные алгоритмы могут динамически определять перегруженные инстансы сервисов и эффективно снижать квантили ResponseTime-сервиса. Но так ли это? Обсудим то, что мы, в OzonTech, смогли увидеть на своих сервисах под нагрузкой более 1 миллиона RPS.

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

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

* Что, вообще, из себя представляет наша система и какова ее суть.
* Как мы делаем нагрузочное тестирование на запись на проде.
* Какие метрики могут помочь в оптимизациях.
* Какие открытия мы совершили по ходу повышения требований к системе.
* Что сейчас? На сколько хватит запаса?
* Что еще можно оптимизировать?

Бэкенд Яндекс Вертикалей живёт в монорепе. В ней четыре миллиона строк кода, за которые ответственны 15 команд, и эти числа постоянно растут.

Flaky-тесты — наша болезнь роста. С ней концепция 100% зелёных тестов становится проблематичной, т.к. юнит-тесты всё время флакают и краснят билд.

Мы, как команда монорепы, эффективно решили проблему с flaky-тестами всех наших команд, не разбираясь детально с каждым проблемным тестом — в режиме blackbox. Мы пришли от кошмарных >= 5% фейлов сборок от flaky — к приятным <= 1%.

Слушатели узнают про эффективные способы борьбы с flaky-тестами — в первую очередь, карантин. И поймут на нашем опыте, какие у этих способов есть подводные камни и как их обходить.

Два года назад мы в Яндекс Маркете начали разрабатывать свой DI-фреймворк — Scout. Это легковесный фреймворк, который предоставляет выразительный Kotlin DSL. Он не генерирует код, а делает всю работу в рантайме. Недавний переход на эту библиотеку привел к замедлению нашего приложения, но мне удалось ее ускорить, применив технологию модификации байт-кода.

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

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

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

1. Идея и первоначальная концепция продукта "Риалтайм-конфигуратор маркетинговых предложений".
2. Где мы в архитектуре.
3. Как выбирали наш стек: Flink, Tarantool, Kafka, PostgreSQL, Scala, Java, Lua.
4. Как дойти до прода с open source и не отхватить множество багов.
5. Движение к продакшну и новые проблемы.
6. Чего удалось достигнуть и наши рекомендации.

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

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

* Я являюсь ведущим разработчиком платформы нагрузочного тестирования Ozon.
* Основной способ взаимодействия микросервисов в компании — это gRPC.
* В пике деплоим порядка 1000 контейнеров с генераторами нагрузки.
* В экосистеме организации существуют сервисы, выдерживающие 1,000,000 RPS.
* Чтобы экономить на железе, нам нужен эффективный генератор нагрузки.
* У нас уже был один из самых эффективных генераторов нагрузки на рынке, но теперь мы смогли ускорить его в 4 раза, реализовав свой gRPC-клиент, предназначенный для нагрузочного тестирования.
* Расскажу, как работает нагрузочное тестирование в Ozon и какие знания нам понадобились, чтобы реализовать свой эффективный gRPC-генератор нагрузки.

Расскажу про платформу А/В-экспериментов в Яндексе, на которой проводится 35 000 экспериментов в год. Как поддерживать А/В для 200 сервисов и проводить 200 экспериментов на каждый хит. Зачем нужны эксперименты с выборками на 200 000 строк. Как обезопасить бизнес от плохих экспериментов. Как выкатывать успешные эксперименты в продакшн и гарантировать, что выкатка соответствует эксперименту.

1. Необходимость кластеризации системы управления гипервизорами для высокой доступности и отказоустойчивости.
2. Основные преимущества etcd при кластеризации системы управления гипервизорами.
3. Процесс кластеризации с использованием etcd.
4. Практические примеры использования etcd для кластеризации системы управления гипервизорами.
5. Возможные недостатки etcd и проблемы.
6. etcd предоставляет мощные возможности для кластеризации системы управления гипервизорами.

В рамках развития продукта MyTarget в компании VK был запущен единый рекламный кабинет. Это привело к серьезному росту нагрузки на backend-компонент, который отвечает за подбор рекламы, — баннерный демон. На развитие сервиса также повлияли и аппаратные ограничения, как в части пополнения серверного парка, так и в части размещения новых аппаратных мощностей.

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

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

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

В Почте Mail.ru стояла задача: научить бэкенд на основе почтового сервера Exim с нагрузкой 1 000 000 писем/мин. переживать отказ ЦОД без простоя и потери писем. Основная сложность была в том, что почтовый сервер использует локальный диск для хранения очереди писем в процессе доставки.

Для решения проблемы мы построили отказоустойчивую распределённую очередь на основе Tarantool и in-house объектного хранилища. Чтобы не менять логику почтового сервера, мы написали свою файловую систему в userspace на Tarantool и FUSE, которая инкапсулирует взаимодействие с распределенной очередью.

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

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

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

Также будет рассмотрено масштабирование Redis и Redisearch. Расскажем, как реплицируем данные для поддержания высокой доступности на нужном уровне.

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

Как известно, в Интернете нет географии, зато есть топология. А это значит, что кратчайшим маршрутом между вашим приложением и пользователем вовсе не обязательно окажется прямая.

Давайте попробуем разобраться:
* из чего складывается задержка и почему это важно;
* что влияет на путь трафика от клиента до приложения и обратно;
* при чём тут облака, DDoS-защита и CDN;
* что можно сделать, чтобы задержка стала меньше.

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

Система троттлинга должна обладать следующими свойствами:
* быстрое применение новых правил;
* низкая затрата ресурсов;
* точный выбор плохого трафика.

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

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

Поговорим о том, как изменившиеся требования повлияли на устройство платформы под капотом: от специфики раздачи экспериментов за 3 мс до быстрого подсчета метрик.

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

Каждый уровень и этап такого конвейера — результат многолетней эксплуатации под большой нагрузкой в Sage, платформе мониторинга и realtime-аналитики Т-Банка.

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

Не любой софт удобно разворачивать в большом масштабе, чтобы обслужить целую страну или весь мир. Иногда все же оказывается выгоднее взять существующее, но неготовое к работе на масштабе решение — пусть даже оно нарушает некоторые парадигмы работы в облаке. И развернуть его на весь мир для работы в режиме 24/7 с помощью некоторой системы балансировки. К сожалению, если так делать, становится очень просто выстрелить себе в ногу. Об этом и поговорим.

Важной особенностью A/B-тестов является то, что они находятся на пересечении нескольких областей:
* бизнеса (проверка гипотез, базовый инструмент аналитика),
* математической (статистическая значимость)
* технической (обработки терабайтов данных и попадание в SLA).

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

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

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

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

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

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

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

Ozon — один из крупнейших e-com-проектов в стране. За последние годы мы построили большую и сложную систему, состоящую из нескольких тысяч сервисов, запущенных на тысячах серверов, распределенных по нескольким ДЦ. На таком объеме всегда что-то ломается: диски, сетевые карточки, сервера, а иногда и целиком ДЦ.

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

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

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

В Яндексе — 50+ сервисов, которые списывают деньги. Каждый из сервисов нужно биллить по-своему с учетом множества разных требований.

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

Ну и, конечно, расскажу, с какими челленджами мы столкнулись и как мы их чинили.

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


Я хочу честно сравнить GQL и OpenApi, показать, что GQL — это не какая-то магия и что это не панацея, а технология со своими плюсами и минусами. Я выведу повествование на рассказ о технологии Apollo Federation, чтобы на ее примере показать, где эффект от использования GQL в больших компаниях с большим количеством микросервисов и клиентов, вроде нашей, становится по-настоящему значимым за счет экономии на разработке сервисов гейтвеев и более развитом тулинге. Я покажу, как мы в итоге решили запускать экосистему GQL применительно к топологии наших сервисов.



Мы перед внедрением GQL много общались с ИБ и Эксплуатацией, и они проговорили нам набор проблем, без решения которых ехать в прод мы не смогли бы (ddos, overfetching, batch и пр.). Мы потратили время на то, чтобы найти решение этих проблем или осознать, как они решаются на уровне написания кода сами. И только когда все блокеры со стороны ИБ были закрыты, мы поехали в прод.

Я расскажу о каждом кейсе отдельно с объяснением того, что за проблема и как мы ее решали: как тюнили федерацию и CI/CD, как пилили ландшафт по продуктам, как делали загрузку файлов и пр
.

Все мы привыкли, что распределённые транзакции «просто работают». Этот доклад посвящён алгоритмам выполнения распределённых транзакций (которых всего три), их «слепым пятнам» и слабым местам, а также обзору конкретных реализаций каждого из алгоритмов. Посмотрим, как разработчики пытаются преодолеть врождённые пороки этих алгоритмов. А под конец узнаем, какой же из алгоритмов выбран в Platform V — фреймворке Сбербанк-Технологий для высоконагруженных систем.

Расскажу, как устроена автогенерация рекламы в Яндексе: за последний год мы перешли от шаблонных сочетаний текста/описания/цен к генерации GPT-нейросетями. Масштабы нашей задачи — создание более 3 миллиардов объявлений, используя для их обработки и хранения несколько тысяч ядер и терабайты памяти. Обсудим тонкости реализации и проблемы с нагрузкой, ведь для генерации текстов и описания баннера используем всего лишь 22GPU v100. Мы разработали алгоритм умного обхода объектов и научили сервис инференса GPT-нейросетей адаптироваться к изменяющейся нагрузке со стороны процессинга объявлений.

Также расскажу о подходах, используемых для выбора наилучшего заголовка для рекламного объявления: поговорим о том, как мы перешли от крошечных dssm к использованию полноценных Bert в RT-процессинге.

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

В докладе рассмотрим эволюцию архитектуры поиска под нагрузками. Так как задача выглядит IOBound, то начнём с очевидного решения. Поставим сервис, к нему подключим redis cache и поехали в прод. Однако со временем данные становятся объёмнее, потеря их может стать критичной, поэтому мы рассмотрим менее популярные альтернативы. После чего придут поставщики и скажут, что стоит снизить количество запросов. Поэтому нам придётся добавить кастомный протокол балансировки, да и настроить HAProxy дальше стандартной документации.

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

Мы каждый день сталкиваемся с распределенными системами и в применении (как пользователи), и в разработке (как специалисты). Системы бывают как сильно распределенными, так и не очень.

В чем разница? Почему у знакомого три дата-центра, и у тебя три дата-центра, но есть нюанс? Когда надо думать про разные штуки с задержками и консистентностью, а когда можно поставить модную БД в режиме as-a-Service и все будет круто?

Приходите послушать и поговорить про скучную теорию, про CAP- (и PACELC-) теоремы и веселые фейл-кейсы построения разных распределенных систем.

Поисковый движок в Ozon — сложная распределённая система, построенная на основе Apache Lucene. Наше решение позволяет эффективно обрабатывать более десятка тысяч разреженных полей в поисковом индексе, осуществляя поиск по миллионам документов при тысячах RPS.

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

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

Стандартная картина: у банка есть АБС (автоматизированная банковская система, ядро банка), которая процессит все сделки/счета/проводки организации. Обычно это монолитное, зачастую вендорское решение.

Агрегированные данные ядра нужны всем, начиная от регуляторной отчетности и заканчивая продуктовой аналитикой. Где-то достаточно актуальности «за вчера», где-то данные нужны онлайн.

Обычная практика — репликация данных в хранилища + API АБС (к сожалению, зачастую используются также прямые интеграции с БД АБС). Но что, если банк решил написать собственное ядро на базе микросервисной архитектуры? Что, если данные теперь не живут в одном месте, а сервисы разрабатываются разными командами, и в них могут различаться подходы к разработке и модели данных?

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

В рамках доклада будут разобраны следующие темы:
* АБС Райфа и основные типы бизнес-процессов потребления данных;
* что меняется во время миграции на новое ядро;
* как можно выстроить архитектуру распространения данных.

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

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

2. Кому может быть полезен реестр?
С 2023 г. компании, которые относятся к критической инфраструктуре, обязаны прекратить использование иностранных программ и перейти на использование отечественного софта. Отечественный софт — софт, который включен в реестр российского ПО, поэтому в скором времени весь софт, используемый такими компаниями, должен быть из реестра российского ПО. Расскажем, как можно легализовать использование иностранного ПО при помощи реестра.

3. Какие льготы дает использование реестра?
* Во-первых, это коммерциализация внутренних разработок. Реестр также дает возможность выйти на новый потребительский рынок, в т.ч. позволяет участвовать в госзакупках: государственные органы и компании должны перейти на использование отечественного ПО к 2030 году, поэтому они закупают ПО из реестра.
* Во-вторых, экономия на налогах. Продукты из реестра могут продаваться без НДС, Пониженные страховые взносы — 7,6%, налог на прибыль — 0% для некоторых компаний (классифайды, рекламные площадки, маркетплейсы).
* В-третьих, правообладатели ПО из реестра имеют право на IТ-аккредитацию, она, в свою очередь, позволяет сотрудникам получить отсрочки от армии и льготные ипотеки.

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

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

6. Разбираем примеры тех, кто смог.
В реестр можно включить не только сложные программы, но и обучающие мультимедийные курсы, лендинги, сайты, открытые библиотеки, встроенное ПО для «железа» и много чего еще.

7. Немного о ПАК.
С недавнего времени в реестре стало возможным зарегистрировать программно-аппаратные комплексы. Кратко пройдемся по плюшкам от включения ПАК в реестр и процедуре.

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

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

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

Attack-Defence CTF — это отличный способ на практике познакомить сотрудников вашей компании с реальными уязвимостями, дать им возможность почувствовать себя как злоумышленниками, так и сотрудниками SoC, пытающимися им противостоять. Качественный CTF привлекает к вам студентов, которые потенциально могут стать вашими сотрудниками. Плюс каждое AD в России — это большое событие в мире CTF, позволяющее вам повысить свою известность и лояльность в IT и ИБ-сообществе.

В докладе будет рассказано:
* какие существуют платформы для AD, какие у них есть плюсы и недостатки;
* как правильно подходить к созданию задач и интегрировать их в инфраструктуру AD;
* как правильно подготовить сеть — полезные советы по сетевому харденингу;
* как защитить свою инфраструктуру от игроков;
* презентуем Open Source-решение: KuberAD — полностью Cloud-незавимое решение для развертывания AD на любой инфраструктуре на базе Kubernetes.

По итогу дадим чек-лист — что нужно сделать, чтобы подготовить свой Attack-Defence и сохранить свои нервы.

В честь предстоящего июльского коммитфеста PostgreSQL на Saint HighLoad++ пройдет вечеринка от разработчика самой популярной российской СУБД — компании Postgres Professional.

В шатре Postgres Professional:

• Обсудим патчи в Postgres — опытом работы поделятся эксперты компании, в том числе Major Contributors Олег Бартунов и Федор Сигаев;

• Покажем решения на базе Postgres Pro: интегрированная в ядро технология BiHA (Built-in High Availibility) для встроенной отказоустойчивости СУБД, новая распределённая реляционная СУБД Shardman для крупнейших инсталляций в десятки и сотни ТБ.

Не просто увидите, а потрогаете технологии! На стенде можно отключить шард СУБД Shardman или узел кластера Postgres Pro Enterprise BiHA и посмотреть, как системы справляются с перераспределением нагрузки.

• Разыграем мерч: подходите к шатру (схема прохода — на карте конференции), сканируйте QR-код, правильно отвечайте на вопросы в боте и выигрывайте призы!

Ждем вас на PostgreSQL Pre-Commitfest Party!

Создаваемые в 2022 и 2023 году системы RAG (retrieval augmented generation) постепенно усложняются, превращаясь в монстров обработки данных — от простой схемы «ретривер-генератор» решения переходят к модульным системам со множеством асинхронных источников данных, несколькими моделями, сложными сценариями, поддержкой самостоятельного принятия решений.

В рамках данного воркшопа мы:
* быстренько слепим не очень простую RAG-систему на Python, langchain и llamaindex, на облачных отечественных моделях;
* освоим модные техники и исследования в области создания модульных и гибридных RAG — актуализированные на момент проведения конференции, так как новые публикации и библиотеки появляются практически каждый день;
* применим методы автоматической оценки эффективности (точности и полноты) систем с RAG.

От участников потребуется:
* ноутбук с любой ОС,
* среда разработки для Python (VS Code, PyCharm, etc.),
* установленный Python 3.12, git, Docker,
* WSL, если у вас Windows,
* хорошее настроение.

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

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

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

Сегодня существуют существенно более дешевые и достаточно прилично работающие альтернативы от Rockchip, причем уже в форм-факторе IP-камер.

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

Я расскажу вам всё про процесс пререндера в браузере.

1. Мы познакомимся с современным движком браузера.
2. Увидим, из каких компонентов он состоит и как они взаимодействуют.
3. Познакомимся с механизмами пререндера и префетча.
4. И заглянем в светлое будущее.

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

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

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

Мы поговорим о том, как устроена система транспортного предпроцессинга федерального уровня, реализованная в Мир Plat.Form (НПСК), о способах оплаты, о том, что находится за кадром смс об успешном списании средств, и почему такая смс может появиться в уведомлениях совсем не сразу после оплаты.

Изначально в KION мы пользовались решениями известных IТ-гигантов. Но в какой-то момент нам стало их не хватать: выросло количество пользователей и продуктовых событий.

Так в KION появился свой приемник событий со средней нагрузкой 6000RPS.

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

На смену процессу классического мониторинга в IТ-индустрию приходит новая концепция Observability (наблюдаемость), характеризующаяся более комплексными и расширенными подходами к извлечению и интерпретации телеметрии объектов наблюдения, а также вовлечением в дисциплину большего числа участников технологических процессов разработки и эксплуатации IТ-систем и сервисов. В рамках техтолка расскажем о том, как все это внедряется в Мир Plat.Form (НСПК).

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

Переходим с 17-й на 21-ю. После того как мы переходили с 8-й на 11-ю и с 11-й на 17-ю, нам ничего не должно быть страшно. Однако то, что мы обнаружили, нас сильно удивило.

Обычно как? Обновляем JDK, но собираемся в режиме совместимости. Тестируем. Затем начинаем использовать новые фичи и обновлять прочие компоненты. При переходе на 21-ю версию JDK нам пришлось сразу обновить вообще все.

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

Вячеслав расскажет о нашей существующей архитектуре (API -> REDIS -> Kafka -> msSQL), почему был выбран Redis на момент возникновения проблем, поднимет вопрос с какими проблемами мы столкнулись, используя эту реализацию (так называемая проблема BIG_KEY), поделится, какие решения мы нашли. А также поговорит о перфомансах и возможностях использования noSql.

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

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

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

В высоконагруженных проектах на первый план выходит оптимизация производительности. Кроме привычных методов оптимизаций: отсутствие лишних операций, уменьшение числа создаваемых объектов, есть еще один способ оптимизировать наше приложение — PGO. Profile-guided optimization (оптимизация с использованием профилировки) позволяет нам в полуавтоматическом режиме ускорить выполнение кода с минимальным числом ручных действий.

В докладе мы поговорим о:
* inlining (встраивание) вызовов;
* девиртуализации вызовов;
* профилировке как части жизненного цикла CI;
* том, как применение оптимизаций компилятором выглядит под капотом;
* какие будущие оптимизации нас ждут.

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

Я хочу кратко перечислить типы ошибок (sentinel, выделенный тип для ошибок и opaque). Затем я покажу, какие и когда их следует использовать.

После этого я хочу поговорить о wrapping (оборачивании), которое позволяет получить stack trace и место, где произошла ошибка. Также wrapping дает возможность получить данные для повторения ошибки, разделить общедоступные и частные сообщения об ошибках для логирования и ответа клиента. Расскажу и о других возможностях wrapping.

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

Большинство разработчиков считают, что fuzzing - это когда какому-нибудь json-парсеру подают случайные строчки в надежде найти segfault. Это важный кейс, но если посмотреть шире, эта технология может предоставить гораздо больше возможностей практически каждому разработчику. Например, можно особым образом генерировать входные параметры для вашей системы и проверять, всегда ли она работает так, как вы ожидали. То есть проверять не набор отобранных примеров, а свойство системы.

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

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

В докладе я расскажу о том, как Temporal работает «изнутри», начиная от архитектуры кластера до реализации конкретных бизнес-процессов. Мы затронем темы детерминизма, версионирования в Temporal и особенностей взаимодействия с помощью gRPC. Будет показано, как Temporal помогает в достижении отказоустойчивости бизнес-процессов через механизм Event History, что позволяет нам не потерять ваш заказ и гарантировать своевременную доставку.

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

Речь пойдет про использование Go для сквозной разработки приложений: от бэкенда до графического интерфейса.

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

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

Рассмотрим недостатки проекта opentelemetry, с которыми мы столкнулись при развитии пайплайна трейсинга в Авито, и расскажем, как мы их решали:
* performance проблемы;
* несовместимость модулей;
* неоднозначные архитектурные решения;
* проблемы протокола передачи данных (OTLP);
* backpresure;
* etc.

В докладе я расскажу о своём опыте написания интеграции Xiaomi Gateway 3 для open source-платформы умного дома Home Assistant, где непоследнюю роль сыграл язык Go. Именно на нём написан «демон» для нескольких шлюзов экосистемы Mi Home:
* Xiaomi Multimode Gateway (архитектура MIPS),
* Xiaomi Multimode Gateway 2 (архитектура ARM),
* Aqara Hub E1 (архитектура ARM).

GitHub проекта — https://github.com/AlexxIT/XiaomiGateway3

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

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

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

* Как устроена музыка в современных компьютерах.
* Как можно использовать Go в современных DAW.
* Как написать свою собственную эмуляцию гитарной педали на Go.
* Какие возникают трудности при разработке плагинов для DAW.

Бэкенд Главной страницы Яндекса был исторически написан на Perl, и сегодня это мешает его развивать, поддерживать и нанимать новых разработчиков. Мы решили переписать его на Go. Нужно было сделать это так, чтобы не останавливать продуктовое развитие, и чтобы пользователи ничего не заметили.

Я расскажу про созданную схему, при которой в ходе переезда два бэкенда — Perl и Go — работали параллельно. Мы использовали real-time-сравнение данных из двух бэкендов, чтобы убедиться в правильности переписанного кода. Расскажу, почему мы решили использовать Apphost — экосистему управления сетевыми сервисами.

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

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

Примерно 4 года назад мы занялись экспериментальным для Яндекс.Маркета проектом — рантайм-сервисом расчёта путей по логистическому графу на Golang. Этот эксперимент вылился в критичный и высоконагруженный сервис с порядка 40k RPS и примерно 50 RPS/CPU, благодаря которому вы можете видеть дату доставки вашей посылки на Маркете.

Мы рассмотрим, как различаются подходы и концепции C++ и Golang, глазами человека, который до эксперимента Golang в глаза не видел, а подавляющее количество кода писал на C++. А также поговорим, чему нас научил язык Go!

К примеру, вы узнаете:
* что общего и кардинально различного есть у указателей в C++ и Go;
* точно ли за аллокацией в Go не нужно следить так же тщательно, как в плюсах;
* есть ли различия в использовании gRPC в C++- и Go-сервисах;
* на сколько полезен и опасен sync.Pool

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

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

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

Языки претерпевают изменения, но не всегда это возможно сделать внутри самого языка, есть боли, которые тяжело затащить даже в мажорный релиз, поэтому мы встречаем такие ситуации, когда появляются TypeScript, Kotlin, Elixir. А что с языком Golang? Может ли он дойти до состояния, когда родится его преемник, который будет транспилироваться в чистый го, который будет просто обладать всеми прелестями рантайма го и горутинами, но синтаксически будет другим?

Цель моего доклада — обсудить данную тему в контексте 2024 года и немножко посмотреть в будущее, рассмотреть варианты, которые уже есть на рынке https://github.com/goplus/gop и другие.

Спроектировать и показать свое решение, которое не будет таким радикальным, как gop, а внедрить систему вставок нового синтаксиса, формата макросов, которая при компиляции превращает все сахара в чистый го и только потом запускает. Управлять системой сахаров в формате yaml-файла, который позволяет настраивать транспиляцию, формат babel в JS, как вариант: данное решение можно заопенсорсить и предлагать реализовывать свои решения. Данный механизм можно использовать в формате разработки, но также как примеры пропоузелов для новых синтаксисов и предложений на гитхабе.

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

Доклад подготовлен в соавторстве с Эдгаром Сипки (Ozon Банк).

Покажу, как при помощи локального ИИ и без ручного написания кода создать, протестировать и задокументировать прототип платёжной системы на Go и Java. Оценим, насколько ИИ полезен в рабочем процессе и насколько сложные штуки понимает.

Бытует мнение, что архитектура ПО — это сложно. Архитектурой занимаются очень умные люди в костюмах и с белой доской под мышкой, цитирующие наизусть Дядю Боба и пространно рассуждающие, «какой именно архитектурный шаблон из дюжины самых расхожих наилучшим образом применим в данной задаче».

Есть и другое мнение: архитектура ПО — это то, чем развлекают себя неспособные к написанию настоящего кода болтуны, ведь «реальная программа не имеет к архитектуре никакого отношения».

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

Что мы сделаем: возьмем реальную задачу и разработаем для неё архитектуру, попутно объясняя, откуда возникают те или иные требования и как формируются те или иные решения. Какую пользу принесут нам эти решения сейчас и в перспективе и какими проблемами чреваты.

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