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

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

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

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

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

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

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

Picodata

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

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

Команда Picodata долгое время разрабатывала и внедряла решения на основе Tarantool, а теперь мы переосмыслили его в cluster-first парадигме. В докладе я расскажу о продуктовых и архитектурных решениях, которые этому сопутствовали:

- Кластер-менеджер мы построили на Raft без использования внешнего state provider и объединили в нем хранение топологии и хранение схемы данных
- Для хранения данных мы используем глобальные и шардированные таблицы, а доступ к ним реализуем посредством языка SQL
- За компанию реализовали близкие к стандарту средства управления доступом
- А для расширения функциональности предоставляем Plugin API

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

Зачем мы унесли три сотни кластеров Postgres в кубер, и как теперь с этим живём

В докладе я расскажу:
- Какова сейчас архитектура компонента Postgres, и почему у нас так много БД
- Мотивация переезда и выбор реализации
- Про сам переезд
- Какие проблемы мы решали переездом в кубер
- Какие проблемы мы получили после переезда в кубер

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

Про UUID v7

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

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

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

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

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

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

Выбор OLAP и OLTP решения для импортозамещения СУБД

Абрамов Антон

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

1. Рассмотрим варианты СУБД с открытым исходным кодом. Например, Greenplum, Hadoop, PostgreSQL, ClickHouse и Tarantool и зоны их применения.
2. Дадим краткую вводную по розничной CRM Газпромбанка: архитектура текущего решения, включая используемую в настоящее время СУБД MSSQL Server, какие OLAP и OLTP нагрузки выдерживает, в какой предел производительности уперлись на уровне СУБД и почему.
3. Обсудим, какие решения с открытым исходным кодом были выбраны для импортозамещения текущего MSSQL Server, чтобы иметь возможность выдерживать нагрузки, кратно превышающие текущие на ПРОМ, и почему.
4. Расскажем о возможностях горизонтального и вертикального масштабирования выбранных решений (PostgresPro от Postgres Professional и Greenplum от Arenаdata DB) на примере проведенных НТ в рамках пилотов.
5. Расскажем о том, какие инструменты имеются для того, чтобы процессы репликации данных на уровне СУБД не влияли на работу прикладных сервисов в момент работы репликации (не вызывали блокировки, конфликт за ресурсы и т.д.)

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

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

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

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

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

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

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

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

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

Автоматизация развертывания OpenStack с помощью GitLab CI/CD и Terraform

Devops / другое
Эффективное использование облаков
Облака
DevOps / SRE
Инфраструктура

- Введение в автоматизацию инфраструктуры: обзор основных инструментов и подходов.
- Использование GitLab CI/CD для создания виртуальной среды в облаке OpenStack.
- Роль Terraform как инструмента для управления инфраструктурой как кодом (IaC).
- Создание пользовательских образов и настройка виртуальных машин и сетей с помощью Terraform.
- Генерация инвентаря Ansible для управления развертыванием OpenStack с помощью kolla-ansible.
- Эффективное развертывание OpenStack для разработчиков с использованием GitLab CI/CD и Terraform.
- Примеры использования: разработка кода для основных проектов OpenStack и создание пользовательских установок.
- Практические рекомендации и лучшие практики по автоматизации развертывания OpenStack.
- Перспективы расширения автоматизированных процессов для развертывания реального облака в будущем.

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

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

Observability в enterprise
Хранилища

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

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

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

Эффект бабочки в SRE

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

* Крупный сбой полученный при смене базового докер-образа для одного из микросервисов. Этот сбой стоил нам двух часов бюджета SLA
* Полный отказ записи данных в кластер Elasticsearch через месяц после внесения правки в конфигурацию кластера
* Драматическая деградация производительности серверов из-за обновления микрокода

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

Масштабирование предоставления оборудования без операционной системы (baremetal) с помощью Nova и Ironic

Devops / другое
Инфраструктура

