Доклады

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

Переизобретаем файловую систему: OpenZFS

Архитектуры / другое
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Администрирование баз данных
Надёжность продакшена
Хранилища
Технологии VK

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

Поcмотрим на проверенную боем OpenZFS, почему её хочется использовать (кто сказал "деградация данных"?) и когда её использовать не стоит (ммм, zero copy в Copy-on-Write).

Также не забудем о людях — обсудим комьюнити, как ФС может пережить родную ОС и жить вне ядра.

Взгляд со стороны контрибьютора.

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

Как сделать поиск в интернет-магазине

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

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

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

YTsaurus: опыт эксплуатации хранилища из 180К дисков

Отказоустойчивость
Распределенные системы
Управление конфигурацией
Хранилища
Инфраструктура

YTsaurus — основная платформа Яндекса для хранения и обработки больших данных, ad hoc-аналитики, построения ETL-задач и регулярных batch-процессов. Сегодня самый большой кластер YTsaurus содержит более 20К хостов различной конфигурации — от 4 до 24 дисков, суммарно более 180К дисков.

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

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

Эффективное обновление состояний в БД из сервисов потоковой обработки

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

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

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

Вроде все просто, какие тут могут быть проблемы? На самом деле проблемы ожидаемые, у нас же Highload, и, если работать с нашей таблицей с баннерами наивным способом, то будем создавать слишком большую нагрузку.

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

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

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

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

7 петабайт логов в Elastic. Как мы это сделали?

В Тинькофф тысячи сервисов, и все эти сервисы пишут логи. За сбор логов и метрик отвечает Sage — платформа мониторинга собственной разработки с Elasticsearch под капотом. Объемы логов постоянно росли и сейчас это 7 ПБ, а суммарное количество нод на 15 кластерах в двух ДЦ достигло 370 штук. На таких объемах вылезает много проблем: под нагрузкой кластеры могут разваливаться, встроенный ILM уже неудобен, да и сопровождать это непросто. В докладе автор расскажет, как эти проблемы были решены в Sage, а также поделится информацией о внутреннем устройстве Elastic.

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

Революция в управлении данными — рассвет графовых баз данных

Базы данных / другое
Архитектура данных, потоки данных, версионирование
Архитектуры / другое
Денис Пчелинцев

Девелоника

1. Почему графы.
2. Бизнес-сценарий: цели, задачи и результаты.
3. Модели данных — "реляционка" против графа.
4. Области применения.
5. Наши планы по развитию.

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

Эволюция репликации в Tarantool. Путь от master-replica к master-master и от асинхронной репликации к синхронной с выборами лидера

Tarantool
Распределенные системы
Обработка данных
Расширение кругозора
Технологии VK

Tarantool прошёл большой путь в репликации. Начиналось всё с master-replica без поддержки транзакций, затем появилась поддержка master-master, потом и поддержка транзакций. Одновременно с этим появились нереплицируемые таблицы. Последним нововведением стала синхронная репликация и автоматические выборы лидера.

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

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

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

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

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

Аналитическая подсистема позволяет анализировать как данные, поступающие в реальном времени, так и исторические данные, диагностировать проблемы, выявлять тренды, строить прогнозы и планы на будущее, список можно продолжать бесконечно… Казалось бы, в чем тут проблема? Прикрути BI-систему и строй себе отчеты на оперативных данных. К сожалению, когда речь заходит про объемы данных, характерные для систем класса BigData, то это перестает работать и нужно строить отдельный аналитический кластер, который синхронизируется с оперативным хранилищем.

Почему не работает подход с единой СУБД при очень больших объемах данных и как сделать так, чтобы данные в аналитическом слое не отставали от оперативных и при этом не растерять эти данные по дороге, я расскажу в своем докладе.

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

Современные базы данных. Как выбрать СУБД в 2023?

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

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

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

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

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

Распределенные графовые СУБД — будущее для аналитики на Больших Данных?

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

Графовые СУБД в последнее время стали очень популярны для аналитических задач. Традиционно к графовым СУБД относились скептически из-за их производительности и масштабируемости: например, очень популярная СУБД Neo4j пока практически не масштабируется на несколько узлов. Но появились новые системы, изначально разработанные как распределенные графовые СУБД, которые в состоянии уже хранить и обрабатывать десятки терабайт данных, а в скором будущем смогут масштабироваться до петабайт.

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

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

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

Переход к Platform as a Service в Яндекс Вертикалях: опыт, проблемы, ошибки

Константин Касев

Яндекс.Вертикали Технологии

Мария Васильева

Яндекс.Вертикали Технологии

Всего пять лет назад в Яндекс Вертикалях разработчики деплоили приложения deb-пакетами. Логи писались в файлы, деплой был долгим и неудобным, мониторинг и алерты лежали на плечах админов — и им же звонили. Мы жили на железе и ручном приводе. Из такой точки А начался наш путь к прекрасному PaaS будущего.

