Профессиональная конференция для разработчиков высоконагруженных систем
7 и 8 ноября 2019 Москва, Сколково

Заявки на доклады

Поиск по тегам:

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

Симметричная и асимметричная фильтрация DDoS-атаки: плюсы, минусы, ограничения

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

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

iptables + consul = :3

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

И в этом докладе я хочу рассказать о том, как вы можете внедрить её у себя и что из этого может выйти :)

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

DevSecOps или как встроить проверки ИБ в микросервисы

Сокращение time-to-market, ускорение процессов разработки ПО, уменьшение релизного цикла, увеличение количества репозиториев кода и артефактов – всё это становится головной болью для специалистов ИБ. Сегодня поговорим о том, как автоматизировать проверки ИБ, как ими управлять, и как тиражировать их на все продукты. В общем, поговорим о DevSecOps.

Микросервисы, SOA
,
Devops / другое
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
Программный комитет ещё не принял решения по этому докладу

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

Building a robot with my daughter - the software part

“Daddy, I want to build a robot. Do you know how to build a robot?” my daughter asked me. “Hmm.. Yes, actually I do know how to build a robot because I was taught Artificial Intelligence in school.” I’ll show how to easily build a speaking and seeing robot (software) using commercial cloud services.

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

История про моделирование "по-быстрому": как сделать скругленные зоны на карте

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

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

AngularJS, Backbone.js и другие JavaScript-фреймворки
,
JavaScript
,
Веб-графика, оптимизация изображений
Программный комитет ещё не принял решения по этому докладу

Блокчейн

Что нам стоит блокчейн построить?

Анализируя многочисленные blockchain проекты (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin и др.), я понимаю, что с технической точки зрения все они построены по одним принципам. Блокчейны напоминают дома, у которых при всем разнообразии конструкций, декора и назначений имеются фундамент, стены, крыша, окна, двери, которые связаны друг с другом определенными способами. И если понять основные принципы проектирования зданий, знать свойства применяемых материалов, то можно определить целевое назначение конкретного дома. В настоящее время с блокчейном возникла ситуация, что все про него слышали, но мало кто понимает архитектуру и принципы работы. Поэтому возникает непонимание для чего и как имеет смысл использовать технологии блокчейна.

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

Распределенные системы
,
Блокчейн-технология
,
Смарт-контракты
Программный комитет ещё не принял решения по этому докладу

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

Почему мы занимаемся Open Source разработкой, и почему вы тоже получите выгоду, если присоединитесь к нам?

Долгие годы корпорация AT&T была известна своими проприетарными решениями из мира UNIX, и использовала практически полностью только проприетарное ПО. Этот доклад расскажет о драйверах изменений в сторону использования и разработки ПО с открытым исходным кодом, и проектах, в которых компания принимает участие. Будут рассмотрены аргументы за и против, рассказано об опыте компании, и приведены примеры расчётов.

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

Будущее рынка разработки ПО
,
Управление / другое
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Процессы и инструменты в enterprise
Доклад принят в программу конференции

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

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

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

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

Локализируй это

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

Помимо этих вопросов, я расскажу о том, как мы в Контуре решали проблемы, с которыми столкнулись при интернационализации сервисов:
- тонкости перевода: падежи, контекстозависимость
- процесс взаимодействия с переводчиками
- localization-friendly разработка
- как не задерживать релиз из-за переводов
- как можно масштабировать это в большой компании
- почему стало сложно переводить сроки вида "уважаемый <user_name>, вы должны перейти <a href=#> style="color: blue">в настройки</a>", и что с этим делать

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

Миллионы миллионов: архитектура большого биллинга

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

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

В докладе я расскажу, как на практике реализовать требования к безопасности, отказоустойчивости, масштабируемости и гибкости системы на примере архитектуры биллинга, объединяющего Badoo, Bumble и другие продукты MagicLab. У нас почти 500 млн пользователей по всему миру, и наш биллинг поддерживает около 40 платежных методов, принимая и выплачивая деньги любыми известными способами — от SMS и банковских карт до криптовалюты, ваучеров в почтовых отделения и подарочных карт.

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

Полнотекстовый поиск в Couchbase Server

Расскажу про внутреннее устройство полнотекстового поиска в Couchbase Server с точностью до байта.

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

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

С++

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

Быстрый рост количества встраиваемых систем и IoT устройств актуализирует вопрос качества их программного кода. Помимо этого, процесс разработки для таких систем связан со сложностью отладки или использования динамических анализаторов кода. Всё это делает привлекательным использование инструментов статического анализа кода при разработке проектов для встраиваемых систем. Поговорим о существующих инструментах, чем они могут помочь, а также о стандартах кодирования (MISRA, AUTOSAR).

C/C++
,
Стандарты кодирования
,
Методы и техника разработки ПО
,
Devops / другое
,
Автоматизация тестирования
Программный комитет ещё не принял решения по этому докладу

Устройство репликации в in-memory базе данных Reindexer

Мы разрабатываем in-memory базу данных для платформы Wink - облачного телевидения/кинотеатра, как быстрый и умный кэш для контентных данных.
Каждая нода системы содержит свою копию кэша, а за репликацию данных из централизованного хранилища отвечает код бэка - приложения на golang

В какой то момент такая схема перестала быть удобной в эксплуатации и мы приняли решение переложить функцию репликации на движок in-memory.

При реализации мы рассматривали несколько альтернативных подходов к архитектуре репликации для решения задачи - в итоге остановились на комбинированном подходе: логическая репликация по WAL + live stream обновлений.

В докладе расскажу о наиболее интересных деталях подкапотной реализации: Как реализовывали сервер, как реализовывали клиент - и то и то приложение на C++11. Какая многопоточная модель используется. Где и как нашлись узкие бутылочные горлышки, и как их удалось пофиксить своими lock free буферами.

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

C/C++
,
Базы данных / другое
,
Оптимизация производительности
,
Распределенные системы
,
Синхронизация данных, параллельная обработка, CDN
Доклад принят в программу конференции

Как мы сделали С++ распределенным

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

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

Базы данных / другое
,
Распределенные системы
Доклад принят в программу конференции

Быстрый HTTP парсер на базе Ragel

В данном докладе будут рассмотрены вопросы создания эффективных парсеров протокола HTTP и в частности одна из реализаций на Ragel разработанная в компании Crazy Panda. Будут затронуты ключевые проблемы при реализации подобного рода парсеров и пути их решения.


Фреймворки
,
API
,
C/C++
,
Perl
,
Бэкенд / другое
Программный комитет ещё не принял решения по этому докладу

Как обогнать и перегнать Spark на коротких дистанциях.

История из жизни стартапа купленного крупной компанией.
Случается, что проверяют много гипотез.
Одна из гипотез выстреливает, но есть проблема реализации гипотезы на python со spark.
Оказывается, что в продакшене на этот несчастный прототип наливают огромную нагрузку и он не справляется.
Не секрет, что бутылочное горлышко у python и spark – работа с ресурсами.
Существуют вполне здравые пути решения проблемы, которые мы пробовали:
поменять подход к обработке входного потока данных;
отказаться от пополнения данных из кластера spark;
отказаться от кластера и работать в один узел и с локальными данными;
отказываться от spark нельзя: слишком много изменений.
Все перечисленные подходы в нашем случае не сработали.

Одно из экстемальных решений проблемы служит переписка некоторого количества api spark на С++ и запуск python из С++.
Причем такой подход будет работать при условии:
работа с большими фрагментами памяти и файлами off python vm;
управление жизненным циклом задач на стороне python;
простота интеграции с текущей кодовой базой.
В докладе я расскажу, какие решения пришлось придумать для того, чтобы заставить все это работать.

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

Очереди сообщений поверх Nginx

В нашей работе мы обеспечиваем доставку служебных сообщений на видео приставки.
Доставка сообщений реализуется очередью сообщений поверх протокола HTTP, для этого мы использовали nginx-push-stream.
В качестве замены мы решили сделать модуля на основе nginx-push-stream.
Мы написали упрощенный вариант для нашей бизнес потребностей, используя систему управления соединениями nginx и свою систему управления ресурсами.
При реализации мы столкнулись с проблемами управления разделяемыми ресурсами в воркерах при обработке запросов.
Про особенности управлениями ресурсами в nginx и как все у нас получилос "хорощо" у меня в докладе.

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

Профайлер запросов в ClickHouse

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

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

Несмотря на это, каждый раз когда запрос выполняется мы спрашиваем себя: “Почему так долго? Почему 5 миллисекунд, а не 1, на что тратится это время?”

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

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

C/C++
,
Профилирование
Программный комитет ещё не принял решения по этому докладу

Способы компиляции C/C++ в Webassembly на примере портирования Redis

В данном докладе будут рассмотрены современные технологии, позволяющие компилировать код на C/C++ в WebAssembly: стандарт WebAssembly System Interface (WASI), компилятор emcscripten, поддержка WebAssembly в LLVM и clang. Чтобы во всём этом разобраться, рассмотрим один из способов портирования Redis в WebAssembly. Также поговорим о том, с какими сложностями можно столкнуться при портировании, насколько быстро можно портировать приложение и насколько быстро оно может работать в сравнении с нативным выполнением.

Фреймворки
,
C/C++
Программный комитет ещё не принял решения по этому докладу

Векторизуй это

В докладах про оптимизацию регулярно дело доходит до векторизации при помощи этих ваших SSE, AVX и прочих непонятных аббревиатур, и не зря, так как фронтир CPU оптимизации неминуемо проходит по ручному SIMD коду, полная идеальная автоматика компиляторам ещё и близко недоступна. Но при этом ни одного внятного крэш-курса "да что это такое вообще и как нормальному человеку их начать использовать" мне не вспоминается. Закроем лакуну!

Что хочется уместить в доклад? Рассказать про общую концепцию SIMD, про MMX/SSE/AVX/FMA. Подробно разобрать "мою первые полторы программы про сложение чисел", плюс как начать использовать это добро, даже если у вас Python (native bindings никто не отменял). Показать, что ассемблер уже давно не нужен, всё выглядит, как обычный императивный код. В ходе разбора посмотреть на основные классические маневры (movups/movaps, swizzle/shuffle, hadd, dot product, prefetch, movntq, итп). Показать, для чего ещё, кроме "арифметики и векторов", применим SIMD, показать побольше разных классов задач (обработка строк, хеширование, парсинг, поиск, итд). Пробежаться по основным группам инструкций, внести общее понимание, что быстро, что медленно. Показать пару живых примеров "когда и почему AVX не нужен, а когда таки да". Ну и пару слайдов с котиками показать, если найдутся хорошие котики.

Доклад достигнет своей цели, если следующий раз при возникновении острой потребности что-то заоптимизировать прослушавшему будет уже нестрашно попробовать эту вашу Магическую Векторизацию, и он (или она, или оно) возьмёт, наконец попробует и даже осилит.

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

Системное администрирование

Coredumper. Мониторинг и управление дампами памяти на всём парке машин Фейсбука

Моя команда отвечает за то чтобы facebook.com работал. Звучит очень размыто, но это наиболее точная формулировка. Нас немного. Такого же размера команды разрабатывают сервисы среднего размера в Фейсбуке. Когда Фейсбук горит, мы его тушим, а горит он не часто. Большую часть времени мы пишем мониторинг и автоматизацию для того чтобы облегчить жизнь себе и другим.

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

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

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

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

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

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

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

Как создать суперкомпьютер своими руками.

Я хочу рассказать о создании и использовании в нашей группе компаний кластера «Колмогоров», который недавно вошел в топ суперкомпьютеров в России.

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

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

Бэкап в современной инфраструктуре

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

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

Основные идеи:

- Быстрое развитие архитектурных подходов и консерватизм резервного копирования: как быть?
- Разбираемся в понятиях: бекап и копия данных?
- Раскладываем по полочкам: горячие и холодные данные
- Бекап сервера или сервиса?
- Бекап MySQL: так ли все просто, как кажется?
- Виртуальные машины: что делать с "черным" ящиком?
- Верификация бекапов: темный лес, без которого все остальное не имеет смысла
- Ceph как хранилище: так ли все просто?
- Рекомендации и выводы из практики инженеров Badoo

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

Кластер Elasticsearch на 200тб+

Цель доклада: Рассказать о подводных камнях и архитектуре кластера elasticsearch для хранения логов в особо крупном объёме.

В докладе я расскажу о том, как в рамках проекта «Одноклассники» мы организовывали хранение и доступ к логам для разработчиков.
Изначально к сервису предъявлялись высокие требования. Все понимали что объёмы обрабатываемых данных будут большими, так же нужна была отказоустойчивость, а пиковая нагрузка могла возрастать до 2 млн. По этим причинам задача оказалась совершенно нетривиальной, с большим содержанием "подводных камней" и пикантных особенностей.
Я изложу историю нашего «извилистого» пути к решению этой задачи, а также расскажу к какой архитектуре кластера мы, в итоге, пришли и какие решения, кажущиеся на первый взгляд правильными, "стреляли в ногу" в самый неожиданный момент.

У нас было 4 датацентра, 500 машин, 200тб+ данных, до 2 млн строк в секунду в пике и требования 100% аптайма сервиса во что бы то ни стало.
Как нам удалось это реализовать, вы узнаете на нашем докладе!

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

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

Что может квантовый компьютер?

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

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

PWA: как внедрение лучших UX практик выводит веб приложения на новый уровень

PWA(Progressive Web Applications) — это набор лучших практик для веба, которые подразумевают, что ваше приложение поддерживает оффлайн режим, имеет небольшой вес, вследствие чего быстро загружается, может быть установлено как standalone и предоставляет максимально комфортный пользовательский опыт. На данный момент, эти пункты соблюдаются в мобильных приложениях, а в случае с вебом все гораздо хуже.

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

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

1. Количество разработчиков зависит напрямую от сложности приложения, а не от количества платформ (отпадает необходимость в группе мобильной разработки).
2. Скорость разработки и простота коммуникации растет. Адаптировать текущее веб приложение для мобильной платформы можно за 2-3 недели, разработка нативного приложения под каждую платформу займет от 3-х месяцев.
3. Это стабильнее, чем внедрять гибридные решения. Например, cordova или кастомные обертки над webview могут порождать множество ошибок, на поиск и починку которых может уходить значительная часть времени разработчика.

Мобильные сайты и приложения на веб-технологиях
,
Single page application, толстый клиент
,
Оффлайн и кэширование в локальных хранилищах
,
Фронтенд / другое
Программный комитет ещё не принял решения по этому докладу

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

Как спроектировать ИТ инфраструктуру, не выстрелив себе в ногу.

Как построить ИТ архитектуру ЦОД, не выстрелив себе в ногу?