- Введение в проблематику: значимость эффективного масштабирования предоставления оборудования без операционной системы.
- Краткое упоминание об основных пользователях данного опенсорс решения (Есть замечательная статья в CERN, которым мы вдохновляемся и с которым работаем) https://superuser.openinfra.dev/articles/scaling-bare-metal-provisioning-with-nova-and-ironic-at-cern-challenges-solutions/ .
- Роль Nova и Ironic в решении задач предоставления оборудования без операционной системы.
- Архитектурные особенности решения: как Nova и Ironic интегрируются и взаимодействуют в облаке.
- Преимущества использования Nova и Ironic для масштабирования предоставления оборудования без операционной системы.
- Вызовы, с которыми столкнулась команда при реализации и масштабировании данного решения.
- Практический опыт применения Nova и Ironic: результаты, достижения и уроки, извлеченные из проекта.
- Перспективы будущего развития и улучшения решения с использованием Nova и Ironic в контексте среды.

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

Highload Паттерны при создании автоматизаций на PowerShell 7, рецепт для DevOps

Логирование и мониторинг
Непрерывное развертывание и деплой
DevOps на собственном (арендованном) оборудовании

* Немного про планирование
* Проблематика или почему не Ansible
* Структура PS скриптов для HL
* "Минимальное документирование но сразу"
* Паттерн "Чек здоровья"
* Паттерн "Логирование событий"
* Явное разделение на последовательные и параллельные процессы
* Паттерн "Асинхронная обработка"
* Паттерн "Управление потоками'
* Паттерн "Пытаемся снова"
* Паттерн "Обработка ошибок"
* Паттерн "Кроссплатформенность"
* Паттерн "Идемпотентность"
* "Юнит тестирование"
* "Контроль версии при запуске"
* Паттерн "Откат изменений"
* Паттерн "Состояние"

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

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

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

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

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

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

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

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

На просторах интернета много информации о том, как автоматизировать сеть офиса или как за три секунды раскатить типовую конфигурацию на новое железо. Мы же прошли через автоматизацию сетевой инфраструктуры одного из самых старых ЦОДов России (наша площадка ОСТ открылась в 2009 году). Расскажу о том, что мы предприняли чтобы начать автоматически конфигурировать услуги на проде и при интеграции не допустить перерыва сервиса для более чем восьмиста клиентов, какие проблемы нам удалось решить и почему в какой-то момент приняли решение начать всё заново.

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

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

Павел Шерепо

VK, ВКонтакте

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

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

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

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

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

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

VK, ВКонтакте

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

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

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

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

Железный FinOPS

про управление расходами на облачную инфраструктуру сейчас не говорит только ленивый - слово FinOPS у всех на слуху. А что делать с on-premise инфраструктурой? Действительно ли это дорого? И как правильно считать затраты на эксплуатацию?

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

Экономим $mln на внедрении Capacity Planning

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверить код ИБ нельзя успеть к релизу

Защита информации
Управление изменениями
Безопасность от планирования до эксплуатации
Автоматизация разработки, доставки, эксплуатации
Безопасная коммуникация, культура
Безопасность
Инфобезопасность
Владислав Верусь

ООО "ВКонтакте"

В рамках дежурных смен и ad hoc активностей, мне, как дежурному, ежедневно приходится проверять MR'ы в код приложений и продуктов. За день дежурному приходится просматривать около 60-70 MR'ов, и, как можно предположить, острота внимания к концу рабочего дня притупляется, а риск пропустить уязвимый пакет или забытый при разработке секрет кратно возрастает, не говоря уж про огромное количество остальных дежурных активностей. Добавляем в эту ситуацию недовольство разработчиков из-за увеличивающихся сроков проверки и задержку выкатки релизов, фиксов и фичей и получаем неблагоприятное мнение об ИБ отделе.

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

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

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

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

Рассмотрим наиболее популярные уязвимости в крупных продуктах по части построения инфраструктуры и приклада высоконагруженных систем.
Традиционно покажу уязвимости и ошибки, которые допускают администраторы и программисты в таких системах. И там таблетки как лечить и какими процессами
Более подробный перечень:
1) Уязвимости в образах и зависимостях
2) Уязвимости контейнерных сборок
3) Уязвимости интеграций микросервисов со службами
4) Уязвимости инфраструктуры подхода IaC
5) Уязвимости окружения продакшена
По каждому классу приведу реальные кейсы и методы борьбы с ними.
Рассмотрим стек ASP.NET, Python, Java, Go

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

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

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

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

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

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

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

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.

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

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

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

