Профессиональная конференция разработчиков высоконагруженных систем

Базы данных и системы хранения (9)

Про UUID v.7

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

Доклад принят в программу конференции

Как мы монгу физически бэкапили

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

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

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

Доклад принят в программу конференции

Балансировка нагрузки шардированного PostgreSQL не своими руками

PostgreSQL
MongoDB
Базы данных / другое
Хранилища
Обработка данных
YDB

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

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

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

Доклад принят в программу конференции

ClickHouse не тормозит в Self-Service BI: как мы достигли этого в Visiology

Архитектура данных, потоки данных, версионирование
ETL
ClickHouse
Хранилища
Обработка данных

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

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

Доклад принят в программу конференции

Гарантии доставки сообщений в YDB Topics

Архитектурные паттерны
Распределенные системы
Архитектура данных, потоки данных, версионирование
Обработка данных
Микросервисы

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

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

Доклад принят в программу конференции

Redis — такой простой и такой сложный!

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

Доклад принят в программу конференции

Как мы сделали собственный Software-Defined Storage для публичного облака Cloud.ru

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

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

Доклад принят в программу конференции

Кэширование пользовательских данных в СХД: реализация протокола синхронизации кэшей в Active-Active-кластере

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

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

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

Доклад принят в программу конференции

Переосмысление Picodata как cluster-first-СУБД

Picodata

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

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

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

Доклад принят в программу конференции

DevOps и эксплуатация (4)

Тернистый путь к единому хранилищу метрик экосистемы

Observability в enterprise
Хранилища
Филипп Бочаров

МТС Диджитал

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

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

Доклад принят в программу конференции

Масштабирование системы хранения секретов на базе HashiCorp Vault

Логирование и мониторинг
Менеджмент в эксплуатации
Управление изменениями
Observability в enterprise

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

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

Доклад принят в программу конференции

Автоматизация сетевой инфраструктуры ЦОД

Сетевое администрирование
Сеть
Анна Кошк

Ростелеком-ЦОД

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

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

Доклад принят в программу конференции

Укрощаем хайлоад из тысячи разработчиков и разрабатываем управляемую систему деплоя

Павел Шерепо

VK, ВКонтакте

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

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

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

Доклад принят в программу конференции

Узкотематические секции (1)

Измеряем качество видео и звука в видеозвонках на реальных девайсах

Алексей Шпагин

VK, ВКонтакте

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

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

Доклад принят в программу конференции

Аппаратное обеспечение, инфраструктура (1)

Capacity Planning в Ozon

Big Data и Highload в Enterprise
Web-scale IT / другое
Расширение кругозора

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

Доклад принят в программу конференции

Безопасность, информационная безопасность (6)

Таксономия изоляции: как оградить себя от хакера

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

Доклад принят в программу конференции

Из гадкого 1G в прекрасный 5G: эволюция безопасности мобильных сетей

Расширение кругозора
Атаки
Безопасность

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

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

Доклад принят в программу конференции

«А так можно было?» — обзор нестандартной криптографии в применении к практическим задачам

Системы прав доступа
Платёжные системы, обработка платежей
Защита информации
Безопасность

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

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

Доклад принят в программу конференции

Психологический возраст кибербезопасности

Управление / другое
Безопасность
Аудит
Инфобезопасность
Антон Бочкарев

Третья сторона

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

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

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

Доклад принят в программу конференции

Микросекьюрити в продуктовых микросервисах

Типовые ошибки
Лайфхаки
Инструменты
Инфобезопасность

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

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

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

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

Доклад принят в программу конференции

Гайд по shift left security для архитекторов и разработчиков

Методы и техника разработки ПО
Безопасность программного кода, SQL и прочие инъекции
Архитектуры / другое
Безопасность
Вацлав Довнар

Независимый эксперт

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

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

Доклад принят в программу конференции

BigData и машинное обучение (9)

YTsaurus SPYT: внедряем Spark SQL в массы

Распределенные системы
Обработка данных
YTSaurus

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

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

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

Доклад принят в программу конференции

Streaming Processing на данных BigData для рекламных кампаний МТС

Java
PostgreSQL
Базы данных / другое
Асинхронное программирование, реактивное программирование
Архитектура данных, потоки данных, версионирование
Big Data и Highload в Enterprise
ETL
Обработка данных

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

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

