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

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

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

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

Roman Gorshunov

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

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

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

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

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

Дмитрий Калугин-Балашов

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

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

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

С++

Профайлер запросов в 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++
Программный комитет ещё не принял решения по этому докладу

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

Игорь Сапего

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

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

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

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

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

Петр Зайцев

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

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

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

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

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

Петр Зайцев

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

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

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

Enterprise-системы

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

Олег Александрович Филиппов

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

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

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

Антон Батяев

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

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

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

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

Алексей Григорьев

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
Программный комитет ещё не принял решения по этому докладу

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

Алексей Еремихин

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

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

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

Андрей Попов

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

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

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

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

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

Vitess: Fearlessly Scaling in the Cloud

Sugu Sougoumarane

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
Программный комитет ещё не принял решения по этому докладу

Smart Call Assistant Using Machine Learning

Amit Sagtani

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

Murali Paluru

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 и управления моделями.

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

Курс уроков волшебства для обычного кота и другие проблемы текстовой классификации чеков

Артем Просветов
Анастасия Семенова

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

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

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

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

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

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

Эдуард Тянтов

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

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

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

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

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

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

Александр Тоболь

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

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

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

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

Алгоритмы быстрой обработки 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++
,
Оптимизация производительности
Доклад принят в программу конференции

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

Антон Иванов

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

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

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

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

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

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

Петр Зайцев

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

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

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

Андрей Маркелов

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

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

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

Денис Тишков

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

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

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

Петр Зайцев

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

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

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

Patroni Failure Stories or How to crash your PostgreSQL cluster

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

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

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

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

Юрий Басалов

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

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

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

Владислав Шпилевой

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

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

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

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

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

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

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

Ярослав Дынников

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

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

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

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

Vittorio Cioe

Вы, вероятно, заметили новые команды в 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)
Программный комитет ещё не принял решения по этому докладу

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

Евгений Буевич

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

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

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

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

Семён Чечеринда

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

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

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

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

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

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

Петр Зайцев

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

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

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

Кирилл Мельничук

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

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

Patroni on GitLab.com

Jose Cores Finotto

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-мерном пространстве.

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

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

PostgreSQL Scaling Usecases

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

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

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

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

Vittorio Cioe

В 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
Программный комитет ещё не принял решения по этому докладу

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

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

Слава Бахмутов

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

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

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

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

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

Николай Устинов

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

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

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

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

Roman Gorshunov

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

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

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

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

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

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

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

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

Григорий Михалкин

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

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

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

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

Талалаев Леонид

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

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

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

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

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

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

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

Александр Афенов

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

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

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

Robin Percy

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.

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

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

Владимир Колобаев

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

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

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

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

Петр Зайцев

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

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

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

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

Андрей Талалаев

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

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

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

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

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

Петр Зайцев

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

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

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

Владимир Хонин

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

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

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

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

Михаил Бородин

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

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

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

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

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

Александр Захаренко

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

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

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

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

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

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

Тимин Алексей

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

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

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

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

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

Ярослав Колбин

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

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

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

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

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

Владимир Озеров

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

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

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

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

Алексей Радьков

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

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

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

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

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

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.

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

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

Дмитрий Химион

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

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

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

Jihwan Chun

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.

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

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

Евгений Журавлев

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

‒ Какие бывают low latency кейсы;
‒ Какие проблемы несет в себе каждый из сценариев;
‒ Какие подходы, технологии и оборудование помогут в решении этих проблем;
‒ Примеры low latency проектов, реализованных с использованием платформ Apache Ignite и GridGain.

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

Time-series DB in E-Commerce - InfluxDb

Борис Тверитнев

TBD

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

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

Олег Бабин

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

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

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

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

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

Артемий Рябинков

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

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

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

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

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

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

Дмитрий Змитрачёнок

Как выживать при обработке большого количества событий при мониторинге больших кластеров.

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

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

Тимур Нурутдинов

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

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

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

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

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

Алексей Скоробогатый

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

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

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

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

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

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

Александр Патрушев

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

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

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

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

Александр Емелин

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

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

Управление командой разработки (тимлиды)

Как отличить профессионального разработчика от непрофессионального?

Даниил Пилипенко

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

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

Обучение. А как могло бы быть?

Антон Сапогов

* Что нужно знать?
* Важные моменты?
* Налоги?
* Запустились...

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