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

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

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

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

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

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

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

iptables + consul = :3

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

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

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

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

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

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

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

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

С++

Устройство репликации в 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.

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

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

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

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

Фреймворки
,
C/C++
Доклад принят в программу конференции

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

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

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

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

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

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

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 не нужен, а когда таки да". Ну и пару слайдов с котиками показать, если найдутся хорошие котики.

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

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

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

Взгляд изнутри на надежность сервисов Facebook

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

Мы называемся Production Engineers. Это похоже на то, что делают SRE в Google.

В моем докладе я расскажу:
- чем именно занимаются Production Engineers в Facebook;
- как мы следим за надежностью и производительностью всего бэкенда;
- какие инструменты мы для этого используем;
- как выглядит наш мониторинг и автоматизация;
- какие крупные сбои у нас были, и как мы, в принципе, справляемся с подобными инцидентами.

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

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

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

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

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

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

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

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

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

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

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

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

Как нам удалось это реализовать, вы узнаете на нашем докладе!

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

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

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

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

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

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

Enterprise-системы

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

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

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

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
Доклад принят в программу конференции

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

Поговорим о том, как усложнилась разработка с приходом ML в коммерческие продукты. Расскажем, с чем столкнулись сами и как внедряли практики Continuous Delivery.

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

* Взаимодействие Data Science и Software Developer.
* Что выходит из попытки использовать MVP, написанное DS, при развитии продукта.
* Необходимость версионировать и хранить не только код, но и данные, метрики, модели.
* Построение пайплайнов получения предиктов, дообучение и обучения моделей для читаемости и упрощения понимания процессов.
* Что использовали и чего не хватило в opensource-инструментах.
* Деплой по кнопке, как он может выглядеть.

Python
,
Архитектура данных, потоки данных, версионирование
,
Непрерывное развертывание и деплой
,
Автоматизация разработки и тестирования
,
Machine Learning
,
ETL
Доклад принят в программу конференции

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

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

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

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

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

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

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

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

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

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

Расчет факторов в Антифроде Яндекса: быстро, удобно, выразительно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В докладе будет рассмотрено:
* как 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
Доклад принят в программу конференции

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

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

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

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

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

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

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

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

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

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

* Concurrency в сочетании со сборщиком мусора уничтожает производительность многопоточных систем. Необходимость работы без аллокаций.
* NET Core поддерживает высокоуровневую концепцию работы с оперативной памятью.
* Оптимизации на основе Span, Memory, IO Pipelines и Off-Heap позволяют качественно изменить производительность многопроцессорной системы.
* Работа со строками уже оптимальна. Так ли это? В самых неожиданных ситуациях возможно многократное ускорение.
* Изменения в технологии .NET Core позволяют использовать C# для скоростных вычислений, которые раньше считались прерогативой других языков.

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

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

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

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

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

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

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

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

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

NJS в production

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

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

Цель этого доклада: поделить всем этим опытом с аудиторией, забегая немного вперед, скажу, что опыт неожиданный. Конечно, пройдемся по практическими кейсами, сделаем упор на Api Gateway и место njs в нем.

Ну и обязательно поговорим о производительности NJS vs LuaJIt vs C.

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

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

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

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

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

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

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

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

Learnings from migrating a high load/low latency production service from JDK 8 to JDK 11

In this session we will explore the journey of migrating major services from JDK 8 to JDK 11 using Amazon Corretto, Amazon's no-cost distribution of OpenJDK. We will walk through the code and dependency changes required to migrate services to JDK 11, how we measured performance, and how we safely deployed such a significant update across multiple regions in production.

Java
,
Работа с Amazon
Доклад принят в программу конференции

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

Переезжаем на 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
,
Базы данных / другое
,
Распределенные системы
Доклад принят в программу конференции

When is MyRocks good?