Доклад принят в программу конференции

Как продакту инфраструктурного софта через телеметрию познать клиента

Продуктовая разработка
ClickHouse

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

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

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

Доклад принят в программу конференции

Highload MLOPs: ускорение и автоматизация

Павел Николаев

Альфа-банк

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

Доклад принят в программу конференции

YTsaurus и аналитические витрины с актуальностью в 15 минут

Архитектурные паттерны
Распределенные системы
Архитектуры / другое
ETL
Хранилища
Обработка данных
Филипп Козьмин

Яндекс Маркет

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

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

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

Доклад принят в программу конференции

Реновация ETL. Как мы подменяли монолит, обслуживающий 6000+ потоков данных

Распределенные системы
Рефакторинг
ETL
Хранилища
Обработка данных

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

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

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

Доклад принят в программу конференции

Collection. Темная сторона Data Science

Ольга Кравченко

Газпромбанк.Тех

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

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

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

Доклад принят в программу конференции

Выбор стримингового фреймворка в 2024 году

ETL
Обработка данных

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

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

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

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

Доклад принят в программу конференции

Hadoop в 3 ДЦ

Hadoop
Хранилища
Обработка данных

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

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

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

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

Доклад принят в программу конференции

Нейронные сети, искусственный интеллект (8)

Атаки на AI-чат-боты и методы защиты

Безопасность программного кода, SQL и прочие инъекции
Machine Learning
Application security
Безопасность

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

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

Доклад принят в программу конференции

"Сильный искусственный интеллект" у вас в подвале: как собрать мультимодальную LLM из опенсорса и настроить её под вашу задачу

Python
Разработка библиотек, включая open source библиотеки
ML
Метрики

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

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

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

Доклад принят в программу конференции

Как с помощью AI в тысячах видео найти нужный кадр

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

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

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

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

Как обеспечить воспроизводимость научных исследований в AI/ML с помощью Open Source?

Разработка библиотек, включая open source библиотеки
Митапы
Управление разработкой

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

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

Доклад принят в программу конференции

Как научить фундаментальные модели читать, видеть, слышать и анализировать всё одновременно

Архитектуры / другое
Machine Learning

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

Доклад принят в программу конференции

Мир будущего: управление устройствами с помощью жестов

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

Доклад принят в программу конференции

Эффективная ML-обработка видео в web-браузере для видеоконференций SberJazz

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

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

Доклад принят в программу конференции

Технологии будущего (1)

Перспективы квантового компьютера в обозримое время

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

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

Доклад принят в программу конференции

Бэкенд, теория программирования (5)

Как научить MongoDB делать горячие физические бэкапы

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

Доклад принят в программу конференции

Как мы шли к 5000 RPS на запись

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

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

Доклад принят в программу конференции

Лечим flaky-тесты в режиме blackbox

Евгений Веретенников

Яндекс Вертикали

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

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

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

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

Доклад принят в программу конференции

Митапы (1)

Fail-митап

Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе!

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

Доклад принят в программу конференции

Производительность мобильных приложений (1)

Байт-код — это просто! Как сделать Dependency Injection по-настоящему быстрым

Java
Разработка библиотек, включая open source библиотеки
Технологии и языки для Android: Java, Kotlin
Оптимизация
Григорий Юрков

Яндекс Маркет

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

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

Доклад принят в программу конференции

Enterprise-системы (2)

Enterprise deploy: почему это больно

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

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

Доклад принят в программу конференции

Опыт перевода банковского продукта в риалтайм

Фреймворки
API
Java
Scala
PostgreSQL
Tarantool
Архитектуры / другое
Теории и техники анализа
Аналитика / другое
Lua
ETL
Teamlead
Управление разработкой
Хранилища
Обработка данных
Типовые ошибки
Лайфхаки

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

Доклад принят в программу конференции

Тестирование, нагрузочное тестирование (3)

Непрерывное нагрузочное тестирование на интеграционных средах

Сергей Жебет

Совкомбанк Технологии

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

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

Доклад принят в программу конференции

Зачем в Ozon понадобилось написать свой gRPC-клиент для нагрузочного тестирования, и как мы это сделали

API
GO

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

Доклад принят в программу конференции

Платформа А/В-тестирования в Яндексе

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

Доклад принят в программу конференции

Архитектуры и масштабируемость (22)

