Доклады

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

Как забыть про проблемы с производительностью? Tarantool в качестве СУБД для каталога товаров

Каждый день витрину Ситилинк смотрят 1,6 миллиона покупателей. Кэшировать товары на витрине нельзя — там цены! Поэтому мы выбрали, развернули и научились использовать Tarantool, чтобы обеспечить чтение и запись более 100 тысяч элементов в секунду с задержкой всего в 30 мс.

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

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

Какие архитектурные решения в Яндекс Go позволяют запускать десятки параллельных продуктовых экспериментов

Олег Ермаков

Яндекс Go

Команда продуктовой разработки Яндекс Go прошла путь от "нескольких человек, пишущих в монолит" до "команды, в которой больше 50 человек, которая развивает микросервисную архитектуру продукта и запускает десятки параллельных продуктовых экспериментов". Этот путь сопровождался поиском и внедрением решений, ускоряющих разработку, позволяющих масштабироваться и увеличивающих надежность системы. Об этих решениях и будет доклад:
* когда и как мы перешли от монолита к микросервисам;
* как и когда мы используем api gateway (и его разновидность backends for frontends);
* как мы запускаем и отслеживаем результаты продуктовых экспериментов.

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

Гибридная архитектура: разделяемый на микросервисы монолит

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

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

И тут возникает проблема: микросервисная архитектура пусть даже в докерах или как-то ещё задеплоенная на один сервер хорошо работать не сможет.

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

Попутно:
* автозамена вызова через RMQ на прямой;
* автозамена вызова через HTTP на прямой;
* автосокращение используемой памяти в 6 раз;
* снижение нагрузки на CPU в 2 раза;
* разные деплои: один для слитого варианта, один для раздельного — на Kubernetes;
* и прочее-прочее-прочее.

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

Микросервисы через боль и превозмогание

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

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

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

Как мы в 1С делаем свой PaaS

Бизнес-приложения и облака — такой связкой уже никого не удивишь. Но что делать, если у тебя не одно приложение и один клиент с парой десятков пользователей, а тысячи приложений и десятки тысяч пользователей в единой инфраструктуре?

Обсудим опыт создания облачной платформы со своими СУБДaaS, LBaaS, мониторингом со встроенным анализом первопричин, ну и, конечно, то, как наш фреймворк для создания приложений интегрирован с облачной инфраструктурой (например, зачем менеджмент пользователей приложений — часть облачной инфраструктуры).

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

Экспертные системы для металлургии: пятилетка за год

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

В докладе я расскажу, как мы научились прогнозируемо работать в таких условиях: от старта проекта до его поддержки. Покажу, как можно быстро начинать проекты на Kotlin, Python и заглушках. Как мы заранее закладываем в архитектуру наших систем "точки корректировки" и моделируем изменения. Что из популярных решений и подходов используем, чтобы обеспечить максимальное качество в таких условиях.

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

Граф компонентов: как отобразить 100 компонентов и 500 связей

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

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

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

Внедрение OpenSource-решений в АСУТП

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

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

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

Как мы запустили систему из 10'000 серверов за 4 месяца

* Немного об умных домах, городах и квартирах, или Зачем такое количество серверов.
* Минисервер — все равно сервер и он приносит свои сложности.
* Процесс обновления на лету — радости работы 24/7.
* Как не убить "стаю" в один клик, или О процессе тестирования и релиза.
* Задачка усложняется, или Как работать с 100К, 1M и более серверов.

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

От 0 до 200 000 000 игроков — об эволюции бэкенда за 40 мин

War Robots — мультиплеерный 3D-шутер. Недавно ему исполнилось 8 лет, и за время существования проекта архитектура претерпела множество изменений. Поначалу она была очень простой и строилась на облачных решениях: на бэкенде был всего один сервис, который отвечал за работу с профилями игроков, а сама игра была реализована с помощью облака Photon. Но уже тогда в качестве хранилища данных была выбрана Cassandra, что сделало архитектуру проекта довольно нестандартной.

Со временем многократно выросли нагрузки, количество игроков перевалило за 200 000 000, размер хранилища вырос до 80 Тб (!) данных, серверов стало более 150, да и команда прокачалась и выросла. Ещё нам пришлось два раза переезжать всем хранилищем данных на новое железо, и об этом мы тоже поговорим.

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

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

Необходимость и боль перехода с IBM MQ + RH Fuse на Apache Kafka + Apache Camel

Александр Крылов

Росгосстрах

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

В нашем случае мы попали в ситуацию, когда мы имеем инструменты, попадающие не только под vendor lock и узкую компетенцию, но и санкции. Речь про так называемую шину данных или ESB, состоящую из брокера очередей на базе ESB IBM MQ и интеграционного слоя на базе Red Hat JBoss Fuse.

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

Собрав всю силу и необходимые компетенции, мы выбрали инструменты Apache Kafka в качестве брокера очередей и Apache Сamel в качестве интеграционного слоя для построения потоков данных.

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