In this talk, we'll walk through RocksDB technology and look into areas where MyRocks is a good fit by comparison to other engines such as InnoDB. We will go over internals, benchmarks, and tuning of MyRocks engine. We also aim to explore the benefits of using MyRocks within the MySQL ecosystem. Attendees will be able to conclude with the latest development of tools and integration within MySQL.

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

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

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

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

DBA-бот Joe. Снимаем боль backend-разработки: как при оптимизации SQL-запросов перестать ждать часами получения копии полноразмерной базы и внимания DBA-экспертов

Как backend-разработчик понимает, что SQL-запрос будет хорошо работать на «проде»? В крупных или быстро растущих компаниях доступ к «проду» есть далеко не у всех. Да и с доступом далеко не все запросы можно безболезненно проверить, а создание копии БД часто занимает часы.

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

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

Для инженеров он выглядит как Slack-бот. Ему можно написать запрос или попросить создать индекс. Joe выполнит все действия на полноразмерной копии «боевой» БД. Но это еще не все: в любой момент можно начать заново, отменив все изменения за несколько секунд, сбросив кэши ОС и СУБД. Если с БД размером 10 TiB одновременно хотят работать 10 разработчиков, нам не нужно искать 100 TiB места, чтобы развернуть 10 копий БД. Достаточно одного диска! Joe способен помочь всем разработчикам, проверяя идеи разных индексов одновременно и изолированно.

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

Миграции данных
,
Бэкенд / другое
,
PostgreSQL
,
Администрирование баз данных
,
Code Review
,
Совместная работа, система контроля версий, организация веток
,
Автоматизация разработки и тестирования
,
Будущее рынка разработки ПО
,
Профилирование и отладка кода
Доклад принят в программу конференции

Дорогой DELETE. Типичные ошибки при выполнении массивных операций в высоконагруженных БД PostgreSQL

Основано на реальных событиях.

Когда-нибудь в далёком будущем автоматическое удаление ненужных данных будет одной из важных задач СУБД [1]. Пока же нам самим нужно заботиться об удалении или перемещении ненужных данных на менее дорогие системы хранения.

Допустим, вы решили удалить несколько миллионов строк. Довольно простая задача, особенно если известно условие и есть подходящий индекс. "DELETE FROM table1 WHERE col1 = :value" - что может быть проще, да?

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

Мы подробно разберём ситуацию из реальной жизни на примере PostgreSQL, баз среднего размера и нагрузок (несколько TiB данных, десяток тысяч QpS). Посмотрим внимательно, что пошло не так и проанализируем основные "грабли", на которые наступили в этом случае:
- не проверили запрос на полноразмерной таблице или же проверили некорректно,
- не разбили массивную операцию на достаточно короткие транзакции,
- не подумали о локах,
- не мониторили disk IO,
- не дали проверить изменение другим инженерам,
- не слушали DBA, не следили за здоровьем БД и не делали checkpoint tuning.

В процессе я коротко расскажу о платформе Postgres.ai [2] и её открытых компонентах и принципах, внедрение и использование которых как раз помогает устранить описанные выше проблемы при проведении любых операций над БД:
- postgres-checkup, инструмент для автоматического слежения за здоровьем Postgres [3] (представлен на РИТ-2019 [4]),
- artificial DBA Joe [5], позволяющий проверять любые идеи оптимизации запросов на многотерабайтной БД, обеспечивая независимую работу десяткам и даже сотням инженеров,
- artificial DBA Nancy [6], систематизирующая проведение экспериментов над БД (была представлена на Highload++ 2018 [7]).

Вовсе не обязательно использовать именно эти инструменты (хотя, конечно, это очень приветствуется!). Главная идея, усвоения которой я буду добиваться: обязательно, обязательно проверяйте все свои мысли и идеи, используйте правильные данные для принятия решений.