Теперь мы живем в облаке, у админов много автоматики, и звонки только по ops-проблемам. Разработчики наших сервисов деплоят по кнопке из телеграм-бота или Web UI, пользуются автосгенерированными дашбордами, просматривают логи сервисов в Grafana и анализируют трейсы. В нашей платформе доступны canary- и branch-деплои и запуск периодических задач. Процесс подготовки сервиса к запуску — это написание карты сервиса и манифеста деплоя, что занимает минимум времени. И все это — без вовлечения в процесс службы эксплуатации.

В нашем докладе расскажем о трудностях, которые мы преодолели при переходе к концепции PaaS:
* Как мы переехали с железа в Яндекс Облако: сервера приложений, базы данных, инфраструктурные сервера.
* Как мы выбирали компоненты инфраструктуры под капотом PaaS.
* Как мы перешли от статической конфигурации балансеров руками админов к динамической.
* Как писали Shiva — систему деплоя и инструменты автоматизации для упрощения жизни разработки.

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

Legacy PHP-FPM в Kubernetes. Тернистый путь опсов

Технологии виртуализации и контейнеризации
DevOps / Кубер
DevOps / SRE

* Перенос legacy PHP-FPM в Kubernetes.
* Горизонтальное масштабирование PHP-FPM.
* Деплой во время нагрузки.

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

Как мы управляем инфраструктурой на более чем 1000 серверах при помощи ansible

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

Расскажем:
* как управляем более чем 1000 хостов при помощи ansible с постоянным деплоем изменений на все сервера;
* как мы написали ansible-agent и ansible-server, который экономит нам ресурсы и время, как он работает и деплоится на сервера;
* как мы строим свой проект и как применяем AWX.

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

Мы охлаждаем воздухом. Дата-центр Яндекса. Какой он?

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

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

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

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

VK Звонки: оцениваем качество видео объективно

Технологии VK
Алексей Шпагин

VK, ВКонтакте

Почему иногда во время звонка зависает видео от кого-то из участников? Почему видео может “пикселить” или напоминать слайд-шоу, и что из этого больше расстраивает пользователей видеоконференций? Как оценить качество видео и выразить эту оценку в виде одного числа?

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

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

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

GPT3+-модели в задачах кибербезопасности

Безопасность

Художники, копирайтеры и журналисты уже на заводе. Пора ли безопасникам идти в магазин за робой?

В рамках доклада разберем, как уже используются GPT3+-модели ИБ-шниками, разработчиками и администраторами.

Кто нам ChatGPT? Друг, враг или так?

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

Пять стадий принятия кибербезопасности

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

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

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

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

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

Управляем доступом в распределённой Linux-инфраструктуре

Логирование и мониторинг
Управление изменениями
Безопасность
Безопасность инфраструктуры

В докладе расскажем, что такое система управления привилегированным доступом (PAM), зачем она нужна и каким критериям она должна соответствовать. Проведём краткое сравнение различных подходов к управлению доступом в высоконагруженных и распределённых Linux-инфраструктурах. Расскажем про свой опыт проектирования и внедрения системы управления доступом на основе open source-решений и собственных разработок. Подробно остановимся на том, как внедрение таких систем влияет на изменение процессов эксплуатации, разработки и DevOps, а также разберёмся, влияют ли эти системы на time to market.

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

CTF as a Service

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

Раздел ИБ — это не только про бумажки и формальности, это практика! Но где искать молодых и амбициозных специалистов? Как проверить их реальные навыки в игровой форме, не подставляя под удар критическую инфраструктуру? Выход есть — CTF-соревнования! С их помощью можно не только собирать под одной крышей как юных, так и опытных специалистов, но и находить себе достойные кадры с практическими навыками в ИБ.

В докладе рассмотрим, как можно быстро и эффективно развернуть как Task-Based-, так и Attack-Defence-соревнования, как их грамотно настроить, чтобы не упасть при запуске соревнований и не быть взломанными, а также как настроить GitOps и какие подводные камни есть при разворачивании.

Еще сделаем краткий обзор доступных open-source-средств и платформ для проведения разных форматов CTF.

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

Подсматриваем за Linux-инфраструктурой и выявляем атаки

Логирование и мониторинг
Observability в enterprise
Безопасность
Безопасность инфраструктуры

В докладе обсудим основные подходы к построению мониторинга информационной безопасности для высоконагруженной и распределённой Linux-инфраструктуры. Разберёмся, чем средства мониторинга ИБ отличаются от классических средств мониторинга. Проведём анализ и сравнение существующих решений, таких как go-audit, osquery, Wazuh, Elastic Agent и некоторых других. Расскажем, почему мы выбрали osquery в качестве ядра нашей системы. Поделимся проблемами, с которыми мы столкнулись при внедрении osquery, а также расскажем, как мы их решали. На практических примерах покажем, как внедрение системы мониторинга упрощает расследование атак. Обсудим, может ли такая система быть полезна командам эксплуатации и разработки.

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

SAST'оумие и отвага

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

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

Я расскажу, как сделать этот инструмент эффективным оружием по поиску уязвимостей, и покажу, какие уязвимости можно найти с помощью SAST.

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