"To peer or not to peer", или Ордеринг транзакций в публичных блокчейнах

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

Публичные блокчейны с точки зрения алгоритмов удобно рассматривать как распределенные системы master-master-репликации, где цепочка блоков является аналогом Write Ahead Log, а публикация и финализация блоков является аналогом commit'ов для транзакций. Но одним из серьезных отличий от централизованных БД является то, что транзакции совершенно свободно принимаются и процессятся откуда угодно, без всяких авторизаций, отфильтровываются и ранжируются с использованием системы комиссий, связанной одновременно со сложностью исполнения транзакций и с размером оплаты. Процесс распространения транзакций по сети, доставки их до производителей блоков и их последующее ранжирование в блоках — это уже сам по себе крайне интересный механизм, но в последние пару лет появление многочисленных DeFi-протоколов вызвало настоящие войны за ordering и скорости получения и доставки транзакций среди трейдеров, что привело к еще большему его усложнению и появлению вторичного рынка ordering'а транзакций с объемами в миллионы долларов ежедневно, в котором участвуют трейдеры, майнеры и производители блоков.

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

Распределенный высоконагруженный BI-движок для Google Data Studio и Microsoft Power BI — как сделать массовую облачную BI-аналитику доступной для человечества

В докладе мы расскажем, как проектировали, разрабатывали и запустили на сотни тысяч компаний облачную BI-аналитику для инструментов Google Data Studio и Microsoft Power BI. Поговорим об ошибках, подводных камнях, выборе column-ориентированных хранилищ от Druid и Pinot до ClickHouse и Amazon RedShift. Затронем инструменты BI-визуализации от Apache Superset до Amazon QuickSight и Яндекс DataLens. Не обойдем стороной вопрос гетерогенной репликации данных, CDC-репликации и приручения Kafka и Amazon Kinesis. Разберем основы создания простых и полезных, но, главное, быстрых облачных BI-отчетов для компаний-пользователей CRM Битрикс24. Обязательно поговорим о рынке BI-коннекторов, архитектуре нашего BI-коннектора, пользе и действительном предназначении облачных кластерных колоночных БД и их ближайших перспективах.

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

Масштабируемая облачная система для дедупликации потока событий с использованием YDB

Кратко расскажем про конвейер обработки событий аппметрики:
* какие задачи он решает;
* общая архитектура: примерно 50 микросервисов, передающие информацию через ClickHouse и ZooKeeper;
* Нагрузка в числах — 250 миллиардов событий в день, до 7 миллионов RPS в пике;
* зачем нужен сервис дедупликации.

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

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

Пайплайн для расшифровки речи в миллионах видео в сутки: инфраструктура автоматической генерации субтитров в VK Видео

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

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

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

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

Без A/B — результат XЗ, или Как мы построили платформу A/B-тестов в Ozon

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

В своем докладе, я расскажу про техническую реализацию платформы А/B-тестов в компании Озон.

А именно:
* об эволюции A/B-тестов в компании. О том, как мы шли от простого к сложному длиной в несколько лет;
* как построена архитектура платформы A/B-тестов в общей экосистеме Ozon;
* как мы обеспечили интеграцию любого сервиса в компании: для подключения одного сервиса к нашей платформе нужно не больше 2 минут! Да-да, мы засекали. Интегрировано более 150 сервисов, причем каждый сервис работает с уникальным набором атрибутов для тестирования;
* и даже секрет молниеносного ответа при высоком RPS. Каждый запрос на сайт Ozon.ru идет в платформу A/B-тестов, а вы этого даже не замечаете.

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

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

10мс на ответ с транзакциями, большими данными, гибкой логикой и opensource

Связываем два open source хранилища через очереди внутри сервисной платформы.
И получаем надежную строго-согласованную систему с очень быстрым доступом и безграничной адаптацией к нагрузке в операциях поиска, обновления, получения и слияния объектов и их состояний.
Добавив высокие требования к качеству и безопасности данных, имеем отличное решение для работы с банковскими данными.
5000 RPS при 10мс на ответ на 40ТБ данных и это не предел)
Это сделано в нашем банке и хочется поделиться этим опытом.

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

Одна платформа, чтобы править всеми

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

В своем докладе я расскажу про нашу платформы:
* что это такое и зачем она нужна;
* конвенции и стандарты;
* на чем мы пишем сервисы: языки и фреймворки;
* как мы их запускаем: CI/CD и прочие прелести;
* как сервисы находят и общаются друг с другом: service discovery, балансировка и gRPC;
* как следим за тем, что все работает: мониторинг, логи, трейсинг;
* все-as-a-service: S3, kafka, cache и т.д.

И многое, многое другое.

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

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

Как сэкономить на масштабировании, переехав с Cassandra на Scylla DB