Будет раскрыто с чего начинается <strike>Родина</strike> проектирование, как соблюсти требования бизнеса и уложиться в бюджеты. Как выбрать и обосновать конфигурации серверов и СХД, откуда берутся метрокластеры и хитьрые репликации данных.

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

Enterprise-системы

Принципы построения экосистемы данных. Data-driven подход у управлению знаниями о данных.

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

Защита информации
,
Архитектура данных, потоки данных, версионирование
,
Непрерывное развертывание и деплой
,
Администрирование баз данных
,
Управление изменениями, управление требованиями
,
Проектирование информационных систем
,
Процессы и инструменты в enterprise
,
Интеграция web и enterprise-решений
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Распределенная система которая работает везде и на всём. Как работает крупный непродуктовый Retail.

- "А что если я скажу тебе что интернет у нас не каждый день бывает?". Почему распределенная система по-прежнему необходима?
- Организация Delivery. Как единовременно внести изменения в структуру 400 БД и ничего не потерять. Почему нас не устроило ни одно из существующих решений и мы вынуждены были разрабатывать собственное.
- А если всё-таки потеряли. Организация резервного контура, быстрого создания, восстановления, резервирования БД.
- Работа на слабом оборудовании - "когда каждый запрос может стать последним".
- Если нужна очень быстрая децентрализованная репликация. Использование CouchDB для дисконтных карт.
- Централизованный дисконтный сервер. Когда расположение серверов имеет значение - "облако" не всегда подходит.
- Организация централизованного мониторинга. Доставка всех логов в ClickHouse.

Прочие языки
,
Отказоустойчивость
,
Распределенные системы
,
Синхронизация данных, параллельная обработка, CDN
,
Бизнес на стыке онлайн и офлайн
,
Enterprise-системы
Доклад принят в программу конференции

Визуализируй это! Архитектурное описание приложений: как, зачем нужно и почему важно.

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

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

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

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

Такие данные преобразуются в коммуникационный граф – метод people analytics, который отражает общую карту коммуникаций внутри компании и указывает на «больные» точки. Например, технология сможет выявить сотрудника, который находится на грани эмоционального “выгорания” – здесь коммуникационный граф позволит сэкономить с каждого удержанного специалиста 18-30% от его годового дохода и 40-70% от годового дохода управленца.

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

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

Задача о рюкзаке для финтех-расчетов

Рассмотрим ситуацию решения задачи о рюкзаке из кластера размером в 15k+ CPU, который нам надо оптимально загрузить расчетами финансовых рисков. Как можно решить NP полную задачу с учетом специфичных знаний о предметной области и как избавиться от излишней сложности.

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

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

Tionix.VDI: Особенности VDI сервиса в облачной среде

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

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

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

Построить Continuous Delivery в ML

* Поговорим об особенностях, с которыми сталкиваешься при организации Continuous Delivery в ML-проектах.
* В чем CD может упростить жизнь команде и Data Scientist, и Software Developer, а также бизнесу.
* Особенности взаимодействия Data Science и Software Developer
* Как MLFlow помогает организовать наглядность ключевых метрик.
* Как обеспечить повторяемость экспериментов и версионирование моделей, используя DVC.
* Чего не хватило в Open Source. C чем смирились, с чем нет.
* Расскажу о pipeline, которые строим в наших ML-продуктах.

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

Как организовать работу с метаданными для большого бизнеса

Это доклад о подходах к организации работы с данными на разных масштабах зрелости BI системы. В качестве примера — развитие Business Intelligence системы в крупной компании. Однозначных ответов и советов нет ни у кого, но я расскажу о подходах, которые сработали и не сработали у нас. Интересно, что в основе лежит грамотная автоматизированная работа с мета данными.

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

Классический ETL и daily based reporting

Как собрать в одном хранилище данных много разных источников? Как обеспечить обратную совместимость при динамичном развитии проекта? Как разделить релизы разных компонентов? Кто отвечает за качество данных? Как предотвратить превращение data lake в data swamp?

Логи, клик-стрим или эвент стрим
Как перестать писать ETL код для очередного лога событий? Как сделать универсальную шину событий? Как засунуть слабо структурированные данные в реляционную СУБД? Как подружить технические метрики с бизнесовыми? Как подружить клиентские события с серверными? Как мотивировать разработчика продукта пользоваться инструментами BI?

Доклад будет полезен архитекторам BI и хранилищ данных, ETL разработчикам и дата-инженерам.

Архитектура данных, потоки данных, версионирование
,
Синхронизация данных, параллельная обработка, CDN
,
Архитектуры / другое
,
Управление изменениями, управление требованиями
,
Проектирование информационных систем
,
Проектные артефакты, инструментарий
,
Аналитика / другое
,
ETL
Программный комитет ещё не принял решения по этому докладу

Современный ML\DL KubeFlow pipeline от экспериментов до продакшена

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

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

Технологии: Kubernetes; KubeFlow; TensorFlow; Python; Apache Bean

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

Microsoft SQL Server big data clusters - новое решение для обработки данных

Новое решение Microsoft в области обработки данных на стеке открытого программного обеспечения. Работает как в облаке, так и локально.

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

Data Lake MTS: как мы рыли котлован и наполняли его смыслом. И немного о пользе сотрудничества с Intel

Практический опыт создания одного из крупнейших в России Озера Данных. Hadoop-экосистема, эксперименты с передовыми серверными технологиями и творческий подход – необходимость для успешного развития Big Data в масштабе телеком-оператора. Задачи, которые приходится решать, и как удается совмещать технические желания и бизнес-рационализм.

Оптимизация производительности
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Архитектуры / другое
Программный комитет ещё не принял решения по этому докладу

Факторы в Антифроде Яндекса: прошлое, настоящее, будущее

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

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

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

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

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

Как мы делаем на Java Join истории изменений профилей миллионов игроков к аналитическим событиям

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

В этом докладе мы расскажем о том, как решали следующие проблемы:

- Атрибуты события собираются из разных микросервисов;
- Обновление старых иммутабельных событий в реальном времени;
- Прием событий, модифицирующих профиль игрока в любом порядке;
- Уменьшение объема денормализованных данных на диске;

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

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

Java
,
Базы данных / другое
,
Архитектурные паттерны
,
Оптимизация производительности
,
Архитектура данных, потоки данных, версионирование
,
Проектирование информационных систем
,
Аналитика / другое
Программный комитет ещё не принял решения по этому докладу

Smart Call Assistant Using Machine Learning

In the talk, I will:
+ Talk about how Machine Learning is revolutionizing communication industry with some examples.
+ Explain some general Machine Learning algorithms that tech companies use to make communication easier and smarter.
+ Show live demo of my own ML project: Smart Call Assistant
+ Explain how anyone can start with Machine Learning.

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

Building a Scalable Data Science & Machine Learning cloud using Kubernetes

A real-life story of architecting & building a cloud-native data science platform using Kubernetes.

A growing team of data scientists was looking for a simple, flexible, scalable and a secure way of migrating to the cloud as the on-prem data center started becoming a bottleneck. Kubernetes, which enables applications to run on a variety of private and public clouds, along with an ever-growing feature set, matched most of the team's requirements.

In this talk, Murali Paluru, who had the opportunity to work with the Data Scientists team, will share the gathered requirements, architecture and in-depth details of the Data Science platform built on top of Kubernetes. He will also demo a one-click solution that he has developed, to hide away the complexity of Kubernetes and enable the Data Scientists to focus on analyzing the data instead of managing the underlying infrastructure.

Data Science is gaining much momentum and is being used by various organizations to get insights into the troves of data being accumulated. The attendees will learn how they can leverage Kubernetes within their teams. They can use the architecture shared in this presentation as-is or build on top of it and they can avoid the common mistakes and pitfalls that would be shared in this presentation.

Архитектуры / другое
,
Devops / другое
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Big Data и Highload в Enterprise
Программный комитет ещё не принял решения по этому докладу

От ноутбука до облака с помощью Azure Machine Learning service

Повествование об экосистеме для машинного обучения на платформе Azure. Путь от расчета модели на ноутбуке до масштабирования в облаке, от тетрадки с Python до Git и управления моделями.

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

Концентрируемся на бизнес-модели данных: от ETL к ELT

Два года назад мы (компания Scentbird), пережив серьезный рост, решили строить свою систему аналитики для обеспечения необходимой гибкости. Мы постоянно совершенствуемся в этом направлении и самым качественным изменением в нашей архитектуре за последнее время стал переход от ETL к ELT концепции посредством инструмента DBT. Это позволило нам сосредоточится на бизнес смысле перевозимых данных, вместо технических особенностей процесса трансформации данных.

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

PostgreSQL
,
Базы данных / другое
,
Работа с Amazon
,
Архитектуры / другое
,
ETL
Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

Эксплуатация ML в Почте Mail.ru

Мы в Почте Mail.ru повсеместно используем machine learning для решения бизнес-задач. Основные направления – сделать Почту умнее (помочь пользователю ориентироваться в нарастающем потоке информации и эффективно решать его задачи) и защитить от спама.

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

Как мы решаем эти и другие проблемы, а также какие общие подходы мы выработали, я расскажу в своем докладе.

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

AnalyticOps: конвейеры для поставки моделей машинного обучения в промышленную эксплуатацию

Data scientist-ы подготовили модель машинного обучения, и показали хорошие результаты на тестовых данных. Если таких моделей единицы, то процесс тестирования можно проводить вручную, а что если моделей десятки/сотни/тысячи? Как и что автоматизировать, не мешая data science делать их работу? Как реализовать требования аудируемости моделей в регулируемых отраслях? Я отвечу на эти и другие вопросы, а также расскажу:

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

Непрерывное развертывание и деплой
,
Автоматизация тестирования
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

Версионирование датасетов и моделей машинного обучения используя open source инструменты

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

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

Мы обсудим три инструмента с открытым исходным кодом которые помогают ML командам повысить эффективность их работы: MLFlow, Git-LFS и DVC.ORG. Покажем чем они могут помочь в ваших проектах, в каких случаях их надо (или не надо) использовать и как их можно комбинировать в одном проекте.

Совместная работа, система контроля версий, организация веток
,
Проектные артефакты, инструментарий
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

Борьба с мошенниками: поиск дубликатов среди сотен миллионов объявлений

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

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

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

Технологии: AWS, kubernetes, python, elasticsearch, scikit-learn и keras.

Python
,
Поисковые системы
,
Работа с Amazon
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

Машинное обучение (lightGBM) и теория вероятностей для предсказания продаж и оптимизации запасов интернет-магазина OZON.RU.

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

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

- Методы оптимизации в ценообразовании.
Оптимизация цен товаров для максимизации оборота с ограничением по марже.
Применение моделей предсказания продаж в оптимизации цен. Линеаризация сложной модели для ускорение работы оптимизатора.

- Замкнутый цикл разработки ML решений для продакшена. Бизнес-применение ML.
feature engineering -> model selection -> training -> results evaluation -> feature engineering -> ...

- Работа с большими данными. Как заставить spark быть параллельным.
Сбор данных и генерация фичей на spark. Подбор настроек spark для достижения высокой степени параллельности вычислений. Осознанное репартиционирование таблиц для равномерной нагрузки на вычислительные ноды.

Python
,
Распределенные системы
,
Общение с заказчиком, извлечение требований
,
Hadoop
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

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

Пересядь с иглы TCP на UDP с миллионами пользователей

Что делать, если вы все оптимизировали, а данные до пользователя доходят недостаточно быстро? Как профилировать сеть и как ее ускорить?

В докладе будет рассказано про то, как и зачем мы пересадили десятки миллионов пользователей c TCP на UDP, и что это дало.

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

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

Backend для PWA: от REST и Docker к GraphQL и Lambda

В докладе рассматривается архитектура современного бэкенда для PWA (Progressive Web Apps) на примере эволюции от REST-сервисов к GraphQL и от Docker контейнеров к функциям как сервису (FaaS) с AWS Lambda. Приводится сравнение подходов и технологий - плюсы, минусы и подводные камни. А также на практических примерах обсуждается можно ли быть полностью serverless или все-таки придется настраивать сервера.

Взаимодействие с серверной стороной (API)
,
Node.js и io.js
,
JavaScript
,
API
,
Бэкенд / другое
,
Организация системы кеширования
,
Микросервисы, SOA
,
Работа с Amazon
Программный комитет ещё не принял решения по этому докладу

Алгоритмы быстрой обработки HTTP-строк

HTTP/2 ввел компрессию стандартных заголовков, но тело URI, Cookie, значения User-Agent по-прежнему могут составлять десятки килобайт и требуют токенизации, поиска и сравнения подстрок и пр. Задача становится критичной, если HTTP-парсер должен обрабатывать интенсивный злонамеренный трафик, как например, HTTP flood. Стандартные библиотеки предоставляют обширный инструментарий обработки строк, но HTTP-строки имеют свою специфику и если разрабатывать HTTP-парсер с учетом этой специфики, то можно получить в несколько раз более высокую производительность по сравнению с современными open source-решениями и даже превзойти быстрейшие из них.

В докладе будет рассмотрено:
* как HTTP flood может сделать ваш HTTP-парсер бутылочным горлышком;
* проблемы x86-64 с branch mispredictions, кэшированием и невыровненной памятью на типичных задачах HTTP-парсера;
* оптимизации C/С++-компилятора для multi-branch выражений и автовекторизации;
* сравнение switch-driven конечного автомата (FSM) с прямыми переходами (например в Ragel);
* особенность структуры HTTP-строк и почему стандартные библиотеки плохо подходят для их обработки;
* strspn()- и strcasecmp()-like алгоритмы для HTTP-строк с использованием SSE- и AVX-расширений x86-64;
* эффективная фильтрация инъекционных атак (SQL, XSS и пр.) с использованием AVX;
* цена переключения контекста FPU и как Linux-ядро работает с SIMD.

Все эти топики будут иллюстрированны микробенчмарками.

C/C++
,
Оптимизация производительности
Доклад принят в программу конференции

Хеши в S3: как мы ускоряли прокачку трафика с 30 до 300 Мб/с с одного ядра

Когда мы создавали свое S3-хранилище Mail.ru Cloud Storage, мы не думали, что клиенты будут обладать достаточно широким каналом, чтобы пропускная способность стала проблемой. Но хайлоад оказался ближе, чем мы думали: мы столкнулись с ним сразу, как только хранилище стали использовать другие сервисы Mail.ru Group. Стало понятно, что требования к внутренней инфраструктуре сильно выше.

В докладе я расскажу про то, как мы искали узкие места при ускорении прокачки трафика и какие ошибки были допущены. Расскажу про расчет хеш-сумм (таких как SHA и MD5) от большого потока данных, какой проблемой это может стать, когда трафик измеряется десятками гигабит — и что с этим делать.