Apache Spark - замечательный инструмент дата-инженеров, который поддерживает языки Scala, Java, Python и другие. Но что бы не было выбрано, вам неминуемо понадобится установить клиент, подключить библиотеки, настроить окружение. И для сложных расчётов это оправдано, их удобнее писать с кофе в какой-нибудь полюбившейся IDE. Однако, иногда хочется оперативно выполнить SELECT на пару строчек, проверив гипотезу, и продолжить заниматься своими делами.
Именно для этой цели в YTsaurus развивается модуль Query Tracker, позволяющий прямо в браузере запускать SQL-like запросы на разных движках: полноценном MapReduce, Clickhouse или Spark.
В этом докладе я расскажу: как строился сервис быстрых SQL запросов поверх Apache Spark, какие готовые решения принесли пользу, а также что за монстры встретились в этом приключении.

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

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

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

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

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

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

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

От pretrain до alignment: как мы обучали языковую модель GigaChat

ML

Мы расскажем о том, как обучали гигачат:

1) о важности сбора чистых данных для претрейна, их фильтрациях
2) о возможности дообучать модели, важности выбора правильной смеси данных
3) о том, как делали SFT-пайплайн и налаживали взаимодействие гигачата с другими моделями через функции

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

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

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

Альфа-банк

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

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

Зачем мы запускаем 20000 моделей dbt сразу на 2х разных оркестраторах и с чем столкнулись на таких масштабах

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

Задача заключается в замене оркестратора и ELT инструмента на высоконагруженном хранилище.
На старте проекта были следующие вводные:
- Хранилище эксплуатируют 10+ доменных команд разработки
- Ежедневно выполняется 5000+ регламентных расчетов.
- Хранилище играет ключевую роль в процессах работы компании.
- Сохранение текущих строгих SLA подготовки данных.
- Сохранение процесса развития хранилища под потребности бизнеса.
Расскажем какой путь прошли во время миграции с вендорного SAS DI на OpenSource экосистему из Airflow + dbt

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

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

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

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

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

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

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

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

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

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

Газпромбанк

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

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

Расскажем, как мы применяем data science в погоне за мечтой о взаимности:

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

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

Влияние трендов в машинном обучении на образование в области AI

Трансформационные изменения
Расширение кругозора
Обзор

В докладе будет рассказано о том, как на факультете компьютерных наук Высшей Школы Экономики строят образовательные программы с учетом постоянно меняющихся трендов в области искусственного интеллекта. В частности, мы расскажем, какие курсы по искусственному интеллекту и треки на программах (и даже какие новые образовательные программы) появились на факультете в последние два года в связи с запросом из индустрии. Также мы расскажем об онлайн и очных мероприятиях для студентов, которые мы организуем с учетом трендов в области AI и потребностей рынка.

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

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

ETL
Обработка данных
Максим Буйлин

Тинькофф

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

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

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

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

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

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

Атаки на 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 в тысячах видео найти нужный кадр по описанию

Перед нашей командой стояла задача находить за несколько секунд нужный фрагмент среди нескольких тысяч часов видеоконтента. Критерии поиска самые различные: от произнесенной фразы в кадре до произвольного описания на русском языке.
В докладе я расскажу о пайплайне из 15 ML моделей для извлечения фичей из видео. О том подружили Dagster с Celery, заставили Celery обрабатывать большие задачи и ускорили обработку контента в 11 раз с помощью связки из Dagster - Celery. Как с помощью Kubernetes обеспечиваем отказоустойчивость и версионирование. Как с помощью Qdrant мы находим ответы на самые сложные запросы от пользователей. И о том, как мы помогли промо продюсерам сократить время разработки в 24 раза

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

MERA: новый инструктивный бенчмарк для оценки фундаментальных моделей

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

Доклад посвящен MERA: Multimodal Evaluation for Russian-language Architectures - новому инструктивному бенчмарку для тестирования и оценки фундаментальных моделей нового поколения. MERA представляет из себя открытую платформу для исследования способностей фундаментальных моделей, которая включает в себя широкий набор заданий для оценки интеллектуальных способностей моделей (от общего знания о мире, до умения писать код и способности решить ЕГЭ), кодовую базу для оценки и открытый лидерборд. Проект собирает всех игроков индустрии и академии в одном месте, а его ключевыми чертами проекта являются открытость и прозрачность процедуры оценки.

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

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