Наш сервис вычисляет инференс моделей машинного обучения в транзакционном режиме. Как БД для наших сервисов мы использовали Cassandra:12 нод по 10 ядер и 32 Гб памяти. Немного цифр: среднее число запросов 600 RPS, в пиковых нагрузках — 800 RPS, ежедневная загрузка данных 500 Гб, нагрузка на базу от 50 000 до 100 000 RPS, желаемое время ответа БД меньше 100мс.

В начале 2020 мы столкнулись с пределами масштабирования: перестало хватать кластеров, появились всплески latency (из-за garbage collection), фантомные данные, увеличилось время загрузки (11-12 часов). У нас был выбор: масштабироваться за счет железа, но с каждым разом это будет все дороже и есть предел, или мигрировать. Мы выбрали миграцию базы с Cassandra на Scylla DB и думали, что мигрируем за пару спринтов...

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

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

Как выжить под нагрузкой, имея 100 Тб в нешардированной MongoDB

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

Взяв за основу реальный проект очень большой track&trace-системы, я покажу, что именно происходит с системой класса big data, в которой по разным причинам откладывали переход на использование шардированной архитектуры хранилища под нагрузкой. И самое главное, как выжить в этих условиях, меняя архитектуру решения на лету без downtime (DT).

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

Оптимизация производительности запросов в ClickHouse

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

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

OK S3: Строим Систему Сами

Вадим Цесько

Одноклассники

Одноклассники уже длительное время эксплуатируют собственные распределённые отказоустойчивые хранилища данных. Для хранения и обработки почти эксабайта бинарных данных (видео, фото, музыка и др.) используются one-blob-storage и one-cold-storage. В качестве транзакционных хранилищ развёрнуты десятки нагруженных кластеров NewSQL на базе Cassandra, распределённых по трём или пяти дата-центрам. Мы успешно переживаем аварии вплоть до выхода из строя дата-центра без деградации обслуживания, в том числе в час пик.

Помимо своих систем, мы эксплуатируем множество готовых продуктов для хранения артефактов сборки и тестирования, библиотек, образов, пакетов, логов, бэкапов и т.д. Единственным общим знаменателем в качестве подключаемого бэкенда хранения для всех этих сервисов является Amazon S3. S3 предоставляет высокоуровневый API для работы с объектами, а также обладает развитой экосистемой инструментов и SDK для многих языков.

Мы рассмотрим реализацию совместимого с S3 сервиса в Одноклассниках поверх уже существующих NewSQL и хранилища блобов: архитектуру и схему данных, особенности и компромиссы, оптимизации и производительность, а также встреченные по пути сложности и неожиданности.

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

Векторный поиск в ClickHouse

ClickHouse быстро выполняет все виды запросов, но его можно ускорить. Это касается работы с многомерными данными, которые могут возникать, например, при работе с текстами или картинками. Такие задачи часто встречаются в аналитике, и для них есть готовые решения. Особенно интересными являются индексы, такие как Faiss, HNSW и Annoy.

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

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

Оптимизация стоимости хранения данных в объектном хранилище, или Когда больше == меньше

Объектное хранилище Dispersed Object Store (DOS) родилось в недрах корпоративной почтовой системы Mailion. Для корпоративной переписки характерно большое количество частично или полностью совпадающих писем. Дедупликация писем и их фрагментов на уровне объектного хранилища позволяет многократно снизить потребление дискового пространства и IO. При этом в DOS реализована не только дедупликация, но и другие механизмы, снижающие избыточность данных (чанкинг и компрессия). Оборотной стороной этих механизмов является рост накладных расходов: увеличивается количество метаданных, хранящихся на SSD, растёт утилизация CPU. Встаёт вопрос определения оптимального баланса аппаратных ресурсов. Что выгоднее — включить максимальный уровень сжатия и дедупликации данных, чтобы сэкономить диски, но при этом потратиться на топовый CPU, или отключить все вычислительно сложные оптимизации, но расплатиться за это покупкой большого количества медленных дисков?

Ответить на этот вопрос не так просто: разные аппаратные ресурсы компьютера имеют разную цену, в то же время алгоритмы дедупликации и компрессии обладают большим объёмом настроек, сложным образом определяющих финальную стоимость хранения данных. Мы воспользовались методами black-box-оптимизации, чтобы определить комбинацию параметров, соответствующую минимальной стоимости хранения. В зависимости от значения параметров она может изменяться в диапазоне от $70 до $600 за отказоустойчивое хранение 1 Тб записанной информации. При этом стоимость максимизируется как раз при тех настройках, которые интуитивно кажутся более логичными и правильными.

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

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

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

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

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

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

Централизованный self-service ETL. О системе автоматизации, умеющей эффективно и дешево двигать данные между десятками систем

С ростом продукта и развитием data-driven-подхода мы должны обеспечивать наших коллег простым и удобным способом автоматизировать трансформацию и батч-транзит данных между системами с целью изучать их и проводить продуктовую/бизнес-аналитику.