C/C++
,
Perl
,
Бэкенд / другое
,
Асинхронное программирование, реактивное программирование
,
Оптимизация производительности
,
Профилирование
,
GO
Доклад принят в программу конференции

Кое-что о вероятностных структурах данных

Вероятностные структуры данных позволяют значительно экономить на памяти для таких запросов как поиск количества уникальных объектов, вхождение объекта, подсчет конкретного объекта.
При этом используется на 1-2 порядка меньше памяти (в некоторых задачах вообще константный объем) чем на хранение исходных данных. Как недостаток, мы иногда контролируемо ошибаемся, например с ошибкой 10^{-9}.

Рассмотрим классические HyperLogLog, BloomFilter, CountMinSketch, как это устроено внутри и математику, использование для простейшего KV-хранилище, хранения "лайков", количества просмотров и уникальных, ротация всего этого во времени.

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

Как разрабатывать SPA на любимом фреймворке не жертвуя SEO? Как сделать так, чтобы каждый занимался своим делом - фронтендеры делали UI, а бэкендеры разрабатывали бизнес-логику и API? Как перевести большое web-приложение с legacy кодом на SPA? Эти и многие другие проблемы можно решить с помощью SSR.

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

Single page application, толстый клиент
,
Взаимодействие с серверной стороной (API)
,
Node.js и io.js
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
JavaScript
,
Фронтенд / другое
,
Непрерывное развертывание и деплой
Программный комитет ещё не принял решения по этому докладу

Оптимизация приложений под Garbage Collector

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

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

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

Новый граф Одноклассников

Граф друзей - один из самых важных и нагруженных сервисов в Одноклассниках. Он нужен практически для любой функции сайта: сформировать ленту, найти новых друзей, проверить права при просмотре фото и много чего еще. Всё это создаёт до 700 000 запросов в секунду к 300 000 000 000 связям между пользователями.

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

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

Миграции данных
,
Java
,
Базы данных / другое
,
Организация системы кеширования
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
Доклад принят в программу конференции

Программистам не нужны стринги или High Performance Computing via C#

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

NET Core поддерживает высокоуровневую концепцию работы с оперативной памятью

Оптимизации на основе Span, Memory, IO Pipelines и Off-Heap позволяют качественно изменить производительность многопроцессорной системы

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

Изменения в технологии .NET Core позволяют использовать C# для скоростных вычислений, которые раньше считались прерогативой других языков

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

Ставьте лайки, подписывайтесь на GraphQL

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

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

API
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Оптимизация производительности
,
Распределенные системы
,
Масштабирование с нуля
,
Бэкенд мобильных приложений
,
Клиент-серверное приложение, REST API, protobuf
,
GO
Программный комитет ещё не принял решения по этому докладу

Логирование, сбор и анализ метрик сетевого сервиса с нелимитированной нагрузкой

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

В докладе мы расскажем о следующем:

* зачем мы используем несколько подсистем логирования
* почему в некоторых случаях мы отдаем предпочтение бинарному формату логов и как потом эффективно с этим работаем
* как мы на лету экспортируем логи в clickhouse
* как мы анализируем логи в clickhouse
* какие оптимизации мы используем при записи метрик в graphite
* как мы анализируем метрики в graphite и зачем нам дашборды в grafana
* в каком виде мы предоставляем метрики клиенту
* прочие особенности

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

Прикладная эзотерика

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

А рассказать хочется про совершенно другие структуры данных.

Существует несколько СД, которые немного посложнее и интереснее вектора; вполне себе практически применимы; но при этом в среднем (среднем!) скорее неизвестны. Heaps, tries, B-trees/LSMs, Bloom filters, CountMin + HyperLogLog, KLL + T-digest. А ещё для как бы стандартных СД существуют всякие интересные реализации или техники. И тоже вполне практически применимые. Judy arrays, parallel_hashmap, google/btree, facebook/rocksdb.

Вот про эти прикладные эзотерические СД и-или реализации и хочется хотя бы обзорно рассказать. Что в природе ещё есть. Какие (нечастые, зато интересные) задачи может помочь решать, и с какими ходовыми характеристиками. И, если времени (уже в коридоре) хватит, как хотя бы в очень общих чертах чего устроено внутри.

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

NJS в production

Модуль JavaScript (njs) как технология достаточно молода, он был представлен NGINX командой только в 2015 году. Его основная ценность заключается в том, что больше не надо писать модули на С и бегать вокруг LuaJIT Garbage Collector. Звучит неплохо верно?
Я начал изучать этот модуль не так давно, и как результат этого изучения я понял, где njs хороший инструмент, а где его можно немного улучшить.

Цель этого доклада: поделить опытом использоваться njs, который даже мне кажется неожиданным. Также я хочу поделиться практическими кейсами, в частности поделю тем, как njs может быть полезен в Api Gateway (AGW)? Ну и обязательно поговорим о производительности .

API
,
C/C++
,
Организация системы кеширования
,
Архитектурные паттерны
,
Lua
Программный комитет ещё не принял решения по этому докладу

Spring Boot, подвинься: знакомство с Micronaut и Quarkus

"Нужно прочитать файл? Берите Spring Boot!" Мы настолько привыкли к Spring Boot, что многим уже трудно представить свою ежедневную жизнь без него. Однако, с приходом GraalVM и cloud-native микросервисов на сцену Java-фреймворков ворвались два новых игрока, которых трудно игнорировать - это Quarkus и Micronaut. По слухам, эти фреймворки вызывают привыкание не хуже, чем Spring - и пока у одних больше вопросов, чем ответов, другие уже пишут на них свои приложения.

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

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

Снятие отпечатков сетевого трафика собственными силами

Я работаю в компании, которая занимается защитой бизнеса от различных угроз в сети Интернет. Речь идет о парсинге, ddos-атаках, скликивании и многом другом. Наше и подобные решения представляют собой высоконагруженные сетевые приложения, которые способны анализивать в райнтайме большие объемы трафика. Мы разбираем сетевые запросы на уровнях L3,4 и, основываясь на этой (и не только) информации, принимаем решение пропускать эти самые запросы дальше или нет.

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

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

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

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

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

Технологии:
ipv4, ipv6, tcp, c++17, linux, p0f, dpdk, mqueue, mhash, graphite

C/C++
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Другое
Программный комитет ещё не принял решения по этому докладу

Как мы "пилили" домен или прикладная репликация данных

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

Фреймворки
,
Java
,
Бэкенд / другое
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Разработка библиотек, включая open source библиотеки
,
Архитектуры / другое
Программный комитет ещё не принял решения по этому докладу

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

Переезжаем на ClickHouse: 3 года спустя. Инструкция по выживанию

3 года назад я рассказывал на HighLoad++, как мы перевели мульти-петабайтовую аналитическую систему на ClickHouse. Это была увлекательная "дорога из желтого кирпича", полная неведомых опасностей. ClickHouse тогда напоминал минное поле, найти безопасный путь в котором было непросто. Прошло три года, что изменилось? Повзрослел и сам ClickHouse, и мы набрались опыта в десятках проектах по переезду на ClickHouse. Это уже не минное поле, но и не проверенный хайвей. В докладе я расскажу об основных особенностях ClickHouse, отличающих его от других систем, и как их эффективно использовать, самые последние и проверенные многими проектами практики по построению систем на ClickHouse, know-how, которые нельзя найти в документации, и реальные примеры.

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

MongoDB distributed transactions from top to bottom

What does it take to deliver ACID transactions in a distributed (sharded) NoSQL database? And why would you do it? This talk describes the building blocks of a modern distributed database from 2PC to MVCC.

MongoDB
,
Базы данных / другое
,
Распределенные системы
Доклад принят в программу конференции

Autovacuum в PostgreSQL: диагностика и предотвращение проблем

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

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

PostgreSQL
,
Администрирование баз данных
Программный комитет ещё не принял решения по этому докладу

Break it Down: An Introduction to Database Partitioning

Did you know that for large data sets, or apps with very high query throughput, simply replicating data is not enough? This talk cover a broad overview of how partitioning is being done today.

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

Odyssey roadmap: что ещё мы хотим от пулера соединений

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

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

Когда хорош MyRocks ?

Думаете, не перейти ли с Innodb на MyRocks? В этой презентации мы расскажем (и покажем), на каких нагрузках MyRocks имеет смысл, а когда Innodb показывает лучшие результаты. Также мы расскажем об отличиях и возможностях, пока не доступных в MyRocks, на которые следует обратить внимание.

Администрирование баз данных
,
MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

Patroni on GitLab.com

We will talk about the change of HA solution on gitlab.com, that we executed in partnership with Ongres, we moved from REPMGR to Patroni solution. We have a large setup for thousands of customers that use our solution, now we have a total functional automated setup with over 25.000.000 git pull operations a day, and over 3000 requisitions per second. The project happened 6 months ago and we have a nice use case to present and really interesting numbers.

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

Поиск объектов на основе расстояния между ними

Многие практические задачи связаны с поиском объектов, ближайших к указанному. Для решения этих задач используются M-деревья, но они - медленные. В некоторых случаях применимы другие варианты индексации и поиска (R-деревья, BK-деревья, Quad-деревья и т.д. и т.п.), но они подразумевают, что объекты представляют собой точки в N-мерном пространстве.

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

Поисковые системы
,
Базы данных / другое
,
Алгоритмы и их сравнение
Программный комитет ещё не принял решения по этому докладу

From SQL to NoSQL: A Gentle Introduction For Devs

“I have heard of NoSQL databases, but don’t know what they are. What’s the difference between NoSQL and relational databases like SQL?” Does this sound like you? In this talk, you will learn about the current NoSQL landscape and how you as a JS developer can take advantage of NoSQL databases.

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

StackGres: Cloud-Native PostgreSQL on Kubernetes

An enterprise-grade PostgreSQL requires many complementary technologies to the database core: high availability and automated failover, monitoring and alerting, centralized logging, connection pooling, etc. That is, a stack of components around PostgreSQL.

Kubernetes has enabled a new model to deploy software abstracting away the infrastructure. However, containers are not lightweight VMs, and the packing of software paradigms that work on VMs are not valid on containers/Kubernetes. How should be PostgreSQL and its stack be deployed on Kubernetes?

Enter StackGres. An open source software that is the result of re-engineering PostgreSQL to become cloud native. Join this talk to learn and see

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

PostgreSQL Scaling Usecases

На сегодняшний день уже никого не удивить тем что инфраструктура живет в клауде, однако не все компоненты заезжают в клауд легко и просто. Одним из таких компонентов является база данных, которая всегда требовательна в плане ресурсов и производительности. Особенно остро стоит вопрос масштабируемости и устойчивости к сбоям, именно поэтому в последние годы можно наблюдать бурное развитие альтернативных СУБД. Однако классические РСУБД за счет накопленных фич нередко остаются выбором №1 при том что они также не стоят на месте и предоставляют богатый набор инструментов в плане масштабирования.
В этом докладе я буду рассматривать преимущественно PostgreSQL, варианты его масштабирования и то когда это стоит делать и как это делать правильно. В докладе будут рассмотрены следующие темы:
Потоковая репликация и разделение read/write рабочей нагрузки
Логическая репликация и шардирование данных
Обеспечение высокой доступности и устойчивости к сбоям
Доклад будет интересен администраторам баз данных, системных администраторам, тимлидам, инфраструктурным архитекторам и широкому кругу специалистов которым интересен PostgreSQL

PostgreSQL
,
Администрирование баз данных
Программный комитет ещё не принял решения по этому докладу

Раскрытие секретов Group Replication в MySQL

В MySQL 5.7 появился новый механизм репликации и высокой доступности под названием Group Replication, который вносит существенные улучшения по сравнению с классическим механизмом асинхронной репликации.
В целях обеспечения современного подхода к высокой доступности и освобождения администратора базы данных от рискованных задач Group Replication внедряет автоматизированное аварийное переключение и функции решения конфликтов.
Посещая этот доклад, вы сможете послушать о внутренних механизмах реализации решения, и увидеть, как взаимодействует с серверным компонентом «runtime» для обработки транзакций, с помощью каких механизмов, серверы, участвующие в репликации, устанавливают общий уровень связи (XCOM), как происходит обмен данными, проверка и, при потребности, решение конфликтов, и как обмен данными используется для автоматизации задач аварийного переключения и восстановления.
В итоге Вы не только поймете, что group replication может обеспечить, но и то, что происходит во время работы этого компонента.

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

Клиентоориентированный Data Lake в игровой компании

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

В докладе мы расскажем о нашем опыте создания единого аналитического Data Lake, обеспечивающего данными все проекты MY.GAMES – игрового направления Mail.ru Group.

Мы обсудим:
- Почему мы реализовали именно Data Lake, а не что-то попроще
- Почему мы выбрали Hadoop и как мы его готовим
- Как мы контролируем огромное количество потоков данных и зачем нам Airflow
- Почему Data Lake должен быть клиентоориентированным
- Проблемы, боли, несчастья и успехи реализации Data Lake
- Стоило ли оно всего этого и как облегчить жизнь команде разработки

Критерии выбора технологий для проекта
,
Проектирование информационных систем
,
Внедрение и поддержка
,
Hadoop
,
ETL
Доклад принят в программу конференции

Учим Kibana работать с Clickhouse

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

Стандартным решением для такого является ELK стек. Но сейчас все большее распространение получает ClickHouse. Его обычно не рассматривают, т.к. из коробки в нём отсутствует полнотекстовый поиск. Но является ли это препятствием?

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

Базы данных / другое
,
GO
Программный комитет ещё не принял решения по этому докладу

MySQL 8 vs MariaDB 10.4 - сравнение возможностей

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

MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

Отъявленные баги и как их избежать на примере ClickHouse

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

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

C/C++
,
Базы данных / другое
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Методы и техника разработки ПО
,
Разработка библиотек, включая open source библиотеки
,
Безопасность программного кода, SQL и прочие инъекции
,
Архитектуры / другое
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Аппаратное обеспечение
,
Администрирование баз данных
Программный комитет ещё не принял решения по этому докладу

Проблемы в OLTP и их решения

Цель финансовых институтов - проведение расчетов между клиентами и партнерами с одновременным учетом их денежных средств.
Для решения этих задач мы используем OLTP систему процессинга платежей – СУБД Oracle.
Бизнес предъявляет высокие требования к доступности сервисов, отказоустойчивости систем и производительности. Например, обеспечить 10 000 ТПС на одном счете клиента или партнера, с доступностью 24/7/365.
Разработкой и эксплуатацией этой системы занимаемся 15 лет. За это время сталкивались с большинством проблем, характерных для OLTP с высокой нагрузкой.
Часть из них типовые и имеют стандартные решения, но для некоторых случаев приходилось находить уникальный подход.
Расскажем про свой опыт решения проблем с высокой нагрузкой, когда использовать типовые решения не получается.

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