Безопасность CI/CD

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

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

В ходе доклада мы разберемся, как защищаться от основных угроз в CI/CD.

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

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

YTsaurus — это будущее DWH, и в Яндекс Маркете оно наступило

Филипп Козьмин

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

* К концу 2022 года мы должны были построить хранилище вместимостью 30 PT с ростом данных в 10 PT в год и наличием жестких SLA по времени доставки данных.
* Мы пробовали делать это так, как принято сейчас — Greeenplum для ядра DWH и MapReduce для остального, оно не взлетало.
* Мы упростили всю архитектуру и сделали DWH на одном YTsaurus.

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

ORC и Parquet. О форматах и их использовании на базе HDFS

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

Современный мир наполнен данными, а количество производимых и хранимых каждой компанией данных непрерывно растет, вызывая множество проблем. Хранение и обработка этих данных является критически важной задачей для бизнеса.

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

В докладе разберём:
* как устроены форматы ORC и Parquet;
* в чём секрет их эффективности;
* каких правил придерживаться при настройке таблиц на примере ORC;
* реальный пример оптимизации таблицы на 500 миллионов записей и ускорения ее обработки в 3 раза.

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

Антифрод наоборот и использование методов ML в нем

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

Сегодня мы с вами посмотрим, как уже сейчас упрощается наш с вами клиентский путь, и почему теперь вовсе не обязательно вводить СМС. А еще рассмотрим, как популярные методы машинного обучения помогают лучше справляться с задачей "антифрода наоборот" или Сервиса Принятия Решений в платежной системе "Мир".

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

YTsaurus SPYT: помогаем планировщику Apache Spark быть ещё эффективнее

При обработке больших данных с помощью Apache Spark наиболее трудозатратным этапом считается Shuffle stage, когда вся информация активно перемещается. А возникает он в вашем плане, как только вы задумываетесь о группировке или джойнах. Но всегда ли он необходим? Нет! Дело в том, что зачастую Spark не знает, как эффективно использовать метаданные источника данных, поэтому строит универсальные способы исполнения.

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

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

Переосмысление рекомендаций в Дзене и внедрение item-to-item-схемы

Технологии VK

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

Доклад будет посвящен нашему пути к построению объяснимой для пользователей персональной ленты и способу сделать рекомендации «контролируемыми». Расскажем, какие ограничения мы себе поставили для этого и почему в их рамках пришли к item-to-item-модели, как решаем задачу построения таких рекомендаций, какие возможности нам это открыло, а также про основные этапы внедрения и развития item-to-item-технологии.

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

MinIO — что изменилось за год

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

Базис-Центр+

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

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

Также хочется рассказать об очень интересном опыте масштабирования MinIO — как мы расширили своё присутствие с 3 до 4 дата-центров, какой реальный прирост производительности дал переход от обычных дисков к дисковым массивам. С какими сложностями можно столкнуться при работе с этими массивами.

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

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

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

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

В докладе сначала будет рассказано про диффузионный подход для задачи генерации изображений по тексту: что такое диффузионный процесс, какие бывают диффузии и как это всё связано с генерацией изображений. После этого детально рассмотрим архитектуру модели Kandinsky 2.1, а также возможные режимы её использования: генерация, совмещение изображений, изменение изображений по тексту, генерация похожих на заданное изображений и inpainting/outpainting. Далее приводятся результаты сравнительных экспериментов с другими моделями как на примере самих генераций, так и на уровне метрики FID. После этого расскажу про официальный запуск проекта, достигнутые показатели по уникальным пользователям и числу запросов, кратко опишу структуру бэкенда для такой нагрузки по инференсу модели и приведу статистические данные за первые недели запуска с точки зрения highload-нагрузки.

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

Применение изображений в рекомендательных системах

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

Поделимся с участниками кейсами, как нам удалось улучшить нашу систему на 20%!

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

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

Hadoop
Machine Learning
Обработка данных
Евгений Смирнов

Альфа-Банк

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

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

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

Как заставить Stable Diffusion генерировать не только аниме и котиков, но и тебя

Machine Learning
Расширение кругозора
Технологии VK
Кирилл Семин

ВКонтакте, VK

Мир генеративного искусства стремительно развивается, создание фантастических и при этом реалистичных изображений уже не кажется магией. Но и возможности методов генерации неуклонно растут. 2022-й год завершился бумом в персонализации text-to-image-моделей — в академической среде выходили статьи с различными подходами, а в продовой — конкретные решения, на них основанные.

В докладе поговорим о диффузионных генеративных моделях и методах персонализации, а также о том, как их использовать в реальном продакшне:
* Сначала немного погрузимся в прекрасный мир теории и поймем две основные вещи: как работают диффузионные генеративные модели на примере Stable Diffusion; и как заставить их генерировать неизвестные для них объекты, например, вас или вашу любимую собаку, с помощью DreamBooth и его модификаций.
* Затем спустимся на землю, чтобы столкнуться с суровой реальностью. Однако справимся со всеми (почти) проблемами: будем кэшировать вычисления модели, считать attention эффективно, и научимся дообучать большие модели, не имея больших ресурсов.

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

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