Кластеризация с помощью etcd

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


Доклад принят в программу конференции

Оптимизация баннерного демона в условиях резкого роста нагрузки

C/C++
Бэкенд / другое
Организация системы кеширования
Оптимизация производительности
Оптимизация
Артем Букин

VK, VK Реклама

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

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

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

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

Доклад принят в программу конференции

Быстрый поиск на Redisearch в ленте операций для миллионов пользователей

C/C++
Поисковые системы
Базы данных / другое
Организация системы кеширования

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

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

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

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

Доклад принят в программу конференции

Как научить почтовый сервер Exim под нагрузкой 1 000 000 писем/мин. переживать отказ ЦОД без простоя с помощью FUSE и Tarantool, а также развернуть такую систему в K8s

C/C++
Электронная почта
Tarantool
Отказоустойчивость
Распределенные системы
Поддержка и развитие legacy систем
Надёжность продакшена
Расширение кругозора

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

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

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

Доклад принят в программу конференции

Ищем кратчайший путь в Интернете

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

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

Доклад принят в программу конференции

Как мы держим миллион RPS в рекламе, троттлим трафик и не теряем при этом деньги

Михаил Кириченко

VK, VK Реклама

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

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

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

Доклад принят в программу конференции

Как платформа A/B-тестов Яндекса превратилась в решение для всего Интернета — Varioqub

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

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

Доклад принят в программу конференции

Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны

Архитектурные паттерны
Отказоустойчивость
Распределенные системы
ETL
Надёжность продакшена
Слабо связанная архитектура

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

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

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

Доклад принят в программу конференции

Чего не хватает обычному сервису, чтобы стать cloud-native

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

Доклад принят в программу конференции

Стенд метрик: как построить архитектуру для расчета тысячи метрик и попасть в SLA

Архитектура данных, потоки данных, версионирование
Архитектуры / другое
A/B-тестирование
Hadoop

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

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

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

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

Доклад принят в программу конференции

Мастер-класс «Разделим данные»

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

Яндекс Маркет

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

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

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

Доклад принят в программу конференции

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

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

Доклад принят в программу конференции

Как регулярно терять один ДЦ и не волноваться?

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

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

Доклад принят в программу конференции

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

Логирование и мониторинг
Управление изменениями
Микросервисы

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

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

Доклад принят в программу конференции

GraphQL: зачем на самом деле он нужен. Apollo Federation — дар бога

Фреймворки
API
Архитектуры / другое
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
Микросервисы

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


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



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

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

Доклад принят в программу конференции

Архитектура биллинга: как не стать единой точкой отказа

Илья Иванов

Яндекс 360

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

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

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

Доклад принят в программу конференции

О распределённых транзакциях

Базы данных / другое
Распределенные системы
Алгоритмы и их сравнение
Теория
Владимир Комаров

АО «СберТех»

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

Доклад принят в программу конференции

Как реклама Яндекса генерирует GPT-нейросетями заголовки для 3 миллиардов объявлений, используя 22 GPU

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

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

Доклад принят в программу конференции

Геораспределенные системы

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

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

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

Доклад принят в программу конференции

Как работать с поставщиками на примере поиска доступных отелей

Иван Чернов

Островок!

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

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

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

Доклад принят в программу конференции

Обновления данных в поиске за секунды. Быстробновляемые атрибуты в поисковом движке Ozon

Java
Поисковые системы
Базы данных / другое
Отказоустойчивость
Распределенные системы
Архитектура данных, потоки данных, версионирование
Надёжность продакшена
Поддерживаемый код
Совместное планирование и разработка
Оптимизация
Хранилища
Обработка данных
Типовые ошибки

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

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

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

Доклад принят в программу конференции

Миграция банковского ядра на собственную разработку. Как выстроить процессы распространения данных?

Лев Осипов

Райффайзен Банк

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

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

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

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

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

Доклад принят в программу конференции

Импортозамещение (2)

Как мигрировать тысячи сервисов между любыми дистрибутивами Kubernetes без единой правки чего-либо

Технологии виртуализации и контейнеризации
Управление конфигурацией
Слабо связанная архитектура
Облака
DevOps / Кубер

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

Доклад принят в программу конференции

Реестр российского ПО. Кому он нужен и что учесть в разработке, чтобы туда попасть?