Tarantool: SQL в NoSQL СУБД

Изначально Тарантул разрабатывался как in-memory NoSQL хранилище, ориентированное на максимально быструю обработку транзакций. За последние несколько лет Тарантул эволюционировал в полноценную СУБД с дисковым движком и поддержкой языка запросов SQL. В последнем релизе появилась возможность выполнять сложные аналитические запросы и предоставлен широкий набор возможностей SQL, включающий в себя ограничения целостности данных (внешние ключи, проверки уникальности данных), триггеры, представления и другой функционал.

В данном докладе мы поговорим о целесообразности внедрения поддержки SQL в NoSQL СУБД. Затем мы проведем экскурс по текущим возможностям SQL реализованных в Тарантуле: пройдем путь от базовых примеров и закончим написанием нетривиальных составных запросов. Мы так же расскажем о том, как устроен SQL "под капотом" и в деталях; уделим время анализу производительности, и рассмотрим как эффективнее переписать запрос для возможности использования различных оптимизаций; покажем как смешать Lua и SQL для получения гибкого и мощного инструмента для обработки данных. В конце, мы поделимся нашими долгосрочными планами развития SQL в Тарантуле: Just-In-Time компиляция запросов, составные типы, JSON пути.

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

Базы данных на GPU – архитектура, производительность и перспективы использования

В последние годы появляется все больше новых систем хранения данных, вроде NoSQL, колоночных или графовых баз данных, InMemory и других решений. Все они направлены на решение определенного класса задач связанных, например, с отказоустойчивостью, распределенной обработкой данных и/или производительностью. И в мире систем хранения и обработки данных появился еще один тип баз данных, который пытается повысить производительность обработки аналитических тяжелых запросов за счет использования GPU. В своем докладе я расскажу про то, как устроены такие базы, как выполняются классические алгоритмы на GPU, в каких случаях есть смысл их использовать. В частности, в докладе будут освящены темы:
- архитектура аналитических баз данных
- принцип работы GPU
- алгоритмы обработки данных на GPU и сравнение производительности с CPU
- как GPU может помочь базам данных ускорить выполнение аналитических запросов
- примеры реализаций баз данных на GPU
- сравнение поизводительности Clickhouse и OmniSci
- OmniSci и машинное обучение
- отказоустойчивость, нагрузка, распределенная обработка данных
- где и как попробовать

Базы данных / другое
,
Архитектуры / другое
,
Другое
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

Провалы и успехи с Redis

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

Миграции данных
,
Java
,
Микросервисы, SOA
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Асинхронное программирование, реактивное программирование
,
Архитектурные паттерны
,
Отказоустойчивость
,
Администрирование баз данных
Доклад принят в программу конференции

Резервное копирование нагруженных СУБД

Мы занимаемся развитием WAL-G - инструмента резервного копирования с открытым исходным кодом.
Изначально WAL-G - это инструмент для PostgreSQL с фокусом на производительности.
Так, например, блочные инкрементальные бекапы, которые сейчас обсуждаются в pgsql-hackers у нас используются уже несколько лет.
Но к этому мы добавляем всё новые и новые фичи, есть о чём рассказать.
В 2019 году неожиданным открытием для нас стало, что идеи орагнизации работы с WAL-G хорошо подходят и другим базам данных.
В этом докладе мы расскажем о том, как в WAL-G появилась функциональность для MySQL, Redis, MongoDB и др.

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

Vitess: Fearlessly Scaling in the Cloud

When Vitess was migrated to run from bare-metal into Google's cloud, it was deployed as a regular stateless application. This meant that a process reschedule resulted in all the local data being wiped.

The property of Vitess to survive in such an unforgiving environment made it naturally suited to run on Kubernetes.

Additionally, you can scale Vitess indefinitely through transparent sharding, and it takes you one step beyond by allowing you to group related data using materialized views.

The session will cover the Vitess architecture with a demo that showcases the power of materialized views in a sharded environment.

Базы данных / другое
,
Архитектуры / другое
,
MySQL (MariaDB, Percona Server)
,
Machine Learning
Доклад принят в программу конференции

Блокировки в PostgreSQL

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

Я расскажу о типах блокировок, которые используются в PostgreSQL: о многочисленных обычных «тяжелых» блокировках (таких, как блокировки таблиц и номеров транзакций), о блокировках на уровне строк (почему они так сильно отличаются от обычных блокировок и почему так тесно с ними связаны), о «легких» блокировках (и чем они легче тяжелых). Мы также поговорим о том, как организована очередь ожидания и в каких случаях она перестает работать. Все это позволит нам разобраться в том, как «читать» pg_locks и pg_stat_activity, и избегать ряда ошибок при проектировании систем.

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

Мониторинг Apache Ignite. Сделали правильно.