Идея отделить в организации ETL-процессов декларативную часть от функциональной позволила нам достичь следующих результатов:
* Автоматизация расчетов для нового интересного отчета за 15 минут.
* Подключение к новым инстансам источников данных за считанные часы (пока там эти сисопсы креды в vault запихают).
* Data quality: проверка данных — это просто еще одна задача, которая падает, если цифры не совпадают. Каждый пишет сам под свои витрины.
* Data lineage: вся трансформация и движение данных представлены декларативно с явно указанными зависимостями между задачами.
* Около 2000 ежедневных задач на обработку петабайта данных в месяц (и нет, это не одна таблица), обновление 300 отчетов в Tableau для сотен пользователей, отправка информации во внешние аналитические системы и рекламные кабинеты. Для поддержки всего этого хватает одного дата-инженера.

Мы не забыли и про всякие удобства, потому что без этого никто нашим инструментом пользоваться не будет:
- Continuous deployment, чтобы каждый мог потестить свои задачи сразу на живых данных.
- Slack-бот для взаимодействия с Airflow. Чтобы запустить какие-то зависимости или целые подграфы задач.
- Получение данных там, где тебе нужно. Хочешь в Tableau, хочешь в гугл-спредшит, хочешь в slack.
- А ведь можно, вообще, не какой-то SQL запустить в BigQuery, а, скажем, процесс в контейнере.

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

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

Менеджмент крупных проектов (1)

Когда свой велосипед лучше чужого Феррари: цифровизация бизнеса на базе Jira

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

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

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

Так тривиально, но не классически у нас появилась команда автоматизации бизнес-процессов, которая с руководителями направлений (да и всеми заинтересованными в развитии процессов членами команд) строит экосистему инструментов управления компанией на базе Jira. 

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

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

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

Бесшовное внедрение практик безопасности в DevOps-конвейер, или Как обеспечить безопасность беспрерывной разработки

Андрей Иванов

Swordfish Security

* Какая часть является главной в магическом сокращении DevSecOps: DevOps (разработка и эксплуатация, встроенные в бизнес-процессы организации) или Sec (все, что связано с безопасностью)? Как понять, что в вашей организации пришло время для DevSecOps и как к нему подготовиться?
* Основные принципы и концептуальная схема DevSecOps. Выделяем главное и даем практические рекомендации.
* Поговорим об основных практиках информационной безопасности в разработке (Sec) и о том, когда и в какой последовательности их внедрять.
* Бесшовное внедрение — миф или реальность? Как его осуществить?
* Кейс крупного банка по успешному внедрению DevSecOps.

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

Развитие и жизненные циклы пайплайна

* Зачастую внедрение и развитие практик CI/CD сопровождаются проблемами и сопротивлением команд.
* Часто это вызвано тем, что делается упор на выбор инструментов, а не на понимание и удовлетворение потребностей команды.
* Любой pipeline проходит через 3 этапа, на каждом из которых закрывается одна из базовых потребностей команды, требуется ограниченный набор инструментов, применение которых даёт максимальный результат/
* Разберём каждый из этапов развития, требуемые инструменты, критерии завершения и особенности прохождения.

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

Как мы защищаем миллионы клиентов при перегрузках при помощи динамического троттлинга в высоконагруженных системах

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

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

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

Ответы на эти вопросы раскрою в ходе доклада, также коснусь темы, как данное решение эксплуатируется и мониторится.

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

Общий флоу разработки в Ozon. Как сделать жизнь разработчиков проще?

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

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

Надёжность высоконагруженных C++-приложений в Яндекс.Маркете

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

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

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

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

Как мы засунули 200+ дата-сайентистов в кластер k8s и перестали волноваться

Создали удобное рабочее окружение для 200+ дата-сайентистов для работы co spark при помощи jupyterhub и k8s. А еще оно легко масштабируется, управляется и тарифицируется в мультитенант-среде.

Расскажем, как мы это сделали и какие проблемы решили.



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

Dashboard as a code, или Путь от правок в UI до grafonnet

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

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

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

Контейнеры мертвы. Да здравствуют виртуальные машины!

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

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

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

Нагрузочное тестирование синтеза и распознавания речи в SberDevices

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

* Проблемы метрик: что такое "быстрый, но качественный ASR/TTS"?
* Как подружить скорость и стабильность?
* Что может влиять на результат, если шаг вашей шкалы — десятки миллисекунд?
* Какие сложности в нагрузочном тестировании встречаются в сервисах работы со звуком?

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

The full chain load test in AliExpress Russia (En)

Maria Skorik

AliExpress Россия

AliExpress is the biggest E-commerce market in Russia, 11.11 shopping festival is the biggest campaign in every year. When in the 11.11 campaign thousands of Russian people place orders and pay in AliExpress. So, checking the stability of AliExpress website is a big challenge in Quality Assurance.

The full chain load test is an efficiency, accurate, intelligent way to assure the performance of AliExpress website.

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

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

