Доклады

Показать только принятые доклады

Интернет вещей (IoT)

Как мы запускали компьютерное зрение для офисов продаж МТС по всей России

Компьютерное зрение все больше проникает в текущие бизнес процессы больших компаний. Большая часть проектов идет на серверах с GPU с хорошим интернетом и охлаждением. Но есть множество ситуаций, когда запуск модели и обработку видео надо сделать как можно ближе к камере, в случае когда у вас нет стабильного интернета или когда передавать видео может быть неправильно с точки зрения безопасности.
У МТС есть большая сеть точек продаж, больше 5000 точек по всей России, и в текущих условиях пандемии посетители хотят все более персонализированный сервис. В докладе я расскажу как мы смогли запустить AI сервис компьютерного зрения на EDGE устройствах в 500 офисах компаний, с какими подводными камнями мы столкнулись и как смогли поддерживать весь флот устройств в актуальном состоянии и выполнять задачи бизнеса с нужной точностью.

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

Узкотематические секции: видео, поиск, RTB, биллинги

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

Вернемся в 2019 — Skyeng, 1500+ одновременных уроков в онлайне и постоянные жалобы на видеосвязь от всех отделов. Продукт быстро масштабировался, количество пользователей росло, а видеосвязь оставалась функцией, которой занимались без фокуса и по чуть-чуть.
Но за 2 следующих года нагрузка выросла в 3 раза, а количество негативных отзывов на видеосвязь наоборот — удалось в 3 раза снизить.
В докладе пройду по нашему пути понимания проблем: как начали измерять видеосвязь, от субъективных оценок перешли к объективным на базе ML, попробовали Pion вместо Janus и принудительную деградацию видеосвязи вместо встроенного механизма в WebRTC, с чем еще столкнулись в пути и как решали, куда двигаться дальше в технической истории.

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

Как мы переводим 10M+ товаров на 20 языков

Если вы хотите продавать товары во всём мире, локализация – одна из ваших ключевых потребностей. Если вы делаете маркетплейс, речь о локализации миллионов товаров, а также потока поисковых запросов, отзывов, точек трекинга и так далее. Машинный перевод стоит денег, а RPS на получение текстов огромен, что автоматически делает подсистему перевода одной из самых высоконагруженных и дорогих в проекте. Я расскажу, какие идеи мы изначально заложили в хранилище переводов и какие из них оказались плохими, как мы экономили за счёт кэширования и пришли к свалке в 4 ТБ, что мы теперь с этим делаем и что ещё только предстоит.

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

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

Почему поиск это сложно.
Что такое хороший поиск. Метрики качества поиска
Что важнее - точность или полнота
Какие данные о поиске нужно собирать
Нужны ли поисковые подсказки
Как сделать поиск быстрым
Управление ранжированием товаров
Мультирегиональность поиска
ML в поиске

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

паттерн архитектуры реал-тайм веб-рекламы (МТС DSP) и примеры реализации

программатик МТС оперирует деперсонифицированными данными: ~3млрд связок ~600 млн кук, относящимся к ~100млн профилей пользователей с разбивкой по более чем 2 тысяч групп интересов. Мы разработали собственную программатик платформу и в докладе мы расскажем как сделать архитектуру программатик, который позволяет решить все "хотелки" бизнеса, не "падает" под собственным весом и практически неограниченно масштабируется.

Расскажем о простом архитектурном паттерне, работающем в реальном-масштабе времени который, позволяет обрабатывать 200к rps с латентностью порядка 20мс/ При этом горизонтально масштабируется, позволяет применять МЛ модели и различные стратегии открутки рекламы, и на горячих путях практически отсутствует копирование данных.

Применение общего архитектурного подхода проиллюстрируем двумя примерами: калькулятор охвата рекламной кампании и «горячий» и «холодный» путь биддера DSP — реалтайм ядра DSP.

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

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

Оптимизация работы скважин на нефтяных месторождениях с применением Deep Reinforcement Learning.

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