* Архитектура подсистемы метрики: Какие виды метрик есть(счётчик, histogram,
* Архитектура подсистемы ведения "списков объектов".
* Дизайн, API, SPI. Принятые решения. Результат.
* Что сделано? - новая подсистема мониторинга распределённой базы данных Apache Ignite
* Что позволяет? - вести метрики, выгружать их "куда угодно". просто создавать новые.
* Сделано 4 стандартных реализации SPI для выгрузки метрик и списков:
* SQL view
* JMX
* Log
* OpenCensus
* Дальнейшие планы:
* Добавить возможность трейсинга в Ignite.
* Отчёты производительности на основе метрик.

Описание на вики проекта - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=112820392

API
,
Java
,
Архитектурные паттерны
,
Профилирование
,
Распределенные системы
Программный комитет ещё не принял решения по этому докладу

Cloud Native ClickHouse

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

Базы данных / другое
,
Распределенные системы
,
Архитектуры / другое
,
Технологии виртуализации и контейнеризации
,
Администрирование баз данных
,
Процессы и инструменты в enterprise
Программный комитет ещё не принял решения по этому докладу

Путь к Open Source DBaaS с помощью Kubernetes

DBaaS (Database as a Service) наиболее быстрорастущий подход к использованию баз данных во всем мире. Несмотря не преимущества этого подхода в удобстве и минимизации накладных расходов, многих смущает привязка к конкретному Cloud-провайдеру.

В этом докладе мы расскажем о создании DBaaS-эквивалента на основе Open Source-технологий Kubernetes Operators. Мы расскажем и покажем, что уже работает, а над чем мы продолжаем работать.

PostgreSQL
,
MongoDB
,
Технологии виртуализации и контейнеризации
,
Непрерывное развертывание и деплой
,
Администрирование баз данных
,
MySQL (MariaDB, Percona Server)
Доклад принят в программу конференции

Tarantool Kubernetes Operator

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

Тarantool может выполнять роль сервера приложений, исполняя stateless-приложения. Но по-настоящему его можно оценить только воспользовавшись им как базой данных и сервером приложений одновременно. Tarantool не используется там, где можно обойтись парой MySQL-серверов. Он используется там, где от нагрузки трещит сеть, где одно лишнее поле в таблицах выливается в сотни гигабайт потраченного места, и где шардинг — это не задел на светлое бизнес-будущее, но суровая необходимость.

Мы занимаемся разработкой решений на базе Tarantool, Tarantool Cartridge и их экосистемы. Как мы докатились до запуска базы данных на Kubernetes? Все очень просто: скорость доставки и стоимость эксплуатации. Я расскажу про Tarantool Kubernetes Operator, почему одного StatefulSet недостаточно для запуска базы данных в Kubernetes, как устроен наш оператор, что он умеет, как это делает и почему разработка качественного оператора это реально сложно.

Tarantool
,
Непрерывное развертывание и деплой
,
Администрирование баз данных
Программный комитет ещё не принял решения по этому докладу

A Gentle Introduction to Building Serverless Apps with MongoDB Stitch

In this session, we will introduce Serverless computing in a friendly and approachable way. We will discuss the pros and cons of using a Serverless platform. We will then build an app together from scratch using MongoDB Stitch.

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

Patroni Failure Stories or How to crash your PostgreSQL cluster

Основная цель Patroni это обеспечение High Availability для PostgreSQL. Но Patroni это лишь template, а не готовый инструмент (что в общем и сказано в документации).
На первый взгляд, настроив Patroni в тестовой лабе, можно увидеть какой это прекрасный инструмент и как он легко обрабатывает наши попытки развалить кластер. Однако на практике в производственной среде, не всегда всё происходит так красиво и элегантно как в тестовой лабе.
В этом докладе я попытаюсь собрать и рассказать в деталях о тех crash кейсах с которыми мы столкнулись при эксплуатации PostgreSQL и Patroni у наших клиентов.
В ходе этого доклада вы узнаете о том с какими проблемами столкнулись мы и как мы с ними справлялись и какие уроки извлекли. Так же узнаете как правильно и как неправильно конфигурировать Patroni (и возможно PostgreSQL). И конечно получите представление как оперативно выявлять возникающие проблемы и оперативно их устранять.

PostgreSQL
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Администрирование баз данных
Доклад принят в программу конференции

Can You Say That Again? Database Replication Best Practices

Have all heard the phrase “If you have one, then you have none?” In this talk, we will discuss best practices for data replication, and give an overview of the pros and cons of leaders/followers, multi-leader replication, and leaderless replication systems.

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

10 Things Developers Need to Know About NoSQL Schema Design

In this talk, you learn about the pros and cons of legacy SQL and modern NoSQL databases, NoSQL terminology, and the basics of data modeling as it pertains to development in JavaScript.

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

SQL/JSON: реализуем стандарт и не останавливаемся на этом

Граница между реляционными и документоориентированными СУБД размывается. Стандарт SQL 2016 уже включает в себя фукнции для работы с JSON. PostgreSQL, пионер эффективной поддержки JSON среди реляционных СУБД, благодаря нашим усилиям уже получил частичную реализацию стандарта. А именно, было реализовано "сердце" SQL/JSON – язык jsonpath.
Данный доклад представляет собой взгляд разработчика реализацию SQL/JSON в PostgreSQL. В нём будут рассмотрены трудности и подводные камни, которые подстверегали на пути реализации стандарта, а также планы на будущее, включая собственные расширения к SQL/JSON и jsonpath в частности.

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

MongoDB vs. Postgres Benchmarks

Benchmarking is hard. Benchmarking databases, harder. Benchmarking databases that follow different approaches (relational vs document) is even harder.

But the market demands these kinds of benchmarks. Despite the different data models that MongoDB and PostgreSQL expose, many organizations face the challenge of picking either technology. And performance is arguably the main deciding factor.

Join this talk to discover the numbers! After $30K spent on public cloud and months of testing, there are many different scenarios to analyze. Benchmarks on three distinct categories have been performed: OLTP, OLAP and comparing MongoDB 4.0 transaction performance with PostgreSQL's.

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

Построение крупных кластеров Tarantool из 100+ узлов

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

В презентации я расскажу о новых возможностях Tarantool, которые
упрощают создание распределенных систем, и как мы к этому пришли:
* Как объединить несколько разнородных приложений и заставить их работать сообща.
* Почему нам так нравится, когда кластер управляет своей топологией самостоятельно.
* О принятии решений на основе внутреннего мониторинга.
* Проблемы производительности и их решение на кластере из 100+ узлов.

Фреймворки
,
Tarantool
,
Распределенные системы
,
Lua
Программный комитет ещё не принял решения по этому докладу

Новая инфраструктура компонентов в MySQL 8.0

Вы, вероятно, заметили новые команды в MySQL 8.0 — INSTALL COMPONENT и UNINSTALL COMPONENT, и вам было интересно, "что это такое".

Я собираюсь объяснить, что такое "Инфраструктура Компонентов", зачем она нужна, что позволяет и какие у нас есть амбиции развития. Я также представлю то, что необходимо знать для создания простого компонента.

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

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

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

MySQL Group Replication vs Galera

MySQL Group Replication и Galera - две технологии, на которых строятся современные высокодоступные кластеры MySQL. Обе технологии активно развиваются и добавляют новые возможности.

В этом докладе мы рассмотрим преимущества и недостатки этих технологий, включая Galera 4 и новые возможности MySQL Group Replication, появившихся в новых версиях MySQL 8.

MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

Производительность Ceph и сказ о конденсаторах

Ceph — это SDS, программная система хранения данных, практически не имеющая равных по функционалу среди открытого ПО. Уникальность Ceph в том, что она одновременно предоставляет объектное хранилище (RADOS и S3), файловую систему и хранилище дисков виртуалок с нативными ядерными драйверами и драйверами QEMU. И все это работает без единой точки отказа, да еще и используется в production по всему миру, в том числе — в CERN.

Однако при выборе Ceph часто возникает вопрос о производительности. Он особенно актуален в связи с тем, что SSD уже подешевели достаточно, чтобы, не особенно переплачивая, собирать кластеры All-Flash. Такой же вопрос встал и у нас, и теперь, после года игрищ с тестовыми стендами, наконец пришло время для доклада.

Для начала определимся, что такое «медленно» и «быстро» применительно к системам хранения. Речь пойдёт о пропускной способности, задержках (latency), параллелизме, а также синхронном режиме (IOPS, MB/s, sync/fsync).

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

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

- Транзакционность записи и почему Ceph на самом деле надежнее RAID.
- Зачем в SSD конденсаторы и при чём тут вообще Ceph.
- Реальные требования к процессорам (CPU), памяти и сети, а также почему не стоит делать из Ceph гиперконвергентные кластеры.
- Почему использование RAID-контроллеров с Ceph — это стрельба себе в ногу.
- Почему cache tiering — плохая идея и как лучше использовать SSD + HDD в кластере Ceph.
- Устройство Bluestore (нового движка хранения Ceph) и его отличия от Filestore (старого движка), и почему при случайном чтении или записи новый не кардинально быстрее старого.
- Влияние на производительность дополнительных фич: контрольных сумм, снапшотов, дочерних образов (клонов), сжатия.

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

PostgreSQL на K8s в Zalando: два года в бою

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

Именно по этой причине более двух лет назад команда DBA в Zalando начала разрабатывать Postgres-Operator и на данный момент с помощью оператора мы обслуживаем больше 1000 кластеров Postgres работающих на Kubernetes.

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

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

https://github.com/zalando/postgres-operator

PostgreSQL
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Администрирование баз данных
Программный комитет ещё не принял решения по этому докладу

Десятки ветвистых ETL-пайплайнов из сотен источников

Мы в ЦИАН собираем через Kafka и храним в Hive большое количество разнородной информации. Это могут быть логи изменения объявлений, действия пользователей на нашем сайте или, например, логи наших внутренних систем.
Для того, чтобы все эти данные можно было использовать для построения аналитических витрин или сбора датасетов для построения моделей машинного обучения, нужно уметь поддерживать десятки зависимых друг от друга ETL-пайплайнов, использующих сотни таблиц, и вносить изменения в код (в том числе и SQL) так, чтобы не сломать существующую логику в совершенно другом (а порой и неожиданном) месте.
В своём докладе я расскажу о том, как и зачем мы допиливали клиентскую сторону оркестратора Luigi, как организовали деплой ETL-процессов, их мониторинг, тестирование HiveQL-запросов и валидацию данных.

Непрерывное развертывание и деплой
,
Интеграционное тестирование
,
Юнит-тестирование
,
Hadoop
,
ETL
Программный комитет ещё не принял решения по этому докладу

The 2019 State of the NoSQL Union Address

In this talk, we will discuss the current state of the NoSQL databases as they compare and contrast document databases, key-value databases, column-oriented databases and graph databases with specific use cases and industry examples.

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

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

Доклад посвящен техническим и логическим особенностям ElasticSearch и способам их обхода.
На примерах из реального опыта разработки архитектуры решения для системы тендерной аналитики, рассмотрим:
- плюсы и минусы использования больших объектов и nested коллекций;
- причины необходимости контроля для обновлением данных;
- варианты распределения нагрузки на чтение данных;
- стоит ли использовать ElasticSearch как primary хранилище;
- технические моменты использования ElasticSearch на Windows и Linux;
- особенности настройки ElasticSearch при работе с большими объемами
данных (Garbage Сollectоr, настройки индексов).

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

SWIM - протокол построения кластера

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

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

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

Вторая задача — распространение событий в кластере. Событие — это отказ узла, смена его UUID или IP-адреса, появление нового узла. Бывает, что пользователь вводит свои собственные типы событий. Когда о событии узнают один или несколько узлов, им надо его распространить, чтобы у нем узнали все. Протокол SWIM описывает алгоритм обнаружения и распространения событий, которому требуется:
- константное время, чтобы хотя бы один узел узнал о событии;
- время, логарифмическое от размера кластера, чтобы о событии узнали все.

В докладе рассказывается о том, как устроен протокол SWIM, как и с какими расширениями он реализован в Тарантуле, как им пользоваться.

API
,
Бэкенд / другое
,
Tarantool
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
,
Разработка библиотек, включая open source библиотеки
,
Lua
Доклад принят в программу конференции

Все домены мира в RAM процесса

В мире в настоящее время зарегистрировано, зарезервировано и имеет специальную цену регистрации около полумиллиарда доменных имен. Данные об их состоянии приходят в виде набора snapshot'ов на сотни миллионов строк. Как хранить эту информацию, обновлять ее по полученным спискам и быстро находить в ней состояние нужного домена?
Мы пробовали использовать для этой цели postresql, redis, и остановились на встраиваемом разделенном kv-хранилище собственной разработки. В результате мы получили скорость добавления новых данных 3M ключей в секунду (3 минуты в сутки на обновление/восстановление всей БД вместо часов), скорость чтения 4M ключей на CPU сервера и минимальную инфраструктуру.

В докладе рассказывается о технических проблемах с которыми мы столкнулись, и о способах их решения. Будет рассказано о том, как мы:
- оптимизировали хеш-таблицу под кеш CPU;
- ускорили добавление новых данных;
- решили проблемы user-space RCU для нескольких процессов в Linux системе;
- комбинировали способы lock-free синхронизации;
- боролись с дисковым кешем Linux и проиграли;
- неожиданно написали очень быстрый IPC-модуль для Perl.

C/C++
,
Perl
,
Организация системы кеширования
,
Оптимизация производительности
,
Разработка библиотек, включая open source библиотеки
Программный комитет ещё не принял решения по этому докладу

Jsonpath и другие новости о PostgreSQL 12

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

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

Распределенные транзакции в YDB

Цель доклада — демонстрация применения детерминистических транзакций для обеспечения строгой консистентности распределенной системы.

Yandex Database (YDB) — горизонтально масштабируемая геораспределенная база данных, рассчитанная на OLTP-запросы и соответствующая требованиям ACID к транзакционной системе.

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

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

Отказоустойчивость
,
Распределенные системы
,
Алгоритмы и их сравнение
Доклад принят в программу конференции

Энтерпрайзные вызовы для постгреса

Postgres бороздит просторы Вселенной, используется все шире и шире, и проникает все глубже и глубже. При этом часто с ним приходится встречаться людям, воспитанным на других СУБД, и пытающихся мигрировать на Postgres крупные системы, не зная его особенностей. Иногда это приводит к трудностям. Некоторые из этих трудностей затем преодолеваются легко, а некоторые требуют изменений - либо в прикладной системе, либо в постгресе. Иногда речь идет о субъективных проблемах типа "кривые руки", а иногда - о важных вызовах, с которым Postgres должен справиться в ходе своего развития.
Мы не будем обсуждать кривизну рук прикладных разработчиков, а рассмотрим основные архитектурные трудности постгреса, и поймем, как они могут быть компенсированы сейчас и преодолены в дальнейшем.
Среди обсуждаемых тем: факторы масштабирования (объемы таблиц, количество объектов, память, коннекты, репликация), особенности хранилища (Heap, Pluggable storages), временные таблицы, вакуум, взаимодействие с ОС.



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

Patroni в 2019: что нового и планы на будущее

За 4 года Patroni прошёл путь от никому известного клона Compose Governor до одного из самых популярных и фичастых решений для PostgreSQL High-Availability. Помимо выполнения своей основной задачи, переключения упавшего мастера, Patroni упрощает автоматизацию ряд других проблем, таких как:
* Добавления новых нод в существующий кластер
* Возвращение упавшего мастера назад в качестве реплики (при необходимости с помощью pg_rewind)
* Централизованное управление кофигураций PostgreSQL
* Создание нового кластера из бекапа (включая выполнения PITR)

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

https://github.com/zalando/patroni/

Python
,
PostgreSQL
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Администрирование баз данных
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Практический опыт переезда боевого проекта со 100 Гб базы данных из MySQL Percona в кластер на базе Vitess для горизонтального масштабирования

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

Миграции данных
,
Базы данных / другое
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Управление конфигурацией
,
Администрирование баз данных
,
Big Data и Highload в Enterprise
,
MySQL (MariaDB, Percona Server)
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Я хочу привести примеры подобных процессов, как они внедряются, как влияют.
Часть из примеров будут следствием какой-то истории(катастрофы) из Dropbox или других IT компаний.

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

Airship: десятки тысяч серверов в сотнях кластеров, и всё в GitOps

Airship - это декларативный фреймворк, разрабатываемый под крылом OpenStack Foundation, используемый AT&T и другими компаниями для развёртывания и управления кластерами серверов и программным обеспечением на них. Доклад расскажет о том, какие бизнес-задачи мы хотели решить и решили с его помощью, а так же научит участвовать в апстрим разработке и расскажет о реализации дальнейших планов проекта.

Слушатели доклада:
- познакомятся с фреймворком
- узнают о нашем варианте реазизации GitOps
- узнают о концепте "Всё выполняется в контейнере. Нет, совсем-совсем всё."
- научатся участвовать в апстрим разработке
- узнают о планах на версию Airship 2.0

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Процессы и инструменты в enterprise
Программный комитет ещё не принял решения по этому докладу

Эволюция работы с production-инцидентами в ЦИАН

Любой highload-проект когда-нибудь сталкивается с проблемами, влияющими на работоспособность сервиса. И недостаточно просто решить проблему, нужно сделать это оперативно и не наступать на те же грабли в будущем. Я расскажу о том, как мы в ЦИАНе выстроили процесс реагирования на production-инциденты и каких результатов добились. Рассмотрим следующие вопросы:
- Логирование и мониторинг (Не все алерты одинаково полезны)
- Расследование инцидента (Что случилось? Что делать? Кто виноват?)
- Ответственность разработчиков за написанный код. Как эффективно решать проблемы на стыке разработки и админов. Как конвертировать разработчиков в SRE.
- Делаем правильные выводы по итогам инцидента. Каким должен быть полезный постмортем.

Микросервисы, SOA
,
Логирование и мониторинг
,
Менеджмент в эксплуатации
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

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

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

В своем докладе расскажу о том, как мы готовим prometheus/thanos/redis/icinga/tg bots/slack/grafana/sentry, как следим за Kubernetes-кластером и базами данных, как заводим новые метрики, как мониторим бизнес-показатели, как предвещаем провалы, начиная от заканчивающегося автоинкремента в базах до роста количества ошибок при подтверждении заказов. Доклад охватит и бэк, и мобильные приложения.

Логирование и мониторинг
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

Scaling to 1 Million RPS and Beyond with Kubernetes, Istio and GRPC

I will speak about my recent experience designing and building production-grade high-throughput istio service meshes on Kubernetes (GKE). In particular, I will discuss three important considerations in designing such a system, with a working demonstration of their implementation:
Ensuring Visibility at all tiers
Efficient use of GRPC streams
Scaling the Istio Control Plane
Ensuring you have visibility into the correct metrics is a critical step in building a high-performance system. Istio provides great tooling around visibility, but the defaults are not suitable for production - especially under heavy load. I will demonstrate the customizations required to Prometheus, Jaeger, and Grafana in order to maximize visibility into the platform, service mesh, protocol, and application tiers of the system.
GRPC streams are a powerful tool, but there are pitfalls to be aware of when adopting them - especially in combination with Istio. For example, Istio has limited metrics for GRPC streams, when compared to HTTP/S, which can waste a lot of time and frustration in debugging and optimizing. Similarly, load balancing GRPC streams requires special considerations. I will demonstrate how to design a production-grade system that works around these limitations.
Finally, I will demonstrate how the Istio control plane can be configured to scale with your workload. As of Istio 1.2.x, a misconfigured control plane can result in backpressure and downtime within the application data plane. In fact, the default HPA and telemetry configurations are not suitable for high-throughput systems. I will describe how these configurations can be modified to suit your workloads.

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

BpfTrace - наконец, полноценная замена Dtrace в Linux

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

В этом докладе мы расскажем о том, что такое BPFTrace, какие возможности она предоставляет, а также покажем примеры ее использования.

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

Кто виноват в тормозах, бессмертный MySQL и ProxySQL 2.0

Пора разобраться, кто же все-таки виноват в том, что у вас тормозит MySQL! Вариант первый - разработка, которая пишет кривой код. Вариант второй - админы и DevOps, которые никак не сконфигурируют MySQL. Вариант третий - это сам MySQL, срочно переходим на PostgreSQL + MongoDB. (Кстати, почему нет?!)

Как жить без тормозов? После 15+ лет ночных авралов, сотен спасенных проектов и заработанного нервного тика ответ забрезжил на горизонте вместе с очередным бессонным рассветом. Давайте посмотрим, как сделать MySQL быстрым и неубиваемым - чтобы просто поставил, сконфигурировал, и все работало. И на своём железе, и в облаке, при сотнях тысяч запросов в секунду.

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

Отказоустойчивость
,
Оптимизация производительности
,
Масштабирование с нуля
,
Администрирование баз данных
,
MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

Building a Scalable Data Science & Machine Learning cloud using Kubernetes

Learn how to enable Data Scientists to consume the unlimited computing power of the cloud with less complexity, to provide a Scalable Self Service Data Science and Machine Learning platform and to leverage Kubernetes for large scale Data Science workloads.

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

Программы и системы как код. Построение логических абстракций с помощью Terraform.

Типовой стенд продукта состоит из 40 различных программ, для корректной работы системы все программы должны быть корректно настроены, соединены между собой и внешними системами. У типовой инсталляции 7 стендов с 4 различными типовыми конфигурациями и интеграциями.
Добавление новой программы в такую инсталляцию занимало 1-5 дней и требовало участие системного инженера, изменение зависимой конфигурации так же требовало 1-4 часа системного инженера.
Мы построили первую систему абстракции на bash&python, которая позволила логически описать зависимости в системах и снизить время участия системного инженера до 10-15 минут для большого круга задач и расширили участие разработчиков в описании абстракций их программ.
Это повысило скорость работы, но все равно подразумевало участие системных инженеров в процессе разработки и все равно оставляло бутылочное горлышко, ограничивающее дальнейший рост количества сервисов и вариантов инсталляций.
Поэтому мы разработали новую систему абстракции и управления конфигурацией с помощью Terraform, которая позволила строить большие многовариантные системы основываясь на логических описаниях самих программ, которые хранятся вместе с кодом программы. Эта система позволила нам исключить прямое участие системного инженера из процесса внедрения и доставки новых компонентов системы до всех целевых инсталляций и стендов, превратив ее в рутинный автоматический процесс.

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

Подходы организации поддержки биллинга для 70млн абонентов

- как управлять сотнями изменений в день в реалиях корпорации, со сложной распределенной инфраструктурой и высоким уровнем требований к качеству предоставляемых сервисов
- подходы автоматизации для устранения аварий близких к катастрофе: использование и разработка bypass, взаимодействие эксплуатации и производства;
- организация рабочего пространства эксплуатации и выбор инструментов: grafana, ansible, Jenkins, TamTam;
- роль общего информационного пространства для подразделений, участвующей в цепочки реализации ценностей : мониторинг бизнес-показателей на базе KQI, календари изменений и каналы обратной связи.

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

Как развернуть петабайтный ClickHouse кластер за 5 минут.

В докладе детально рассмотрим, как развернуть "боевой" ClickHouse кластер произвольного размера, с шардированием и репликацией, на Amazon или Google Cloud, какие задачи конфигурации при этом возникают, и как они становятся тривиальными, при использовании ClickHouse оператора в сочетании с облачным Kubernetes-сервисом.
Далее обсудим, как с ростом кластера усложняется управление системой, и как оператор помогает в:
- развертывании новых узлов;
- обновлении конфигурации и апгрейдах;
- мониторинге и поддержании работоспособности;
- cпецифичных для ClickHouse-кластеров задачах DBA.

Доклад строится на основе разработки и опыта эксплуатации ClickHouse оператора для Kubernetes

Администрирование баз данных
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Как мы сократили время деплоя Django-сайта с 4к+ страниц документации в 20 раз

Доставка свежей документации до пользователя — приоритетная задача, решение которой позволяет узнать все возможности продукта и использовать их. Сайт tarantool.io (ранее tarantool.org) существует с 2008 года и пережил множество обновлений, революций и разработчиков, а также содержит более тысячи документов (4к+ печатных страниц).

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

В данном докладе я расскажу о своем опыте:

- Что было сделано, когда продуктов с документацией стало много, а сайт — один. При этом сократили деплой сайта до двух минут.

- А как быть, когда источники документации разные? Форкнули LDoc и приучили его к порядку

- Как был добавлен Wagtail в существующий сайт и чего мы добились

Непрерывное развертывание и деплой
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Есть ли жизнь без Kubernetes?

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

На примере внедрения системы оркестрации на базе Apache Mesos в компании MFMS (www.mfms.ru, крупнейший СМС-агрегатор в финансовом секторе РФ):
- расскажем как мы выбирали систему оркестрации
- сформулируем требования, которые предъявляет к инфраструктуре типичное завернутое в контейнер приложение
- поделимся практическими выводами, решениями и шишками от граблей в каждой из областей, которых пришлось затронуть (управление приложениями в кластере, service discovery, конфигурирование приложений, оркестрация сети, безопасность и т.д.)

Архитектурные паттерны
,
Распределенные системы
,
Технологии виртуализации и контейнеризации
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Почему service mesh стоит суеты.

Я всегда считал service mesh лишней абстракцией которую используют большие корпорации. Но жизнь в service oriented architecture натерла мне много мозолей. И оказалось что как раз в этих местах прекрасно можно проложить envoy для исправления ситуации. И суета по организации лишней абстракции окупится с лихвой.

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

Оператор в Kubernetes для управления кластерами БД - архитектура и функционирование. На примере clickhouse-operator.

Доклад посвящен практическим вопросам разработки оператора в Kubernetes, проектированию его архитектуры и основных приниципов функционирования.
В первой части доклада рассмотрим:
- что такое оператор в Kubernetes и зачем он нужен;
- как именно оператор упрощает управление сложными системами;
- что оператор может, а что оператор не может.
Далее, перейдём к обсуждению внутреннего устройства оператора.
Рассмотрим архитектуру и функционирование оператора по шагам.
Подробно разберём:
- взаимодействие между оператором и Kubernetes;
- какие функции оператор берет на себя, а что делегирует в Kubernetes.
Рассмотрим управление шардами и репликами БД в Kubernetes.
Далее, обсудим вопросы хранения данных:
- как работать с Persistent Storage с точки зрения оператора;
- подводные камни использования Local Storage.
В заключительной части доклада рассмотрим практические примеры применения clickhouse-operator с Amazon или Google Cloud Service
Доклад строится на примере разработки и опыта эксплуатации оператора для ClickHouse.

Базы данных / другое
,
Управление конфигурацией
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Как менять инфраструктуру при взрывном темпе роста компании

С 2014 года CIAN вырос в пять раз по дневной аудитории и достиг 1.2 миллиона уников в день (более 11 миллионов в месяц).

В докладе Вы узнаете о том, как мы меняли инфраструктуру и архитектуру:
- мониторинга: ELK, Prometheus, Graphite
- IaC: SaltStack
- хранение данных: Elasticsearch,Cassandra,Postgres
С какими проблемами столкнулись и какие решения помогли нам их преодолеть. Что бы мы сделали иначе, с учетом полученного опыта.

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

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

Мониторинг современного k8s-проекта глазами разработчика

В последние годы K8S стал промышленным стандартом для развертывания приложений в web. А кто как не разработчики лучше всех знают архитектуру современного проекта и принципы работы отдельных сервисов? И именно они понимают (зная при этом бизнес-логику приложений), за чем нужно следить, чтобы избежать потенциальных проблем даже в такой надёжной среде, как Kubernetes.
Но «слежкой» дело не ограничивается: в докладе, на примере эволюции крупного проекта мы рассмотрим, как организовать процесс построения мониторинга современного проекта в k8s, как организовать команду и не оставить мониторинг «на потом»; какие готовые решения стоит применять; какие решения придется разрабатывать самостоятельно (бонусом – разбор проекта создания собственного плагина для инструмента Grafana).

План доклада:
1) Анализ существующих решений на рынке ПО для мониторинга k8s-приложений. Применимость этих решений для мониторинга проектов, с точки зрения разработчиков (а не системных администраторов)
2) Подходы к мониторингу проекта со стороны разработки и бизнеса (ключевые точки мониторинга application-уровня)
3) Практические кейсы внедрения инструментов для мониторинга + разработка собственных решений (плагинов для Grafana и т д):
- мониторинг уровня сервисов
- мониторинг уровня service-mesh
- distributed tracing