Multi-tenant Kubernetes

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

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

Эксплуатация голоса в Марусе. С какими проблемами мы столкнулись и при чем тут GPU

GPU - вещь капризная: видеокарты горят, вылетают из системы, отвечают с ошибками. Что делать с ними, когда ответ "переустанови драйвер" перестает работать? А если они просто исчезают? А если их еще при этом сотни?
За три года эксплуатации Маруси мы разрослись до порядка двухсот серверов, внутри которых более тысячи видеокарт. В этом докладе я раскажу, как мы применяем gpu, какие проблемы мы получили и как их решали. Рассмотрим типичные ошибки и не очень типичные действия по устранению этих ошибок.

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

Могут ли данные управлять аппаратной конфигурацией дата-центра?

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

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

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

Как это работает, чего мы достигли и с какими сложностями мы столкнулись — расскажем о нашем опыте решения сложной задачи построения платформы обработки данных с Большого Адронного Коллайдера (LHC) в Открытом Институте Ядерных Исследований в г. Дубна.

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

Безопасность (2)

OpenSource как источник атаки. Чем опасно? Как лечить?

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

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

Безопасные вычисления в высоконагруженных системах — что можно позволить себе с Intel® SGX в облаке

Все мы знаем поговорку «нет никакого облака — есть серверы в дата-центре».

Покажем, как добавить в ваши сервисы, размещенные у провайдера, новый уровень безопасности — создадим изолированный анклав в СPU с помощью технологии Intel® Software Guard Extensions (Intel SGX), к которому не имеет доступа ни гипервизор, ни сисадмин, ни сотрудник ЦОД. Это нужно для безопасного управления ключами, размещения критических функций в облаке и совместной децентрализованной обработки данных без раскрытия датасетов и моделей.

Рассмотрим SGX-анклав с точки зрения разработчика высоконагруженных систем, открытый инструментарий и уровни производительности на конкретных примерах. А также пригласим в лабораторию Selectel протестировать все вышеперечисленное на серверах Intel® Xeon® Scalable третьего поколения.

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

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

Автоматический подбор параметров для Spark-приложений: как запускать больше на ограниченном кластере и не тратить время инженеров

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

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

Как мы подружили биореакторы и ML

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

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

Несмотря на большое количество вендоров, которые предлагают свои продукты на разных стадиях автоматизации производственного процесса, мы выбрали OpenSource-решения. Будут затронуты вопросы взаимодействия с программно-техническими средствами АСУТП, MLOps-архитектура, а также рассмотрен конкретный пример применения методов машинного обучения для создания виртуального датчика процесса культивирования в биореакторе.

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

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

Выкатили в highload production сервис рекомендаций с BERT-like-моделью. Что было дальше?

Марк Паненко

Работа.ру

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

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

«ML-свадьба» между миллионами товаров, или Как выдержать нагрузку в потоке

В докладе мы расскажем о том, как нам удалось построить крутой real-time-алгоритм матчинга для товаров на огромной e-commerce-площадке. Задача была не из простых и заслуживает целого доклада.

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

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

Основные пункты доклада:
1. Про нашу задачу и цель.
2. Стек и технологии.
3. Метрики и мониторинг на всех уровнях.
4. Про ML и используемые SOTA-подходы.
5. Как мы боремся с деградацией наших моделей.
6. Нагрузки и поток данных, с которым нам приходится работать.

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

Применение машинного обучения в анализе научных данных

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

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

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

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

Это рассказ от команды подготовки данных Поиска Яндекса про то, как мы построили процессинг, обрабатывающий потоки в 5 Gb/s, как именно мы к нему пришли. Почему мы остановились на гибриде между лямбда- и каппа-архитектурами, почему наши аналитики в запросах в поле FROM вместо таблицы указывают библиотеку. И как это помогает учитывать изменения бизнес-логики без изменения кода у потребителей наших данных.

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

Мне нужна твоя поддержка: как запустить чат-бот на пяти языках, быстро без разметки и смс

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

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

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

Свой распределённый S3 на базе MinIO — практический опыт наступания на грабли

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

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

Любому проекту — нагруженному или нет — требуется где-то хранить свои данные. И, если это не тестовая среда, хранилище должно быть надёжным, отказоустойчивым и достаточно быстрым для решения задач, перед ним стоящих. При планировании такого проекта на ум любого архитектора (включая меня) сразу приходят S3-совместимые хранилища вроде Amazon AWS, Google Cloud Storage, Yandex Object Storage и т.п. Они удобны, распределены по нескольким географически удалённым друг от друга дата-центрам и не требуют никакого обслуживания. Однако при действительно больших объёмах данных даже приблизительно ожидаемые цифры, выдаваемые калькулятором стоимости, способны повергнуть в шок любого финансового директора. И тогда ключевой фразой для гугления становится "своё s3-совместимое хранилище". Пару лет назад настала моя очередь вбивать её в поисковик. Я пересмотрел несколько коммерческих и OpenSource-решений, пообщался с их разработчиками, несколько протестировал и одно внедрил.

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

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