Нефтяное месторождение представлено сетью скважин, оборудованных установками электроприводного центробежного насоса (УЭЦН) и связанных между собой общим трубопроводом. При этом активные добывающие скважины оказывают друг на друга влияние через давление в трубопроводе и в пласте. Изменяя модель УЭЦН, частоту его работы, а также глубину спуска можно управлять добычей нефти как отдельной скважины, так и их совокупностью. Кроме того, в силу особенностей скважины и пласта, не все насосы могут работать постоянно, в следствие чего возникает необходимость составления расписания работы насосов.

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

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

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

The Magic of Puzzle Driven Development

We created Puzzle Driven Development (PDD) methodology more than ten years ago. Since then, there were hundreds of projects that used it in their GitHub repositories. PDD helps large software teams decompose long tasks on-fly, letting programmers participate in the planning of future tasks. I will explain how it works and demonstrate the hosted web service we created. After the presentation, you will be able to either use this methodology in your projects or try our service for free.

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

BigData и машинное обучение

Unboxing многокомпонентных Big Data-проектов инструментом DataLog на основе подхода software as artefact

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

Однако для Big Data это дополнительно все осложняется еще следующим:

1. Множество компонентов в одном проекте (например, в обычном проекте архитектура выглядит так: webserver <-> webapp, в bigdata проекте так: oracle -> sqoop -> hive -> spark -> kafka -> model -> kafka -> spark -> hive);
2. Невозможность применения единой архитектуры проекта упорядочивающей сложность системы, такой например, как domen-driven-design;
3. Декларативность инструментов программирования pipeline, декларирующих что нужно сделать, а не описывающих как это будет делаться;
4. Необходимость отдельно вести учет компонентов системы и объектов данных.

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

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

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

Евгений Малютин

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

Любовь Пекша

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

Рекомендательная система может как стать черной дырой, пожирающей железо и время разработчиков и не приносящей результат, так и управляемой точкой роста для продукта. В случае b2c-продуктов: социальных сетей, e-commerce или контентных платформ ставки еще выше — от качества рекомендаций напрямую зависит Life time value пользователя и ключевые метрики компании.

В докладе разберем, как работают рекомендательные системы и какие возникают проблемы, когда нужно рекомендовать контент 97 млн пользователей и отдавать результат на скорости 10k rps. Покажем, как логически и технически устроены подобные системы на примере рекомендаций сообществ ВКонтакте. Обсудим плюсы и минусы трех классов систем: офлайн, онлайн и асинхронные, чем стоит руководствоваться при выборе и как жить c последствиями.

Подробно поговорим про источники кандидатов для рекомендаций, расскажем как сделать простые и рабочие или сложные и тоже рабочие. Погрузимся в Deep Learning (но без фанатизма) и расскажем, как отфильтровать буллщит из потока статей по этой теме и собрать свою нейронную факторизацию, с каких прототипов стоит начинать и как их развивать. Из доклада вы узнаете, как из понятных кубиков собрать свою рекомендательную систему, а с помощью грамотной работы с инфраструктурой легко экспериментировать и итеративно её улучшать.

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

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

Tekton – нативный CI/CD для любого публичного и частного облака

Tekton – это мощный и гибкий фреймворк с открытым исходным кодом для создания CI/CD систем, позволяющий разработчикам собирать, тестировать и развертывать их приложения в облаке и на частной инфраструктур. Расскажу о ключевых преимуществах, которые дает Tekton разработчикам. Например, позволяет стандартизировать инструменты и процессы CI/CD для разных облачных провайдеров, языков и сред развертывания, масштабируется без необходимости распределения ресурсов или любых других модификаций, обеспечивает высокую степень гибкости. Покажу как устроен рабочий процесс при создании CI/CD на Tekton: как с его помощью построить собственный каталог типовых задач и пайплайнов внутри организации. Расскажу о нюансах эксплуатации, а также сравним Tekton с классическими системами для построения CI/CD.

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

CI умеют делать все, но как сделать CD? Делаем CI/CD удобным и прозрачным

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