Максим Метальников

ПАО "Сбербанк"

Максим Смоляков

ПАО "Сбербанк"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура беспилотного транспорта нового поколения

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

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

Где и как использовать LLM в задачах поиска

В докладе расскажу о том как LLM могут быть полезны для улучшения качества поисковых алгоритмов.
Будут затронуты следующие вопросы:
— как ускорить разметку и собрать больше примеров для обучения и валидации;

— как обогатить индекс дополнительной информацией и знать больше о документах;

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

— как использовать эмбеддинги от LLM в проде для улучшения семантического поиска;

— как сформировать позапросный индекс дообучая LLM и в чем его преимущества по сравнению с эмбеддиноговым поиском.

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

Структурированная нормализация текста с использованием недетерминированных FST

* Что такое нормализация текста и зачем она нужна
* Что такое конечные автоматы, принципы работы конечных автоматов
* Использование конечных автоматов для обработки текста
* Оптимизация FST, принципы построения сложных конечных автоматов
* Декомпозиция процесса нормализации
* Продвинутые способы построения FST для выполнения сложной многоэтапной обработки текста
* Использование недетерминированных FST для повышения качества нормализации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как мы оптимизировали ML-ки и обогнали xgboost в 7 раз

C/C++
Алгоритмы и их сравнение
Оптимизация
Рекомендации / ML
Александр Кирсанов

VK, ВКонтакте

В нашем продакшене ML-модели используются давно, и во многих сервисах они развивались параллельно и реализованы у кого как. Настало время унифицировать инференс и повысить производительность. Чтобы избежать требования переписать весь ML, мы решили написать общее ядро для инференса деревьев решений, которое бы работало идентично xgboost/catboost, только в рамках наших ограничений (CPU и один поток). В итоге получилось сделать отдельные алгоритмы, работающие как оригинальные, но обгоняющие их по скорости.

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

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

Использование JMH (Java Microbenchmark Harness) для точного измерения производительности в Java: обзор методологий и лучших практик при создании микробенчмарков в Java.

Java
Оптимизация

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

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

gRPC стримы на практике - к чему готовиться

Мы построили свой альтернативный интерфейс для Kafka через промежуточный сервис на Go и синхронный gRPC-стрим. И это помогло нам выдержать до 5млн RPS, при этом сократив нагрузку на брокеры.

Я расскажу на какие грабли мы наступили, и как не наступить на них вам. Поговорим о том как устроен gRPC-стрим и на что вам стоит обратить внимание при затаскивании такого способа взаимодействия в свои проекты. Почему важно помнить про flow-control, дедлоки и graceful shutdown. И, конечно, затронем тему балансировки нагрузки при работе со стримами.

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

«Бегущий по витринам»

Расскажем о том, как контент, загруженный на платформу KION, попадает на витрины онлайн кинотеатра — в realtime и с помощью Machine Learning.

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

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

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

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

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

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

Remout Config и АБ эксперименты

Расскажем о том, как сделать свой Remout Config и разбивалку для проведения АБ экспериментов (аналог firebase).

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

Доверяй, но проверяй

Расскажем о том, как KION обрабатывают свыше 400М продуктовых событий в сутки, слои обеспечения Data Quality. Путь от приемника до витрины.

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

Свой приемник событий

Расскажем о том, как создать свой приемник событий со средней нагрузкой 6000RPS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Речь пойдёт про борьбу с флаками изолированных тестов — т.е. тестов, которые должны быть зелёными 100% времени, т.к. не ходят никуда по сети, и т.д.

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

Митапы (1)

Fail-митап

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

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

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

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

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

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

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

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

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

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

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

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. Что удалось достигнуть и наши рекомендации.

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

Построение TelcoCloud – частное облако для телекома

Дмитрий Горохов

Инфосистемы Джет

Алексей Пантелеев

Инфосистемы Джет

Расскажем как мы построили частное облако для сетевых сервисов одного из крупнейших телеком-операторов РФ на open-source решениях, которыми будут пользоваться 30-40 миллионов абонентов по всей стране.

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

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