Логирование и мониторинг
,
Менеджмент в эксплуатации
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Everything as Code – Stop Clicking, Start Committing

Keeping track of infrastructure, operational tasks, and configuration (among other things) can be a daunting tasks to accomplish in this modern Elastic/Cloud world. Clicking on a Console or a Wizard does not give us the flexibility and speed at scale. If we start treating everything as code, and that everything being Infrastructure, Configuration, Application Deployment, and Operations, we can ensure to have repeatable, testable and secure ways of running our applications. In this session we will see how can we orchestrate all of this, and manage our workloads with a text editor and git. Its time to stop clicking and start committing.

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Атоматизированная система полного цикла эксплуатации, мониторинга и анализа работоспособности высоконагруженного ПО

* Построение ПО, использование статического анализатора кода.
* Регрессионное тестирование.
* Тестирование стабильности в лаборатории, сбор и анализ метрик.
* Автоматическая доставка и настройка ПО.
* Мониторинг и анализ метрик во время эксплуатации.

Логирование и мониторинг
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

Минимализм Kubernetes: привычные подходы highload на слабом сервере

Мы говорим Kubernetes - подразумеваем highload. Говорим про highload - где-то рядом точно развернуты кубы. За годы мы привыкли использовать “комбайн” Kubernetes, научились отслеживать статистику сотен нод, искать узкие места в балансировщике и бутылочные горлышки между микросервисами и базами данных. Мы в Evrone занимаемся заказной разработкой и точно так же используем Kubernetes на больших проектах. Но иногда проект… недостаточно большой. Это может быть стартап, legacy решение, прототип, собственный эксперимент наконец. В докладе я поделюсь нашим опытом использования Kubernetes на слабом железе: расскажу про его архитектуру, разные “distributions”, какие функции можно безболезненно отключить, а что можно быстро заменить на легковесные аналоги. Цель моего доклада - показать разработчикам как они могут использовать весь свой опыт работы со “взрослым” фреймворком контейнерной оркестровки даже на небольших проектах, с какими проблемами они скорее всего столкнуться и как их лучше всего решать.

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

“Восстание машин” – это ок

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

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

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

Также, мы расскажем, какие механизмы защиты мы предусмотрели, чтобы “восстание машин” не "уничтожило человечество" (не положило продакшн).

И, напоследок, изучим проблему фрагментации ресурсов в облаке. И узнаем, как наш алгоритм размещения контейнеров вместе с “восстанием машин” помогают с этим бороться.

Java
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
,
Методы и техника разработки ПО
,
Алгоритмы и их сравнение
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Программный комитет ещё не принял решения по этому докладу

Зачем мы разработали Kubernetes-оператор и какие уроки из этого вынесли

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

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

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

AutoLSR - автоматизированный сбор сведений при значительных инцидентах

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

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

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

Автоматизация операционной деятельности продукта

В Департаменте информационных технологий Москвы в целом и в проекте "Московская Электронная Школа" в частности достаточно давно озадачились описанием, внедрением, оптимизацией и автоматизацией процессов операционной деятельности.

Многие задаются вопросами вроде:
1. Что является предпосылками автоматизации operations?
2. С чего начинать автоматизацию?
3. Каких правил придерживаться?
4. Что можно ожидать в результате реализации проекта по автоматизации operations?

Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
,
Code Review
,
Управление / другое
,
Управление изменениями, управление требованиями
,
Автоматизация тестирования
Программный комитет ещё не принял решения по этому докладу

Развертывание статического анализатора в Travis CI, Cirlce CI и Azure DevOps на примере PVS-Studio

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

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

Простые инструменты для улучшения incident response: опыт Tutu

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

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

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

Продуктивный WebAssembly

2 года назад мы приняли решение что свои Web приложения мы будем строить на технологии WebAssembly, в итоге мы вместе с командой Blazor прошли путь от версии 0.3 до версии 0.9 в разработке до непрерывного развертывания в продуктиве.

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

С точки зрения разработчика-архитектора системы

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

С точки зрения инженера по инфраструктуре

* как мы используем мульти стек передачи данных на RabbitMQ, ActiveMQ, Apache Kafka и NATS и какие задачи исполняет каждый из серверов
* что нужно сделать в части настройки CDN для доставки платформы WASM и скомпилированного приложения в случаях если ваши клиенты находятся по всему миру
* как мы обеспечиваем мониторинг на клиентской части и как обеспечивать hotfix отдельных компонентов

Конечно же мы покажем как организовали CICD и DevOps в условиях ежедневного изменения в самой технологии WebAssembly.

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

Фронтенд / другое
,
Синхронизация данных, параллельная обработка, CDN
,
Непрерывное развертывание и деплой
,
Web-scale IT / другое
Программный комитет ещё не принял решения по этому докладу

Построение распределённой системы слияния логов

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

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

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

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

Как Wargaming Platform прод шатает?

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

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

Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Нагрузочное тестирование
Программный комитет ещё не принял решения по этому докладу

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

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

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

Расскажу о некоторых особенностях работы с платформой VMware vSphere: преодолении неочевидных ограничений nested-гипервизоров и тонкостях Auto Deploy. В докладе будут рассмотрены проблемы использования восстановленного и бывшего в эксплуатации аппаратного обеспечения в качестве «личного» тестового стенда. Также проведена грань, за которой экономия начинает вредить обслуживаемости и масштабируемости тестовой инфраструктуры, что сказывается на качестве выпускаемого ПО.

Защита информации
,
Оптимизация производительности
,
Технологии виртуализации и контейнеризации
,
Проектирование информационных систем
,
Нагрузочное тестирование
Доклад принят в программу конференции

MADT: Моделируем сетевое взаимодействие клиентов и сервисов - удушение, отключение, и другие "а что если?"

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

Для облегчения тестирования распределённых приложений в Центре Технологий Распределённых Реестров разрабатывается система MADT, предназначенная для моделирования распределённых приложений и изучения влияния сетевых условий на их работу.

Мы хотим, чтобы тестирование и отладка систем, работающих по сети, были максимально простыми и комфортными для разработчика программиста. Программист хочет поставить эксперимент:
1. Описал докер образы компонентов (клиентов, серверов, баз данных и т.д.)
2. Рассказал какая сеть может связывать их между собой простым кодом на питоне (какие узлы с какими разговаривают, сколько их и где узлы расположены)
3. Описал что за события в сети должны произойти и когда. Например, роутер Х стал пропускать в 10 раз меньше трафика на 30 секунд, а потом восстановился.
Программист запускает MADT и получает интерактивную визуализацию эксперимента, вывод логов каждого экземпляра участвующих в системе докер образов. Программист может подключиться к интересующему его образу и локально провести отладку интересующего его ПО.

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

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

По мимо статической маршрутизации мы поддерживаем важные протоколы динамической маршрутизации:
• RIP (Routing Information Protocol)
• OSPF (Open Shortest Path First)
• BGP (Border Gateway Protocol)

Есть ли альтернативы? Не совсем:
1) GNS3: виртуальные машины, а не контейнеры; для отладки сетей, а не приложений; ethernet, а не IP
2) eve-ng: ручное описание экспериментов; нет распределённого запуска; максимум в 1024 узла

И везде нужно уметь настраивать сеть! MADT для программиста которому приходится учить программу жить с причудами сети на высоком уровне – например роутер стал пропускать в два раза меньше трафика и стал дублировать 30% пакетов. Другими словами, мы фокусируемся на формировании понимания эффектов, оказываемых сетью на разрабатываемое ПО.

Таким образом MADT позволяет:
• создавать реалистичные модели IP-сетей большого масштаба
• разворачивать поверх них распределённые приложения
• управлять качеством работы отдельных участков моделируемой сети
• визуализировать состояние работающего в модели распределённого приложения в реальном времени
MADT может быть использован для сравнения работы нескольких распределённых приложений в одинаковых условиях, проверки устойчивости приложения относительно нестабильной работы сети, изучения влияния структуры сети на его работу или для проверки наличия уязвимостей сетевого плана.

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

От сервиса нагрузочного тестирования к центру компетенций.

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

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

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

Управление / другое
,
Нагрузочное тестирование
Доклад принят в программу конференции

Анализ запросов в MySQL, PostgreSQL, MongoDB

В этой презентации мы расскажем о том, как мы создали инструмент глубокого анализа производительности запросов в Percona Monitoring and Management. Мы расскажем о способах получения этой информации из баз данных, как мы ее храним в ClickHouse для оптимальной производительности и как можно удобно анализировать и визуализировать эти данные для улучшения производительности высокодоступных систем.

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

Этап нагрузочного тестирования в большом проекте

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

Об этом — на примере проекта Единый Биллинг.

Oracle
,
Tarantool
,
Отказоустойчивость
,
Распределенные системы
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Работа со внешним заказчиком/исполнителем
,
Внедрение и поддержка
,
Нагрузочное тестирование
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Приёмочные и функциональные тесты
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Наш опыт построения процесса разработки продукта без отдела тестирования

Доклад рассказывает об опыте разработки программного продукта PVS-Studio, в котором отсутствует звено "тестировщик". Этот опыт специфичен и не будет применим напрямую в других проектах. Однако, вы услышите интересные идеи и приемы, благодаря чему сможете максимально автоматизировать процесс обнаружения ошибок.

Автоматизация разработки и тестирования
,
Функциональное тестирование
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
,
Приёмочные и функциональные тесты
,
QA / другое
Программный комитет ещё не принял решения по этому докладу

Построение автоматизации: танцуют все

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

Я хочу поделиться как в Headhunter выстроили систему автоматизации регрессионного тестирования:
Какие проблемы были
Как из них выходили
Как сейчас организован процесс входа в автоматизацию для “новичков”

В данный момент в Headhunter проходит более 10 релизов сервисов в день, регрессионный набор GUI автотестов состоит из 8-9 тысяч тестов, которые проходят в среднем за час.

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

Пишем и внедряем интеграционные тесты на Go для распределенных систем

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

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

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

Микросервисы, SOA
,
Распределенные системы
,
Автоматизация разработки и тестирования
,
Функциональное тестирование
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Приёмочные и функциональные тесты
,
QA / другое
,
GO
Программный комитет ещё не принял решения по этому докладу

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

Сбор и аналитика клиентских ошибок на продакшене highload-проекта

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

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