Юридические вопросы
Интеллектуальная собственность на программное обеспечение;
Взаимодействие с государством

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

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

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

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

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

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

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

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

Доклад принят в программу конференции

Оффтоп (4)

Помогаем спасать жизни: как работает IT-команда крупнейшей российской фармы

Расширение кругозора

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

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

Доклад принят в программу конференции

Red&Blue AD — как подготовить и защитить свой Attack-Defence за 30 минут

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

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

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

Доклад принят в программу конференции

Вечеринка от Postgres Professional — обсуждение патчей PostgreSQL, демонстрация решений и розыгрыш мерча

Олег Бартунов

Postgres Professional

Федор Сигаев

Postgres Professional

В честь предстоящего июльского коммитфеста 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!

Программный комитет ещё не принял решения по этому докладу

Чему нас учит Чёрный квадрат и при чём здесь программирование?

Олег Бунин

Онтико

Вирна Штерн

Aletheia Digital

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

Почему супрематизм возник именно в России? Почему через 20 лет после возникновения он был запрещён? Что хотел сказать Казимир Малевич своим Чёрным квадратом? Это его наиболее значительное произведение в концептуальном смысле, одна из самых обсуждаемых и самых известных картин в мировом искусстве.

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

Доклад принят в программу конференции

Воркшоп (2)

Мастер-класс «Создание модульной (и желательно эффективной) RAG-системы»

Python
Логи, метрики, ошибки
ML

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

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

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

Доклад принят в программу конференции

Postgres Pre-Commitfest Party

Олег Бартунов

Postgres Professional

Федор Сигаев

Postgres Professional

Михаил Жилин

Postgres Professional

Николай Шаплов

Postgres Professional

Максим Орлов

Postgres Professional

Антон Мельников

Postgres Professional

Алена Рыбакина

Postgres Professional

Юрий Соколов

Postgres Professional

Павел Селезнев

АО «СберТех»

В июле начинается первый коммитфест — процесс рассмотрения разработок от сообщества, которые могут быть приняты в Postgres 18. Внушительное количество разработок уже перенесено из версии 17, что-то ещё добавится до июля.
https://commitfest.postgresql.org/48/

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

Если вы хотите попробовать найти ревьюера — подготовьте короткий (на 2-3 минуты) рассказ о своём патче. Присылайте заявки через эту форму https://forms.yandex.ru/u/6634e043c417f3cae70775a6/

Мы с вами свяжемся!

Доклад принят в программу конференции

Резерв (3)

Поиск и рекомендации Wildberries: почти миллион RPS, ML, персонализация и большинство запросов не через индексы

Python
Поисковые системы
Бэкенд / другое
GO
Рекомендации / ML
ML

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

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

Доклад принят в программу конференции

Identity Aware Proxy — как сделать весомый шаг в сторону Zero Trust

Безопасность
Безопасность инфраструктуры

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

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

В своем докладе я расскажу, как минимизировать риск при выдаче доступа к VPN для наименее доверенных групп сотрудников. Про то, как можно заменить доступ к сети компании через VPN максимально точечным и гранулярным доступом до веб-приложений с помощью достаточно простого и лаконичного решения — Identity Aware Proxy, сделав тем самым весомый шаг в сторону Zero Trust.

Доклад принят в программу конференции

Spark in K8s для десятков DS-команд

Уже более двух лет создаем MLOps-платформу для создания рекомендательных сценариев.

В докладе будет рассказано:
* как реализовали работу со Spark-нагрузками на RecSys-платформе;
* какие были проблемы со Spark и почему пришли к текущему решению:
* как использовать Spark в Multi-tenant-архитектуре;
* также поговорим о проблемах использования Spark in K8s.

Доклад принят в программу конференции

Edge Computing (3)

Как оптимизировать обработку звука на ограниченных в ресурсах устройствах и не потерять в качестве

Аппаратное обеспечение
QA / другое
Железо
Расширение кругозора

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

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

Доклад принят в программу конференции

Нейросети на китайских камерах: дешево и задорно

ML

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

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

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

Доклад принят в программу конференции

Механизм пререндера в браузерах

Фронтенд / другое
C/C++
Препроцессоры CSS
Производительность и мониторинг фронтенда
HTML и CSS
ML
Теория
Алексей Кузнецов

Chromium contributor и энтузиаст

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

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