Нагрузочное тестирование АБС на импортозамещенном стеке

Профилирование и отладка кода
Приёмочные и функциональные тесты
QA / другое

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

Обсудим:
Подход и цели тестирования
Оценка результатов
Выявленные тех. проблемы
Ключевые показатели производительности и метрики

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

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

Сергей Жебет

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

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

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

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

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

API
GO

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

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

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

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

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

Нагрузочное тестирование - управление долгоиграющими процессами и работа с метриками

Ксения Бирюкова

Платформа Сфера

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

Дополнительно, рассматриваем возможность проведения мастер-класса.
Можно в связке с докладом, возможно отдельно.
Есть два варианта:
1. запуск нагрузочного тестирования несколькими инструментами
показать как не собрать типовые ошибки, как работает инструмент, как пишутся скрипты, как запускаются, как анализировать отчёты и тд (может сочетаться с докладом, так как в нём рассказывается о разработке платформы со всеми тремя генераторами нагрузки)
(к6, jmeter, gatling)
2. вместе с аудиторией попробовать разработать свой плагин для к6
разбираемся с хк6, пишем сам плагин (функционал + метрики), компилируем, запускаем и смотрим результаты
(чуть меньше сочетается с докладом, но всё же подходит, так как в рамках разработки платформы плагины мы тоже добавляли и можно информацию об этом добавить в доклад)

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

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

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

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

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

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

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

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

Как построить архитектуру и процессы распространения данных нового микросервисного ядра Банка

Лев Осипов

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

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

В рамках доклада будут разобраны следующие темы:
- Концепция ядра банка до и после миграции
- Основные типы бизнес-процессов потребления данных ядра в старой концепции + новые запросы от потребителей
- Как мы строим новую архитектуру распространения данных для удовлетворения всех потребностей, но с единым подходом

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

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

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


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

AaC- панацея или хайп

кому и зачем
порог входа
что гарантирует успех

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

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

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

VK / VK Реклама

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

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

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

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

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

Типовые проблемы highload-проектов в микросервисной архитектуре

За последние несколько лет продукт, которым я руковожу, вырос больше чем в 30 раз.
Мы потратили много сил и времени на то, чтобы подготовить не только себя, но и другие сервисы Авито к нашему лавинообразному росту. В докладе я расскажу про основные проблемы, с которыми приходилось сталкиваться и решениях, которые помогли с ними справиться. Поговорим про них на примере абстрактного сервиса "Еще один крутой сервис" и посмотрим, как будет меняться его архитектура.

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

Быстрый поиск на 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 на продакшене.

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

Как мы увеличили пропускную способность поиска картинок с помощью ML и изменения архитектуры

Картинки - это часть поиска Яндекса, работающий с визуальным контентом и обрабатывающий более 10 000 тяжёлых запросов в секунду с помощью десятков тысяч CPU в рантайме. Мы расскажем, как столкнувшись с необходимостью масштабирования сервиса, с помощью ML в сочетании с архитектурными изменениями смогли не только увеличить пропускную способность в ~2 раза на том же железе, но и дать инструмент для более гибких продуктовых внедрений.

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

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

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

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

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

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

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

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

VK / VK Реклама

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

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

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

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

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

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

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

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

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

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

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

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

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

Делаем потоковые машины состояний для обогащения и подготовки товарных данных

API
Оптимизация производительности
Распределенные системы
Архитектура данных, потоки данных, версионирование
Критерии выбора технологий для проекта
GO
Микросервисы
YDB

В этом докладе я расскажу о том как мы строили систему обработки данных о товарах так чтобы ее было легко дополнять новыми процессамии и масштабировать.
Перед тем как начать проектровать новую систему мы провели анализ всех наших процессов построенных вокруг товарных данных. Товаров у нас больше 100M и обрабатывать их нужно несколько раз в день. Как оказалось оновное, что происходит с данными это путешествие записи по состояниям. За переход между состояниями обычно отвечает отдельный сервис. Я расскажу как мы построили и перешли на систему построенную на этих принципах. Почему в качестве СУБД мы выбрали YDB. И как мы уменьшили потоки данных в несколько раз.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Черные лебеди в HighLoad-системах

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

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

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

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

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

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

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

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

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

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