Наш подход решает следующие проблемы:
• Прозрачность: все всегда знают, какая версия какого-либо сервиса стоит на каком-либо окружении, когда и кем установлена, информация о коммите и т.д.;
• Состояние: система помогает сразу понять, обновился ли компонент или нет;
• Простота деплоя: любой сотрудник может задеплоить нужную версию сервиса просто изменив значение в таблице;
• Автоматика: после изменения ветки сервиса она автоматически деплоится на все окружения, которые заданы в таблице;
• Разделены сборка и деплой:
- При деплое не нужно каждый раз собирать сервис заново;
- На продакшн отдаётся именно тот образ, который тестировался, а не собирается новый.
• Дёшево поддерживать k8s манифесты сервисов: для каждого сервиса пишется всего один набор манифестов (хельм чарт).

А еще расскажем:

• Как на стенде за 5 секунд развернуть релизные версии всех компонентов;
• Как сократить время деплоя на стенд в 10 раз;
• Как на стенде автоматически поддерживать последние версии компонентов с заданных веток;
• Как тестировать и деплоить на продакшн один и тот же артефакт;
• Как экономить силы DevOps на поддержку k8s манифестов.

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

Open Policy Agent - серебряная пуля для Kubernetes. И не только для него

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

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

Но кажется, что сообщество обратило на это внимание и сейчас активно выходят фичи, которые позволяют гибко настроить политики безопасности. И одной из очень перспективных на мой взгляд технологий является Open Policy Agent, который реализован в Kubernetes с помощью Gatekeeper.

В рамках доклада мы с вами разберемся:

- Что такое Open Policy Agent (OPA) и почему за ним будущее?
- Как можно валидировать вообще все объекты, что создаются в Kubernetes, с помощью только одного admission-controller'а?
- Как и чем заменить устаревший PSP, получив при этом кучу дополнительной полезной функциональности?
- Как внедрить Gatekeeper в большой работающий кластер на продакшн и при этом ничего не сломать?
- Какие важные аспекты и подводные камни необходимо учитывать при внедрении у себя OPA/Gatekeeper?

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

Настраиваем инцидент менеджмент: от хаоса до автоматизации

Эволюция инцидента менеджмента от одного дежурного до сложной системы дежурств, состоящей из команды SRE и нескольких команд разработки. Каждая команда имеет свое расписание дежурств, команды разработки дежурят по своим сервисам в течение рабочего времени, SRE являются второй линией для них и дежурят во вне рабочее время.
На данный момент процессу дежурства автоматизирован, от первого алерта до генерации драфта постмортема для разбора последствий инцидента. В докладе будет описана работа текущего процесса инцидент менеджмента и автоматики вокруг него. Для мониторинга наших сервисов мы используем схему Prometheus + Alertmanager + Pagerduty, постмортемы с недавнего времени храним в Notion, а сам процесс инцидента менеджмента автоматизирован при помощи Slack бота

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

LINSTOR - это как Kubernetes, но для блочных устройств

В этом докладе поговорим про LINSTOR - open source хранилище от компании LINBIT (разработчика DRBD).

Начиная с девятой версии DRBD сменил курс с «‎одно большое отказоустойчивое устройство на всех»‎ на «‎по отдельному DRBD-устройству на виртуалку»‎, стал поддердживать diskless-реплики, появился оркестратор, поддержка снапшотов, шифрования и много другого.

Тезисы:

- Почему LINSTOR - это просто хранилище, а скорее оркестратор блочных устройств. В чём его схожесть с Kubernetes?
- Выделим преимущества и недостатки DRBD перед Ceph и другими кластерными файловыми системами.
- Копнём чуть глубже и посмотрим как работает DRBD9, LINSTOR и что находится у него под капотом.
- Разберём сущности LINSTOR и как его правильно настроить.
- Как работают снапшоты, бэкапы, дедупликация, шифрование
- Почему не рекомендуется использовать опцию allow-two-primaries, и зачем вообще она нужна
- Какие есть проблемы. Как устранять неполадки и чинить split-brain, если потребуется.

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

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

Kubernetes cluster. Testing Performance and Scalability

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

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

Соберем свой большой кластер и проверим, как Kubernetes переносит масштабирование, когда количество нод переваливает за 5 тысяч. Рассмотрим, как это влияет на мастер-компоненты и попытаемся побить некоторые рекорды масштабирования.

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

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

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

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

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

Как бы Парето мониторил твою распределённую базу данных