Платформа OpenAPI: что за "зверь" и с чем его "едят"

API
Бэкенд / другое
Микросервисы, SOA
Архитектура данных, потоки данных, версионирование
Работа с облачными сервисами
GO
Эффективное использование облаков
Микросервисы
Сеть
Инструменты

Расскажу, как строится и что находится "под капотом" у OpenAPI-платформы (на примере TelecomAPI-платформы Exolve), а также как можно на ее базе строить конкретные приложения в парадигмах low(no)code и/или serverless и зачем. Разберем узкие места, технические находки и границы применения, а также порассуждаем о перспективах распространения таких подходов.

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

Алиса, не тормози!

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

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

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

Поставка данных телеметрии складского робота, и что с этими данными можно сделать

Николай Долганов

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

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

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

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

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

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

Ищем товары по фото

Python
Поисковые системы
ETL
ML

Практический опыт интеграции ML в продакшн. Как мы делали "поиск по фото" для интернет-магазинов.

Блоки:
1) Теория — эмбеддинги, векторный поиск.
2) Обработка данных — удаление фона, выделение главного объекта на изображении.
3) Хранение эмбеддингов, организация поискового индекса.
4) Организация работы серверов для работы с векторным поиском.
5) Проблема похожести цветов, восприятие цветов человеческим глазом. Алгоритмы сравнения похожести цветов.

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

Всё, везде и сразу: трейсинг в условиях хайлоада и 10к бэкендов

Бэкенд / другое
Профилирование
Распределенные системы
Логирование и мониторинг
Логи, метрики, ошибки
Технологии VK
Александр Кирсанов

VK, ВКонтакте

Поговорим о том, как мы расширяли distributed tracing под нужды ВКонтакте. Сама по себе технология понятна — это сбор информации о взаимодействии между элементами системы при обработке запроса. Есть и популярные инструменты для хранения и визуализации трейсов: например, Jaeger и Sentry. А также способы их сбора из прикладного кода (tracing SDK для различных языков).

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

Я расскажу, как мы в целом переосмысливали процесс трейсинга, упёршись в подход Open Telemetry. В итоге у нас получилась более богатая модель данных, при этом сбор трейса на реальном проде получился практически zero overhead.

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

Почему вам стоит писать backend на Elixir

Java
PHP
Python
Прочие языки
GO
.NET

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

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

Также обсудим, в чём уникальность Elixir: BEAM, OTP, модель акторов и то, как Elixir расширяет ваше мышление в плане подходов к написанию кода. Посмотрим, какие компании уже применяют Elixir для разработки своих сервисов.

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

Цифровая культура / CTO-трек (2)

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

Архитектурные паттерны
Отказоустойчивость
Архитектуры / другое
Методологии и процессы разработки ПО; Сроки и приоритеты
Большие проекты/команды
Модели руководства
Выбор стратегии долгосрочного развития, KPI
Продуктовая разработка
Антикризисный менеджмент
Обслуживание клиентов, техническая поддержка, обратная связь
Управление / другое
Enterprise-системы
Теория
Типовые ошибки
Проектный офис

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

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

А также:
1. Разберем, что делать, чтобы подготовить Сбербанк Онлайн к периоду высокой нагрузки.
2. Узнаем об особенностях нашей архитектуры.
3. Как и почему появился сервис: "Вход в СБОЛ по талонам".
4. Разберемся в том, почему построение отказоустойчивого финансового сервиса — это непростая задачка.

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

Внутреннее облако в Яндексе — от прототипа до платформы. Жизненный цикл сервиса от А до Я и вызовы на каждом из этапов

Большие проекты/команды
Дмитрий Липин

Yandex Infrastructure

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

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

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

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

TechTalk (8)

Как мы пишем код в Дзене: move fast and break things

Технологии VK

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

Первая бета-версия Дзена появилась в 2015 году: проект запустился как внутренний стартап с четырьмя разработчиками. Сейчас их больше 300 — и мне, как CTO, важно не потерять скорость разработки.

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

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

ML-исследования в Дзене: как жить без KPI?

Технологии VK

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

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

Платежная система «МИР» и ее (не)персональные данные

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

Что можно анализировать в компании, которая предоставляет банкам услуги по обработке платежей? На самом деле сама платежная система — это не только информация о платежах. В TechTalk'е разберемся подробнее, какие данные у нас есть и как мы их используем.

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

Как мы интегрировали нагрузочное тестирование в юнит-тесты

Нагрузочное тестирование
Юнит-тестирование
Кирилл Борисов

Газпромбанк

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

Сейчас в классическом процессе исследования производительности нужна отдельная сервисная команда, дорогостоящая инфраструктура и недели, а может, и месяцы работы. Изменяющийся мир заставляет нагрузочное тестирование, как и IТ в целом, совершать движение на ранние этапы процесса (shift left).

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

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

НТ как сервис

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