1. Tova Milo. Getting Rid of Data. Keynote at VLDB-2019, https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf
2. Postgres.ai, система поддержки принятия решений для разработчиков и DBA, работающих с PostgreSQL https://postgres.ai
3. postgres-checkup https://gitlab.com/postgres-ai/postgres-checkup
4. Как не «проспать» проблемы в базах данных Postgres: автоматизируем проверку здоровья, РИТ-2019 http://bit.ly/postgres-checkup-rit2018
5. Joe, Slack-бот для оптимизации SQL на полноразмерных БД https://gitlab.com/postgres-ai/joe
6. Nancy CLI, фреймворк для автоматизации экспериментов над БД https://gitlab.com/postgres-ai/nancy
7. Правильный staging для баз данных Postgres, Highload++ 2018 http://bit.ly/nancy-hl2018-2

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы занимаемся развитием 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
Доклад принят в программу конференции

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

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

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

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

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

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

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

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

Мониторинг 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
,
Архитектурные паттерны
,
Профилирование
,
Распределенные системы
Доклад принят в программу конференции

Tarantool Kubernetes Operator

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

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

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

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

Patroni Failure Stories or How to crash your PostgreSQL cluster

Основная цель Patroni - это обеспечение High Availability для PostgreSQL. Но Patroni - это лишь template, а не готовый инструмент (что, в общем, и сказано в документации).

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

Фреймворки
,
Tarantool
,
Распределенные системы
,
Lua
Доклад принят в программу конференции

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

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

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

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

MySQL Replication vs Galera: что лучше для твоей нагрузки?

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

Galera, Group Replication, InnoDB Cluster, Semi-synchronous replication, delayed replication, crash-resistant replication, Row-based replication. Я научу вас выбрать правильный вариант репликации MySQL, основываясь на нагрузке, требованиях к надёжности и бюджету.

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

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
Доклад принят в программу конференции

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

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

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

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

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

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

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

Hовости о PostgreSQL 12

Я расскажу о том, что появилось нового в PostgreSQL 12 с упором на понимание некоторых важных фич.

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

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

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

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

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

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

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

Энтерпрайзные вызовы для Postgres'а

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

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

Среди обсуждаемых тем: факторы масштабирования (объемы таблиц, количество объектов, память, коннекты, репликация), особенности хранилища (Heap, Pluggable storages), временные таблицы, вакуум, взаимодействие с ОС.



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

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

В MySQL 5.7 появился новый механизм репликации и высокой доступности под названием Group Replication, который вносит существенные улучшения по сравнению с классическим механизмом асинхронной репликации.

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

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

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

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

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

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

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

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

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

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

MySQL (MariaDB, Percona Server)
Доклад принят в программу конференции

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

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

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

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

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

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

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.

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

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

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

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

Логирование и мониторинг
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
Доклад принят в программу конференции

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

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

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

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

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

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

Непрерывное развертывание и деплой
,
Автоматизация тестирования
,
Machine Learning
Доклад принят в программу конференции

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

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

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

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

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

Доклад посвящен практическим вопросам разработки оператора в Kubernetes, проектированию его архитектуры и основных принципов функционирования.

В первой части доклада рассмотрим:
- что такое оператор в Kubernetes и зачем он нужен;
- как именно оператор упрощает управление сложными системами;
- что оператор может, а что оператор не может.

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

Рассмотрим управление шардами и репликами БД в Kubernetes.
Далее, обсудим вопросы хранения данных:
- как работать с Persistent Storage с точки зрения оператора;
- подводные камни использования Local Storage.

В заключительной части доклада рассмотрим практические примеры применения clickhouse-operator с Amazon или Google Cloud Service. Доклад строится на примере разработки и опыта эксплуатации оператора для ClickHouse.

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

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

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

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

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

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

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

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

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

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

Логирование и мониторинг
,
Менеджмент в эксплуатации
,
Devops / другое
Доклад принят в программу конференции

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

Мы говорим Kubernetes — подразумеваем highload. Говорим про highload — где-то рядом точно развернуты кубы.

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

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

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

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Devops / другое
Доклад принят в программу конференции

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

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

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

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

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

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

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

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

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