RePlay — библиотека построения рекомендательных систем

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

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

Авторы в Дзене и как мы ищем их аудиторию

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

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

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

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

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

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

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

Геолокация по Wi-Fi/GSM в больших городах на базе ML для 30 миллионов пользователей

Геолокация при помощи триангуляции по сотовым вышкам в прошлом! Крупные города содержат миллионы Wi-Fi-точек. Современные статистические методы позволяют рассчитывать честные двумерные карты сил сигналов, а современные инженерные приёмы — строить сотни миллионов таких карт и использовать для позиционирования десятков тысяч пользователей в секунду. Наш подход позволил улучшить точность геолокации по Wi-Fi/GSM более чем в 2 раза там, где GPS неточен или недоступен.

В докладе расскажем, как симбиоз data science и инженерных решений позволил построить экономную по аппаратным ресурсам систему силами небольшой команды для 30+ М пользователей c нагрузочной ёмкостью 10K+ RPS.

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

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

Как и для чего делать свой переводчик в эпоху облачных решений

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

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

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

Как собрать облачную платформу для NLU-powered голосовых роботов и не облажаться

Сегодня коммуникационными роботами на базе NLU уже никого не удивишь: есть и коробочные решения вроде DialogFlow от Google, и опенсорс-фреймворки вроде Rasa, да и каждый уважающий себя ML-инженер хоть раз да и файн-тюнил BERT'а на задачу текстовой классификации. Нам в Voximplant захотелось собрать лучший опыт и дать возможность использовать state-of-the-art-модели и подходы людям далеким от машинного обучения — и все не покидая браузера в рамках облачной платформы. И, естественно, это оказалось не так-то и просто.

В рамках этого доклада Артем Бондарь, Head of AI компании, расскажет о тонкостях создания облачного AutoML-решения, какими трюками мы добивались низкой стоимости, сохранив возможность использовать тяжелые нейросети, кастомизированные под каждого клиента, как мы работали с разными языками и как мы подошли к задаче few-shot-learning, пряча от клиента под ковер всю игру с гиперпараметрами.

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

Распознавание речи для субтитров в VK Видео

Виталий Шутов

Вконтакте

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

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

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

Высоконагруженный блокчейн в mission critical-системе

Иван Косарев

Веб3 Технологии

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

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

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

Вадим Михайлов

Координационный центр доменов .RU/.РФ

В докладе планируется кратко ввести в курс истории интернационализации интернет-идентификаторов, рассказать о текущей работе экспертных сообществ (таких, как IETF, Unicode Consortium, W3C, ICANN и т.д.) и разработанных ими отраслевых стандартах, коротко напомнить о работе системы доменной адресации и почтового взаимодействия, а также раскрыть особенности и проблемы с внедрением поддержки IDN и EAI.

В основной части доклада будет дан обзор доступных готовых решений, таких как: почтовые сервисы Microsoft Live, Gmail; почтовые программные продукты от Apple, Microsoft, Communigate Pro, Xgen Plus и др.; программные библиотеки и фреймворки популярных языков программирования, а также будет рассказано о реальных кейсах реализации корректной работы с IDN- и EAI-технологиями в почтовых системах различного масштаба.

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



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

Что есть в китайских облаках

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

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

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

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

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

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

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

Также хочется рассказать про компоненты для создания игровых сервисов.

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

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

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

Service Mesh на стероидах (часть 2): Zero Deployment Downtime в корпоративных приложениях

Представляю вторую часть триптиха на тему "Service Mesh в Enterprise-grade-приложениях". В первой части я рассказал об основных принципах построения управляемого многоуровневого Service Mesh и дал основные паттерны его использования для обеспечения версионирования и структурирования приложений. Вот тут можно посмотреть запись https://www.youtube.com/watch?v=XtvwZqdtfgI.

Вторая часть будет посвящена техникам ВlueGreen и Canary-деплоймента для обеспечения Zero Deployment Downtime а также одновременного тестирования нескольких независимых фич.

В докладе я расскажу:
* что собой представляет версия контракта на техническом уровне и как система ее узнает;
* принципы мультиверсионности в REST, Messaging, DB;
* как воедино связывается работа с версиями в разных "средах" (REST, Messaging, DB);
* унифицированный жизненный цикл версий (deploy, promote, rollback);
* дискавери контрактов — как микросервис может определить контракт своего пира и подстроиться под него;
* границы использования мультиверсионности для обеспечения Zero Deployment Downtime — всё-таки это не silver bullet и, по опыту, работает не всегда.

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

Как не провалить импортозамещение. Меняли в Сбере шину данных, а сделали платформу