Материал будет полезен преимущественно frontend-разработчикам, так как описывает некоторую специфику дивного мира, где мы живем. Backend-разработчикам — тоже, в силу достаточно схожих механизмов и подходов для сбора ошибок. И, конечно, доклад заинтересует QA-инженеров.

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

lock-free, жизнь без блокировок

Большой процент разработчиков привыкли к синхранизациям на основе блокировок, но это ведет к гонке, взаимоблокировке и может серьезно снижать производительность. Чтобы получить максимальное преимущество от параллелизации, надо стремится к коду, свободному от блокировок. Wait-Free и Lock-free - делают код гораздо эффективнее. Но если первое - это совсем редкие случаи, то lock-free алгоритмы и структуры на их основе - сегодня уже достаточно изучены, и имеют ряд реализаций и в .NET

В наших докладах вы узнаете:
- О постановке ТЗ на выбор lock-free структуры данных
- как они устроены и на основе каких алгоритмов работают
- как разработать свой собственный алгоритм lock-free
- и как его протестировать

Асинхронное программирование, реактивное программирование
,
Архитектурные паттерны
,
Оптимизация производительности
,
Алгоритмы и их сравнение
Программный комитет ещё не принял решения по этому докладу

Игра на выживание: запуск трансляций Английской Премьер Лиги в новом формате

Расскажу, как IT-команда онлайн-кинотеатра Okko за 3 месяца построила абсолютно новый для себя и для России продукт внутри продукта – сервис, предоставляющий онлайн доступ к прямым трансляциям футбольных матчей Английской Премьер Лиги.
Кроме абсолютно новой области, дополнительная сложность заключалась в необходимости встраивания в живой работающий сервис с ежемесячной аудиторией в несколько миллионов пользователей.
В докладе будут затронуты следующие темы:
1) Из аналогового мира в цифровой или «то, о чем не расскажет Стогниенко». Как состыковать мир старого доброго телевидения с современным миром OTT.
2) Технологическое отличие от существующих OTT-сервисов российских телеканалов (в том числе спортивных), что такое DRM или «сколько клиентов – столько реализаций плееров».
3) Почему не написали свой софт для транскодирования и пакетирования видео на лету и какие ограничения существуют при выборе поставщика подобного решения.
4) Как один маленький баг на клиенте может привести к аварии размером с весь спортивный интернет и как не дрогнуть под потоком хейта, а все исправить за 3 дня.

Отказоустойчивость
,
Критерии выбора технологий для проекта
,
Архитектуры / другое
,
Devops / другое
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Продуктовая разработка
Доклад принят в программу конференции

Персонализация за 10 миллисекунд или как tinkoff.ru подстраивается под вас

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

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

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

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

C/C++
,
Бэкенд / другое
,
Архитектурные паттерны
,
Оптимизация производительности
,
Профилирование
,
Рефакторинг
,
Масштабирование с нуля
,
Архитектуры / другое
,
Продуктовая разработка
,
A/B-тестирование
,
Machine Learning
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Реализация асинхронного фреймворка на базе Nginx: асинхронные задачи и сервисы на примере nginx-haskell-module

Технические аспекты реализации асинхронных задач, контент-хэндлеров и сервисов (то есть персистентных задач, не привязанных к запросам пользователей) и их интеграции в событийный механизм Nginx. Асинхронные каналы eventfd. Разделяемые сервисы, то есть сервисы, обслуживающие все рабочие процессы одновременно, и как реализовать их безопасно (использование advisory file locks). Сервисные хуки и глобальные состояния.

Быстрая и безопасная передача данных между Nginx и Haskell хэндлерами, и почему cleanup хэндлеры Nginx играют здесь важную роль. Оптимизация работы с памятью в обычных и разделяемых сервисах (разделение и подсчет ссылок). Типизированная передача данных.

Краткое описание плюсов и минусов Haskell в роли языка для написания сервисов и асинхронных задач.

Пример. Онлайн мониторинг распределения запросов между рабочими процессами Nginx.

Асинхронное программирование, реактивное программирование
,
Архитектурные паттерны
,
Оптимизация производительности
,
Методы и техника разработки ПО
,
Разработка библиотек, включая open source библиотеки
,
Архитектура данных, потоки данных, версионирование
,
Критерии выбора технологий для проекта
Программный комитет ещё не принял решения по этому докладу

Нормально делай - нормально будет. Готовим рабочие нагрузки в AWS так, чтобы не было стыдно людям в глаза смотреть.

AWS словно игры от Blizzard - easy to learn and hard to master.

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

Во второй части мы пройдемся подробно по AWS Well-Architected Framework, и как, используя сервисы Config, Trusted Advisor и прочие, довести свое облако до ума. Мы наладим разработку и эксплуатацию облака таким образом, чтобы обеспечить автономию разработчиков и стабильность нашего окружения.

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

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

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

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

Single page application, толстый клиент
,
Node.js и io.js
,
Профилирование
,
Производительность и мониторинг фронтенда
Программный комитет ещё не принял решения по этому докладу

Использование трейсинга для определения производительности сервисов на Tarantool

Для несложных проектов вы можете отлаживать ваши Tarantool Lua-приложения простыми print'ами или доступными для Lua библиотеками. Но с ростом проекта возникают более сложные вопросы: маркировка разных событий для анализов логов, просмотр графа выполнения запросов между сервисами и другие, агрегация логов между разными сервисами. Мы написали адаптер для сервиса сбора трейсов zipkin и реализовали спецификацию opentracing для использования в ваших Lua-проектах.

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

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

Analysing and minimizing tcmalloc fragmentation in MongoDB

MongoDB uses TCMalloc, which provides good performance for highly concurrent applications. But in some workloads we also see high memory fragmentation, causing excessive use of RAM. To avoid such situations we have tested the effect of configuration options in tcmalloc.

MongoDB
,
Масштабирование с нуля
Программный комитет ещё не принял решения по этому докладу

Cluster and Resource Management at Facebook

Доклад посвящен тому, как мы построили низкоуровневую систему управления вычислительными ресурсами Facebook - Resource Broker. Этот компонент предоставляет базовый API и хранилище для Service Management систем следующего по стеку уровня - сервисные аллокаторы и шедулеры. К системам подобного рода применяются весьма жесткие требования по надежности и отсутствию зависимостей. Из-за этого например мы используем специально написанный для Resource Broker хранилище данных - Delos, так как не можем использовать общее хранилище, которое будучи внутренним сервисом Facebook опосредованно управляется Resource Broker-ом.
В качестве одно из примеров использования этой системы я рассажу как мы выполняем автоматизированное выведение серверов из продакшена как для планового обслуживания (maintenance) так и в качестве реакции на какие-либо неполадки на сервере. Все это выполняется в автоматизированном режиме для миллионов контейнеров, на которых запущены сервисы Facebook.

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

Почему вам нужна платформа межсервисного взаимодействия и как её построить уже сегодня?

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

В сервисной архитектуре сложность поддержки растёт экспоненциально с количеством сервисов. Я дам вам инструмент, который позволит значительно замедлить рост этой сложности. Мы поговорим, что можно считать платформой для межсервисного взаимодействия, как она может уже сейчас помочь вам решить проблемы с «наблюдаемостью» сервисов и увеличить надёжность системы, уменьшить объем рутины и снизить Time To Market.

Обсудим плюсы и минусы актуальных протоколов прикладного уровня. Расскажу, почему gRPC — «не вариант», и с какими проблемами вы столкнётесь, если начнёте его использовать.

Доклад будет интересен как тем, кто только начинает свой путь в SOA, так и тем, кто уже хорошо знаком с инструментами OpenAPI, Swagger, gRPC, protobuf. Авторизация запросов, трассировка и логирование, A/B-тестирование, сегментация фич — как получить всё то, что так легко давалось нам в монолите?

API
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Распределенные системы
,
Методы и техника разработки ПО
,
Масштабирование с нуля
,
Архитектуры / другое
,
Логирование и мониторинг
,
Автоматизация разработки и тестирования
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
GO
Доклад принят в программу конференции

5 лет в А.Д.у - Расчет цепочки поставок - ДДД Эванса на практике - Взгляд в будущее на 21 день.

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

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

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

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

Сравним, чем наше решение на Python в рамках компании Связной отличается от существующих решений(1с, SAP, ...), какие предлагает возможности, и почему нам важна производительность.

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

Как справиться с 500 000 000 подарочков в день

Сервис подарков был запущен 15 лет назад, это один из самых важных для бизнеса сервисов в Одноклассниках. В год 71 миллион пользователей одноклассников отправляют друг другу огромное количество подарков. Нагрузки на сервис критически возрастают в периоды праздников, в это время наши пользователи отправляют друг другу в 4-5 раз больше подарков чем обычно. В 2019 году только за 8 марта пользователи Одноклассников отправили более 500 000 000 подарочков.

Такие нагрузки – большой вызов для команды, ведь любые проблемы с сервисом негативно отражаются на пользователях. Периодически во время праздничных пиковых нагрузок мы испытывали много проблем с базами ms sql, внешними системами пополнения счетов и чрезмерной нагрузкой на наш new sql кластер. В конце 2018 года мы решили оптимизировать сервис таким образом, чтобы он был в состоянии штатно обработать как пиковые так и ежедневные нагрузки, возросшие в 5-10 раз по сравнению с прошлыми годами.

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

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

Священный грааль: запуск React в Java

Много слухов ходит, про загадочный и суровый сайт в компании Одноклассники. Многие слышали, что там все делается на Java. Даже фронтенд.

А что же на самом деле там происходит?

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

Я расскажу о том:
- Почему мы не взяли NodeJS, Kotlin, Nashorn и другие решения
- Почему был выбран GraalVM
- Как работает JS в GraalVM и какие это дает преимущества
- Как собрать и запустить React в такой конфигурации
- Какие появляются задачи и способы их решения
- Как можно начать постепенную миграцию, огромного проекта

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

Risk Control System или Антифрод-перезагрузка

Мы расскажем, что такое антифрод и anti-money laundering и почему они необходимы в фин.тех проектах.

Пробежимся по разным способам фильтрации нежелательного трафика: классические фильтры vs ML. Поведаем о реальном опыте разработки антифрод или о том, как старая добрая система FraudStop передала эстафету новой амбициозной Risk Control System (RCS).

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

Миграции данных
,
PHP
,
Организация системы кеширования
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Синхронизация данных, параллельная обработка, CDN
,
MySQL (MariaDB, Percona Server)
,
Machine Learning
Доклад принят в программу конференции

Map-Reduce операция длиною в год: архитектура отказоустойчивого планировщика batch-задач в системе Yandex.YT