Доклад принят в программу конференции

TechTalk (6)

Build vs buy. Сравнение и выбор технологий, вендоров

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

Доклад принят в программу конференции

Как устроена оплата в транспорте по банковским картам на примере Санкт-Петербурга

Продуктовая разработка
Бизнес на стыке онлайн и офлайн
Enterprise-системы
Владимир Гайдук

Мир Plat.Form (НСПК)

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

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

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

Доклад принят в программу конференции

Как и зачем создавать свой приемник событий

Алексей Жиряков

KION, МТС Диджитал

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

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

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

Доклад принят в программу конференции

Observability в Мир Plat.Form

Логирование и мониторинг
Менеджмент в эксплуатации
Observability в enterprise
Иван Липкин

Мир Plat.Form (НСПК)

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

Доклад принят в программу конференции

Обновление ПО и управление зависимостями

Архитектурные паттерны
Стандарты кодирования
Архитектура данных, потоки данных, версионирование
Сергей Богданов

Газпромбанк

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

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

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

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

Доклад принят в программу конференции

Сложности в архитектуре, или Как мы c BigKey в Redis боролись

Вячеслав Артамонов

Газпромбанк.Тех

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

Доклад принят в программу конференции

Инструменты на Go и для Go (3)

Быстро — не всегда хорошо: рейтлимиты в мультикластерном окружении

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

Доклад принят в программу конференции

Меньше кода, больше результата: применяем SQLC для работы с БД

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

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

Доклад принят в программу конференции

Как ускорить программу, не переписав ни строчки: PGO для Go-разработчиков

Оптимизация производительности
GO
Оптимизация
Микросервисы
Инструменты
Методологии

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

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

Доклад принят в программу конференции

Лучшие практики, Go-way (1)

Регламент для работы с ошибками в Go

GO

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

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

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

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

Доклад принят в программу конференции

Проблемы и приключения (3)

Как сделать тесты надежными: property-based-тестирование и fuzzing на практике

Николай Климов

VK, ВКонтакте

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

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

Доклад принят в программу конференции

Как Temporal помогает не потерять вашу пиццу

Бэкенд / другое
Отказоустойчивость
Распределенные системы
Архитектура данных, потоки данных, версионирование

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

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

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

Доклад принят в программу конференции

Fullstack v2: я научу вас писать UI на Go

Браузеры
Фреймворки
Мобильные приложения без native (PWA, AMP)
Кросплатформенная разработка
Мобильные приложения / другое
GO
Адаптивная вёрстка
Илья Глухов

Независимый эксперт

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

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

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

Доклад принят в программу конференции

Проекты и решения на Go (4)

Opentelemetry и эволюция распределенного пайплайна трейсинга в Авито

GO
Observability в enterprise
Оптимизация

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

Доклад принят в программу конференции

Go в умном доме: опыт успешной интеграции

Расширение кругозора

В докладе я расскажу о своём опыте написания интеграции 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 для камер.

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

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

Доклад принят в программу конференции

Rock’n’roll — это не работа: пишем обработку звука на Go

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

Доклад принят в программу конференции

Видишь суслика? А он есть! Как переехала на Go Главная страница Яндекса

Рефакторинг
Критерии выбора технологий для проекта
GO

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

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

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

Доклад принят в программу конференции

Идеальный язык (3)

Мир Golang глазами C++-разработчика: так ли уж плох этот наш Go?

GO
Никита Деревянко

Яндекс Маркет

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

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

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

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

Доклад принят в программу конференции

Расширяем Go: зачем и как строить свое надмножество языка

GO
Теория
Илья Горкун

Независимый эксперт

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

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

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

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

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

Доклад принят в программу конференции

В поисках идеального языка: чему Go стоит поучиться у Rust

Прочие языки
GO

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

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

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

Доклад принят в программу конференции

Go и AI (1)

Как воспитать себе помощника: применение локального ИИ для разработки

Java
Методы и техника разработки ПО
Автоматизация разработки и тестирования
GO
ML
Профессиональное развитие инженера
Лайфхаки
Алексей Цветков

Независимый эксперт

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

Доклад принят в программу конференции

Резерв (1)

Прагматичная архитектура: как проектировать Go-приложение, руководствуясь чисто практическими соображениями

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

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

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

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

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

Доклад принят в программу конференции