Стандартный подход к мониторингу (собрать всё, что можно собрать) не дает ответа на вопрос, как траблшутить сложные сценарии. В своем докладе поделюсь опытом настройки системы мониторинга для распределенной базы данных Apache Ignite, но те же принципы справедливы для любой другой распределенной БД. Поговорим о том, куда, зачем и как смотреть, а на что можно закрыть глаза, чтобы снизить нагрузку на систему.

Другими словами:
- что мониторить необходимо в базе данных, и о чем нельзя забывать при мониторинге compute grid;
- на какие trade-off можно пойти при оптимизации системы;
- как прикрутить трейсы, чтобы следить за действиями не только в базе, но и в приложении;
- куда смотреть разработчикам, чтобы быстрее найти источник проблем.

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

How to fix "built in" storage problems in Kubernetes

We have been keeping the pulse of the storage world for 21 years and evaluate the demands of those who need primary storage in the open source world. We develop block storage solutions in this direction.

LINSTOR, a world-class SDS for persistent container storage for Kubernetes, works seamlessly with most critical and intensive business applications.

However, k8s has some "built in" problems. These;

Lack of disk localization, slow pod failover times, external storage integration difficulty and management problems.

What we build in open source, is solving all of these problems. With the help of DRBD replication and STORK we fix disk localization. HA controller decreases 60 second pod failover into less than 15 second. LINSTOR operator makes it easy to deploy & manage storage solutions in K8s. Splitting the data & management layer is making day2 operations easy. 

In the session, we'll explain all of these features technically and how they work wisely.  

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

Как существенно улучшить работу реляционной БД с помощью оптимистичного параллелизма

- в наличии монолитный проект на 2 млн строк кода, ходящий в БД через ORM
- десятки тысяч OLTP запросов в секунду (на запись!)
- периодические "цепные реакции" дедлоков - что-то начинает блочиться, и очень быстро БД может деградировать до практически неработоспособного состояния
- расскажу как определялись основные места приложения усилий, что потребовалось доработать в Data Acess Layer и как это повлияло на бизнесовые метрики
- расскажу общий принцип масштабирования подхода и при чем тут DDD

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

Что нового в плане мониторинга в PostgreSQL.

В PostgreSQL очень много самой разной статистики при помощи которой можно наблюдать за тем как работает БД. Практически все инструменты и плагины для мониторинга PostgreSQL берут данные из этой статистики. Статистики действительно очень много, но даже несмотря на это, с каждым релизом появляется что-то новое. В этом докладе я расскажу про нововедения в средствах для мониторинга которые появились в последних двух релизах Postgres 13 и 14, который выйдет осенью, но уже доступен для бета-тестирования. Я расскажу о том какие конкретно добавлены улучшения, в каких случаях они могут быть полезны и как их применять, приведу практические примеры их использования. Доклад будет полезен системным администраторам и ДБА которые интересуются мониторингом и занимаются их поддержкой.

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

pgSCV — новый экспортер PostgreSQL-метрик для Prometheus

Если вы хоть чуть-чуть знакомы с миром opensource-мониторинга, то наверняка знаете, что такое Prometheus. А еще лучше, если вам приходилось его настраивать или поддерживать, то вы знаете про его особенности в виде pull-модели и ориентированность на экспортеры. Если кто не слышал, это агенты, которые собирают метрики, а Prometheus далее забирает их самостоятельно. В индустрии мониторинга Prometheus получил очень широкое распространение и на сегодняшний день практически для каждого софта или даже оборудования есть свой экспортер. PostgreSQL — не исключение и для него также есть экспортер. Однако у этого экспортера есть свои недостатки, и более того — существуют конкретные ограничения, которые ограничивают его функциональность. Посмотрев на это, я, засучив рукава, написал pgSCV — новый экспортер, задача которого обойти ограничения и предложить пользователю лучшую функциональность.

В этом докладе я расскажу о проблемах, с которыми я столкнулся и которые подтолкнули меня к написанию экспортера. Также расскажу, как эти проблемы решены в pgSCV и какой функциональностью он обладает в целом. Доклад будет полезен всем, кто занят в поддержке и обслуживании мониторингов на базе Prometheus и мониторит PostgreSQL-инфраструктуры (sic), именно так, ведь pgSCV сделан не только для PostgreSQL, а для всего, что с ним связано...

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