Илья Иванов

Яндекс 360

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

Также затронем:
— За счет чего достигается гибкость биллингов Яндекса, как мы разделяем процессинг платежей и продуктовую логику
— Как нам удается выдерживать нагрузку в 3000 RPS и ничего не уронить.
— Чем отличается современный биллинг от сервиса, отвечающего за обработку платежей.
— Обсудим как распределяется нагрузка между разными уровнями.

На примере Биллинга Яндекс 360 рассмотрим, как представляются продукты и какие подписочные механики нам помогают их продавать.

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

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

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

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


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



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

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

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

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

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

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

Как мы раздаем картинки в дзене и история одного переезда

Миграции данных
Бэкенд / другое
Отказоустойчивость
Микросервисы
Зуев Евгений

ООО "ДЗЕН.ПЛАТФОРМА"

Как перевезти сервис с 120к рпс? а дважды ?
Как раздавать 100500 вариантов картинок на лету и не потратить все деньги мира на железо?
Почему не тупо с3?


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


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

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

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

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

Сбербанк-Технологии

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

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

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

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

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

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

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

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

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

Low-code аналитика на предельной скорости

Влияние low-code аналитики на современные бизнес-процессы. Ее роль в ускорении цикла разработки аналитических решений. Продвинутая аналитика без ИТ-департамента. Как low-code позволяет эффективно использовать ресурсы и сокращать затраты. Рассмотрение примеров применения low-code аналитики, с фокусом на платформе Loginom. Описание платформы Loginom и ее основных возможностей. Рассмотрение техник, применяемых в платформе для обеспечения высокой скорости обработки данных, экономного расходования памяти и возможностей масштабирования. Обсуждение причин быстрой работы Loginom и используемых методов оптимизации.

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

Давайте построим движок поиска отелей

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

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

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

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

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

Отказоустойчивая виртуализация на отечественных решениях: ожидание и реальность. Реальный опыт построения метро-кластера на отечественной СХД и виртуализации

Дмитрий Горохов

Инфосистемы Джет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Осмысленный подход к построению облачной инфраструктуры с использованием Open Source на практике: от задач автоматизации к цифровой трансформации"

Devops / другое
Эффективное использование облаков
Облака
DevOps / SRE
Инфраструктура

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

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

Оффтоп (3)

Ипотека для IT специалистов

Оксана Лаврова

Тренд новостройки

Инвестиции в недвижимость с помощью IT ипотеки
Квартиры мечты для жизни
Кейсы, расчёты и лайфхаки

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

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

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

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

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

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

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

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

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

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

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

Воркшоп (2)

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

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

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

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

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

Postgres Pre-Commitfest Party

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

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

Резерв (4)

Identity Aware Proxy - как перестать раздавать доступы через VPN

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

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

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

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

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

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

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

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

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

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

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

Уже более двух лет создаем MLops платформу для создания рекомендательных сценариев.
В докладе будет рассказано
- Как реализовали работу со Spark нагрузками на RecSys платформе
- Какие были проблемы со Spark и почему пришли к текущему решению
- Как использовать Spark в Multi-tenant архитектуре.
- Также поговорим о проблемах использования Spark in k8s.

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

Point in time recovery в базе данных ETCD

SPQR — система для горизонтального масштабирования PostgreSQL посредством шардирования.

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

В PostgreSQL реализована поддержка Point-in-Time Recovery -восстановление состояния базы данных на определенный момент во времени. Хотелось иметь этот функционал и в SPQR, но для этого необходимо было научиться делать PITR в ETCD.

В докладе я расскажу о том, что такое Point-in-Time Recovery, как происходила реализация этой технологии в базе данных ETCD и с какими трудностями пришлось столкнуться.

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

Архитектурная прожарка (2)

SberAds: современные технологии в legacy продукте

C/C++
Бэкенд / другое
Tarantool
Базы данных / другое
Отказоустойчивость
Стандарты кодирования
Масштабирование с нуля
Логирование и мониторинг
Поддержка и развитие legacy систем
GO
Observability в enterprise
DevOps / Кубер

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