Поэтому сегодня мы поговорим про:
1. доступное, релевантное и удобное нагрузочное тестирование, или как организовать процесс НТ в компании;
2. как глубоко прокачать скилы в НТ, или какие вызовы могут бросить легаси системы.

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

Trunk based continuous deployment в банке

Максим Морев

Газпромбанк

Банки славятся медленной, бюрократизированный, грустной разработкой. Но новые проекты вроде "цифрового рубля" нужно релизить очень быстро. Что делать? Полностью менять пайплайн.

В techtalk я расскажу, как выглядит наш новый pipeline создания софта, когда от пуша до прода может пройти менее 10 минут.

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

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

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

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

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

Диспутные процедуры в платежной системе «Мир»

Роман Назаров

Мир Plat.Form

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

Основными тезисами будет разговор про:
* Что такое диспут в платежной системе?
* Зачем нужны диспутные процедуры в платежной системе и в каких случаях используются.
* Как работают диспутные процедуры в платежных системах.
* В чем уникальность диспутной модели ПС "Мир".
* Основные задачи, разделы и функции диспутной платформы НСПК Диспут плюс.
* Наши рекорды.

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

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

Темные боги корпоративной архитектуры. До варпа и обратно

Андрей Жуков

С7 ТехЛаб

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

Я расскажу о четырех непохожих, но все равно опасных пути построения корпоративной архитектуры. Каждый из темных богов покажет свои привлекательные и отвратительные стороны: Безопасник, Системный Архитектор, Милорд-разработчик и Бизнес-заказчик.

А в конце посмотрим, чем опасен путь IТ-императора.

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

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

Групповые чаты в Одноклассниках

Технологии VK

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

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

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

Успеть за 350 миллисекунд. Эволюция архитектуры Антиспама Почты Mail.ru

Микросервисы, SOA
Отказоустойчивость
Рефакторинг
Обработка данных
Технологии VK

Для того чтобы защитить пользователей почты Mail.ru от вредоносных писем, Антиспам Почты Mail.ru проверяет более 400 млн писем ежедневно.

В своем докладе я расскажу, как и почему менялась архитектура Антиспама за более 15 лет развития.

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

До встречи на докладе!

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

Feature store: как мы совместили высокую производительность и безграничные потребности data scientist’ов

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

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

В данном докладе я расскажу:
* какой путь проходит товар, чтобы оказаться в выдаче поиска,
* зачем нам понадобилось создавать целую систему хранения ML-фич с нуля,
* какие хаки мы применили для уменьшения latency всего поиска,
* что мы сделали, чтобы справляться с миллионами запросов в секунду на терабайтные базы данных,
* как data scientist’ы получили возможность ставить A/B-эксперименты не только с разными моделями, но и с по-разному посчитанными фичами,
* как мы минимизировали временные затраты разработчиков на добавление новых видов фич.

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

Ах, как хочется вернуться, ворваться в монолит!

Микросервисы — это все еще новый черный. Любой продукт станет лучше, если в нем есть блютус, блокчейн и микросервисы. Даже моя бабушка спросила, можно ли сделать микросервисную швейную машинку.

Но как оно на самом деле? Ждет ли вас “град на холме”?

В докладе я расскажу о том, как Авито шло к микросервисам. Это будет таймлайн-история, где покажу разные этапы микросервисной архитектуры Авито. И на какие компромиссы шли в процессе.

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

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

Архитектура ленты и рекомендаций ВКонтакте

Технологии VK
Андрей Якушев

ВКонтакте, VK

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

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

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

Warden — зачем нам свой service mesh?

Проблема дискаверинга и балансировки нагрузки в межсервисном взаимодействии не новы. На рынке существует ряд готовых решений, реализующий все виды дискаверинга и балансировки (reversed-proxy, client-side load balancer в связке с control-plane). Из популярных: nginx, isito и ряд других решений. Но около 3 лет назад мы в Ozon решили пойти своим путём, реализовав собственное решение для service discovery и client-side load balancing.

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

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

Продуктовая платформа исполнителей в Яндекс Go

Яндекс Pro — это суперапп для исполнителей, выполняющих заказы клиентов разных online-to-offline-сервисов Яндекса: Такси, Самокатов, Доставки, Еды, Лавки, Маркета. Но так было не всегда, раньше Яндекс Pro был только водительским приложением Такси. Я расскажу о том, какие архитектурные принципы позволили пройти этот путь, тем самым это поможет командам разработки множества бизнесов развивать общее высоконагруженное приложение, сохраняя и его стабильность и скорость разработки.

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

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

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

Надежность поставки данных при потоковой обработке на примере хранилища товарных предложений Яндекс Маркета

Евгений Равнушкин

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

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

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

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

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

HighLoad для "маленьких"

Бэкенд / другое
Асинхронное программирование, реактивное программирование
Отказоустойчивость
Оптимизация производительности
Масштабирование с нуля
ClickHouse
Удаленная работа
Микросервисы

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

Задача платформы — отвечать на http-запрос с задержкой не более 50 мс и обслуживать тысячи запросов в секунду (сейчас более 500 000 RPS). В докладе мы покажем, какие решения принимали в области архитектуры, системного ПО, инфраструктуры и, собственно, разработки.