Базы данных с точки зрения НИОКР: исследуем и готовим с правильными ингредиентами

critskiy

Ростелеком Солар

За свой разнообразный опыт я успела повидать множество дисфункций и результатов неправильного выбора или работы с различными базами данных. Практически так или иначе хуманам свойственно выбирать на основе best practices технологии или стэк, расплачиваясь после безграмотными процессами или проблемами неправильно спроектированных решений. В своем докладе я постараюсь собрать паттерн для минимизации проблем на основе баз данных, используя старый добрый подход в лице НИОКР (иными словами, R'n'D).

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

База данных для 60Tb эвентов за 190$

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

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

JIT in ClickHouse

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

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

Ребаланс в распределенной БД: как нагнать состояние узла до состояния кластера, при этом не перемещая все данные

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

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

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

Подсистема I/O в PostgreSQL: архитектура, проблемы, обходные пути

Несмотря на то, что подсистема ввода-вывода PostgreSQL вполне хорошо подходит для большинства решаемых задач, она все-таки имеет несколько особенностей и проблем:
* трудно предсказать задержку записи/чтения данных, особенно для баз данных, размер которых значительно больше доступной памяти;
* пропускная способность ввода-вывода, особенно в быстрых подсистемах хранения (например, в NVMe-дисках), недостаточно высока для использования на все 100%;
* бэкенды сами выполняют слишком много операций ввода-вывода, так как фоновый писатель (bgwriter) работает не очень оптимально;
* генерируется ненужная случайная запись данных (bgwriter, backends);
* двойная буферизация между страничным кэшем ОС и общими буферами (shared_buffers) памяти Postgres;
* все операции на чтение данных являются синхронными (из страничного кэша ОС);
* большой размер shared_buffers может вызвать проблемы, когда таблицы очень часто удаляются или очищаются.

Об этом и не только я расскажу в своем докладе...

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

Архитектура Vitastor. Тёмная сторона моей распределённой СХД

Виталий Филиппов

Личный проект

Vitastor — это мой быстрый «Ceph-заменитель». Распределённая блочная программная система хранения данных (SDS), способная, в отличие от большинства других систем, нормально работать с быстрыми твердотельными накопителями, и при этом, в отличие от большинства других систем, имеющая симметричную распределённую архитектуру без единой точки отказа. А под «нормально», конечно, понимается «так быстро, как только возможно» :-).

В предыдущем докладе на DevOpsConf (https://devopsconf.io/moscow/2021/abstracts/7458) я рассказал о ситуации с SDS («нечего надеть»), причинах создания Vitastor и общих принципах его разработки.

В этом докладе я хочу больше остановиться на технической стороне. Тёмной, архитектурной технической стороне.

Что такое «симметричная распределённая архитектура»? Как конкретно обеспечивается консистентность? Как реализованы снапшоты и клоны? Зачем нужен io_uring? Как Vitastor использует RDMA? Что ещё за монитор на node.js и откуда там LP солвер (утилита решения задач линейного программирования)?

С какими ещё архитектурными выборами придётся столкнуться по ходу разработки? Например, что будет, если всё-таки захочется реализовать поверх Vitastor файловую систему? Обо всех этих вопросах и пойдёт речь в докладе.

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

О чем надо думать выбирая хранилище в публичном облаке

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

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

Структура доклада будет выглядеть

1) Сформулируем требования к хранилищу
2) Рассмотрим объектные хранилища в облаках и сделаем выводы о критериях выбора типа объектного хранилища
3) Рассмотрим файловые хранилища в облаках и сделаем выводы о критериях выбора типа объектного хранилища

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

Блокчейн

Современные векторы атак на DeFi проекты

DeFi - быстро растущий рынок, приманивающий своими высокодоходными ставками. Любой высокий доход сопровождается и высоким риском. В докладе я рассмотрю контролируемые (минимизируемые) риски. Из $100B+ вложенных в DeFi более $14B подверглось атакам и хищениям. При этом речь идет только про публично известные случаи. По нашей оценке непубличные хищения могут увеличить общий размер утрат на 50%.