Долгие годы крупнейшие Enterprise-компании строили свои решения на базе иностранных ИТ-вендоров — Oracle, SAP, IBM и так далее. С уходом этих вендоров все стали метаться в поисках импортозамещения. Сейчас к нам приходит достаточно много таких компаний за нашим опытом замены высоконагруженной шины данных. Глядя на подходы к “импортозамещению”, кажется, что такие попытки обречены на провал. С другой стороны, внутри всего Сбера мы смогли успешно заменить иностранную шину данных.

Поговорим о том, как не провалить импортозамещение — почему есть успешные и неуспешные кейсы. Обсудим, почему мы решили “импортозамещать" свою шину данных еще до того, как это "стало модным”, что выбрали в качестве альтернативы (spoiler: Service Mesh) и с чем мы столкнулись в процессе разработки и внедрения. Разберем, почему заявленные преимущества Service Mesh, такие как “горизонтальное масштабирование” и независимость команд разработки не работает “из коробки” и что с этим делать.

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

Блокчейн в корпоративной архитектуре — дань моде или необходимость?

Денис Васин

Waves Enterprise

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

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

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

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

ERP-проект на десятки тысяч пользователей. Боимся и делаем! Как?

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

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

Ретроспектива технологий и архитектурных паттернов (6)

Эволюция распределенных атак в Интернете: 1994 — настоящее время

Предметная область нашей работы предполагает изучение DDoS-атак, бот-активности и методов их реализации. В данном докладе я расскажу:
* о путях развития DDoS с важнейшими временными вехами как с точки зрения техники, так и в публичном восприятии проблемы: Panix, Sony, XboxLive/PSN, Mirai, memcached, а также значимые случаи в Рунете;
* о том, как параллельно с DDoS возникал и развивался инструментарий для парсинга веб-страниц и API, создавались боты для скрэпинга и росла их массовость;
* о технологиях и новшествах, которые улучшают нашу жизнь в Интернете и одновременно открывают новые пути для DDoS и бот-атак.
* об уроках, которые преподнесла история, и выводах, которые удалось сделать из 11-летнего опыта в данной сфере.

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

История онлайн-видео

Максим Лапшин

Эрливидео

В этом докладе будет раскрыт срез истории онлайн-видео от wmv/avi через edonkey и internet explorer к современному выбору между av1 и h265 в браузерах.

Будет освещено развитие как кодеков, использовавшихся в онлайн-стриминге, так и протоколов для их доставки.

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

Архитектура ВКонтакте: история и будущее

В докладе рассмотрим архитектуру ВКонтакте, почему она так устроена и какие у неё сильные и слабые стороны. Посмотрим, как развивался проект с 15-летней историей, кодовой базой в восемь миллионов строк и ежемесячной аудиторией в 100 млн пользователей:
* как устроена архитектура ВКонтакте;
* как мы эксплуатируем систему с более чем 20 тысячами серверов;
* где и как мы храним данные пользователей;
* как доставляем данные;
* зачем нам свой компилятор;
* баланс uptime и time-to-market;
* какие решения позволяют делать релизы vk.com раз в час в автоматическом режиме из мастера;
* как устроена система сборки и деплоя, которая позволяет собрать 8 млн строк кода и раскатить на 10000 серверов за 7 минут.

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

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

Про историю и будущее поиска

Поисковым системам, на минуточку, уже больше 60 лет, и вымирать они не собираются. За это время человечество придумало и опробовало много разных теорий и техник. Что-то застряло в вечности практически навсегда, что-то напрочь уже забылось. Попробуем пробежать все эти 60 лет за 30 минут!

Обзорно поговорим про историю и современность технологий "просто" поиска (матчинга документов об слова), ранжирования наматченного, сжатия индексов, нехитрой прикладной лингвистики. Пробежимся по нескольким десяткам важных ключевых слов, и по топ-3 победивших на сегодня (и нет, это не Google плюс Elastic плюс хзчто, это IF плюс BM25 плюс PFD).

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

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

Postgres от начала веков и до наших дней

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

Postgres Professional

Иван Панченко

Postgres Professional

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

Из доклада слушатель узнает:
* когда была создана первая база данных, и когда людям потребовалась СУБД;
* как менялись представления человечества о том, какой должна быть СУБД, и почему язык SQL возник именно тогда, когда он возник;
* какие были периоды дикого хайпа вокруг тех или иных фич СУБД и во что они вылились после;
* как Стоунбрейкер пришел к идее Постгреса и зачем;
* кто основные контрибьюторы в постгрес и в чём их вклад;
* меняют ли технологии СУБД мир, и если да, то как;
* чем отличается сообщество Постгреса сейчас о того, каким оно было в прошлом веке и почему, насколько это применимо для других сообществ СПО;
* в чем причина(ы) роста популярности Постгреса;
* и наконец, история от самого известного российского постгресиста — что значит Постгрес для него лично. В какой степени он сделал Постгрес, а в какой — Постгрес сделал его.

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

Языки программирования: прошлое, настоящее и будущее

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

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

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

Фейл-секция (4)

Как мы базу в облако увозили