В Яндексе десятки тысяч машин, которые постоянно нагружены под завязку различными вычислительными задачами. Большая доля этих вычислений относится к так называемой batch-нагрузке, как правило, оформленной в виде операций в парадигме Map-Reduce. Мы используем собственную разработку YT (https://habr.com/ru/company/yandex/blog/311104/, https://www.youtube.com/watch?v=VQGfH0sZi18), предоставляющую распределённый storage, а так же удобный интерфейс для запуска распределённых вычислений с произвольным пользовательским кодом.

В реалиях Яндекса потребителей вычислительных ресурсов намного больше, чем самих ресурсов, поэтому критически важным компонентом любого большого вычислительного кластера YT является планировщик. При разработке планировщика приходится решать целый спектр задач:
* Планировщик должен быть **отказоустойчивым**. Если по каким-то обстоятельствам планировщик перестаёт быть доступен (maintenance, аппартный сбой, сетевые неполадки, падение из-за программной ошибки), это должно минимальным образом влиять на прогресс уже бегущих вычислений и на возможность запускать новые.
* Планировщик должен быть **эффективным**. Иными словами, если планировщик работает неэффективно, то может возникнуть ситуация, при которой вычислительный кластер не утилизирован на 100% только потому, что планировщик не успевает распределять задачи между машинами. В идеале планировщик должен быть **горизонтально масштабируемым**, то есть, архитектура системы должна позволять вводить несколько планировщиков, равномерно распределяя нагрузку между ними.
* Планировщик должен быть **честным**. В системе, в которой ресурсов не хватает, чтобы в любой момент времени удовлетворить потребности всех клиентов, приходится задумываться о том, по какому принципу вычислительные мощности надо распределять между потребителями. Стоит помнить, что потребители бывают разных видов - у кого-то могут быть CPU-intensive вычисления, кому-то нужны нетривиальные ресурсы на машине (такие как, например, GPU), кому-то нужно много RAM, что усложняет модель ресурсов и делает задачу честного планирования весьма творческой и нетривиальной.

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

C/C++
,
Архитектурные паттерны
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Доклад принят в программу конференции

Архитектура Мессенджера Авито – путь одного сообщения

Мессенджер Авито – достаточно крупный и нагруженный проект. У нас 11 миллионов уникальных пользователей в месяц, порядка 25k RPC-запросов в секунду и 500k подключений онлайн в пике. В докладе я расскажу о том, какой путь проходит сообщение от отправителя до получателя, о цепочке сервисов на этом пути. Поговорим о том, как мы деплоим сервисы, как храним данные в MongoDB и о некоторых любопытных паттернах очередей RabbitMQ. Обсудим протокол WebSocket и поразмышляем о необходимости HTTP-fallback'a в 2019 году. Расскажу про нашу шину real-time нотификаций, использующую под капотом Redis. Эта шина, которую мы называем SockStream, позволяет нам без проблем держать около полумиллиона постоянных соединений, имеет задел для масштабирования на порядок, обеспечивает возможность реконнекта всех подключений в течение нескольких секунд, при этом предотвращая завал основной базы данных запросами об актуальном состоянии благодаря горячему кешу сообщений. Также затронем тему антиспама и посмотрим на наш механизм “middleware” на пути сообщения до получателя.

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

Архитектура и возможности Tarantool Data Grid

На базе Тарантул нами было разработано ядро инвестиционного бизнеса Альфа-Банка (https://www.youtube.com/watch?v=o9XuVXTotHU). В процессе разработки пришло понимание, что созданная система по своим возможностям не только удовлетворяет всем требованиям заказчика, но и позволяет быстро реализовывать произвольную логику, то есть по сути является удобным средством разработки распределенных приложений с персистентным хранилищем. Используя полученный опыт мы создали новый продукт - Tarantool Data Grid, который уже активно используется в нескольких наших новых разработках. В докладе/статье будет рассказано о его возможностях и архитектуре.

Tarantool
,
Архитектурные паттерны
,
Распределенные системы
Программный комитет ещё не принял решения по этому докладу

Кафка. «Описание одной борьбы»

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

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

Основные темы, которых коснёмся:
- Область применения и типовые usecases
- Надежность vs производительность
- Управление кластерами и capacity planning
- Мониторинг и эксплуатация

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

PHP
,
Архитектурные паттерны
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Масштабирование с нуля
,
Критерии выбора технологий для проекта
,
Логирование и мониторинг
,
Управление конфигурацией
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Администрирование баз данных
,
GO
Программный комитет ещё не принял решения по этому докладу

Автоназначение курьеров в Delivery Club или безопасные эксперименты в логистике

У нас в Delivery Club много курьеров и еще больше заказов.
Но как найти "того самого" идеального курьера, который и заказ быстро доставит, и не будет долго ждать в ресторане?
Желательно за пару секунд, используя разные стратегии поиска и пересчитывая уже доставляемые заказы.

Мы расскажем про
- платформу автоназначения курьеров и её эволюцию в микросервис на Golang;
- эксперименты в бою над пользователями и почему им от этого хорошо;
- Grafana-driven-development и что он даёт бизнесу;
- повышение отзывчивости платформы с помощью Event Bus;
- нашу любовь к дождю и размышления про A/B тестирование.

Архитектура данных, потоки данных, версионирование
,
Управление изменениями, управление требованиями
,
A/B-тестирование
,
GO
Программный комитет ещё не принял решения по этому докладу

Как устроена многопоточность в Hazelcast

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

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

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

How to handle a million transactions per second?

Traditional data processing systems may be scalable up to very big numbers, but they still have limits. In order to achieve unlimited performance, we may use decentralized data processing systems, which process the data in a parallel mode and then integrate them. Zold, the cryptocurrency we designed, implements a unique algorithm of data processing, using thousands or millions of anonymous servers. It will be explained how it works and demonstrated how you can do similar things in your projects.

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

У одного моего друга, не у меня, есть опыт работы с SAGA

«У одного моего друга, не у меня есть, опыт разработки SAGA». SAGA – механизм поддержки функционала с транзакционной семантикой в микро-сервисной архитектуре и всё вроде понятно, но у моего друга возникли проблемы. И уже вам, а не моему другу, будет интересно избежать проблем:
• SAGA может быть избыточно длинной и «стабильной»
• В SAGA-у могут засунуть «неправильный функционал» и получится совсем не SAGA
• В реализации высокочастотной SAGA-и можно сэкономить часы кодирования днями ручной работы
• Тесты для слабаков, но когда дела пойдут плохо, они пойдут по-настоящему плохо
О miss-use SAGA и других проблемах, которые можно выгрести расскажу в этом докладе.
Мой друг хороший программист, его часто торопил другой друг.

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

Кэша много не бывает. Масштабируем Redis

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

Бэкенд / другое
,
Организация системы кеширования
,
Оптимизация производительности
,
Распределенные системы
,
Масштабирование с нуля
Программный комитет ещё не принял решения по этому докладу

Sphynx: PUBG's Data Platform Powered by Apache Spark on Kubernetes

Kubernetes has achieved one of the dominating platform for container-based infrastructure. Many platforms are starting to support Kubernetes as first-class and Apache Spark, analytics engine for large-scale data processing, is one of them. From Spark 2.3, Spark can run on clusters managed by Kubernetes. PUBG Corporation, serving an online video game for 10s of millions of users, decided to migrate its on-demand data analytics platform using Spark on Kubernetes. At this talk, Jihwan Chun and Gyutak Kim will describe the challenges and solutions building a brand-new data platform powered by Spark on Kubernetes.

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

Управление группой виртуальных машин с помощью сервисов Яндекс.Облака

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

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

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

Какие вызовы ставит перед инженерами e-commerce бизнес?

Расскажу как устроен современный e-comm, мало кто догадывается, обычно это не просто сайт на WordPress, а десятки сервисов в части интернет магазина и еще в 10 раз больше в собственной службе доставки, управления огромным автоматизированным складом, системой управления современной студией, контакт центр, а также финансовые и операционные процессы.

Какие вызовы ставит перед инженером индустрия e-commerce? Какие интересные задачки могут встретиться в работе? И почему мы от этого получаем удовольствие?

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

Микросервисы, SOA
,
Архитектура данных, потоки данных, версионирование
,
Критерии выбора технологий для проекта
,
Большие проекты/команды
,
Бизнес на стыке онлайн и офлайн
Программный комитет ещё не принял решения по этому докладу

AWS для бережливых: трюк, как снизить затраты на compute

Все хотят экономить на облачных сервисах. Для этого есть масса трюков. Использование Spot Instances - один из них.

Мы поговорим о том, что такое Spot, обсудим детали и примеры использования в различных сервисах AWS (Analytics, Containers, ML / AI и др).

Оптимизация производительности
,
Работа с Amazon
Программный комитет ещё не принял решения по этому докладу

Starship Enterprise Evolution: архитектура e-commerce платформы

Что из себя представляет архитектура современного e-commerce? Поговорим об эволюции систем от монолитов через микросервисы к event-based архитектуре. Lamoda – это data-driven компания, которая уделяет большое внимание аналитике данных и использует полученные результаты для развития продукта.

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

Микросервисы, SOA
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
Программный комитет ещё не принял решения по этому докладу

Хьюстон, у нас проблема. Дизайн систем на отказ, паттерны разработки внутренних сервисов облака Amazon

Программные и аппаратные компоненты решения постоянно ломаются, ведут себя непонятно и непредсказуемо. Кошмар разработчика? Да нет, совершенно обычная ситуация. Для распределенных систем такое поведение нормально и является следствием эффекта масштаба и банальной статистики. Именно поэтому Design for failure является базовым принципом при проектировании облачных сервисов AWS. Системы изначально строятся так, чтобы сделать незаметным ущерб от известных и даже пока еще неизвестных сбоев и максимально быстро восстанавливать свою штатную работу.

Мы обсудим некоторые причины отказов сервисов и на их примере разберем паттерны проектирования распределенных систем, используемыми разработчиками Amazon. Поговорим о том, что такое Cell-based architecture, Constant Work, Shuffle Sharding, и пр. Используйте подходы AWS в своих собственных решениях.

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

Масштабируемая среда исполнения для СУБД и не только

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

Базы данных / другое
,
Архитектурные паттерны
,
Оптимизация производительности
,
Архитектуры / другое
Программный комитет ещё не принял решения по этому докладу

Опыт обработки десятков тысяч тарификационных транзакций в секунду на middle серверах

Построение трёхзвенной архитектуры биллинга вместо монолитной БД
Вынос ресурсоемких расчетов с БД на отдельные сервера тарификации
Организация кеширования данных, необходимых для расчётов, собственная реализация кэша: хранение данных вместе с поисковыми алгоритмами с целью оптимизации
Уникальный алгоритм распределения нагрузки между тарификаторами с равномерным перераспределением ёмкости кэша выключенного из работы тарификатора на другие экземпляры
Механизмы мягкого ввода в работу, останова, прогрева кэшей, предварительной прокачки кэшей
Бесконечное масштабирование, возможность использовать сервера любой производительности
Реализация на Bercut Service Delivery Platform – гибкость и простота разработки и кастомизации сервиса (скриптовая логика работы, встроенные возможности интеграции со сторонними системами, единообразные конфигурирование, мониторинг и аудит)
Использование в продуктиве с производительностью десятки тысяч реальных вызовов со сложной логикой расчета стоимости (подключенные услуги, скидки, пакеты, стоимости), низкое время отклика (100 ms)

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

Кешируем статику: nginx или не nginx

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

- возможности
- удобство
- доступная статистика
- производительность

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

Языки, платформы, версии: масштабируем локализацию

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

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

В докладе я поделюсь полным описанием процесса перевода проекта: интеграция с Jira, Git-хуки, автоматические скриншоты из тестового окружения. Рассмотрим, как устроено ядро системы, как поддерживать А/Б-тестирование и проводить тестирование, имея множество версий. Поговорим, как обеспечить единство стиля с помощью глоссария и памяти переводов на ElasticSearch, а также как успевать переводить новый функционал за 48 часов и не нагружать разработчиков рутиной. И наконец, поговорим про оптимизацию, ведь на продакшене серверам и так несладко.

PHP
,
Бэкенд / другое
,
Методы и техника разработки ПО
,
Архитектуры / другое
,
Совместная работа, система контроля версий, организация веток
,
Автоматизация разработки и тестирования
,
Большие проекты/команды
,
A/B-тестирование
,
Бэкенд мобильных приложений
,
Другое
Доклад принят в программу конференции

Микросервисная операционная среда для высоконагруженных вычислений в АСУ ТП АЭС

На HighLoad уже не первый раз поднимается тема высоких нагрузок в АСУ ТП АЭС. На таких объектах надежность управления, скорость обработки, отказоустойчивость - не пустые слова. В данном докладе предлагается погрузиться глубоко в Ядро реального времени, которое является наиболее критическим узлом Системы Верхнего Уровня АСУ ТП, то есть ПО.
В докладе будет разобрана архитектура Ядра CoreShock, которое представляет собой микросервисную операционную среду, и состоит из In-Memory Key-Value TimeScale СУБД и встроенной среды выполнения, которая предназначена для определения логики алгоритмов диагностики и управления с поддержкой параллельных вычислений.
Будут рассмотрены механизмы управления балансировкой нагрузки, качеством сервиса (QoS), управляемой деградации, то есть, что делать, когда данных в систему «прилетает» больше, чем она физически может обработать, как правильно жертвовать данными и не потерять критические данные, необходимые для управления. Будет рассмотрен интероперабельный механизм подключения скриптов, то есть как выполнять на удобном Вам языке программирования логику с прямым доступом к СУБД Ядра.
А так же, будут рассмотрены кейсы применения данной технологии в мониторинге и управления обычными объектами, типа ЦОД и др., все таки система разработана в России и тема импортозамещения достаточно актуальна.

API
,
C/C++
,
Защита информации
,
Организация системы кеширования
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Асинхронное программирование, реактивное программирование
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Масштабирование с нуля
,
Архитектуры / другое
Доклад принят в программу конференции

Паттерны проектирования приложений на Apache Kafka

Я расскажу о том, как проектировать надёжные пайплайны состоящие из большого числа компонент на основе Apache Kafka. В докладе будут разобраны основные принципы проектирования, а также будут разобраны архитектурные паттерны очередей, обратной связи (back pressure), стыковка с HTTP, потери сообщений, и обработка задач с большим разбросом по времени выполнения.

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

Архитектурные паттерны
,
Методы и техника разработки ПО
,
Критерии выбора технологий для проекта
Доклад принят в программу конференции

Основы велосипедостроения при репликации данных между дата-центрами.

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

Отказоустойчивость
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Синхронизация данных, параллельная обработка, CDN
Программный комитет ещё не принял решения по этому докладу

Reversive Decentralized Deployment: Zold Cryptocurrency Example

A traditional deployment scenario includes a central point of control, which sends updates to server nodes. In our Zold cryptocurrency project we were forced to create a different and reversive deployment model, where distributed and anonymous servers pull updates from an open public repository and restart themselves. The biggest problems we had to solve were related to error tracking and resolving of exceptional situations. In the presentation I will demonstrate how it works and we will deploy a new version right on the stage.

Архитектурные паттерны
,
Оптимизация производительности
,
Распределенные системы
Программный комитет ещё не принял решения по этому докладу

Урок географии (или ищем кратчайший путь сквозь Интернет)

Как известно, в Интернете нет государств, зато есть топология. А это значит, что кратчайшим маршрутом между вашим приложением и пользователем вовсе не обязательно окажется прямая.
Что это значит на практике? Зачем придумали CDN и Anycast? Что на самом деле показывает GeoIP? И при чём тут скорость света?

Вот обо всём этом мы и поговорим.

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

Low Latency при работе с данными - какие бывают кейсы и как с ними работать

Для кого-то low latency ‒ это миллисекунды, но за это время нужно обрабатывать большое количество данных, для кого-то ‒ сотни микросекунд. А для кого-то (например, на бирже) ‒ десятки микросекунд или даже меньше. С точки зрения архитектуры всё перечисленное ‒ это совершенно разные кейсы, требующие принципиально отличных подходов. Где-то для достижения минимального времени отклика потребуются специальные технологии, а где-то даже и специальное оборудование. В своем докладе расскажу:

‒ Какие бывают low latency кейсы;
‒ Какие проблемы несет в себе каждый из сценариев;
‒ Какие подходы, технологии и оборудование помогут в решении этих проблем;
‒ Примеры low latency проектов, реализованных с использованием платформ Apache Ignite и GridGain.

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

Заключая контракт: как осуществить хороший API для (микро)сервиса

Процесс построения API никогда не проходит без споров. Процесс вывода API в public - это настоящий coming out, которому предшествуют масштабные переделки и даже изменения процессов компании.

В этом докладе мы поговорим про дизайн REST API для сервисов и предложим практический checklist для оценки зрелости API.

Мы обсудим следующее:
- Контрактные выборы и их значимость: RAML vs swagger, API first vs code first. Как сделать выбор и как обеспечить его поддержку на всех уровнях компании?
- Разработка API Guideline. Как сформировать этот свод правил и можно ли форсировать его применение?
- Toolchain. Что можно и что нужно автоматизировать, можно ли проверять безопасность на уровне RAML?
- Внедрение практик на все команды. Как помочь программистам добиться совершенного API и не помешать project-manager'ам выпустить продукт в срок.

Взаимодействие с серверной стороной (API)
,
API
,
Микросервисы, SOA
,
Стандарты кодирования
,
Автоматизация разработки и тестирования
Доклад принят в программу конференции

Управление командой разработки (тимлиды)

Before team leading

Как понять готов ты к тимлидству, твоё ли это и что тебе предстоит делать?



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




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

Как отличить профессионального разработчика от непрофессионального?

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

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

Зачем R&D e-commerce проекту

Вы конечно слышали, что есть R&D. Но чем конкретно они занимаются? Алгоритмы, данные, математика, аналитика или разработка?
В зависимости от проекта у такой команды будут разные задачи, и мы расскажем, как устроен Research & Development в Delivery Club - пионере foodtech'а в России.

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

Обсудим следующие темы:
1. Близость команды разработки к бизнесу - зачем и что дает.
2. Какие процессы и роли отличают R&D команду в Delivery Club.
3. Метрики на все - бизнес, техника, команда, процесс.
4. Когда остановиться в исследованиях. Трудности в оценке затрат на наукоемкие проекты.
5. Что нас мотивирует сегодня и помогает не выгореть завтра.
6. Наша адаптация Inner Source.

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Модели руководства
,
Выбор стратегии долгосрочного развития, KPI
,
Продуктовая разработка
,
Бизнес на стыке онлайн и офлайн
Программный комитет ещё не принял решения по этому докладу

Обучение. А как могло бы быть?

* Что нужно знать?
* Важные моменты?
* Налоги?
* Запустились...

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