-DeFi рынок. Размер. Темпы роста. Доходы и потери за год существования рынка. Типы проектов.

-Контролируемые риски со стороны создателя и мейнтейнера проекта, их цена, объем потерь:
--Misuse of Third-Party Protocols and Business Logic Errors
--Coding Mistakes
--Flash Loans, Price Manipulation, Miner attack
--Некомпетентность разработчика

-Практический разбор векторов атак ($5B+ потерянных средств):
--Flash loan, block mining attack
--RFI в masterchief
--Flash Loan
--Изменение кода популярных библиотек OpenZeppelin (SafeMoon $2B+ эксплойт)

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

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

Распределенная трассировка - подключить всех и не умереть!

Мы в МТС строим экосистему и всерьез занимаемся ее наблюдаемостью. Распределенная трассировка - один из столпов наблюдаемости. Она жизненно необходима, если вы работаете со сложной распределенной системой.
В докладе я расскажу как мы собираем 100% трассировки с 50+ продуктов при помощи Jaeger и Elasticsearch. Как справляемся с постоянно растущей нагрузкой от новых продуктов. Затрону вопросы мониторинга и влияния сбора трассировки на наблюдаемою систему.

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

Эволюция API Gateway - как не допустить хаос при цифровой трансформации на примере телеком-оператора

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

Аутентификация и авторизация "всех со всеми" если у Вас несколько поставщиков идентификационной информации (Identity Providers), множество сервисов, а безопасностью взаимодействия нельзя пренебречь.

"Купить или не купить - вот в чем вопрос". Вопрос выбора API Gateway и почему мы решили пойти своим путем.

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

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

Перебои и ошибки в работе распределённых систем (будь то Web или IOT) совершенно обычная ситуация. Проблемы в работе с сетью, перебои в работе зависимостей и банальный человеческий фактор — та цена, которую мы платим за общую стабильность системы, лёгкую масштабируемость и гибкость в разработке.

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

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

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

Kubernetes: Как зайти в cloud и не утонуть в docker-образах

Михаил Мозальков

Deutsche Bank Tech Center

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

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

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

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

Для этого хорошо иметь наглядное визуальное представление, которое послужит основой для обсуждения. Классические подходы и диаграммы проектирования — ER-диаграммы, UML и другие — были придуманы в эпоху монолитов, не слишком хорошо позволяют обсуждать такую архитектуру. Я расскажу о модели, которая позволяет рисовать схемы современных приложений и обсуждать их масштабирование и устойчивость работы при отказах. И проиллюстрирую ее использование конкретными примерами.

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

Бессерверные web-приложения c Azure Durable Entities, SignalR, React и TypeScript

Виртуальные акторы переживают второе (третье?.., четвертое?..) рождение в бессерверном мире, как альтернатива теряющему свои позиции объектно-ориентированному программированию. Durable Entities (расширение Azure Functions) - самая актуальная реализация этого архитектурного шаблона в Azure, доступная к тому же из многих языков программирования. Я написал обертку над Durable Entities на TypeScript - https://github.com/scale-tone/durable-mvc-starter. Она позволяет реализовывать акторы (entities) в виде TypeScript-классов, а также автоматически (через Azure SignalR Service) передает изменения их состояний на клиента (в браузер), где эти акторы отображаются с помощью React. Используя все это, мы напишем, запустим и задеплоим простое тестовое приложение, и я расскажу/покажу, как оно работает.

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

Прокачаем Чистую Архитектуру от дядюшки Боба

Кажется что про архитектуру монолита уже все песни спеты и книги написаны - бери, читай и делай. Мы тоже так думали. Но при применении описанных в различной литературе подходов на практике появляется много вопросов.
В своем докладе я расскажу о нашем опыте применения Чистой Архитектуры на практике.
О чем не сказал в своей книге дядя Боб?
Как соединить вместе все архитектуры: Чистую, Луковую и Порты-адаптеры?
Можно ли использовать CQRS вместе с Чистой Архитектурой?
И наконец - кому нужна Чистая Архитектура, если все уже давно на микросервисах?

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