* Собственные сервера + docker, чтобы нивелировать различия в установленных версиях ОС и пакетов.
* Мы любим микросервисы и shared nothing и стараемся избегать решений с единой точкой отказа. Все, что можно задублировать — должно быть задублировано.
* KV БД Aerospike — наш главный помощник. Невозможно или слишком дорого держать вообще всю рабочую информацию на каждой ноде.
* Своя библиотека для асинхронного http client/server позволяет мультиплексировать запросы и заполнять канал, экономя соединения. Мы, как и большинство, все еще живем в мире http 1.1.
* Своя библиотека для map/reduce, чтобы обрабатывать 40 Тб данных в сутки.
* У нас нет silver bullet, мы просто хотим поделиться радостью, что оно работает :)

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

Сеть АЗС и сервис онлайн-заправки — от стартапа до промышленной процессинговой системы

API
Java
Микросервисы, SOA
Отказоустойчивость
Масштабирование с нуля
Микросервисы
Ольга Корабельник

ГК ТПК, Газпром нефть-Региональные продажи

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

Онлайн-оплата на сети АЗС «Газпромнефть» стартовала в 2018 году с собственной сети. Сейчас ежедневно более 2,5 миллиона литров топлива водители покупают на сети АЗС «Газпромнефть» онлайн. Сервис интегрирован с партнерами с большой клиентской аудиторией, а также с узкопрофильными мобильными приложениями. Поговорим о пользовательском приложении, что стоит за тремя «простыми» экранами заправки?

1. Как мы начинали: low-code-платформа для быстрого старта на 30 точек продаж, 6 месяцев разработки.
2. Рост сервиса опережает функционал, разработка играет роль догоняющего, решение — только распределение нагрузки и изоляция сервисов друг от друга. Все понимаем, планируем переход на новую архитектуру, но не успеваем.
3. Тираж mvp на 1000 точек и первые проблемы low-code, дублирующие сервисы, параллельная нагрузка, функциональное разделение платформы, дополнительный сервер для асинхронных запросов и ODS. Все это на «горячую», без остановок развития функционала и самого сервиса.
4. Рост использования приложения х10 за 1,5 мес и первый серьезный даунтайм, начинаем переход на микросервисы в части транспортного слоя, сложности нагрузочного тестирования распределенных систем, CAP-теорема.

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

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

От алгоритма до прода: как подойти к верификации распределенных систем

Базы данных / другое
Распределенные системы
Интеграционное тестирование
GO
Теория
Технологии VK
Никита Галушко

VK, ВКонтакте

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

Пройдемся по всем этапам от зарождения идеи до ее реализации и разберём, как на каждом из них понять, что корректность не нарушена. Поговорим про TLA/TLC+, fuzzing и причинах, почему нам пришлось написать "свой" Jepsen.

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

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

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

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

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

Вам нужна CDN! ...или нет?

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

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

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

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

Микросервисы как худший архитектурный выбор для стартапа

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

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

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

Но! Затевая стартап, никто не рассчитывает, что он останется маленькой наколенной поделкой. Все мы ждем, что из быстро-и-грязно слепленного MVP вырастет многомиллионный бизнес с высокими нагрузками и постоянной потребностью в расширении и масштабировании. И тут как раз микросервисы пришлись бы очень кстати! Как совместить потребность в быстром и дешевом старте с желанием быть готовыми к взрывному росту? Об этом — в основной части доклада.

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

Как перевезти 4K человек на in-house-систему инцидент- и алерт-менеджмента за месяц

Доклад о том, как мы за месяц заменили SaaS-продукт Opsgenie на свое собственное решение.

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


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

Универсальные пуши для андроид. FCM, HMS и RuStore в одном месте

API
Бэкенд / другое
Архитектуры / другое
Архитектура платформы Google Android
Технологии и языки для Android: Java, Kotlin
Бэкенд мобильных приложений
Клиент-серверное приложение, REST API, protobuf
GO

* Когда был только Firebase, все было просто. Теперь тренды меняются, появился HMS, появляются региональные решения. Расскажем, как охватить большую аудиторию, используя не только Firebase.
* Как добиться лучшей доставляемости уведомлений, используя сразу несколько транспортов для пуш-уведомлений.
* Дополнительные плюшки — уверенность, что пуш не доставлен, локализация уведомлений, периодические кампании рассылок.
* Что будет дальше, какие альтернативные решения появятся, и что можно уже тестировать. Есть ли будущее у unifiedpush.

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

Авито Автозагрузка: как качать миллионы фотографий в сутки, выдержать кратный рост и не умереть

Оптимизация производительности
Рефакторинг
Архитектуры / другое
Поддержка и развитие legacy систем
Микросервисы

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

На таком объёме данных простая, на первый взгляд, задача «скачай фото по ссылке» обрастает большим количеством проблем:
* что делать с медленными и нестабильными хостами;
* как не устроить DDoS-атаку на сервера клиентов;
* как обеспечить высокую производительность системы и не вызывать негатив у пользователей.

