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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы занимаемся развитием WAL-G - инструмента резервного копирования с открытым исходным кодом.

Изначально WAL-G - это инструмент для PostgreSQL с фокусом на производительности. Так, например, блочные инкрементальные бэкапы, которые сейчас обсуждаются в pgsql-hackers, у нас используются уже несколько лет. Но к этому мы добавляем всё новые и новые фичи, есть о чём рассказать.

В 2019 году неожиданным открытием для нас стало, что идеи организации работы с WAL-G хорошо подходят и другим базам данных. В этом докладе мы расскажем о том, как в WAL-G появилась функциональность для MySQL, Redis, MongoDB и др.

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

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

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

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

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.

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

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

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

Мы в ЦИАН собираем через Kafka и храним в Hive большое количество разнородной информации. Это могут быть логи изменения объявлений, действия пользователей на нашем сайте или, например, логи наших внутренних систем.

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

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

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

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

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

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

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

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

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

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

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

Когда-нибудь в далёком будущем автоматическое удаление ненужных данных будет одной из важных задач СУБД [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

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

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

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

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

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

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

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

At the moment MySQL 8 and MariaDB 10.4 are the latest versions of the corresponding database management systems. Each of these DBMSs has a unique set of features, unavailable in its analogue (MariaDB features might be unavailable in MySQL, and vice versa). In this presentation we’ll cover these new features and provide recommendations re: which application will work best on which DBMS.

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

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

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

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

Данный доклад представляет собой взгляд разработчика на реализацию SQL/JSON в PostgreSQL. В нём будут рассмотрены трудности и подводные камни, которые подстерегали на пути реализации стандарта, а также планы на будущее, включая собственные расширения к SQL/JSON и jsonpath в частности.

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

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

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

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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

3 года назад я рассказывал на HighLoad++, как мы перевели мульти-петабайтовую аналитическую систему на ClickHouse. Это была увлекательная "дорога из желтого кирпича", полная неведомых опасностей. ClickHouse тогда напоминал минное поле, найти безопасный путь в котором было непросто.

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс построения API никогда не проходит без споров. Процесс вывода API в public - это настоящий coming out, которому предшествуют масштабные переделки и даже изменения процессов компании.

В этом докладе мы поговорим про дизайн REST API для сервисов и предложим практический checklist для оценки зрелости API.

Мы обсудим следующее:
- Контрактные выборы и их значимость: RAML vs swagger, API first vs code first. Как сделать выбор и как обеспечить его поддержку на всех уровнях компании?
- Разработка API Guideline. Как сформировать этот свод правил и можно ли форсировать его применение?
- Toolchain. Что можно и что нужно автоматизировать, можно ли проверять безопасность на уровне RAML?
- Внедрение практик на все команды. Как помочь программистам добиться совершенного API и не помешать project-manager'ам выпустить продукт в срок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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