Олег Блохин

Dodo Engineering

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

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

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

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

Fail-митап "This is fine, или Все делают это"

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

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

Без камер, записи и трансляции.

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

Как понять, что проекту плохо, если ты инженер

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

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

Объясню, как понять, что проект провалится до того, как это заметит менеджер.

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

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

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

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

Иногда такое "не то" способно завести проект в тупик, а если и не весь проект, то карьеру инженера в этом конкретном проекте.

Как выглядит такое "не то", как его можно распознать, и как эти риски можно митигировать?

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

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

Энергетика и транспорт (2)

Аналитика по самолетам S7: pets vs cattle

Для вас полеты — это поиск билетов, электронный check In, "пристегните ремни" и паспортный контроль. Для нас, программистов в авиакомпании, это полное техобслуживание самолетов раз в два года, проверки раз в два дня, штрафы в сотни тысяч долларов за задержку в десять минут. Мы не может делать А/В-тесты и "быстро двигаться, ломая штуки". А бизнес хочет, чтобы мы как можно точнее предсказывали время обслуживания самолета по совсем скромному количеству исторических данных.

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

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

Face Pay

Жанна Ермолина

ГУП "Московский метрополитен"

Face Pay — сервис полностью бесконтактной оплаты проезда с помощью распознавания лиц в Московском метрополитене. Технологическим партнером проекта выступила компания VisionLabs, один из лидеров в области компьютерного зрения и машинного обучения.

Face Pay позволяет оплатить проезд, не используя при этом никакие физические носители. Пассажиру нужно пройти регистрацию в мобильном приложении «Метро Москвы» или «Московский транспорт», привязать фотографию своего лица, карту «Тройка» и банковскую карту. Чтобы оплатить проезд, нужно встать на специальный черный стикер перед турникетом и посмотреть в камеру, установленную на турникете. Турникет откроется, а деньги спишутся с привязанной к сервису банковской карты.

Face Pay — первый в России и в мире сервис по оплате проезда с помощью биометрии, запущенный в таком масштабе. Сервис доступен на всех 250 станциях метро, а с 16 марта 2022 года — на станции «Кутузовская» Московского центрального кольца.

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

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

Платформенная разработка (3)

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

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

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

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

"Канал. Продукт. Платформа", или Эволюция подходов к развитию мобильного банка Тинькофф

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

Я расскажу про то, как дошли до формулирования принципов и правил платформы МБ, без которых дальнейшее развитие было бы невозможно. Отдельно я расскажу про две текущие задачи, которые приводят к очередному организационному редизайну и изменениям в архитектуре:
1) выделение сквозных кросс-функциональных команд, условно, МБ <-> API <-> backends;
2) улучшения архитектурных подходов в интеграции МБ и API.

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

Technical governance IDP (Internal Developer Platform) для 7000 разработчиков

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

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

На докладе расскажу:
* Как приняли решение делать IDP и почему.
* Какие главные вызовы были перед новой командой.
* С чего начали делать платформу, какие были приняты ключевые архитектурные решения.
* Как справлялись с ростом вовлеченных в разработку людей на порядок.
* Использование практик API Managment для контроля за целостностью платформы.
* Как обеспечивается качество и доступность системы, разрабатываемой также и не напрямую подчиненными командами.

В конце ретроспективно взглянем на то, что у нас получилось сделать всего за 2 года.

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

Резерв (3)

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

Глеб Сахнов

Сбербанк

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

Рассмотрим предпосылки появления кэша в CPU и почему он работает. На реальных примерах кода увидим многократное ускорение алгоритмов при реализации в cache-friendly-манере. Рассмотрим, что такое false sharing и причины его возникновения в многоядерных процессорах. Поговорим о том, как распознать проблемы с кэшем в многопоточных приложениях. Покажем, как можно измерить эффективность использования CPU-кэша в linux.

Бонус: приведем пример ускорения алгоритма с использованием branch-prediction.

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

Сверхскорость. Единая платформа экспресс-доставки Яндекса

Сергей Хорошеньких

Яндекс Доставка

Мы расскажем, как устроена единая платформа для экспресс-доставки в Яндексе.

Слово “экспресс” означает, что заказ нужно доставить вскоре после его создания (естественные примеры — заказы в Яндекс Лавке или Яндекс Еде).

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

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

Частотный и байесовский подходы оценки TPR при неполной разметке данных

Алан Савушкин

Лаборатория Касперского

Практически в каждом проекте, в котором применяются модели машинного обучения, присутствует необходимость оценивать метрики онлайн, отражающие качество модели. Например, в задаче классификации целевыми метриками могут быть Precision и Recall (TPR). В случае доступности полной разметки данных, то с точки зрения статистики достаточно просто получить оценки и построить доверительные интервалы для этих оценок. Но что, если решается задача фильтрации данных, и полная разметка для отфильтрованных объектов отсутствует и необходимо оценить TPR?

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

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