Если прибавить сюда резкий кратный рост продукта, то мы получим интересную историю о том, как за год мы выросли в 4 раза и полностью переосмыслили и переработали архитектуру нашей “фотокачалки”. Вместе мы пройдем путь от решения “в лоб” до решения, сумевшего ответить на все эти (и не только) вопросы.

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

5 GB трейсов в секунду, или Как устроена система трассировки в Ozon

В этом докладе я пролью свет на трейсинг внутри Ozon и на то, как у него получается обрабатывать 5 Gb/s трейсов. Речь пойдёт об архитектуре системы трассировки запросов, пайплайне обработки трейсов, методах хранения такого большого количества данных и, конечно же, о проблемах, с которыми мы сталкивались во время разработки и поддержки системы трейсинга.

Помимо этого, расскажу и покажу, как мы строим граф взаимодействия (dependency graph) более 2 тысяч сервисов внутри Ozon, а также как благодаря трейсингу мы умеем выявлять наиболее ресурсоемкие запросы (critical path), например, при загрузке какой-либо тяжелой страницы. Дополнительно затрону тему взаимодействия системы трассировки запросов с другими системами Observability внутри Ozon.

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

CБОЛ. Архитектура слоя хранения

Миграции данных
PostgreSQL
Oracle
Базы данных / другое
Синхронизация данных, параллельная обработка, CDN
Архитектуры / другое
Администрирование баз данных
Внедрение и поддержка
Бэкенд мобильных приложений

Путь, пройденный командой развития Сбербанка Онлайн при построении надежной и отказоустойчивой архитектуры слоя хранения, является уникальным, и опыт, полученный в процессе становления, может стать подспорьем для развивающихся проектов, идущих прямиком в «клуб HL++». Доклад призван в доступной форме рассказать об архитектуре сервиса Сбербанк Онлайн в части хранения данных и поделиться планами по импортозамещению СУБД.

Содержание:
* СБОЛ — это платформа для реализации продуктов экосистемы Сбера;
* архитектура строится вокруг 2 клиентов: Клиент Сбера и команды развития бизнес-продукта;
* данные СБОЛ-а делятся на 5 типов;
* End 2 End — целостный клиентский блок, основа надежного и масштабируемого сервиса;
* Client Backup Layer, который развязал нам руки;
* микросервисная архитектура платформы помогает нам мигрировать на PostgreSQL;
* какие данные блока не прижились в Oracle, и куда их отселяем. С какими проблемами столкнулись;
* СБОЛ 2025. Целевая картина хранения данных Сбербанк Онлайн.

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

Use actors, Luke

Фреймворки
Платёжные системы, обработка платежей
Распределенные системы
.NET

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

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

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

Совмещаем потоковые и пакетные процессы в Camunda BPM

Практические примеры построения схем процессов, техники и приемы. Эволюция BPM-схем процессов в проде за 3 года, изменение подходов, работа над ошибками.

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

На^WНу зачем ты форкнул NGINX, муд^Wдорогой?!

Расскажу, что мы сделали за полгода c веб-сервером Angie, и спрошу вас, что нужно делать дальше.
Также расскажу, что значит ^W в названии доклада :)

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

Прожарка архитектурных кейсов

Технологии VK

Открытый экспертный разбор архитектуры ваших кейсов прямо во время конференции.

Как это работает:
Заранее собираем архитектурные кейсы — то, что вы только планируете реализовать, только-только запустили или что-то, что существует уже давно. Обсуждаем на уровне структуры, без чувствительной информации и деталей под NDA. Для наибольшей наглядности демонстрируем через Miro и публикуем в доступ на нашем сайте.

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

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

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

Уроки из проекта с коммитом 2001 года

Микросервисы, SOA
Архитектурные паттерны
Отказоустойчивость
Оптимизация производительности
Методы и техника разработки ПО
Микросервисы
Технологии VK
Василий Романов

VK, Облако Mail.ru

Про очевидные вещи, которые особенно ценятся на дистанции в 10 лет.

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

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

Внедрение YDB CDC на примере Yandex Monitoring

Егор Литвиненко

Yandex Infrastructure

Yandex Monitoring используется всеми сервисами Яндекса внутри, а также доступен в Яндекс.Облако для внешних пользователей. Мы обрабатываем 700 миллионов метрик на запись ежесекундно.

У каждого клиента есть конфигурация процесса загрузки метрик. Конфигурация — это Control-Plane-объекты, которые:
* хранятся как таблицы в базе данных;
* меняются на лету;
* связаны между собой.
Чем быстрее Monitoring получает обновления объектов, тем выше доступность для пользователей.

Для хранения мы используем YDB — распределенную open-source-базу данных Яндекса.
Команды YDB и Yandex Monitoring проработали сценарий загрузки изменений с помощью YDB CDC. В результате получили архитектуру, в которой изменения объектов доставляются в тысячи компонентов менее чем за 800 миллисекунд.