Облачная платформа OpenNebula

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

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

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

В программе:
- Рассмотрим концепцию Cloud и её отличие от традиционных платформ виртуализации.
- Из чего состоит OpenNebula и за что отвечает каждый из ее компонентов.
- Посмотрим, как OpenNebula общается с compute-нодами и как происходит запуск виртуальных машин на них.
- Как работают и что представляют собой драйверы в OpenNebula.
- Как администрировать и как разделять ресурсы облака между пользователями.
- Расскажу, как мы разворачиваем OpenNebula в Kubernetes и как мы, вообще, пришли к такому решению.

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Devops / другое
Доклад принят в программу конференции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жизнь без блокировок: не только lock-free и не только коллекции

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

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

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

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

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

Расскажу, как IT-команда онлайн-кинотеатра Okko за 3 месяца построила абсолютно новый для себя и для России продукт внутри продукта – сервис, предоставляющий онлайн-доступ к прямым трансляциям футбольных матчей Английской Премьер-лиги.

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

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

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

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

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

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

Cluster and Resource Management at Facebook

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мессенджер Авито – достаточно крупный и нагруженный проект. У нас 11 миллионов уникальных пользователей в месяц, порядка 25k RPC-запросов в секунду и 500k подключений онлайн в пике.

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

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

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

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

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

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

Архитектура данных, потоки данных, версионирование
,
Управление изменениями, управление требованиями
,
A/B-тестирование
,
GO
Доклад принят в программу конференции

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

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

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

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

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

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

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

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

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

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

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

SAGA – механизм поддержки функционала с транзакционной семантикой в микросервисной архитектуре и всё вроде понятно, но у моего друга возникли проблемы. И уже вам, а не моему другу, будет интересно избежать проблем:
* SAGA может быть избыточно длинной и «стабильной»;
* в SAGA могут засунуть «неправильный функционал» и получится совсем не SAGA;
* в реализации высокочастотной SAGA можно сэкономить часы кодирования днями ручной работы;
* тесты для слабаков, но когда дела пойдут плохо, они пойдут по-настоящему плохо.

О miss-use SAGA и других проблемах, которые можно выгрести, расскажу в этом докладе.
Мой друг хороший программист, его часто торопил другой друг.

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

Yandex Cloud Instance Groups: опыт создания сервиса оркестрации

Yandex Cloud Instance Groups - сервис управления группами виртуальных машин.

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

Мы рассмотрим системный дизайн сервиса, дизайн его апи. Обсудим как трафик попадает на наш бекенд.

Yandex Database - newsql база данных, доступная для всех с 1 октября. Мы же ее начали использовать сильно раньше - и мне есть что рассказать про опыт ее использования.

И мы обязательно детально рассмотрим как устроен основной наш функционал - деплоймент процесс.

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

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 в своих собственных решениях.

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

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

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

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

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

Распределенные системы
,
Критерии выбора технологий для проекта
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Доклад принят в программу конференции

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

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

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

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

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

Когда работает не только на твоем ноутбуке. Опыт управления сетью в облаке.

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

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

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

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

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

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

На HighLoad уже не первый раз поднимается тема высоких нагрузок в АСУ ТП АЭС. На таких объектах надежность управления, скорость обработки, отказоустойчивость — не пустые слова. В данном докладе предлагается погрузиться глубоко в Ядро реального времени, которое является наиболее критическим узлом Системы Верхнего Уровня АСУ ТП, то есть ПО.

В докладе будет разобрана архитектура Ядра CoreShock, которое представляет собой микросервисную операционную среду и состоит из In-Memory Key-Value TimeScale СУБД и встроенной среды выполнения, которая предназначена для определения логики алгоритмов диагностики и управления с поддержкой параллельных вычислений.

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

А также будут рассмотрены кейсы применения данной технологии в мониторинге и управлении обычными объектами типа ЦОД и др., все-таки система разработана в России, и тема импортозамещения достаточно актуальна.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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