В докладе я хочу осветить как нынешний SberAds вырос из кодовой базы, созданной еще в begun.ru, а затем долгое время жившей в Рамблере. Сейчас, когда у нас огромные планы роста, мы модернизируем наш технологичесий стек. Я расскажу как мы:
- стали переходить на Go;
- перемещаем старые сервисы в Kubernetes;
- внедряли istio и какую пользу получили от этого;
- интегрировали jaeger;
- стали использовать tarantool;
- заменили самописные "сокеты на стейройдах" на kafka;
- стандартизировали мониторинги;
- и, самое главное, стали горизонтально масштабируемыми.

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

Проектирование БД: От NF к денормализации данных

Миграции данных
Базы данных / другое
Рефакторинг
Архитектуры / другое
Оптимизация

Когда я учился в университете нас учили проектировать БД с помощью нормальных форма(NF). Однако на работе я столкнулся с тем, что с ростом проекта, увеличения кол-ва данных этот подход работает медленно. Об этом я и хочу рассказать.

Я один из разработчиков edu.tinkoff.ru, которые строили платформу с самого начала.

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

Edge Computing (3)

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

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

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

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

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

ML

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GO

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

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

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

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

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

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

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

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

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

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

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

CRM как платформа. Решения, подводные камни при проектировании архитектуры.

Avito RE-Arm — платформа, на базе которой, сотрудники любого профиля могут реализовывать бизнес процессы. Более того это не просто платформа, это огромный опыт, которая получала моя команда и я начиная от формирование самой команды и требований, заканчивая уже конкретно поставленных задач. Начиная от простых по типу "Поставил задачу - Закрыл задачу" и более сложных "А еще хочу уведомлять, автораспределять, звонить, а еще и статистику хранить".

На таком объёме поставленных требований, на первый взгляд, задача "Сейчас сделаю сервис и кучеряво заживем" обрастает большим количеством проблем, которые затрагивали как формирования процесса, так и создание самой платформы:
* как создать роадмап если бизнес не совсем определился с требованиями
* как выжить в течении квартала с двумя мидлами и одним стажером
* что может помочь если новые тиммейты видели Go только на картинках
* как хранить данные и как их обрабатывать
* как предвидеть резкое увеличение нагрузки
* как обеспечить внесение изменения в платформу другими командами и не умереть
* как быть с авторизацией и к чему может привести не правильный выбор
* как написать распределение тасок для покрытия бизнес процессов разных направлений

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

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

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

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

VK, ВКонтакте

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

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

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

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

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

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

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

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

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

Магия процессов: Реализация эффективного CI/CD с применением автоматизации в ваших проектах.

API
Непрерывное развертывание и деплой
GO
Автоматизация разработки, доставки, эксплуатации
Облака

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

Мы вместе пройдем через реальный пример небольшого Go-приложения, и я покажу, как автоматизировать каждый этап разработки, начиная от проверки линтера и заканчивая развертыванием в продакшен. С помощью Github Actions мы настроим базовые процессы CI/CD, а затем реализуем деплой приложения в инфраструктуру Yandex Cloud. Присоединяйтесь, чтобы открыть новые горизонты автоматизации и сделать вашу разработку более удобной и эффективной.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тинькофф

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

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

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

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

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

Go и AI (3)

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

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

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

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

Exploring AI-Powered Image Discovery: Advanced Techniques with TensorFlow and Go

Salma Shaik

OpenMined

Join us on a journey into the world of AI-powered image discovery using TensorFlow and Go. This talk will delve into advanced techniques for image classification, object recognition, and more, all within the context of Go programming. We will explore the integration of TensorFlow's powerful machine learning capabilities with Go's efficient concurrency model, enabling developers to build intelligent image search applications. From understanding the basics of AI and machine learning to implementing complex algorithms for image analysis, this talk will provide a comprehensive guide for leveraging TensorFlow and Go in your projects. Whether you're a seasoned developer or just starting with AI, this talk will equip you with the knowledge and tools to unlock the full potential of AI-driven image discovery.

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

Алиса? Салют? Алекса? Нет, <Название ассистента в разработке> !

embedded, AI, Rassbery PI, Repka PI, gobot, devices, gpt

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

Резерв (2)

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

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

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

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

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

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

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

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

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

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

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

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

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