В докладе:
* Сложности до перехода на Change Data Capture.
* Подходы к доставке изменений, их особенности.
* Чем YDB CDC отличается от других решений.
* Рекомендации, как правильно готовить YDB CDC, поделюсь граблями и их решением.
* Какую модель данных выбрать, чтобы решить проблемы с конкурентными изменениями.
* Мониторинг и поддержка решения.

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

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

Протокол MirAccept 2.0: что нас ждёт дальше

Время и технологии не стоят на месте. Кто-то из вас, возможно, замечал, что в последнее время при оплате банковскими картами все реже запрашивается ввод PIN-кода, а при платежах в интернете далеко не всегда требуется подтверждение операции через SMS.

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

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

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

Замещение Thales — аппаратных модулей шифрования

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

На мировом рынке тотально доминирует одна компания — французская Thales. В 2022 году она ушла из РФ и более не предоставляет лицензионную поддержку и свои модули. Но некоторые российские производители оказались готовы представить собственные разработки аппаратных криптомодулей.

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

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

Хардкор (3)

Как профилировать, когда perf видит не всё?

Оптимизация производительности
Профилирование
Технологии VK

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

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

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

CPU-изоляция по memory bandwidth

Аппаратное обеспечение
DevOps / Кубер
Инфраструктура
Лев Плинер

Yandex Infrastructure

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

Один такой квест мы рассмотрим на примере приватного вычислительного облака Яндекса. Потребители облака, сервисы Яндекса, запускаются в миллионах контейнеров на более, чем 100 тысячах серверных ЭВМ. Через контейнер потребителям облака предоставляется гарантия на вычислительные ресурсы облака.

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

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

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

Эндогенные угрозы физической целостности СУБД

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

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

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

Фейл секция (1)

Fail-митап

Технологии VK

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

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

Модератор: Екатерина Фирсова.
А делиться ошибками будут Алексей Мерсон, Григорий Богданов и многие другие.

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

Воркшоп (3)

Мастер-класс "Асинхронное взаимодействие в распределенных системах"

Распределенные системы
Алексей Лосев

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

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

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

Как при помощи бумаги, карандаша и алгоритма Raft достичь консенсуса

Распределенные системы
Алгоритмы и их сравнение

Есть во вселенной такой алгоритм — Raft. Он широко используется для решения задач консенсуса в распределенных системах (для наглядности — сервисы Etcd или Consul, как наиболее известные проекты его использующие).

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

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

Делаем свой умный дом на коленке

Собираем в прямом эфире свой умный дом на четырех платформах.

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

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

Резерв (1)

Паттерн Service Discovery в Kubernetes и Istio, или Как сломать DNS в нагруженном кластере

Архитектурные паттерны
Технологии виртуализации и контейнеризации
Работа с облачными сервисами
Микросервисы
Облака
DevOps / Кубер

Разберем в деталях, что такое Service Discovery — когда появился паттерн, чем полезен в микросервисах и как он реализован в популярных опенсорсных облачных решениях Istio и Kubernetes. На сладкое обсудим, какие есть проблемы с Service Discovery в нагруженных кластерах и узнаем, зачем Istio пытается убить DNS в Kubernetes и как этого избежать.

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

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

Проектирование сервиса мониторинга самолетов в реальном времени

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

Знаменитый Flightradar показывает в реальном времени положение всех самолетов мира миллионам пользователей, но как ему это удается?

Основную нагрузку создает необходимость довольно быстро отрисовывать обновления в положении самолетов у всех пользователей-наблюдателей, а это, при заявленной средней нагрузке в 3'000'000 пользователей, не меньше 150ГБ данных в секунду. А ведь данные нужно еще и обновлять. Какая база справится с такими объемами? А может, ей и не нужно с этим справляться? В этих вопросах мы постарались разобраться вместе с командой и с радостью выскажем вам свои мысли. Подробно разберем проблемы, с которыми столкнулись, и выслушаем любую критику.

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

Архитектура приёмки товаров на складах

Система на вход принимает документы, которые нужно сопоставить с фактическим наличием товаров — произвести пересчет, сверку, проверку на брак и т.д.

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

В проекте выделены 2 мастер-системы: задачи и накладные. Разделение произведено в соответствии с контуром видимости: накладные — это внешняя сущность, задачи для сотрудников — внутренняя сущность, имеющая смысл только в замкнутом контуре проекта.
Все интеграции с внешними системами реализованы через ACL, взаимодействие со всеми видами фронта — через BFF.

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

Архитектурный вынос магазина

Миграции данных
API
Бэкенд / другое
Микросервисы, SOA
Архитектурные паттерны
Рефакторинг
Поддержка и развитие legacy систем
Оптимизация
Микросервисы
Технологии VK

Разделение системы на несколько максимально независимых компонентов/сервисов для устранения проблем монолита:
- ограниченный стэк технологий
- сложность контролировать четкость абстракций
- legacy код
- проблемы с ответственностью
- релиз монолита
- долгий time to market фич

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

Асинхрон, от которого хотели синхронности

API
Java
Асинхронное программирование, реактивное программирование
Распределенные системы
Микросервисы

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

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