Рейтинг@Mail.ru

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

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

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

Высокие нагрузки в индустриальном интернете вещей

Евгений Потапов

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

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

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

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

1. Практические применения индустриального интернета вещей - обзор.
2. Проблемы сбора и надежной обработки потоков данных от сенсоров.
3. Построение цифровых платформ обработки данных.
4. Принципы хранения потоковых данных IIoT.
5. Принципы анализа больших данных IIoT. Машинное обучение и искусственный интеллект.
6. Отказоустойчивость и катастрофойустойчивость систем обработки данных.
?. Практическое применение - примеры действующих архитектур, проблем и путей их решения.

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

Как мы разрабатываем прошивки для IP камер (практически любых, в том числе и самых дешевых)

Олег Герасимов

Мы разрабатываем платформу облачного видеонаблюдения. IP камеры - важнейший компонент любой системы видеонаблюдения. И от того, как работают камеры - напрямую зависит качество работы видеонаблюдения.
На старте разработки платформы мы использовали камеры с прошивками от вендоров, но в ходе развития платформы мы разработали собственную прошивку для IP камер, которая теперь используется уже на ~100 тысячах IP камер.
Основные причины разработки своей прошивки - информационная безопасность и эффективное использование скромных ресурсов CPU/RAM камеры.

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

Для сборки прошивок мы используем gitlab CI - расскажу о нашем опыте использования gitlab CI.

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

Высоконагруженная распределенная система управления современной АЭС

Подольный Вадим Павлович

В докладе будет представлена новая платформа распределенной системы управления АЭС.
Вы узнаете как обеспечивается управление сложнейшими объектами автоматизации в мире. В режиме жесткого реального времени обеспечивается работа более 150 специальных подсистем, управляющих различными технологическими процессами АЭС, таких как система управления реактором мощностью выше 1000 МВт и турбиной весом более 2000 тонн. Более 100К источников данных от датчиков и до 500К расчетных параметров. 5 разновидностей физических процессов: нейтронная кинетика, гидродинамика, химия и радиохимия и физика прочности.
При некоторых отклонениях вся система превращается в огромный источник DDoS полезной диагностической информации, которой всегда больше, чем способна переварить сеть и вычислительные ресурсы автоматизированной системы, что мешает нормальному управлению объектом, Вы узнаете как мы «разруливаем» такие проблемы.
Из доклада вы узнаете о аппаратной и программной архитектуре таких систем, узнаете как обеспечивается резервирование и репликация данных в таких системах, зачем нужна избыточность данных и технологическое разнообразие. Как обеспечивается управление нагрузками, как устроен QoS. И, что будет если отключиться система нормальной эксплуатации, как, например было на Фукусиме.
Но мы все же про кодинг. Ни каких SSD и HDD, только InMemory, структуры данных из десятков миллионов элементов, забудьте про кэш процессора, он не работает, Ваш новый Xeon 4-го поколения потерял все преимущества и превратился «в тыкву», поэтому закатываем рукава и ковыряемся в таймингах, жесточайшей асинхронике, и выжимаем из железа максимум. Кто слабое звено, процессор, память, ОС или сеть, выясняем это.

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

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

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

Дмитрий Сапаев

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

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

QUIC illustrated

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

Протокол QUIC предложен компанией Google в качестве транспортного протокола, который бы доставлял web контент эффективнее, чем TCP. Стандарт протокола QUIC еще обсуждается. По разным оценкам сейчас в Internet 7-10% трафика несет QUIC, в основном, к серверам Google. Тем не менее, web сервера уже адаптируют этот протокол, CDN учатся его доставлять, а производители сетевого оборудования оптимизируют свои решения под UDP, на котором базируется QUIC.

В докладе я сфокусируюсь на важных для разработчиков сетевого ПО вопросах:
- архитектуре QUIC и взаимодействии UDP, QUIC, TLS, HTTP
- формате пакетов
- алгоритмах управления потоком и целостностью данных
- имеющиеся реализации
- обсуждаемый в сообществе дизайн Linux kernel QUIC

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

Lua @ HighLoad++

Разработка Application Server на C++ и Lua со скоростью пули

Александр Боргардт

В нашем динамичном мире разработки, надо очень быстро внедрить новый функционал для развития продукта.
При этом никто не отменял требования по масштабируемости, отказоустойчивости, времени отклика API-вызовов.
В нашем Application Server на C++ и Lua с хранением данных в mongodb и tarantool у нас получилось совместить скорость разработки с жесткими требованиями к уровню обслуживания.
В докладе я расскажу как мы этого добились.

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

Совместное использование Lua кода игровой логики на сервере и клиенте

Андрей Трифанов

Я расскажу о нашем опыте использования игрового кода на бэкенде и фронтенде. Мы использовали OpenResty с Lua в качестве серверной платформы и defold, который тоже поддерживает Lua, как 2D движок.
Сейчас в мобильном сегменте очень популярны midcore игры, в которых есть два игровых процесса. Назовем их “обустройство базы” и “бой”. На практике при реализации “боя” многие игровые мобильные разработчики сейчас пренебрегают сервером, оставляя всю логику на клиенте. Я расскажу про наш опыт совместного использования кода на сервере и клиенте. Про цену, которую пришлось за это заплатить, и про то, что же мы в итоге выиграли.

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

Множественное наследование в Lua как механизм компонентного программирования

Сергей Леляков

Компания IPONWEB занимается разработкой RTB-платформ более 10 лет. Решения для наших клиентов мы строим на базе внутреннего технологического стека, который постоянно развивается. В таких условиях повторное использование кода является ключевым в управлении кодовой базой. Для решения задачи повторного использования мы применяем компонентный подход.

Один из способов реализации компонентного подхода в Lua – множественное наследование.

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

Методы и техника разработки ПО
,
Lua
Программный комитет ещё не принял решения по этому докладу

Effil: иной подход к многопоточности в Lua

Михаил Куприянов
Илья Удалов

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

В рамках доклада мы:
- Расскажем о том, как бы мы хотели работать с потоками в Lua, и чего нам не хватает в существующих решениях.
- Расскажем о нашем подходе к обмену данными и как мы практически избавились от копирования.
- Обсудим проблемы передачи userdata между состояниями интерпретатора и захвата upvalues-функций.
- Оценим результаты тестов производительности Effil vs LuaLanes.

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

Как мы работаем над стабильностью нашей реализации Lua

Антон Солдатов

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

* Расскажу, как мы с нуля создавали тестовую базу для нашей реализации.
* Разберу несколько случаев, когда тесты оказывались бессильны против сложности тестируемой системы – в результате что-то ломалось на боевых серверах "внезапно" и "нерегулярно". Опыт, который мы получили в процессе исправления таких ошибок, можно применить и к работе с LuaJIT'ом.
* Поделюсь инструментами и приёмами, которыми мы пользуемся при отладке.

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

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

Взрывной рост производительности

Александр Павлють

Завязывайте уже с Эджайлом, куда ни глянешь - сплошной стыд и Скрам.

Вступление

В основе создания (воплощения) любой идеи — от зубочистки до космического корабля — лежит объектная сложность (от слова сложение).

Чтобы командам победить сложность, нужно уметь разделять труд.

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

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

Основы

Окружение важнее и первичнее целевого замысла.

Всегда будет проект — потом на основании него действие.

Замысел начинается с онтологии.

То, что не записано — не реализуемо.

Факты — только те действия, что приносят экономическую выгоду.

Основа экономики — система организации труда (действий).

Экономический смысл — основа и проверка всего на пригодность.

Деятельность — это в первую очередь информация о деятельности.

Любая вещь создается не из материалов, а из деятельности по созданию этой вещи.

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

Технологическое разделения труда — единственный источник богатства.

Система разделения труда — цепочка отнормированных операций, проверяемая и предъявляемая.

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

Инновация в систему разделения труда — единственный способ создания новой системы разделения труда.

Деятельность предпринимателя — создание инкубаторов для производства знаний о деятельности и масштабное распространение знаний о способах деятельности.

Практикум

* Еще раз общая онтология.
* Никто не умеет SMART цель, потому что (онтология):
- Намерение.
- Проект (как контракт) на Продукт. (Проект vs Продукт).
- <strike>Job To Be Done</strike> => WPTBP!
- Архитектура (КОНКРЕТИКА).
+ Компоненты.
+ Модули (вещество).
+ Размещения.
- Все это РАБОТЫ во времени.
* Ответственность и бирюзовое лидерство.
* Краткий пересказ СМД — перформер и его изменения.
* Что будет дальше с тимлидами.
* Что им делать.

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

Как мы растим будущих сотрудников благодаря стажировкам

Тимофей Лавренюк

В последнее время все сложнее найти преданных и сильных специалистов. Мы это поняли 5 лет назад и начали проводить стажировки для студентов по 11 направлениям, из которых половина - не технические.

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

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

Школа программистов как решение проблемы найма

Лев Екасов

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

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

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

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

Как пасти котят или Опыт создания push и pull команд с использованием одного инструментального ящика

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

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

Рассматриваются типичные проблемы функционирования технологических компаний (разработка, R&D и т.п.) и методики формирования команд. В качестве примера push-команды взят инновационный практикум ФИВТ МФТИ, как достаточно типичный случай формирования культуры разработки из сотрудников разной квалификации и мотивации (разработчики "с рынка"). Технологический уровень обеспечивался стеком Atlassian, управленческий уровень - элементами Scrum, впоследствии - Essential SAFe, образовательный уровень - выявлением на практике слабых мест в знаниях сотрудников и соответствующей корректировке программ обучения.
В качестве примера pull-команды взят отдел инфраструктуры, эксплуатации и DevOps компании Aspect Enterprise Solutions - разработчика SaaS системы CTRM (Commodity Trading Risk Management), состоявшей из сотрудников высокой квалификации и мотивации.
В качестве примера команды смешанного типа взята команда из внутренних сотрудников департамента ИТ ФРИИ и внешних разработчиков.
Гибкость инструментария позволяет использовать один и тот же комплекс методик для формирования команд разных типов.

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

Сам себе HR: что и как развивать

Тахир Базаров

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

Попробуем разобраться и подискутировать на тему функции HR в компаниях, занимающихся разработкой:

1. Причины задумчивости современного HR:
Люди + технологии = технологичные люди или очеловеченные технологии?
Умения + вовлеченность = потенциал развития или развитие потенциала?
Интеллект + эмоции = эскизность мышления или целостность восприятия ситуации.
Статус + задача = целеполагание в каждый момент или готовность к любому будущему.

2. Субъект – объектная парадигма
Целостный образ себя и команды. Корпоративная культура и взращивание профессионалов.

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

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

Фабрика по выпеканию кода

Кирилл Ветчинкин

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

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

В докладе мы поговорим о процессах в заказной разработке: методиках оценки проектов, минимизации рисков на старте проекта, организации процессов разработки, как удалось подружить Kanban и "Scrum" и выстроить поток от идеи до реализации, где в этом процессе архитектор, DevOps, где и как можно сократить стоимость.

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

Управление людьми как инженерная задача:  экосистема краудсорсинга в Яндексе

Ольга Мегорская

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

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

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

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
SMM (маркетинг в соцсетях)
,
PR-менеджмент, исследования рынка, рекламные концепции
,
Обслуживание клиентов, техническая поддержка, обратная связь
,
Управление / другое
Доклад принят в программу конференции

От одной команды к нескольким. Масштабирование разработки

Руслан Остропольский
Алексей Паршуков

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

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

Подход применим как к стартапам, так и к крупным компаниям, которые хотят быстро и эффективно масштабировать свою разработку.

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

“Сообразим на троих?” или мини-команды как наш путь масштабирования разработки

Артём Назыров

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

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

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

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
Доклад принят в программу конференции

Почти continuous delivery при почти тысяче коммитов в день

Сергей Кукс

.NET отдел в JetBrains -- это несколько различных по численности и стилю управления команд, которые одновременно выпускают более полудюжины десктопных продуктов. Эти продукты запускаются на разных операционных системах, интегрируются в 5 разных версий Visual Studio, имеют общие части и тесно взаимодействуют друг с другом.

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

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

# Инструменты управления большой командой

Дмитрий Безуглый

Создание команды - далеко не простая задача. Размер "естественной" команды 7+/- 2 человека. Создание и управление командой, в которой больше 30 человек - это управленческий и лидерский вызов. Перед каждым руководителем стоит задача: 
* достичь целей (удовлетворить стейкхолдеров),
* развить и сохранить команду и компетенции (создать условия для продуктивной работы),
* выжить .

Для решения этой задачи посмотрим на коллектив с точки зрения методов развития и управления командой. Системный подход к организации работы команды Хокинса включает пять областей командной компетенции:
* Управление целями и исполнением. Каждая группа и команда внутри коллектива достигает своих целей и задач, и регулярно возникает вопрос: "Зачем что-то делать для других?". "С нашей стороны пули вылетели..." и т.д.
* Отношения и коммуникация. Внутри команды, между командами, "Сверху-вниз". Что значит выстроить доверие ? Руководители часто сталкиваются с проблемой того, что руководители команд - не команда. И каждое столкновение интересов приходится "разруливать" вручную. 
* Внутренние процессы. Коллективы решают задачи разного типа и определить один workflow для всех видов задач сложно. Хорошо, когда 9 женщин должны родить 9 младенцев, а если нет? В докладе рассмотрим, как использовать три модели взаимодействия команд.
* Внешние процессы и среда. В больших коллективах политические процессы сложны и часто на работу с коллективом времени катастрофически не хватает. Чем может помочь команда руководителю? 
* Обучение. Процесс самообучения команды еще можно представить как сумму накопленных индивидуальных знаний, но для коллектива само по себе это уже не работает. Наличие знаний не гарантирует их применения. Мы рассмотрим три аспекта - работу с хард- и софт-навыками и компетенциями и развитие команд.

Системные инструменты, которые помогают решить эту задачу:
- Карта территории.
* Диагностика культуры и командных процессов. Типы команд.
* Закон Конвея, Технологическое ядро, Внутренний продукт.
- Управленческая команда.
* Зоны ответсвенности. Ваши команды внутри коллектива.
* Управление групповой динамикой на уровне команды руководителей.
* Менеджмент и лидерство. Смешать, но не перемешивать.
- Обучение и развитие 
* Hard skills - алмазы получаются под давлением. Жизненный Цикл сотрудника.
* Soft skills - поддержка руководителей, создание среды и развитие команд.

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

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

Привлечение tinkoff.ru: от клика по баннеру до выдачи персонализированной страницы

Александр Поломодов

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

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

В процессе реализации имеющегося решения росла и команда, реализующая это решение. Рост команды требовал изменения процессов и роста культуры внутри команды. Я раскрою тему как эти процессы взаимосвязанны и сделаю отсылку к закону Конвея:

Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации.
M. Conway

Основная целевая аудитория доклада - Руководители разработки, Software Архитекторы, Techlead-ы, Senior Developer-ы и все остальные участники вовлеченные в процесс превращения верхнеуровневых бизнес целей заказчика в Архитектурное решение.

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

Про культуру, цифровую трансформацию и зачем CTO кодить

Александр Зиза

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

В конце концов именно genuine digital business стали «виновниками» принятой Программы по цифровой трансформации в России, за что многие топ-менеджеры «не цифровых» корпораций не выполнили KPI и не получили бонусов!

- За что получает деньги руководитель
- Может ли кодить CTO, зачем и когда
- Смысл работы тимлида и кто создает договоренности
- Декомпозиция целей и зачем нужны ОКR
- В чем смысл цифровой трансформации и внезапная роль CTO в цифровой экономике

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

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

Инженерный Буткамп и суперспособности новых разработчиков

Игорь Луканин

Число разработчиков и команд в нашей компании ежегодно растёт на 20 %. Сейчас это 70 команд и больше 1000 человек. Два года назад наши «обычные» процессы подбора, найма и адаптации новых разработчиков забуксовали и перестали работать. Мы провели серьёзный рефакторинг и запустили инженерный Буткамп. Теперь у новых разработчиков есть суперспособность выбирать для работы любую команду, однако это только самое заметное изменение.

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

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

Enterprise-системы

Опыт разработки кластерного Telegram-бота

Михаил Сидоров

Если для работы над проектами вы используете какой-то time-tracker, например, Redmine, то наверняка вас не раз посещала мысль о том, что было бы здорово иметь более простой, быстрый и удобный способ ставить новые задачи, писать на них ответы и получать обо всём этом уведомления через какой-нибудь популярный мессенджер. Например, получили сообщение, тут же написали ответ, и он добавился комментарием к задаче. А если ещё приходится активно взаимодействовать с клиентами, то это становится ещё более актуальным.

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

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

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

Серьезный ритейл: методика тренировок ERP-тяжеловеса

Александр Лищук
Дмитрий Цветков

История преодоления трудностей одной из высоконагруженных SAP ERP крупнейшего ритейлера в России X5 Retail Group. Развитие классической 3-Tier OLTP-системы в ногу с органическим ростом компании, оптимизация производительности, преодоление архитектурных барьеров и неожиданные инфраструктурные находки.
От мониторинга к автоматическому управлению нагрузкой.

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

AWS Cost Reduction - Experiences and Strategies

Andrew Boag

Catalyst IT Australia has been working heavily with Amazon Web Services (AWS) infrastructure since 2010, we have built up a solid base of expertise and capability around the architecting and management of AWS-based application stacks.

As well as being AWS Partners, we are also AWS clients, with a large monthly AWS spend to support and deliver our as-a-service product offerings.

Over this time, we have had considerable exposure to the real world challenges of "bill shock" considerations that are the norm with large AWS infrastructure footprints. Cost management is critical for us as we are a managed service provider where our profitability depends on our ability to optimise our cloud infrastructure spend. We have also been engaged by some of our Enterprise clients to help provide advice on how they might optimise their AWS cost profile.

During this presentation, we'll talk about some of our experiences and learnings. And how we have been able to make meaningful impact on our AWS spend, without a reduction in the quality of platform we deliver.

Unfortunately, there is no magic wand here. But there are some useful policies and practices that will improve your spend.

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

Как мы внедряли ядро инвестиционного бизнеса Альфа-Банка на базе Tarantool

Владимир Дрынкин

Архитектура инвестиционного бизнеса Альфа-Банка была заложена в первой половине 2000-х годов. С тех пор мир пережил финансовый кризис 2008 года, появление криптовалют и mobile-first революцию. Мир ценных бумаг и финансов стал доступен каждому, число торговых операций выросло на несколько порядков, усилилось регулирование рынка ценных бумаг.

- В своем докладе мы расскажем о том, зачем инвестиционному бизнесу Альфа-Банка понадобилось кардинально менять свою архитектуру и переходить на In-Memory СУБД.
- Рассмотрим задачи, которые стояли перед нашей командой, и какую ценность инфраструктурный проект может принести бизнесу.
- Расскажем, почему мы выбирали не только технологии, и почему в конце концов был выбран Tarantool.
- Поделимся опытом внедрения и тестирования прикладного решения на базе Tarantool.
- Поговорим о том, какие бизнес-задачи уже решены, а также какие планируется решать на новой платформе в ближайшее время.

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

Эволюция архитектуры торгово-клиринговой ситемы Московской биржи

Сергей Костанбаев

Фундамент системы торгов на Московской Бирже был заложен во второй половине 90-х годов. Система тех времен была простой и имела монолитную архитектуру. Было достаточно одного сервера для ведения торгов.

За прошедшее время объемы торгов выросли на десятки порядков. Требования к производительности системы росли бОльшими темпами, чем производительность серверов (особенно в последние годы). Кроме того, в последнее время стала набирать обороты высокочастотная торговля (HFT), что добавило требований не только по производительности, но и по задержке обработки каждой транзакции и джиттеру.

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

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

Документация как код: Java, PlantUML, Confluence

Антон Решетников

Everything-as-code и документация в том числе!

Большое количество современных веб-проектов переходит на микросервисную архитектуру. Она решает огромное количество
проблем, присущих монолитным системам. Но микросервисы тоже нужно документировать :)

Популярный подход docs-as-code (документация как код) хорошо применим к микросервисам.
На порталах вроде github.com его легко начать использовать – кладете файл README в корень проекта и все.

Однако, в корпоративной разработке есть ряд ограничений, мешающий внедрению этого подхода:

* непрерывный рефакторинг большого монолита на микросервисы (как ремонт в квартире - начали и пока не закончили)
* территориально-распределенные команды из разных стран
* привычка разработчиков откладывать написание документации "на потом".
* зафиксированный стек используемых технологий и инструментов (в нашем случае это Java, Maven, Confluence)

В докладе рассмотрены темы:

1. Виды документации. Разработческая, пользовательская, документаци на API
2. Подход docs-as-code. Какие проблемы решает.
3. Обзор средств автоматизации работы с документацией
4. Сравнение форматов документации: Markdown, AsciiDoc, reStructuredText
5. PlantUML - генерация диаграмм и схем из текстового описания
6. Confluence - плюсы, минусы, особенности работы
7. Журнал архитектурных решений как код.

Рассказ о том, как подход docs-as-code развивается в компании Ingram Micro.

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

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

Как поднять эффективность разработки. Переход от проектной разработки к микрокомандам

Тимур Гумиров

Можно ли измерить эффективность разработки? Чем микрокоманды лучше проектных команд? Из кого состоят такие команды? Будет ли работать такой подход именно у вас? На эти и многие другие вопросы менеджмента разработки можно узнать из доклада

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

«Разработка не деливерит». Что делать?

Павел Довбуш

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

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

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

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

Сергей Жданов

* Какие у нас команды, и как их формировали.
* Почему Unity, и особенности нашей симуляции.
* Почему не все решения общие.
* Что планируем делать дальше.

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

Джедайские техники в управлении командой или Счастье бородатых айтишников

Виктория Юркевич

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

Оказывается, люди мотивированы всегда, и их не надо пинать!. Вопрос не в том, мотивированы они или нет, а в том, что мешает раскрытию их максимального потенциала.

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

Не нужно создавать созданное, нужно научиться применять имеющееся. Все проще, чем кажется.

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

Яндекс.Облако: сложный выбор между time-to-market и управляемостью продукта

Ян Лещинский

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

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

Менеджмент Гос Проекта: от камасутры с новичками до отчетов за 2 минуты

Анна Хворостьянова
Роман Буданов

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

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

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

План выступления:
1. Регламентированная стратегия погружения новичка на проект
2. Выстраивание эффективного взаимодействия между коллегами
3. Четко разграниченные зоны ответственности и инструменты контроля
4. База знаний новичка
5. Наставничество
6. Эмоциональный баланс и мотивация

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

Руководитель проекта и тест-менеджер: есть контакт!

Наталья Руколь
Виктория Соковикова

В идеальном мире по радуге бегают розовые пони. Аналитики и QA-инженеры работают в мире и согласии. А в реальном они постоянно пропускают ошибки и делают плохие ТЗ. В результате у компании два враждующих лагеря, которые не могут договориться.

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

Во время доклада мы покажем, как решить следующие задачи:
- Говорить с тестировщиками на одном языке
- Подключать тестировщиков на этапе сбора требований к продукту
- Одинаково понимать цели продукта и целевую аудиторию со всеми участниками проекта
- Определять цели и ожидания от тестирования
- Научить тестировщиков читать ТЗ и задавать правильные вопросы
- Отслеживать изменения в проектных документах
- Обеспечить своевременную актуализацию проектной документации
- Наладить процесс всем полезного тестирования требований
- Делать так, чтобы тестировщики не ломали, а помогали выпускать продукт
- Сделать тестирование измеримым
- Оценивать текущий статус тестирования и делать прозрачным этот процесс
- Предоставлять полезную для всех участников отчетность по статусу продукта и его качеству
- Ускорить процесс релизного тестирования
- Приоритизировать задачи по важности и критичности для пользователей
- Трассировать требования, тесты и результаты тестирования
- Собирать понятные и полезные метрики и KPI отдела тестирования
- Наладить процесс управления дефектами, который не будет создавать белый шум

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

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

Архитектура и производительность фронтенда

Building High Performance React Applications

Joe Karlsson

React is built with performance in mind. But when is React slow? In this talk we’ll discuss common bottlenecks in React and when you might be making your program work harder than it should. You will learn practical ways to speed up your real world React applications today.

React is built with performance in mind. But when is React slow? In this talk we’ll discuss common bottlenecks in React and when you might be making your program work harder than it should. We will discuss how Best Buy builds components that stay fast, even during the enormous stress of Black Friday traffic. You will learn practical ways to speed up your real world React applications today.

This talk is for developers curious to learn how to make high performance React applications. You may or may not have already used React, but to get most out of the talk, you should be familiar with the basics of JavaScript.

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

Создание сложного веб-приложения небольшой командой

Мулявка Дмитрий

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

Single page application, толстый клиент
,
Пакетные менеджеры и организация модульности
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
JavaScript
,
Интерактивные приложения
,
Фронтенд / другое
Программный комитет ещё не принял решения по этому докладу

JS and Parallel Processing(!?)

Joe Karlsson

For a long time, JavaScript was missing any kind of processing threads. While the single-threaded model added to developer comfort, it also made the platform unable to do serious and time consuming calculations, and the only way to circumvent it was to do it on a remote server. Luckily, with the introduction and widespread adoption of Web Workers, we can now do resource-intensive calculations on background threads. In this talk, we will explore Web Workers, how and when you can use them, and their peculiarities.

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

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

Как мы сделали свой собственный Netfilter с Intel DPDK и префиксными деревьями

Павел Коростелев

Linux Netfilter лежит в основе огромного количества МСЭ, как открытых, так и коммерческих. Это проверенное, надежное и с недавних пор даже достаточно производительное решение.

Но в современных реалиях, когда через МСЭ зачастую приходится пропускать десятки гигабит трафика, а количество правил фильтрации может переваливать за тысячу, именно Linux Netfilter оказывается узким местом. Именно так и произошло в нашем случае.

В докладе я хочу рассказать о том, как мы переписали сетевую подсистему Linux, которая получилась:
1. Быстрой — десятки гигабит stateful- и stateless-фильтрации, отслеживания сессий, NAT и маршрутизации. На маленьких пакетах!
2. Удобной в управлении — мы научили нашу подсистему понимать команды хорошо известных утилит iproute2 и nftables.
3. Независимой от количества правил фильтрации! Одно правило фильтрации или 10000 — производительность остается неизменной (как тебе такое, Linux Netfilter?).

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

Scale Your Auditing Events

Philipp Krenn

The Linux Audit daemon is responsible for writing audit records to the disk, which you can then access with ausearch and aureport. However, it turned out that parsing and centralizing these records is not as easy as you would hope. Elastic's new Auditbeat fixes this by keeping the original configuration, but ships them to a centralized location where you can easily visualize all events. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. This talk shows you what can you do to discover changes, events, and potential security breaches as soon as possible on interactive dashboards. Additionally, we are combining Auditd events with logs, which are security relevant.

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

A Token Walks Into a SPA...

Sam Bellen

Between Angular, React, & Vue it can be hard NOT to build SPAs these days. But having to deal with cookies, tokens, auth, & resource access - you may even feel like you need a second page (gasp!) for security! Fear not, for the technology to create truly secure SPAs is there and I’ll show you how.

Seems like all you hear about these days are Single Page Applications. Angular, React, Vue, Ember are transforming the way we think about the frontend. But what about securing these applications? This often tends to take a back seat to speed, animations and other cool features of these frameworks. Between cookies, tokens, keeping users authenticated, and handling resource access, securing these apps can be tricky - you may even feel like you need a second page (gasp!) for your authentication setup! But we have the technology to create truly secure single-page applications. In this talk, we’ll walk through securing a Vue application, but our approach will apply to nearly any single-page application framework.

Single page application, толстый клиент
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
Программный комитет ещё не принял решения по этому докладу

Как нас ломали на HighLoad++ Siberia

Андрей Бугрин
Наталия Наумова

Для тех, кто пропустил HighLoad++ Siberia, мы расскажем о проведенном CTF: "Ломай меня полностью!".

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

Этот доклад может быть полезен специалистам, задумывающимся об организации безопасного доступа к Linux-инфраструктуре.

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

Разработка с учетом современного законодательства о защите персональных данных

Денис Лукаш

1. Базовые различия GDPR и 152-ФЗ.
2. Privacy by design новый принцип GDPR.
3. Учет национальных и международных требований к защите персональных данных при проектировании IT - систем.

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

Фишинг. Война бесконечности.

Богомазов Евгений

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

Удивительно, но спустя много лет успешные атаки демонстрируют, что одинаково эффективны оказывается как “старые” атаки с использованием фейковых ссылок, так и принципиально новые виды атак, использующие архитектурные уязвимости протоколов BGP и DNS (атака на криптобиржу с перехватом трафик DNS сервиса Amazon).

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

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

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

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

Виталий Золотарев
Эдуард Макаров

Почему капча в 21 веке – это уже плохой тон. Как можно классифицировать ботов по способу их применения. Про хороших ботов, о которых не стоит забывать, — например, поисковых, используемых мессенджерами и т.д. Про плохих ботов, которых клиенты не хотят у себя видеть, — занимающихся DDoS-атаками, парсингом, перебором паролей, либо даже Робота Веру. Расскажем о том, почему забывать про API – серьезная ошибка, которую не стоит допускать никому. Покажем на реальных примерах, как после фильтрации ботов нагрузка на инфраструктуру клиентов уменьшается более чем в два раза.

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

Борьба за живучесть в условиях DDoS: строим непотопляемое приложение

Георгий Тарасов
Артём Гавриченков

Спроектировать защищенный от DDoS-атак сервис -- значит придать ему характеристики, которые позволят ему продолжать работу в условиях, когда атакующий меняет способ атаки, вектор, интенсивность в попытках найти-таки слабое место. Что это за характеристики? Попробуем определить их с точки зрения того, кто защищает такие сервисы, и ответить на ряд вопросов:
- Что такое живучесть и целостность? При чем тут корабли?
- Что нужно учесть на этапе проектирования сервиса, чтобы минимизировать количество уязвимых для DDoS-атаки компонентов?
- Как снизить критичность выхода из строя тех компонентов, которые останутся уязвимыми все равно? Как быть с Websockets, Long Polling, HTTP/2? Можно ли что-то сделать с UDP?
- Что пригодится сервису, чтобы было проще защитить его от атак внешними средствами защиты, и как избежать обхода этих средств в дальнейшем?
- Какой информацией могут обмениваться сервис и его средство защиты, чтобы взаимодействовать лучше?

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

Make passwords great again!

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

"love", "god" и "sex". Пока людям можно пользоваться паролями, они будут продолжать использовать самые простые.

Взломы баз данных в ста процентах случаев ведут к получению информации о большинстве пользовательских паролей, даже если используется хэширование с солью. А замедление хэширования с помощью современных алгоритмов бьёт по производительности бэкенда. Достаточно ввести свой адрес почты на https://haveibeenpwned.com и, скорее всего, он будет значиться в одной из взломанных баз данных.

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

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

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

Применение Kerberos в разработке: новые возможности создания распределенных систем

Андрей Бугрин
Наталия Наумова

В рамках доклада вы узнаете:
- об использовании MIT Kerberos + OpenLdap как системы централизованного безопасного доступа к Linux инфраструктурам на примере JSS (Jacky Security System);
- о мандатном ticket-based-доступе как альтернативе логину-паролю из конфига;
- об использовании Kerberos как составной части программного обеспечения, играющей роль центра авторизации и обеспечивающего возможность кросс-серверной архитектуры ПО;
- о возможности использования SSO-доступа для автоматического монтирования удалённых хранилищ с данными.

Этот доклад позволит по-новому взглянуть на вопросы авторизации в server-side-программировании, а также стандартизировать задачи авторизации инстансов в рамках Linux-инфраструктуры.

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

Modern fraud trends in RTB: shifting focus from websites to applications

Екатерина Сафонова

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

Для веб-трафика:
- определение: виды фрода, реальные примеры bots/ad stacking/domain spoofing/fake domains;
- границы: insentivised traffic;
- паттерны и борьба: правила datacenters/high friq bids, maсhine learning алгоритмы.

Для application traffic:
- определение: виды фрода и примеры - fake device ID/bundle id spoofing/fake app name/fake scoring and popularity/autoreloads/install postback URL;
- проблемы: куки, собственные уникальные "браузеры", прокси.

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

Технические аспекты блокировки интернета в России. Проблемы и перспективы.

Кулин Филипп

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

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

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

«Платформа» в Badoo: как мы построили инфраструктурную разработку

Антон Поваров

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

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

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

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

Дата-инженеры и кому они нужны

Валентин Гогичашвили

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

Я хочу рассказать о том, с какими организационными и какими из мировых проблем мы столкнулись в наших Data Science-командах, и как мы эти проблемы решаем в Zalando – самом большом е-магазине обуви и модной одежды в Европе.

Профилирование
,
Поиск и развитие команды
,
Продуктовая разработка
,
Будущее рынка разработки ПО
Доклад принят в программу конференции

Переписывать или не переписывать? Жизнь с техническим долгом

Антон Потапов

Как подходили у управлению техническим долгом? Работали над тем, что съедает время команды разработки: улучшили удобство работы, убрав VPN, внедрили CI и e2e, написали и начали использовать Updater для выкатки релизов, отдали часть разработки в другие команды, поддержав плагины. Оказалось важным иметь свой roadmap и vision развития продукта.

Как мы решили, что пора все переписать с нуля? Появилась большая задача "продуктизовать" и выпустить на рынок in-house-решение. Много споров и еще больше усилий в дизайн помогли понять, что разумно переписать с нуля. Большая часть вопросов требовала качественного дизайна, поэтому 4 месяца ушло на разработку первой базовой функциональности, но мы сделали дизайн, на который потом еще за 2 месяца нарастили около 40 фичей.

Как смогли не переписывать что-то вечно? Управляемо накопили долг по фичам, технический долг.

Как смогли сохранить обратную совместимость? По документации старой версии и примерам написали новые тесты. Для каждой проблемы, сравнивая, сколько стоит исправить во всех плагинах (разработка, тестирование, релиз) и у нас.

Как продали идею переписывания руководству? Детально разобрали, что именно хотим получить на выходе, дотошно обсудили критерии сравнения, пользовались экспертными оценками и результатами proof of concept.

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

Скорость или качество?

Егор Бугаенко

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

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

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

Как мы подготовились к BlackFriday

Михаил Косыхин

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

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

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

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

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

Инструменты разработчика для написания тестов

Владимир Янц

Разработчики в Badoo очень любят писать тесты. Без шуток, это действительно так. Сейчас у нас около 30000 тестов для бэкэнда, из которых около 3000 интеграционных, и мы все еще недовольны покрытием!

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

Мы рассмотрим весь арсенал инструментов, доступных разработчику для быстрого и удобного написания тестов:
- DbMock/SoftMocks — наши библиотеки для моков;
- наше облако для запусков тестов, как оно работает и зачем нужно;
- пул тестовых пользователей;
- что такое QA API и как мы используем его в тестах;
- DHR — внутренняя система для автоматизации процессов выявления и починки нестабильных или сломанных тестов

PHP
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
,
Приёмочные и функциональные тесты
Доклад принят в программу конференции

Автоматизация на проектах 1С

Кадысев Василий

Я расскажу о внедрении и автоматизации тестирования конфигураций на платформе 1С.

В сети информации по данному вопросу крайне мало. При работе с инструментами автоматизации у тестировщиков всегда возникает масса вопросов, ответов на которые в принципе нет.

Я структурировал опыт, полученный на проектах, сотни часов анализа и разбора инструментов, скомпилировал наработки и подготовил доклад-лайфхак для коллег тестировщиков 1С.

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

Обязательно упомяну про проблемы автоматизации 1С по сравнению с привычным понятием об автоматизации тестирования, возможные решения по устранению проблем

Будет интенсивно, сложно и супер полезно

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

Нагрузочное тестирование шины. Подача нагрузки "один в один, как в проде"

Сергей Журин

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

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

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

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

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

Антон Барабанов
Дмитрий Годов

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

Расскажем, каким образом мы выбираем те или иные методы в зависимости от ресурса и того, чем он защищен, когда планируем очередное тестирование и какими инструментами пользуемся. Разберем популярные ошибки, которые приводят к тому, что сайт становится крайне уязвимым к атакам, а также расскажем про нестандартные способы атаки на ресурс. Поделимся статистикой успешных тестов на уровнях L3&4 и L7.

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

Нагрузочное тестирование многокомпонентной системы

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

- Параметры системы:
-- более 140 уникальных приложения, более 45kTPS, более 1k серверов;
-- расстояние от Питера до Владивостока;
-- сервера от супердома до виртуалок.

- Отвергнутые решения:
-- запись и повтор трафика;
-- проприетарные решения;
-- выделенные сервера (почему-то на них всегда экономят);
-- 1/10 от нагрузки и ресурсов;
-- читаем из базы;
-- маленькая продолжительность тестов;
-- не учитывать расстояния.

- Решения, которые выжили:
-- бьем в голову, топ по частоте + топ по нагрузке;
-- jmeter;
-- grafana;
-- автоматический анализ мониторинга железа и бизнес-показателей;
-- плановое окно для запуска, приоритет трафика;
-- полнота покрытия: мониторинг, системные и UAT-тесты во время НТ.

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

Методики USE, RED и Golden Signals для анализа производительности и оптимизации

Петр Зайцев

USE (Utilization-Saturation-Errors), RED (Rates-Errors-Duration) и Golden Signals - одни из наиболее известных методик анализа производительности и траблшутинга систем. В этой презентации мы рассмотрим основы этих методов и область их применимости.

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

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

«Как мы построили CDN мирового уровня c нуля? История G-Core Labs».

Василь Михаленя
Дмитрий Самошкин

История создания CDN – от кастомного инфраструктурного запроса одного клиента Wargaming до коммерческого решения.

— 2013. Как выглядела система дистрибуции компании Wargaming в 2013 году с использованием сторонних зарубежных CDN).
— 2013. Командой G-Core Labs мы создаём для Wargaming p2p-инфраструктуру.
— 2013. Улучшаем качество системы и одновременно снижаем затраты на неё: цена упала вдвое, а производительность выросла на 20%.
— 2014. Развитие p2p-сети и увеличение производительности инфраструктуры ещё в три раза.
— 2015. Решение сделать собственную CDN и выбор технологии. Запуск первых серверов, балансировка. Увеличение производительности CDN в два раза по сравнению с предыдущими версиями.
— 2015-2016. Делаем CDN для коммерческого использования: проблемы и вызовы. Выпуск первой версии личного кабинета в августе 2016.
— Сейчас. Как принимаем data-driven решения для улучшения связности, размещения новых точках присутствия и подключения канал.
— Сейчас. Как разрабатываем и поддерживаем продукт.

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

Почти без магии или как просто раздать терабит видеопотока

Михаил Райченко

Я работаю в команде ВКонтакте и занимаюсь разработкой системы видеотрансляций.

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

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

Как разработать нечеткий поиск с нуля

Василий Грудистов

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

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

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

Платформа 4К стриминга на миллион онлайнов

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

Сервис Видео в Одноклассниках – вторая площадка в Рунете по просмотрам видео. Ежедневно мы фиксируем свыше 590 миллионов просмотров видео. Платформа стриминга ОК сейчас позволяет вести профессиональные трансляции в 4К, стримить с телефона в FullHD и отдавать пользователям более 1 Тб/сек трафика.

В докладе я расскажу про платформу стриминга:
* стриминг с телефона и WEB-браузера;
* протоколы стриминга и просмотра live видео: hls, dash, rtmp, webrtc;
* архитектура системы доставки контента и тюнинг congestion control;
* настройка кодеков на клиенте и нарезка видео на GPU;
* о проблемах гарантии задержки на TCP и о том, как мы пришли к собственному протоколу стриминга поверх UDP с гарантированной задержкой доставки видео зрителям;
* свой UDP-протокол: измерение MTU, pacer, шифрование с потерей пакетов, fast retransmite;
* простые способы FEC не работают и google в QUIC его отключили.

Технический прогресс позволил пользователям вести трансляции со своих смартфонов и интерактивно общаться с пользователями в прямом эфире – появились такие мобильные приложения, как Periscope, Insta Live и стриминговое приложение Одноклассников OK Live.

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

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

Результатом нашей работы стал запуск первого в мире приложение на Android, способного стримить в FullHD (1080p) в мобильных сетях.

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

Найди мне работу: как устроен поиск в hh.ru

Алексей Бичук

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

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

Куда идём мы с ZFS и другие вопросы оптимизации

Вячеслав Ольховченков

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

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

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

Cross Datacenter Active/Active Architecture

Артем Гуртовой

Опыт реализации, запуска и эксплуатации распределенной active/active-архитектуры.
Что делать, когда простой продукта стоит миллионы, или зачем нужны распределенные системы.
Доклад о практическом опыте реализации устойчивости системы к отказам на уровне датацентра.

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

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

Переезд на новый ElasticSearch сразу тремя монолитами

Николай Киндяков

Бывает случается так, что идея, которая кажется на первый взгляд хорошей, с течением времени оказывается далеко не самой удачной. Так, в 2012 году идея построить единый API для трёх наших проектов казалась вполне себе хорошей и логичной. Однако, с течением времени проекты стали развиваться, расти каждый в свою сторону, и в результате удерживать их в рамках единого API становилось всё труднее и труднее. API “оброс” специализированными методами и то, что он единый для всех проектов, стало всё больше мешать, нежели помогать.

Хранение и поиск объявлений в API организованы на базе связки MongoDB + ElasticSearch. Случилось так, что к моменту, когда вышла версия ElasticSearch 6.2 мы всё ещё сидели всеми тремя проектами на ElasticSearch 1.4. О том, что послужило триггером для распила API, и с какими проблемами мы столкнулись при переезде на новую версию elasticsearch и будет этот доклад.

Я расскажу:
1. о том, как организовано хранение и поиск объявлений в трёх проектах “Колёса”, “Крыша” и “Маркет”;
2. о том, с какими проблемами мы столкнулись при использовании ElasticSearch в едином API трёх монолитов;
3. почему единое API для трёх проектов – это плохо;
4. как мы переводили одновременно три монолита с ~41 млн объявлений без downtime с Elasticsearch 1.4 на Elasticsearch 6.2. Сколько это заняло времени, с какими проблемами мы столкнулись;
5. как переезд повлиял на нагрузку на железо;
6. почему не нужно копить технический долг.

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

От гигантов до карликов. Как защищать 1,5 миллиона сайтов и чувствовать себя отлично

Виталий Золотарев
Эдуард Макаров

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

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

Как ВКонтакте ускоряет сайт, компилируя PHP в С++

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

В докладе я расскажу про наш компилятор KPHP, который транслирует PHP в C++.

* Что такое KPHP, зачем он нужен, как работает, что умеет;
* эвристики вывода типов;
* как ещё можно ускорять код, помимо типизации и компиляции;
* как мы развиваем KPHP сейчас и с помощью этого ускоряем ленту и discover на десятки процентов.

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

Обработка долгоиграющих процессов (Saga) в распределенных системах на базе NServiceBus

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

В докладе пойдет речь о таких архитектурных решениях, как очереди, событийный обмен данными на базе асинхронного обмена сообщениями (publish/subscribe), устойчивые к сбоям долгоиграющие процессы (saga). Это неполный список фич, которых требует любая распределенная система, и которые мы рассмотрим на живых примерах, разработанных на базе NServiceBus.

Если вы не работаете с .NET, все равно приходите, поскольку в докладе рассматриваются универсальные высокоуровневые принципы построения распределенных систем, которые неизменны для всех языков программирования и платформ.

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

Применение микросервисов в высоконагруженном биллинге

Олег Ивлев
Александр Деулин

1) Архитектура высоконагруженного биллинга.

2) Новые вызовы и двухскоростное IT.

3) Платформа микросервисов (CI&CD).

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

Microservices? Yes, but no spaghetti please!

Peter Eijgermans

Microservices set high standards for architecture and infrastructure: asynchronous message-based applications that are automatically deployed containerized, scaled and managed. This talk focuses on the microservices architecture, design patterns and anti-patterns of implementing microservices.

Microservices is no longer only the latest buzzword, but stands for a broad development/paradigm change to Continuous Delivery, RESTful Services and Agile Development. Teams develop independent (micro) services with a private life cycle, so that new functionality is placed in a very short space of time in production. For online services such as Netflix and Spotify this is vital to compete. Microservices set high standards for architecture and infrastructure: asynchronous message-based applications that are automatically deployed containerized, scaled and managed.

The talk provides answers to the following questions: What are the differences that people might not be familiar with between a monolith and microservices? What do most people or businesses get wrong about microservices? And finally what are the drawbacks of implementing microservices and how to deal with them? After this talk, you will have learned the full spectrum of deploying a microservices architecture.

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

Ураган на заднем дворе: что делать, если нужно обрабатывать миллиарды хаотичных задач

Антон Горин

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

* Всё бы ничего, но каждый из этих кусков выполняется плохо предсказуемое время: от десятков миллисекунд до десятков секунд.
* Всё бы ничего, но в нашей системе резкие всплески нагрузки 2х, 10х, 100х+ (от моды распределения) - не Black Friday, а крайне регулярное событие.
* Всё бы ничего, но такая нагрузка может независимым образом прилететь практически на любой из ~900 изолированных экземпляров сервисов нескольких десятков разных типов. 

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

В своем докладе я расскажу о том, какие подходы мы пробовали, что получилось, на каких вариантах остановились. 
Расскажу про нашу архитектуру и наши инструменты, которые позволяют нам справляться (почти всегда!) с процессингом миллиарда событий в сутки с помощью очень скромных ресурсов. 
Как стоит двигаться, если вдруг понадобится за пару вечеров сделать аналогичную production-ready-систему для своего проекта. И когда с ней начнутся проблемы.

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

Создание высоконагруженного облачного колл-центра

Евгений Пинашин

В своем докладе мы расскажем как достичь высокой производительности системы телефонии на базе Asterisk. Сам по себе сервис Asterisk не очень производительный, но очень популярный и у многих компаний наступает момент, когда один сервер Asterisk'a перестает справляться с количеством звонков и возникает вопрос "Что делать, если ваш сервер может одновременно обрабатывать 300 вызовов, а нужно обрабатывать 1000 и более?".
Расскажем, основываясь на опыте Tinkoff.ru, как можно архитектурно решить проблему производительности на Asterisk.

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

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

Биллинг в Дримсим

Дмитрий Симонов

* mvnx-биллинг: кластеризация и девопс обвязка микросервисов erlang к операторам связи и tarantool, как fast сервер приложений
* бизнес-биллинг на mysql: нагрузочное тестирование забора транзакций из mvnx-биллинга
* использование clickhouse для архивации и аналитики
* вопросы консистентности данных

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

Решение задачи автомасштабирования сервисов в Яндекс Облаке.

Рюрик Крылов

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

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

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

Амангелды Кадыл

Переход на микросервисы несет не только много плюсов, но и свои подводные камни.

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

API
,
PHP
,
Бэкенд / другое
,
Микросервисы, SOA
,
Профилирование
,
Распределенные системы
,
Архитектуры / другое
,
Логирование и мониторинг
,
GO
Программный комитет ещё не принял решения по этому докладу

DNS в Facebook

Олег Облеухов

- Как организована публичная DNS-инфраструктура в Facebook.
- Как ресурсные записи попадают в глобальную инфраструктуру Facebook.
- Как Facebook использует DNS в организации dogfooding.

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

Опыт изменения подхода внедрения: от релизов до фасттрека

Евгений Фоменко
Евгений Беляков

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

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

Решение проблем высоконагруженной балансировки

Алексей Бурылов

Я расскажу о проблемах высоконагруженной балансировки, с которым сталкивалась компания Qiwi. Опишу различные способы повышения отказоустойчивости. Расскажу про разработанную и активно используемую в компании библиотеку балансировки для микросервисной архитектуры qiwi-thrift-pool, и как ее можно использовать в ваших проектах на Java, Kotlin, Scala.

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

Спрут против кашалота: великий соблазн SOA

Alex von Rosen

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

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

Запуская новый продукт, всегда имеет смысл рассмотреть для MVP монолитную архитектуру: на старте монолит часто оказывается гораздо выгоднее, особенно если он модульный. Главное, о чем нужно помнить, — монолитная архитектура не означает отказа от горизонтального масштабирования, а обозначившиеся после запуска «бутылочные горлышки» можно и нужно выносить в отдельные сервисы, тем самым плавно выстраивая SOA. Хороший модульный монолит — надежный фундамент для будущего зоопарка сервисов.

Имея определенный опыт работы с SOA-проектами, мы начали разработку своего нового продукта — (антифрод-системы) — с позиций смешанного подхода: простота модульной монолитной системы должны соседствовать с гибкостью и расширяемостью SOA. Проработка единой модели представления и архитектуры потока данных показала, что сами данные и необходимые для управления их обработкой метаданные могут быть успешно объединены в общую сущность — задание, а работа системы в целом сведется к конвейерному движению таких заданий по общей шине от одного воркера к другому.
Правильный выбор транспорта общей шины и stateless-воркеры априори гарантируют горизонтальное масштабирование и, как следствие, отказоустойчивость. Разумеется, общая шина не является единственным хранилищем данных, результат каждой конвейерной стадии обработки задания сохраняется в хранилище соответствующего воркера. Стратегия движения сущностей по общей шине выстраивается и задается FMS (Flow Management System), на которую также возложены дополнительные функции дополнительного контролера гарантированной обработки заданий. Технологический стек Python + RabbitMQ + PostgreSQL + Redis был выбран из соображений предсказуемости и популярности, он призван минимизировать стоимость владения кодовой базой, с чем успешно справляется.

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

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

Как мы качаем 700 стр. в секунду и 60M в день месяцами из веба

Александр Сибиряков

В этом докладе я расскажу о том, как мы построили контент-систему для поисковой машины одного из наших клиентов. Их задачей было обойти 14М доменов, скачать с каждого не более 100 разных страниц в течение месяца и осуществить пере-обход в следующих месяцах. Система должна быть вежливой по отношению к веб-сайтам, не перегружать чрезмерным RPS и уважать robots.txt. При этом расходы на железо и обслуживание системы должны быть минимальными, а производительность высокой: минимум 600 страниц в секунду.

Таким образом, нам нужно было реализовать робота, который может скачать robots.txt, sitemap, распарсить, обнаружить и запланировать не более 100 уникальных ссылок с каждого хоста и сделать это для нескольких тысяч доменов параллельно. При этом нам нужно было учитывать количество запросов, которое мы отправляем каждому хосту в единицу времени, и делать задержки.

Скажу, что получилось сделать систему, которая может масштабироваться во время обхода без необходимости начинать обход сначала. Все это работает под управлением Marathon и управляется через Slack-бота. На текущий момент робот эксплуатируется уже 1,5 года.

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

Наш стек: Apache HBase, Kafka, Mesos/Marathon, Frontera/Scrapy Python frameworks.

Python
,
Поисковые системы
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Hadoop
Доклад принят в программу конференции

Контейнеры в облаке AWS: сравниваем Amazon ECS, EKS и Fargate

Василий Пантюхин

Напомним базовые принципы работы с docker в AWS.
Обсудим нюансы использования Amazon Elastic Container Service, Fargate и Elastic Container Service for Kubernetes.
Рассмотрим интересные варианты реализации.
Поспорим о достоинствах, недостатках и ограничениях этих решений.

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

FAQ по архитектуре и работе ВКонтакте

Алексей Акулович

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

Например:
* Почему мы все еще на kPHP (и почему он так называется). О множестве интересных подробностей про kPHP планируется доклад Александра Кирсанова (http://www.highload.ru/2018/abstracts/4093).
* Если ли у нас "обычный" PHP, где и почему. А какие еще ЯП используем?
* В чем отличие pu.vk.com от pp.vk.com.
* Как обновить код на десятках тысяч серверов за секунды.
* Отказоустойчивость кластеров мемкэша при постоянно ломающихся серверах.
* Зачем нам свои движки (БД), сколько их, и как мы с ними живем.
* Чем бинлог отличается от снэпшота, и как "откатить DELETE".
* Чем можно все это мониторить.
* Как со всем этим живется новичку в команде.

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

Как мы в Mail.Ru запускали первый в России Kubernetes как сервис в облаке

Дмитрий Лазаренко

Уже год, как Kubernetes вытеснил все остальные системы оркестрации, став стандартом де-факто в мире контейнеров. Mail.Ru Cloud Solutions первыми на российском рынке запустили Kubernetes как сервис. С тех пор прошло уже полгода, и у нас набрался серьезный портфель клиентов, их историй и проблем, с которыми они сталкивались.

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

– Подходы к обновлению Kubernetes-кластеров, которые мы применяем
– Неочевидное поведение Kubernetes при работе со stateful-приложениями в облачной среде и способы решения таких проблем
– Особенности переноса в Kubernetes legacy-приложений без исходных кодов
– Напоследок: как мы делаем Kubernetes максимально отказоустоустойчивым в облаке. Спойлер: это не совсем тривиальная история

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

Distributed systems howto: scalability constraints and solutions

Oleg Klyudt

This talk will cover some very high-level principles for distributed system design (e.g. some web service). The talk doesn't go into particular frameworks or products, rather outlines basic principles underlying all of scalable system designs.

* Architectural principles to enable scalability.
* Handling failures.
* Managing data consistency and state.

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

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

Андрей Моревский

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

Из доклада вы сможете узнать:
- Почему Додо Пицца - это IT-компания;
- В чем уникальность нашей информационной системы, и как мы делаем то, что никто не делал до нас раньше;
- Стартап и архитектура по Фаулеру - почему наша система получилась такой монолитной;
- Как сеть пиццерий оказалась под угрозой краха из-за проблем монолитной архитектуры;
- Как распилить монолит на микросервисы по Рихтеру - почему это больно, и что это лечит;
- Какие существуют способы распилить монолит, и почему мы выбрали тот, что выбрали;
- Как асинхронность и отказ от ACID ломали наши бизнес-процессы и помогали находить в них дыры - практические кейсы из реальной жизни и реального бизнеса;
- Наш путь к микросервисам - честно обо всех проблемах, неудачах и профите.

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

Опыт использования GraphQL в Sports.ru/Tribuna.com — онлайн-медиа со множеством разнородных клиентов

Сергей Кузьменко

TL;DR
Если вы занимаетесь разработкой API для клиентских приложений и веба в 2018 году, вам точно надо узнать про GraphQL. Как минимум, это другой взгляд на дизайн API по сравнению с привычными RPC и REST. А еще эта вещь сделает вашу жизнь лучше.

В докладе:
- описание стандарта, инструменты разработки, лайв-демо;
- преимущества, которые дает GraphQL по сравнению с RPC и REST;
- где нужно использовать GraphQL, а где нет;
- типичная структура вашего бэкенда: gateway, resolver, dataloader, кэширование.

И да, мы используем GraphQL в проде, доклад основан на личном опыте.

* * *
Немного больше слов
Допустим, вы делаете онлайн-медиа, e-comm, соцсеть или еще какой-то consumer web, тогда вас есть три клиента: Web, iOS и Android. Ваши клиенты используют RPC (или REST) API. У клиентов очень похожие требования к API, но все же немного разные. И вы постоянно пытаетесь сбалансировать свое API так, чтобы оно было эффективно для клиентов, но при этом оставалось общим и гранулярным, чтобы ваш бэкенд не превратился в свалку мусора.

Мы решили для себя эту боль, начав использовать GraphQL. А еще мы получили приятные бонусы:
- упростилось API exploration, документирование;
- сократилось количество запросов между клиентом и сервером за счет батчинга;
- клиент всегда получает только те данные, которые ему нужны.

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

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

Трафик-инфраструктура Dropbox

Алексей Иванов

Доклад покроет весь путь запроса от пользователя к серверам приложений Dropbox. Внешняя DNS/BGP-балансировка с использованием RUM, устройство точек присутствия по миру: ipvs/nginx/lua. Трафик внутри дата-центра: самописный reverse-proxy на Go, изоляция, метрики и трейсинг. Трафик между микросервисами бэкенда: Service Mesh на gRPC, Service Discovery и распределённой ФС для хранения конфигов.

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

Переход от клиент-серверной архитектуры к децентрализованной вычислительной системе

Игорь Лебедев

Доклад об опыте разработки децентрализованной вычислительной системы командой enterprise-разработчиков.

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

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

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

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

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

Function as a Service in private cloud

Сергей Рыбалкин

* Мы рассмотрим вопрос постоение Function as a Service системы внутри Alibaba private cloud.
* Расскажем, с какими трудностями сталкиваемся при разработке платформы и как оптимизируем нагрузки.
* Поговорим о том, как предоставить максимально комфортную среду разработчику функций.
* Рассмотрим, почему для своего решения мы выбрали Kotlin и какими фичами языка активно пользуемся.

FaaS позволяет нам снять с разработчиков ответственность за разворачивание и масштабирование сервисов.
А также существенно сокращает количество микросервисов в нашем деплойменте.

Java
,
Прочие языки
,
Бэкенд / другое
,
Асинхронное программирование, реактивное программирование
,
Архитектуры / другое
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Доклад принят в программу конференции

Camunda на микросервисах

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

Как уйти от монолита при построении промышленных BPM-систем. Распределение процессов по микросервисам, организация взаимодействия между процессами.

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

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

«Отложенные данные» — наш механизм обеспечения консистентности

Андрей Литуненко

Пять лет мы жили с самописной шиной для обмена данными — теряли сообщения и страдали от однопоточного импорта. Сегодня мы используем Apache Kafka и Golang для обмена данными между сервисами.

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

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

Тернии контейнеризованных приложений и микросервисов

Иван Круглов

За последние два с половиной года Booking.com прошел через три поколения приватных облаков. Первое было построено на Mesos и Marathon. В активной фазе оно просуществовало около полгода. Решили отказаться. Второе - на OpenShift. Работали над ним около года и тоже отказались. Сейчас у нас третье поколение на чистом Kubernetes. Пока живем с ним.

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

Микросервисы, SOA
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Оценка сложности проекта
Доклад принят в программу конференции

Java и Linux - борьба за микросекунды

Алексей Рагозин

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

Разработка систем оптимизированных для малого времени на Java имеет много особенностей.

Доклад осветит практические аспекты разработки решений с малым временем отклика на платформе Java + Linux
- Low latency, Ultra low latency и Real time - что всё это значит?
- Оптимизация архитектуры для минимизации времени отклика
- Оптимизация времени отклика Java кода
- Многопоточность, параллелизация и время отклика
- Настройка Linux для минимизации времени отклика

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

How we deliver 1Tbps of video with our WebRTC peer-to-peer network

Jordan Pittier

At Streamroot, we have built a peer-accelerated delivery network for video that now delivers more than 1Tbps of data through our Distributed Network Architecture (DNA) based on WebRTC.

We will talk about how we built our P2P solution and how it works, and how we scaled our backend to handle tens of thousands of requests per second, and millions of simultaneous users, and how we make sure to handle even more during the FIFA worldcup.

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

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

Игорь Муратов

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

Подобные узлы в некотором смысле аналог роутеров IP-трафика, но с особенностями:
* оперирование трафиком на прикладном уровне;
     * сигнальные протоколы используют разный транспорт TCP/IP, SСTP;
     * реализация некоторых интерфейсов (Gx, Gy, Sy и т.п.) требует stateful-обработки.

Будут рассмотрены следующие аспекты:
* Маршрутизация — атрибуты таблиц маршрутизации и основные типы применения;
* Контексты сессий — необходимость  stateful-обработки трафика и типы применения;
* Резервирование — резервирование сетевой функции на примере Gx, Sy;
* Связывание сессий — multiple PCEF, VoLTE;
* Масштабирование — применение  DRA  для масштабировании по горизонтали сетевой функции;
* Балансировка — применение  DRA  для балансировки трафика на несколько элементов сетевой функции;
* Отказоустойчивость — алгоритмы восстановления при сбоях.

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

Разгоняем обработку событий до 1.6М/сек. Опыт Badoo

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

Три года назад на Highload++ я рассказывал, как мы построили масштабируемую систему near-realtime обработки событий. С тех пор она эволюционировала, в процессе росли объёмы, и нам приходилось решать задачи, сопутствующие любому проекту с нагрузкой — масштабирование, отказоустойчивость и прочие. В определённый момент мы достигли точки, когда потребовались радикальные меры, а именно — смена технологического стека.

В докладе я расскажу, как мы заменили связку Spark + Hadoop на ClickHouse, в три раза сэкономили железо и увеличили нагрузку в пять раз (с 300 000 событий в секунду до 1 600 000 в пике).

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

Что мы знаем о микросервисах?

Вадим Мадисон

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

В общем, поделюсь всем тем, что называется «жизнь после запуска в Kubernetes»...

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

Архитектура "Колёса Автокредит"

Виталий Березнёв

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

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

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

О чём доклад:
- архитектура проекта;
- хранение и поиск данных;
- логирование;
- мониторинг и статистика;
- использование микросервисов на Go;
- небольшие хитрости и оптимизации, которые улучшили нашу жизнь.

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

DDoS attacks - threat and protection

Kajetan Staszkiewicz

- How DDoS attacks influence network infrastructure and applications.
- How can we protect ourselves against them:
-- What can be done in-house?
-- Traffic analysis and automatic network configuration in response to threats
-- What is better achieved with external DDoS mitigation services?
- How protection can (or rather: will) fail and what can be done about it.

- Kernel-level performance issues:
-- Measuring how your system reacts and what it really does during an attack using HWPMC (Hardware Performance Monitoring Counter)
-- Using HWPMC to find other issues with firewall performance.
-- How we improved FreeBSD kernel to better handle DDoS attacks.

- Latest trends:
-- the changes on DDoS attack scene.
-- new threat: IPv6.

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

Сказ об удалении данных на шардированной базе

Кристина Кучерова

Доклад будет полезен тем, у кого есть общие данные на шардированных базах. Например, в нашем проекте базы данных были шардированны по пользователям (точнее по их компаниям), но при этом были данные, которые использовались несколькими компаниями. Этот доклад описывает непростой переход, полный удивительных и иногда немного печальных открытий, от одной системы удаления файлов (в БД), которая уже не справлялась с объемом, к новой, сияющей и прекрасной. Проект по sharing’у файлов, входит в лидеры по магическому квадранту Гартнер, система работает 24\7, клиенты и в США и в Европе - самые высокие часы нагрузки, когда работает и Европа и США. На момент оптимизации удаления файлов на S3 было 2 Pb лишних данных, за которые, конечно, платила сама компания. Все изменения были сделаны в базе данных.

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

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

Игорь Луканин

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

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

Согласованность данных в гео-распределенном кластере с помощью CRDT

Дмитрий Мартьянов

In search of greater scalability, more and more projects are considering eventually consistent models for data persistence. At the same time, software designers are focused on creating resilient systems ready to work in production with minimal complexity. Dmitry will share lessons learned in developing a distributed system based on an eventually consistent data store. Specifically, the pragmatic design decisions around eventually consistent data access operations, managing the trade-offs between correctness and consistency, and anticipating misbehavior in components both upstream and downstream of the system. The final solution utilizes conflict-free, replicated data types with causality tracking to achieve eventual consistency for critical data in multi-master, multi-datacenter DB (Aerospike) deployments.

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

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

Serverless adventures in the world of NLP

Alizishaan Khatri

Do you marvel at the idea of production-grade Natural Language Processing (NLP) that can scale infinitely in nearly constant time?

You will learn how to design, build and deploy a general purpose NLP application using serverless computing. The talk will also cover tricks to maximize performance.

This talk will discuss:
- The design of an NLP system for batch processing texts performing tasks like tokenization, Named Entity Recognition, Part Of Speech Tagging, text-classification, etc.
- The following constraints of working with serverless computing and approaches to work with them:
* Package size restrictions.
* Memory restrictions.
* Speed.
- An automated build and deploy strategy.
- Tips and tricks to maximize performance.

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

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

Игорь Лебедев

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

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

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

Аренда у cloud-провайдеров - тоже дорого. Однако есть люди, у которых потенциально есть много GPU по низкой цене. Это - майнеры. Потенциально их устроят доходы (за те же мощности) существенно дешевле, чем у GCP, AWS и других, а суммарная мощность GPU у них порядка 200-500 TFlops.

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

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

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

Исправление опечаток в пользовательских запросах

Тигран Салуев

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

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

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

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

Андрей Дроздов

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

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

Поисковые системы
,
Продуктовая разработка
,
Реклама и ее эффективность
Доклад принят в программу конференции

Using events based data architecture for near real time, machine learning, time-series prediction

Nir Malbin

Gett is using events based data architecture, collecting millions of records per minute. In this talk i shall describe how we built, using this data, an end-to-end machine learning solution for predicting the company KPI's in near real time.

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

Big-Data-процессинг пользовательских данных из соцсетей в AlibabaCloud MaxCompute

Максим Алексеев

В докладе я покажу пример объединения разнородных данных 700 млн аккаунтов из 15 разных источников, включая внутренние данные кастомеров AliExpress и внешние данные аккаунтов соцсетей. Мы будем использовать Big-Data-движок Alibaba MaxCompute, при этом весь код может с минимальными изменениями запускаться на привычном Apache Hive.

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

Инструменты: MaxCompute (Hive) engine, Java 8 / Kotlin, SQL, MapReduce / Graph jobs.

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

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

Building useful and scalable Data Lake

Guy Cohen

There are many options to collect and store data. Using RDBMs works fine for small and medium datasets with well defined schemas. But what if you also have very large datasets with a variety of mixed schemas? How can you store them once and use them later for all your analytic use cases?

Building useful and scalable Data Lake:
- Architectural considerations for building scalable Data Lake
- Smart ways to make your Data Lake useful
- How to calculate business KPIs from raw data with Presto

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

Прогнозирования продаж интернет магазина с помощью градиентного бустинга (lightGBM).

Александр Алексейцев

Мы в OZON.ru разработали автоматическую систему пополнения склада.

Мозг системы - ML для прогнозирования продаж:
- Постановка задачи и выбор лосс функции
- Feature enginering - около 180 признаков. Расскажу как сочиняли, а потом отбирали признаки. Как дать "понять" модели сложные сезонные особенности спроса на товары, выход на рынок конкурента, неожиданный хайп и такое же неожиданное забвение
- Генерация датасета - известные и не очень баги Spark, сложные джойны, оконные функции и многое другое
- Выбор модели - перепробовали все на свете (линейную регрессию все же обыграли).
- Подводные камни процесса обучения lightGBM - выбор гиперпараметров, регуляризация, балансировка выборки
- Оценка результатов - как убедить весь мир (и себя заодно), что все работает хорошо

Скелет системы - Spark/Hadoop/:
- Весь код написан а Spark (около 5к строк).
- Ежедневная доставка/валидация данных
- Решения по повышению надежности системы (если упадем, OZON просто ничего не закупит)

Бизнес-реалии закупок товаров:
- Выбор поставщика
- Страховые запасы
- Борьба с уровнем сервиса поставщиков

БОНУС: использование обученных lightGBM моделей для оценки эластичности спроса на товары по цене, планирования маркетинговых акций и эффекта от них.
Разные виды функций зависимости спроса от цены для разных типов товаров и много другое, получили как "побочный" эффект от основной задачи.

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

Жизненный цикл ML в боевых условиях

Сергей Виноградов

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

Big Data и Highload в Enterprise
,
Hadoop
,
Machine Learning
,
ETL
Доклад принят в программу конференции

Алгоритм поиска цвета на изображении как идеальный beauty-помощник в сфере красоты

Корсак Олеся
Тишкин Павел

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

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

Платформа данных в соответствии с GDPR: теория и практика

Рустам Аляутдинов

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

Попробуем разобраться во всем этом на примере платформы данных в Nvidia и 20 миллионах пользователей

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

Медицинский чат-бот и система оценки врачей, или Как DS применяется в медицине уже сегодня

Илья Ларченко

Доклад посвящен применению DS в сфере медицины первичного звена.

Я расскажу:
- как мы создали два продукта, обученных на медицинских картах пациентов: чат-бот для сбора жалоб и первичной маршрутизации и систему контроля качества медицинской помощи;
- как прошли путь от постановки DS-задачи, исходя из бизнес-целей, до релиза продуктов внутри компании и для внешних партнеров;
- про опыт применения NLP, RBM, Word2Vec, XGB, CNN и др. для решения задач, основанных на текстовых данных;
- про аугментацию данных и автоматическую разметку данных для текстовой выборки;
- про трансфер моделей, обученных на одних данных, для работы с другими.

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

Ранжирование объявлений на основе машинного обучения и ElasticSearch

Павел Тарасов

Я расскажу, как мы в cian.ru сделали персонализированное ранжирование объявлений при поиске на основе ElasticSearch и существенно увеличили эффективность поиска объявлений. Сам ElasticSearch не позволяет сделать персонализированное ранжирование, да еще и на основе сложных моделей, таких как градиентный бустинг и нейронные сети, из коробки. К тому же, применение таких моделей к сотням тысяч объявлений - очень вычислительно-сложная задача.

Мы придумали элегантное решение, которое позволяет на таком объеме данных использовать сложные модели, быстро отвечает и одновременно выдерживает RPS крупнейшего в России сайта недвижимости без дополнительных вложений в сервера ElasticSearch. Заодно немножко расскажу о самих моделях, их построении и тестировании, о том, как используются данные user-item-рекомендаций для улучшения качества, и как делать ранжирование в условиях, что клиенты платят за место объявления в выдаче.

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

Обмани меня… Разрушаем мифы о Spark-аккумуляторах

Сергей Жемжицкий

На сегодняшний день техники оптимизации обработки данных весьма хорошо известны и понятны. Вот некоторые из них:

1) Вертикальное или горизонтальное масштабирование инфраструктуры путем добавления большего количества серверов, RAM, CPU, GPU, увеличение пропускной способности сети – другими словами, оптимизация методом грубой силы.

2) Чтение только тех данных, которые необходимо прочитать, минимизируя дисковый IO, например:
- путем организации данных в соответствии с паттерном доступа к ним, например, используя шардинг, партиционирование, бакетирование и т.д. или
- путем использования колоночных форматов хранения данных, таких как Parquet и ORC.

3) Минимизация сетевого IO
- путем партиционирования нескольких наборов данных заранее и одинаковым образом (co-partitioning).

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

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

Мы с вами попробуем разобраться, можно ли использовать Spark-аккумуляторы для подсчета и сбора метрик гарантированно единожды, в качестве side-effect'а основного процесса обработки данных (немного заглянув во внутренности Spark'а), тем самым сократив объемы обрабатываемых данных и время выполнения задач в некоторых случаях более чем в 2 раза, а также с тем, действительно ли верны утверждения документации Spark и, если нет, то в каких случаях.

Scala
,
Big Data и Highload в Enterprise
,
Hadoop
,
ETL
Программный комитет ещё не принял решения по этому докладу

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

Building Resilient Data Pipelines in Go

Grant Griffiths

The modern world runs on Data. In this talk we will cover how Gophers of any level can easily build Data Pipelines in Go with Kafka and Cassandra. At the end, we will look at how GE has written a Data Pipeline in Go that can handle over 800,000 writes per second of industrial time series data.

Introduction to Data Pipelines:
- What are data pipelines
- Why Go is a good language for them

Package structure:
- How to lay out our data pipeline’s packages
- How data will flow throughout the application
- Example code

Writing integration tests:
- Using docker to write integration tests
- Simulating downtime using docker pause on Kafka or Cassandra
- Example code

Data source: Kafka:
- What is Kafka and how we can use it with Go
- How to ensure no data loss is possible with good offset management
- Reading from multiple Kafka partitions with a high level consumer
- Example code

Performing ETL on the data and business logic:
- Parsing data
- Data ETL
- Performing intermediary business logic
- Example code

Persistent Data Storage: Cassandra:
- Setting up gocql to write to Cassandra
- Best practices for writing to Cassandra
- Example code

Demo: Processing hundreds of thousands of message:
- Finished version of our demo application
- Running in a Kubernetes cluster at scale
- Killing components, seeing how it recovers
- Finished example code

Example use case: Go Data Pipeline at GE Digital:
- Example data pipeline that’s running in production at GE Digital
- Production results of a similar data pipeline with over 800,000 writes per second

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

Выбираем систему репликации для PostgreSQL

Виктор Егоров

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

Какую систему репликации для PostgreSQL выбрать? Какие могут быть ограничения или подводные камни?

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

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

Will Postgres Live Forever?

Bruce Momjian

This presentation explains how open source software can live for a very long time, and covers the differences between proprietary and open source software life cycles. It also covers the increased adoption of open source, and many of the ways that Postgres is innovating to continue to be relevant.

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

Tarantool 2.1 появилась поддержка SQL: подробности

Кирилл Юхин

С выходом версии 2.0 в Tarantool появилась поддержка языка запросов SQL ориентированная на соответствие спецификации стандарта ANSI.
В текущей реализации SQL Tarantool способен не только выполнять нетривиальные запросы для выборки данных, но так же обладает полноценным набором ограничений целостности данных, включающих в себя внешние ключи, триггеры, проверочные ограничения, привилегии.
При этом SQL поддерживает работу как с in-memory движком memtx, так и с дисковым vinyl.
В ходе доклада прежде всего мы рассмотрим архитектурный подход нашего решения и ход выполнения запросов. Посмотрим на симбиоз возможностей Lua (включая протокол IProto) и SQL: на данный момент SQL запросы возможно применять к спейсам с заданным форматом. Подробно остановимся на выполнении сложных составных запросов. Проанализируем поведение запросов при наличии совокупности различных ограничений целостности данных и очередность их выполнения. Разберем особенности работы и реализации представлений, внешних ключей, триггеров и их отличия от других баз данных.

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

Как стать классным спецом по базам данных?

Илья Космодемьянский

Системы хранений и манипуляции данными в том или ином виде есть в любом хайлоад-проекте, как традиционные MySQL/PostgreSQL, так и экзотические - DB2 или "две-недели-назад-придуманная-NoSQL-база" (легкая и производительная, под наши задачи, конечно же!). Как разобраться в этом постоянно растущем и изменяющемся ворохе технологий? Ответ простой: читать книжки, документацию, иногда (если есть исходники), следить за полезными ресурсами в интернете и набирать, набирать опыт. Но так-ли просто следовать такому общему совету? Начав разбираться с одной только реляционной алгеброй, можно насыщенно и достаточно бесполезно провести несколько лет. В топе популярных IT-форумов годами висят неверные ответы. В серьезных книжках рассматривают CAP-теорему как-будто это действительно теорема а книжки с настоящими теоремами невозможно читать не засыпая над ними после трудового дня.

В этом докладе я расскажу как более системно подходить к вопросу. Начиная с того, какие книжки обязательно надо прочесть, заканчивая тем, как искать ответы на вопросы которых в книжках нет и не будет. Мы пройдем по списку теоретических знаний, которые нужны современному базисту, рассмотрим варианты как поддерживать их up to date. То же самое мы сделаем с практическими навыками и поговорим о том как их получить. На практических примерах мы разберемся как разобраться что делает конкретная настройка и как она влияет на работу СУБД.

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

Фантазии девелопера, или Ночной кошмар DBA

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

Я и мои коллеги из Data Egret - PostgreSQL-консалтеры, и жизнь дала нам уникальную возможность смотреть и участвовать в процессе развития баз данных в самых разных компаниях - от маленьких до больших. Но, независимо от размера, при эксплуатации СУБД все команды периодически наступают на разные грабли.

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

В докладе я рассмотрю:
- проблемы с дефолтными конфигурациями, которые встречаются практически везде и всегда;
- антипаттерны, связанные с проектированием схем данных;
- проблему длинных транзакций, которая часто становится сюрпризом;
- мониторинг, и когда его отсутствие тоже доставляет массу материала для статей на Хабре;
- еще будет про самописные системы очередей, HTAP workload, немного подзабытую бигдату, микросервисы, docker/kubernetes.

По ходу доклада слушатели узнают про некоторые best и worst practices при работе с СУБД и, уже смотря на свои базы, смогут заранее спрогнозировать возникновение неприятных ситуаций и предпринять меры.

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

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

Make Your Database Dream of Electric Sheep: Designing for Autonomous Operation

Andy Pavlo

In the last 20 years, researchers and vendors have built advisory tools to assist DBAs in tuning and physical design. Most of this previous work is incomplete because they require humans to make the final decisions about any database changes and are reactionary measures that fix problems after they occur. What is needed for a "self-driving" DBMS are components that are designed for autonomous operation. This will enable new optimizations that are not possible today because the complexity of managing these systems has surpassed the abilities of humans.

In this talk, I present the core principles of an autonomous DBMS based on reinforcement learning. These are necessary to support ample data

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

Переезжаем в облака: опыт миграции 10 TB PostgreSQL-кластера на AWS

Александр Кукушкин

Ни для кого не секрет, что мы в Zalando очень любим PostgreSQL. Общее количество кластеров на данный момент превысило 700. Объёмы данных и нагрузка самые разные: от нескольких десятков мегабайт до 10 терабайт. Что может быть интереснее, чем поддержка высоконагруженной базы размером в 10 терабайт и смешанным ворклоадом (high-OLTP/OLAP)? Конечно же, переезд такого кластера в облака.

Ниже представлен ряд наиболее интересных вопросов и проблем, которые необходимо было решить:
* Какой тип EC2 Instance выбрать? i3 с эфемерными NVMe-дисками или m4/r4 + EBS?
* Может быть, стоит попробовать Amazon Aurora?
* Сервера в дата-центре находятся в приватной сети и не доступны из AWS. Как построить реплику и поддерживать её в актуальном состоянии, если по ряду причин нежелательно использовать VPN?
* База данных используется десятком легаси-приложений и несколькими сотнями сотрудников компании. В идеале они не должны заметить переезда и продолжить работать через старые хост и порт.
* Как делать бэкапы? Этот вопрос особенно актуален в случае использования i3-инстансов.
* Нам нужен план отступления (переезда назад), если что-то пойдёт не так.

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

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

ClickHouse тормозит

Кирилл Шваков

Практическое руководство по созданию неэффективных решений при помощи СУБД ClickHouse.

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

Continuous Optimization for distributed BigData analysis

Kai Sasaki

The performance of distributed data analysis highly depends on the data structure such as file format.In practical we also need to consider the application workload. We developed a technology which can improve OLAP performance by optimizing storage structure continuously to fit application workload.

The performance of distributed data analysis highly depends on the data structure. The factors which can have impact on the performance are this.

- File format.
- Metadata statistics.
- Network bandwidth.
There are a lot of researches and technologies to make them optimized. For example, we have several de fact standard columnar file format such as ORC, Parquet. These are optimized for OLAP processing and their metadata enables us to skip partitions.

But we found the best storage structure is also decided by application workloads in practical use case. The best storage for a user is not always the best one to another user. It means we need to take use cases and application workloads into consideration to optimize storage system. What we need to do was

1. Collect accurate metrics of storage access (access rate of each partition, column and.
2. Decide the target table based on 1.
3. Then optimize user storage system continuously.

We call this process Continuous Optimization. In the process of Continuous Optimization, we reorganize storage structure to fit application workloads. Concretely it reorganizes partitions and metadata of the table by using application workload metrics. So we could reduce the storage access cost in average then improve query performance.

Since in many cases the storage file is huge size, we make use of our Hadoop infrastructure which also provides our cloud service. Therefore we can make sure scalability when we improve our storage system without any additional instance cost. At the same time we can achieve high cluster utilization by improving scheduling algorithm of Continuous Optimization job.

Last but not least, data consistency is also the most important factor in OLAP. While optimizing the storage, we make sure the consistency of dataset by using transactional metadata update. We developed RDBMS base distributed storage system to guarantee no data lost, no data duplication even in the case of distributed update semantics. We talked about this storage system at the part of previous talk. See from the page 24 of the slide

So the key points of Continuous Optimization are:
- analysis of application workload;
- scalability and High utility cluster;
- distributed update semantics.

I’ll talk about the architecture and implementation to achieve these goals.

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

PostgreSQL 11 и далее: обзор новинок и тенденций

Иван Панченко

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

Наибольшее внимание уделено следующему:
- параллелизм при исполнении запросов: что параллелится, как настроить, влияние на производительность;
- интеграция с LLVM (JIT-компиляция): что JIT'ится, как настроить, влияние на производительность;
- секционирование (партицирование): в 11-й версии польза для повышения производительности существенно возросла, в чем она заключается, сравнение с pg_pathman;
- ожидавшиеся, но не попавшие в 11-ую версию фичи - SQL/JSON и MERGE.




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

Инструменты создания бэкапов PostgreSQL

Андрей Сальников

Старая истина гласит, что есть люди, уже делающие бэкапы, и есть люди, еще не делающие бэкапы.

Данный разговор посвящен доступным инструментам бэкапирования PostgreSQL. Логические бэкапы, бинарные бэкапы, встроенные средства бэкапирования и сторонние инструменты. Нужны ли инкрементальные бэкапы, когда они могут действительно помочь. Посмотрим, когда и какой инструмент уместнее использовать. Как лучше автоматизировать процесс бэкапирования и проверки целостности сделанного бэкапа. Посмотрим вблизи на инструменты, такие как pg_dump, pg_basebackup, barman, wal-e, wal-g, pgbackrest, BART и pg_probackup.

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

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

Иван Раков

Как бы ни развивались технологии, резервная копия в трудную минуту продолжает сохранять нам нервы, а иногда и работу. Платформа GridGain работает поверх распределенной системы с открытым исходном кодом Apache Ignite, где отсутствует возможность делать бэкапы данных. На сегодняшний день максимальный объем данных в клиентском проде GridGain составляет 200 терабайт на 160 узлах. Данные не только хранятся, но и постоянно модифицируются с обеспечением транзакционных гарантий.

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

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

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

The cost of MongoDB ACID transactions in theory and practice

Henrik Ingo

MongoDB 4.0 introduced support for full ACID transactions. This is the culmination of several durability, consistency, and isolation related features released in the past years. We will review all the available options for readConcern and writeConcerns. We explain their implementation in order to understand their latency cost to the client application, and then compare this theoretical cost with real measurements.

Durability levels:
- j: true/false (journaling to disk)
- w: 0, 1, majority, N (nr of replicas)

Consistency levels:
- sessions: causal consistency
- readConcern: local, available, majority, linearizable, snapshot
- readPreference: primary, secondary, etc...

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

Document oriented vs relational data modeling

Henrik Ingo

Now that MongoDB supports both joins and transactions, users could in theory go back to using MongoDB as a relational database. However, this is not the intent with transactions and would not be optimal. In this session we explore the spectrum of data modeling alternatives from heavily normalized to the more document oriented models and even some graph queries. And we then consider what use cases are optimal for each model, both from a developer as well as performance point of view.

This session contains code examples both from MongoDB and PostgreSQL.

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

Latest evolution of Linux IO stack, explained for database people

Илья Космодемьянский

Input-output performance problems are on every day agenda for DBAs since the databases exist. In Linux - probably the most popular operating system for databases now - there is a major overhaul of IO stack for last several years.

In this talk i will review what is going on, why IO stack needed an urgent improvement and what can bring tfor databases, and database people all those brand new NVMe driver and blk-mq layer improvements. As a useful takeaway I will suggest a checklist of PostgreSQL and Linux settings to maximize IO performance with new kernels.

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

Масштабирование реплик PostgreSQL под нагрузкой с точки зрения технологий резервного копирования

Андрей Бородин
Владимир Лесков

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

WAL-G - простой и эффективный инструмент резервного копирования PostgreSQL в облака. В основной функциональности WAL-G является наследником WAL-E, написан на Go. Доклад будет посвящён новым возможностям, базовая функциональность резервного копирования будет рассмотрена предельно сжато.

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

MySQL 8.0: SQL and NoSQL Scalability

Vittorio Cioe

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

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

Объединение этих двух аспектов позволяет вам разрабатывать современные приложения, готовые к гибкостью и масштабируемостью!

MongoDB
,
Oracle
,
Сравнение enterprise и web
,
Мобильные решения для enterprise
,
Big Data и Highload в Enterprise
,
MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

Разработка аналитического хранилища данных в условиях стартапа

Алексей Кузьмин

Дано:
- 40+ реплик баз данных продакшн-систем (PostgreSQL) + одна БД (тоже PostgreSQL), которая держит на них fdw;
- Несколько бизнес-аналитиков, которые хорошо знают SQL и уже привыкли пользоваться этой системой;
- 100+ отчетов, завязанных на эту систему;
Надо:
- На всем этом взлететь.

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

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

В докладе я расскажу, какую архитектуру на основе PostgreSQL мы придумали, как все это взлетало, затрону вопросы работы PostgreSQL с foreign-servers и расскажу, как мы организовали мониторинг.

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

Как устроить хайлоад на ровном месте

Олег Бартунов
Федор Сигаев

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

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

Один из вариантов реализации Data Discovery в микросервисной архитектуре

Николай Голов

Представьте, что вы распиливаете монолит/реализуете микросервисную архитектуру на основе паттернов Database-per-service и Polyglot Persistence.

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

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

Много вопросов, и много потенциальных сложностей. Я хотел бы рассказать вам о концепции "Помнящей ткани", Persistence Fabric, которая, надеюсь, поможет решить сложности, и об элементах ее реализации на графовой СУБД Neo4J.

PostgreSQL
,
MongoDB
,
Tarantool
,
Базы данных / другое
,
Организация системы кеширования
,
Микросервисы, SOA
,
Распределенные системы
,
Автоматизация разработки и тестирования
Доклад принят в программу конференции

Demystifying MySQL Replication Crash Safety

Jean-François Gagné

Up to MySQL 5.5, replication was not crash safe: it would fail with “dup.key” or “not found” error (or data corruption). So 5.6 is better, right? Maybe: it is possible, but not the default. MySQL 5.7 is not much better, 8.0 has safer defaults but it is still easy to get things wrong.

Crash safety is impacted by positioning (File+Pos or GTID), type (single/multi-threaded), MTS settings (Db/Logical Clock, and preserve commit order), the sync-ing of relay logs, the presence of binlogs, log-slave-updates and their sync-ing. This is complicated and even the manual is confused about it.

In this talk, I will explain above with details on replication internals, so you might learn a thing or two.

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

"Заряжай" или CDC из MariaDB и Postgres в аналитическую СУБД MariaDB Columnstore

Роман Ноздрин

Я продемонстрирую две схемы Change Data Capture для потоковой передачи данных из MariaDB Server 10.3 и Postgres 10 в аналитический движок MariaDB Columnstore. Желающие смогут принять участие, подняв у себя на машинах схемы на docker. А чтобы понять, для чего это может понадобиться, какие сложности могут встретиться, и где эти схемы используются, я расскажу о Change Data Capture и проектах: MariaDB ColumnStore, MariaDB MaxScale и Debezium.

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

Яндекс.Метрика и нестандартный ClickHouse

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

ClickHouse доступен в open-source уже более двух лет, однако, команда разработки Яндекс.Метрики перешла на эту СУБД еще в далеком 2014 году и с тех пор ни разу не пожалела об этом. В своем докладе я расскажу о том, как мы эксплуатируем ClickHouse, на какие грабли мы наступали, какие необычные решения принимали и с какими трудностями сталкивались за эти четыре с лишним года. В частности, слушатели узнают, как мы организовали вычислительное облако поверх серверов с ClickHouse'ом, как мы используем эту СУБД в качестве key-value хранилища, а также как мы сделали мониторинг таймингов вставки.

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

Место row level security в высоконагруженном проекте

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

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

Далее будет приведён пример практического кейса выбора способа реализации row level security в высоконагруженном enterprise-проекте (4000 пользователей, 10000 запросов одновременно, транзакционная и olap-нагрузка одновременно).

Будет рассмотрен анализ 3-х технологий реализации row level security в СУБД Oracle, и почему же была выбрана именно security в базе, а не на сервере приложений:
1. самодельный;
2. virtual private database;
3. real application security.

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

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

SQL на стероидах. Масштабируемая SQL система аналитики на postgresql, greenplum и clickhouse.

Максим Вихарев

DWH, BI, ETL, DATALAKE - слова ныне знакомы каждому. Бизнес как никогда активно и изощренно анализирует cвою активность, активность своих информационных систем, производительность всевозможных производственных цепочек.
Рассмотрим новые возможности для создания платформ данных с помощью opensource.

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

Расскажем о том, как мы с 2011 года пилили свою велосипедную систему аналитики на основе Postgresql. А потом перестали cтрадать и просто добавили к постгресу готовые greenplum и clickhouse. Получив в итоге простую миграцию, 100% opensource, легкий стэк, простое обслуживание, надежность и горизонтальное масштабирование, уменьшение костов на инфрастуктуру и широкие функциональные возможности за счет сочетания ANSI SQL, MPP, In-memory. Вскроем простоту внутренностей решения и рассмотрим компоненты стека под микроскопом, проведя ретроспективу вывода в прод и дальнейшей эксплуатации.

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

Миграция реального приложения на Percona XtraDB Cluster

Владимир Буянов

В докладе я расскажу о нашем опыте миграции на с MySQL на Percona XtraDB Cluster и особенностях его эксплуатации.
Основные темы:
* Принцип работы Galera Cluster
* Подготовка приложения к миграции
* Развертывание и конфигурирование кластера
* Миграция данных online
* Подводные камни
* Мониторинг кластера
* Балансировка нагрузки
* Резервное копирование
* Подводные камни, на которые мы натолкнулись

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

MariaDB и MySQL — какую статистику использует оптимизатор, или Как обойтись без индексов

Сергей Голубчик

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

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

И, конечно, как не нужно использовать индексы, когда достаточно адекватной статистики.

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

Под капотом in-memory db: как обработать миллионы запросов в секунду. Или, почему Reindexer такой быстрый

Олег Герасимов

Мы уже 2 года разрабатываем in-memory базу данных Reindexer, которая была создана для решения задачи фильтрации и отдачи контента со сложной бизнес логикой в системе, обслуживающий 10м+ пользователей.
На одном физическом сервере Reindexer может выполнять более миллиона простых запросов в секунду и десятки тысяч запросов с JOIN и нетривиальной фильтрацией.

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

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

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

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

Как Tinkoff.ru использует Greenplum

Дмитрий Немчин

Мы - одни из первых в России пользователей Greenplum и:
- написали свою систему репликации данных из Oracle и Postgres;
- каждый день 4к ETL-джобов обрабатывают больше 20 ТБ данных, а храним мы больше 70 ТБ данных;
- около 1000 пользователей ежедневно используют наш кластер, приходя из SAS, Zeppelin и напрямую в БД клиентами;
- свой DR с проверкой бэкапов и задержкой в 2 часа до попадания на бэкапную СХД;
- тонны сломанных копий (тех, которые оружие) и боли администраторов.

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

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

Александр Мазуров

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

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

Доклад рассчитан на разработчиков, имеющих базовые знания о Hive и Mesos/Marathon.

Базы данных / другое
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
,
Big Data и Highload в Enterprise
,
Hadoop
,
ETL
Доклад принят в программу конференции

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

Петр Зайцев

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

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

VShard - горизонтальное масштабирование в Tarantool

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

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

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

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

API
,
Архитектурные паттерны
,
Распределенные системы
,
Масштабирование с нуля
,
Lua
Доклад принят в программу конференции

Простые ответы на сложные вопросы про BI

Сергей Кукс

Многие компании задумываются о том, что им нужен “BI”. Некоторые даже понимают зачем. Но мало кто, задумываясь о собственной системе Business Intelligence, отдают себе отчет какие системы (а это именно системы, а не одна система!) необходимо построить и что необходимо использовать.

Мы прошли весь путь от идеи до использования платформы в бою.

В рамках доклада мы поговорим про следующие вещи:
- Из чего вообще состоит BI.
- Чего можно взять на рынке, а что лучше сделать самим.
- Какие требования были у нас.
- Из чего мы выбирали: поговорим в том числе про колоночные базы данных, e.g. GreenPlum, Vertica, ClickHouse и другие
- Как построить архитектуру такой системы.
- На какие грабли мы наступили, наши планы по технической части.

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

Nancy CLI – автоматизированные эксперименты для глубокой диагностики и оптимизации производительности БД

Николай Самохвалов

Администрирование баз данных в будущем будет полностью автоматизировано. Это уже так для базовых операций DBA: поднятие инстансов, бэкапы, управление репликацией, failover — мы наблюдаем это по бурному развитию облачных «управляемых» СУБД (AWS RDS, Google Cloud SQL и десятков игроков поменьше), работе над k8s-оператором для Postgres и MySQL в ряде компаний, внедрению внутренних RDS-like DBaaS (database-as-a-service) решений внутри крупных организаций.

Но диагностика и оптимизация производительности баз данных сегодня всё ещё очень «ручные». Например, в Postgres: находим медленную группу запросов в pg_stat_statements, ищем конкретный пример (а то и «выдумываем» его на ходу), пробуем EXPLAIN ANALYZE сначала в dev/staging-окружении, где, как правило, данных не так много, а потом на prod-е... Подбираем индекс, убеждаемся что он ускоряет (вроде бы) один SQL-запрос и — всё, отправляем в production. Метод «чик-чик и в production» должен остаться в прошлом! Как остались в прошлом развёртывание и настройка серверов и сервисов вручную.

Nancy CLI (https://github.com/postgres-ai/nancy) – открытый фреймворк для проведения экспериментов над базами данных PostgreSQL, позволяющий любому инженеру наладить системный подход к анализу и опмимизации производительности БД. Nancy поддерживает проведение экспериментов локально (на любом сервере) и удалённо на дешёвых высокопроизводительных спот-инстансах AWS EC2.

Без каких либо специальных знаний, ипользуя Nancy CLI, любой инженер может теперь:
- собрать подробную информацию о поведении «SQL-запросов с прода» на «клоне прода», но «не трогая прод» с целью выявления узких мест (на «проде» под нагрузкой включать обширную диагностику неразумно, а иногда и невозможно),
- проверить, как тот или иной индекс влияет на производительность SQL (в том числе: насколько он замедлит UPDATE-ы),
- подобрать оптимальные параметры настройки Postgres-а (пример: запустить в облаке проверку 100 вариантов default_statistics_target с подробным исследованием эффекта и анализом для каждой группы SQL-запросов),
- сравнить 2+ прогонов моделированной нагрузки на клоне реальной БД в различных условиях (разное оборудование, разные версии Postgres, разные настройки, разные наборы индексов).

В докладе мы также обсудим конкретные примеры внедрения метода автоматизации экспериментов над БД и Nancy CLI в ряд проектов различных компаний (БД до 2ТБ, hybrid workload, до 15k TPS) и трудности, которые пришлось преодолеть на пути:

1. Включение полного логирования запросов: когда это просто страх, а когда это действительно серьёзный стресс для сервера? Как быть, если диски «не тянут» полное логирование?
2. Вопросы безопасности: нужно ли давать доступ к эксмериментальным узлам всем разработчикам или можно обойтись без этого? Обфускировать ли данные?
3. Как убедиться, что результаты эксперимента достоверны?
4. Как проводить эксперименты над терабайтной базой данных быстро?
5. Стоит ли включать Nancy в CI/CD-конвейер?

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

Как Яндекс построил DBaaS на 1000 кластеров

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

В инфраструктуре Яндекса довольно давно существует платформа вычислительных ресурсов, на которой работает большинство stateless-сервисов компании. Давно есть и хорошее объектное хранилище, но относительно недавно не было инфраструктуры для хранения того, что обычно кладут в базы данных. В докладе речь пойдёт о том, как мы сначала построили инфраструктуру database as a service для собственных разработчиков сервисов, а теперь масштабируем для внешних пользователей.

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

Руководство по выживанию с MongoDB

Загурский Сергей Валерьевич

MongoDB — это популярное NoSQL-решение для хранения данных. С MongoDB легко стартовать и многие проблемы имеют решения "из коробки". Однако, по мере увеличения нагрузки вылезают грабли, о которых вас заранее никто не предупреждал... до сегодняшнего дня!

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

Репликация между разными СУБД: для чего мы написали репликатор MySQL-Tarantool

Михаил Буйлов

* Где у нас закончились возможности MySQL;
* кэширование базы данных в memcache - не такая тривиальная задача, как это выглядит на первый взгляд;
* в чем Tarantool действительно превосходит memcache;
* подводные камни выноса части MySQL-функционала в Tarantool.

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

ClickHouse at Messagebird: analysing billions of events in real-time*

Aleksandar Aleksandrov
Felix Mattrat

At MessageBird we send hundreds of millions of messages across the world every month,
which generate billions of events. Providing real-time* analytics is key to being able to
quickly deliver those messages to our customers. From measuring and optimising the
performance of our platform, to providing insights to our customers, ClickHouse is being
used far and wide inside our organisation.
In this talk, we look into how Clickhouse allows us to ingest large amount of data and run
complex analytical interactive queries. We also present the business needs that brought
ClickHouse to our attention and detail the journey to its deployment. We cover the problems
we faced, and how we dealt with them. We talk about our current Cloud production setup
and how we deployed and use it. Last but not least, we talk about mistakes we did along the
way and what we learned from running and maintaining a ClickHouse cluster by ourselves.

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

Забиваем телескопом гвозди или нестандартные способы использования ClickHouse

Александр Зайцев

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

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

Анализ производительности запросов в ClickHouse

Алексей Миловидов

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

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

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

Правильно готовим ElasticSearch: Как не утонуть в потоке логов.

Красников Валерий


- Elasticsearch - как основной инструмент хранения/анализа логов.
- Какие коллекторы логов стоят на вооружении команд Туту.
- Первая версия кластера логов: Развернуть не сложно, но так-ли просто оптимально настроить ?
- Первая версия неудачна ? - Конечно нет! Работаем над ошибками.
- Как мы архитектуру хранения придумывали - или все придумано до нас.
- Решение проблем с емкостью кластера. Работают ли договоренности ?
- Cluster Nodes: так ли тут все просто? Расскажу к чему мы пришли.
- Итоговая архитектура кластера логов. История успеха.
- Работая в команде – работай с другими командами.

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

Software Defined Storage the Linux way

Philipp Reisner

I will start with a refresh the audience's overview of the storage functionalities that are available as open source with the Linux kernel: LVM, thin provisioning, RAIDs, SSDs as HDD caches, deduplication, targets/initiators and DRBD. They are all compatible on the data plane, but each brings its own control mechanism.

Then I will present an open source software called LINSTOR, that combines all those parts and allows one to manage block storage volumes on the level of a storage cluster. It supports synchronous and asynchronous replicated volumes to build a resilient storage system.

On top of that, it comes with a FlexVolume driver for Kubernetes to provide persistent storage to containers. At this level one of the Linux file systems is put on top of the block storage. Drivers for Cinder/OpenStack, OpenNebula and XenServer are available as well.

It is mainly targeted at workloads requiring high performant IO subsystems(e.g. databases). It can be deployed hyper-converged or on dedicated nodes.

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

Introduction to MyRocks and production deployment at Facebook

Yoshinori Matsunobu

At Facebook, we created a new MySQL storage engine called MyRocks (https://github.com/facebook/mysql-5.6). Our objective was to migrate one of our main databases (UDB) from compressed InnoDB to MyRocks and reduce the amount of storage and number of servers used by half. In August 2017, we finished converting from InnoDB to MyRocks in UDB. In this session, I will introduce MyRocks, and introduce several interesting production issues that we have faced, and how we have fixed them. Some of the issues were very hard to predict.

Attendees will learn the following topics.

- What is MyRocks, and why it was beneficial for large services like Facebook
- What should be considered for production database migration
- How migration should be executed
- Learning 3~5 real production issues

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

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

Александр Рубин

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

Типичный пример - запрос с join, group by, order by. Типичное решение - создать индексы. Однако не все так просто - в некоторых случаях MySQL не использует индекс или использует не тот индекс, который нам бы хотелось. Чтобы разобраться с такими случаями и понять, что происходит, мы будем использовать новые возможности MySQL 5.7 и 8.0 - optimizer trace, performance_schema (новые таблицы) и другие возможности.

В результате мы сможем лучше понять, что происходит внутри MySQL optimizer, и сможем оптимизировать медленные запросы.

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

Репликация в Tarantool: конфигурация и использование

Георгий Кириченко

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

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

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

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

Hadoop at scale: мы построили большой кластер, как его теперь сохранить?

Сергей Корсаков

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

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

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

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

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

Немного о нашей инфраструктуре:
* сейчас у нас два кластера, состоящие в сумме из более чем 4000 серверов;
* ежедневно наши приложения шлют более 500 миллиардов сообщений в Kafka, которые потом попадают на HDFS. В сумме это более 150 TB данных в день. Всего же в течение дня у нас появляется около 0.5 PB новых данных;
* более 30 команд активно используют нашу инфраструктуру;
* более 300 тысяч MapReduce- и 6 тысяч Spark-джобов запускается на кластере ежедневно.

Менеджмент в эксплуатации
,
Администрирование баз данных
,
Большие проекты/команды
,
Hadoop
Доклад принят в программу конференции

Как мы ищем по всем атрибутам всех объектов системы или немного Oracle In-Memory

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

Один из наших Заказчиков поставил следующее требование к программному продукту: возможность поиска по любой комбинации атрибутов объектов всей системы в едином интерфейсе. Когда мы спросили о скорости, ответ был не менее прост: "Как у Amazon". Задачу усложняло то, что одновременно с данным функционалом работает не менее 1000 пользователей, а другие части приложения не менее 5000 раз в секунду запрашивают данный функционал через REST API.

Очевидным решением для данного функционала является faceted search.

Наше приложение реализовано с использованием СУБД Oracle, и мы решили использовать встроенные возможности, чтобы минимизировать доработку кода на стороне сервера приложений.

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

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

Продолжая тренд OpenSource, я расскажу, что вышло бы по скорости и объему изменений, если бы мы использовали в качестве СУБД Tarantool и Apache Ignite.

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

Путь к кластеру для хранения слабоструктурированных данных

Артём Картасов

История об эволюции нашего хранилища данных девайсов.

Расскажу, как мы прошли путь от одной таблички в MySQL до целого кластера на MongoDB, с какими проблемами столкнулись и как их решали. Поговорим о том, насколько стабилен Redis, когда autovacuum вас не спасёт, и почему одной технологии иногда недостаточно.

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

BBM’s 150M+ users Oracle to Postgres migration without downtime

Álvaro Hernandez

BBM (the Black Berry Messenger) is one of the largest chat and voice/video applications in the world, with more than 150M users. And it was running on on-premise Oracle. We helped them migrate to PostgreSQL running on GCP with real-time replication and near-zero downtime.

This talk is a use case and a detailed description of the process, caveats, techniques, technologies and best practices to migrate Oracle to PostgreSQL effectively without downtime.

Oracle to PostgreSQL migrations are the new hot topic in the database industry. However, they are quite involved process, with many caveats, and deep expertise required. Join this talk to get an overview of how it was performed on a mission critical, high-profile use case.

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

Apache Kafka как основа для велосипедостроения

Николай Сивко

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

Доклад не столько про нашу базу данных, сколько про то, как можно для данной задачи НЕ реализовывать часть сложнейшей логики, а взять это от apache kafka:
* как НЕ делать репликацию своими руками
* как легко получить шардинг из коробки
* как обеспечивать/контролировать целостность данных

Также я поделюсь нашим опытом эксплуатации достаточно нагруженной кафки:
* ~20k produce ops/second;
* ~100k fetch ops/second;
* 1 major upgrade кафки в online;
* 3 переезда между серверами online;
* 2 факапа:)

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

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

Feature Toggles или как выкатывать фичи без релиза

Ян Ашенкампф

Отдел маркетинга интернет-магазина заказал новую фичу - персонализированные рекомендации товаров для клиентов. Допустим, на разработку и внедрение полностью работающей версии требуется месяц. На этот месяц запланировано 8 релизов. Что делать?
- выкатить последним релизом весь функционал огрести проблемы запуска сразу?
- или выкатывать постепенно и «пугать» пользователя недоделанным функционалом?
- а если не "взлетело"?
- как быть с мобильными приложениями, которым требуются недели, чтобы быть установленными у всех клиентов?
- что делать с совместимостью API
- как померять, что пользователям фича понравилась и они стали покупать больше?
- как программистам поддерживать код со всей этой комбинаторикой?

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

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

Автоматизация замены дисков с помощью Ansible

Артём Александров

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

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

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

DevOps: важность статических анализаторов кода

Андрей Карпов

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

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

Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency

Henning Jacobs

Kubernetes has the concept of resource requests and limits. Pods get scheduled on the nodes based on their requests and optionally limited in how much of the resource they can consume. Understanding and optimizing resource requests/limits is crucial both for reducing resource "slack" and ensuring application performance/low-latency. This talk shows our approach to monitoring and optimizing Kubernetes resources for 80+ clusters to achieve cost-efficiency and reducing impact for latency-critical applications. All shown tools are Open Source and can be applied to most Kubernetes deployments.

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

BeyondCorp: модель DevOps-безопасности без регистрации и VPN

Глеб Лесников

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

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

В докладе я расскажу:
* Что даст вам BeyondCorp
* Как выпилить VPN и SSH ключи из компании с помощью временных(ephemeral) SSH сертификатов и аудита (Netflix BLESS, ScaleFT, Gravitational Teleport)
* Как сделать доступ к базам данных с помощью бастионов и SSH проксирования
* Как сделать доступ к тестовым стендам: утилиты для proxy_command
* Как сделать доступ к HTTP сервисам, и как Kubernetes нам в этом помогает
* Почему oauth2_proxy это полумера и не выход, спойлер: нужны контролируемые девайсы!
* Почему нельзя доверять доступ всем устройствам и MDM подряд
* Почему мы внедряем FIDO/U2F ключи как второй фактор аутентификации

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

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

Особенности реализации доступа по протоколу iSCSI к СХД Ceph

Алексей Костин

В случае, если у вас имеется СХД ceph, и ваши клиенты не поддерживают rbd (например, клиент - это windows или vmware), вам приходится искать решения, какими еще способами можно отдать устройство клиенту и обеспечить отказоустойчивость этого решения.

Я расскажу, какие варианты решения проблемы есть, и какие существуют ограничения, расскажу, что такое tcmu-runner и почему его стоит использовать. Рассмотрю решение ceph-iscsi и сравню его с решением компании SUSE. Объясню, почему может потребоваться передавать Persistent Reservation через rbd-устройство, где это может понадобиться, в каком случае лучше подождать с внедрением этих технологий.

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

Deploying MySQL on Kubernetes & Openshift

Александр Рубин

В этом докладе я расскажу о том, как с помощью одной простой команды можно развернуть целый MySQL-кластер (Percona XtraDB Cluster) из 3-х или более узлов + ProxySQL + мониторинг. Kubernetes & Openshift позволяют оркестрировать docker containers и быстро развертывать приложения.

Я также расскажу о том, что такое Percona XtraDB Cluster и ProxySQL, и как ProxySQL позволяет взаимодействовать с кластером.

В конце презентации я продемонстрирую, как развернуть кластер с помощью одной команды, после чего мы попробуем его сломать и посмотреть, как Openshift и Percona XtraDB Cluster сам себя починит.

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

Базы данных и Kubernetes

Дмитрий Столяров

Нам, компании Флант, множество раз задавали вопрос: "Можно ли базу в Kubernetes?".

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

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

Мониторинг — разработчикам! Технологии — сообществу! Профит — всем!

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

Инженерная команда Авито сегодня — это более 350 специалистов, разделенных на десятки кросс-функциональных команд. У нас более 5 миллионов входящих метрик в минуту и около миллиона бизнес-ивентов в секунду. Как сделать так, чтобы внимательно отслеживать состояние всех наших сервисов, монолита, инфраструктуры, и при этом не нанимать армию DevOps-инженеров?

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

Наш сервис построен на популярных OpenSource-решениях: Graphite, Clickhouse, Prometheus, Moira. Мы активно используем StatsD-агрегаторы и в какой-то момент написали свой, который выложили для общего пользования. Поэтому, прослушав доклад, вы сможете частично или полностью реализовать такое решение у себя.

План доклада:
1. Необходимость в системе мониторинга в виде сервиса.
2. Как мы строили сервис мониторинга.
3. Как на данный момент выглядит схема работы нашего сервиса мониторинга.
4. Какой результат мы сейчас имеем.
5. Проблемы, с которыми мы столкнулись.

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

Доставляем в Kubernetes. Непрерывно и по-своему

Евгений Дехтярёв

Два года назад нам не хватило готового решения для доставки приложений в Kubernetes, и мы придумали собственное. Взглянем на историю развития PaaS в 2ГИС, сравнив его со стандартным путём доставки приложений и инфраструктуры на бой. Вспомним, каким был Helm в конце 2016 года. И в итоге увидим, зачем нам понадобился свой способ доставки в Kubernetes.

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

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

Деплой в VM, Nomad и Kubernetes: опыт Lamoda

Павел Агалецкий

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

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

From Ansible to SaltStack - как и зачем

Дмитрий Самохвалов

- Расскажу про проблемы, с которыми мы столкнулись при использовании Ansible для раскатки и поддержки инфраструктуры в Альфа-Банке.
- Что показалось интересным в SaltStack, и как мы думали решить возникшие проблемы.
- С чем пришлось столкнуться при внедрении Salt.
- Как мы делали Salt удобным для привыкших к Ansible.
- Наш опыт использования возможностей Salt-api.
- Поделюсь опытом написания модулей для Salt.

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

Terraform best practices with examples and arguments

Anton Babenko

This talk is for the developers who want to learn best practices in using Terraform at companies and projects of various size (from small to very large), get pros&cons on code structuring, composition. Also, attendees will be able to learn Terraform (and Terragrunt) tricks and gotchas.

It is easy to get started with Terraform to manage infrastructure as code. Just read the documentation on terraform.io, and you are done. Almost.

The harder part begins when infrastructure grows in all directions (several AWS/GCP accounts, regions, teams, projects, environments, external integrations). One of the most frequent questions is "how to structure code".

In this talk, I will explain many of challenges related to that, what works, what does not work, why so, and most importantly I will show all the code which works from small projects to very-large infrastructures (featuring multi-cloud and multi-region setup).

This talk is best suitable for people who have been using Terraform at least for some time and already have practical questions.

All the code and solutions presented at the workshop will be open-sourced.

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

Опыт миграции с on-premise инфраструктуры в AWS Cloud: задачи и решения

Кузнецов Кирилл Александрович

Практический опыт реализации крупного проекта трансформации и миграции ИТ-систем издательской компании в публичное облако AWS. Трансформация геораспределенной инфраструктуры при миграции. Перенос баз данных Oracle RAC. Оптимизация фронтэнда: переход на микросервисную архитектуру. Перенос SAP в контейнеры: масштабирование и проблемы роста. Сокращение затрат: использование opensource-решений – Terraform, Jenkins, Chef. Оптимизация поддержки: infrastructure as a code, continuous delivery, модульность. Способы миграции больших объемов данных >500 ТБ – Snowball, Direct Connect, репликация распределенных данных.

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

Как VK вставляет данные в ClickHouse с десятков тысяч серверов

Юрий Насретдинов

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

Основные тезисы:
— Как VK использует ClickHouse (логи / статистика).
— Производительность ClickHouse в наших условиях, конфигурация кластеров.
— Буфер-таблицы.
— Проблемы в эксплуатации.
— kittenhouse: локальный прокси для ClickHouse.
— LightHouse: легкий веб-интерфейс для просмотра содержимого таблиц.
— GreenHouse: интерфейс на основе LightHouse, позволяющий просматривать сразу все кластеры, заведенные в kittenhouse.

C/C++
,
PHP
,
Логирование и мониторинг
,
ETL
,
GO
Доклад принят в программу конференции

Лучшие практики нативных облачных сервисов

Елена Граховац

Написать и запустить «Hello, World» — дело нескольких секунд даже для новичка. А что, если «Hello, World» должен быть представлен в виде микросервиса, удовлетворяющего требованиям нативной облачной инфраструктуры? Что это, вообще, за требования такие и откуда они взялись? Разбираемся по порядку.

Доклад рассматривает практические вопросы написания нативных облачных (cloud native) приложений:
— проектирование сервиса и структурирование кода;
— проверка качества кода с помощью тестов и анализаторов;
— управление зависимостями и взаимодействие с внешними ресурсами;
— задание конфигурации и «секретов»;
— контейнеризация;
— наблюдаемость и безопасность: почему это важно;
— непрерывные интеграция и развертывание;
— эксплуатация в рамках системы управления контейнерами.

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

Metrics! Metrics! Metrics!

David O'Brien

Metrics are important to understand what is happening in your environment and the health of your application. Microsoft Azure has a powerful and easy way of surfacing metrics for all kinds of workloads and we will see how we can leverage all of them.

3AM, on a Sunday, you should be asleep, but instead you are woken up by a text claiming that “the super-critical app is timing out again”. What is happening? Where is it slow? Why is it slow? In this session we will discover the services that Microsoft Azure offers to customers to collect logs and specifically metrics of our cloud workloads. We will understand what metrics we should be interested in when running on a cloud platform and how to get to those metrics. We will learn about open-source tools and will definitely build some nice dashboards. In the end attendees will have the knowledge to start building their own metrics dashboards and next time they are woken up at 3AM they will be able to quickly understand what is happening.

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

Автоматизируем сборку deb/rpm-пакетов сразу под 5 версий Debian и CentOS

Борис Ершов

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

Решить их позволяют системы управления пакетами (deb-based, rpm-based, etc), которые имеются практически в каждой современной ОС. Но для того, чтобы установить пакет, его сначала нужно создать и положить в пакетный репозиторий. А этот процесс не такой простой, как может показаться с первого взгляда.

В докладе будет рассказано о том:
* как данный процесс построен в нашей компании
* как и почему мы к этому пришли
* как создать свои собственные deb и rpm-репозитории
* как и какими средствами обеспечить сборку deb и rpm-пакетов для конкретного приложения
* как выкладывать подготовленные пакеты в репозитории
* как автоматизировать этот процесс и сделать его по настоящему простым и удобным
* что в итоге нам всё это дало

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

Бэкапы в Kubernetes

Станислав Тибекин

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

В рамках данного доклада мы расскажем о том:
* почему мы используем наше собственное решение;
* как нами осуществляется резервное копирование Etcd Kubernetes;
* как мы бэкапим такие сервисы как: MySQL, MongoDB, Redis и др;
* где хранится и как бэкапится код приложений;
* где хранить сами резервные копии;
* как использовать собранные бэкапы:
** для восстановления определённого сервиса,
** для восстановления всего k8s.

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

Deploying MySQL on Kubernetes & Openshift

Александр Рубин

В этом докладе я расскажу о том, как с помощью одной простой команды (oc create -f pxc.yml) можно развернуть целый MySQL-кластер (Percona XtraDB Cluster) из 3-х или более узлов + ProxySQL + мониторинг. Kubernetes & Openshift позволяют оркестрировать docker containers и быстро развертывать приложения.

Я также расскажу о том, что такое Percona XtraDB Cluster и ProxySQL, и как ProxySQL позволяет взаимодействовать с кластером.

В конце презентации я продемонстрирую, как развернуть кластер с помощью одной команды, после чего мы попробуем его сломать и посмотреть, как Openshift и Percona XtraDB Cluster сам себя починит.

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

eBPF для анализа производительности Linux

Петр Зайцев

eBPF - на сегодняшний момент самый продвинутый интерфейс для инструментации ядра Linux и приложений.

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

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

zabbix, 100kNVPS на одном сервере

Михаил Макуров

* Мониторинг - онлайн и аналитика.
* Основные ограничения платформы ZABBIX.
* Решение для масштабирования хранилища аналитики.
* Оптимизация сервера ZABBIX.
* Оптимизация UI.
* Опыт эксплуатации системы при нагрузках более 40k NVPS.
* Коротко выводы.

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

Что делать, когда минута простоя стоит 100000$

Кузовлев Евгений

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

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

Мастер-класс: диагностические инструменты JVM

Алексей Рагозин

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

Из коробки, Java Developer’s Kit (JDK) включает несколько полезных инструментов. Причины, ведущие к неадекватному поведению Java компонента, могут быть разными: недостаток ресурсов, проблемы в коде, некорректные настройки JVM. В рамках мастер-класса будет продемонстрировано использование этих инструментов для оценки состояния Java процесса и выявления потенциальных проблем. Так же, в рамках мастер-класса, будет, затронут вопрос мониторинга.

Для участия в мастер классе вам потребуется компьютер (Windows, Linux или MacOS) и следующее ПО:
- JDK 8 от Oracle
- Apache Maven 3.4 (или выше)
- git клиент

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

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

Deep Learning с Apache Ignite в качестве источника данных для Tensor Flow

Юрий Бабак

Что делать, когда нужно deep learning, а данных больше, чем может поместиться на одной машине? Чтобы не изобретать велосипед, научили распределенную In-Memory базу данных работать с Tensor Flow.

План доклада:
* Обзор Apache Ignite.
* Ignite Thin Client Dataset for TensorFlow: работа со сложными структурированными данными.
* Apache Ignite как инфраструктура для распределенного обучения на TensorFlow.
* Демо.

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

Tips & Tricks for Fast Neural Net Inference in Production

Дмитрий Коробченко

Сегодня нейронные сети с успехом решают множество задач, демонстрируя более высокое качество по сравнению с классическими алгоритмами машинного обучения. Однако, при использовании нейронных сетей в реальном бизнесе не менее важно, чтобы после внедрения они работали быстро (иногда даже в real-time). В докладе будет рассказано, за счёт чего можно достичь повышения скорости работы нейронных сетей при минимальных или нулевых потерях в качестве.

Зачастую, на этапе моделирования и экспериментирования внимание Data Scientist’ов приковано к повышению качества модели, а оптимальность её работы в промышленном использовании (production) отходит на второй план. В докладе будет дан набор советов о том, как продумать оптимальность еще на ранних стадиях моделирования.

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

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

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

Глеб Альшанский

Все мы наверно слышали, что нейронная сеть AlphaGo, разработанная компанией DeepMind, выиграла у человека в Go. Но DeepMind использовала эти же алгоритмы для управления системами кондизицонирования в датацентрах Google, и в результате снизила затраты электроэнергии на охлаждение датацентров на 40%.

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

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

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

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

Учим машину варить парацетамол

Артем Кондюков

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

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

В рамках доклада хочется разобрать один use case машинного обучения в фармацевтике: построение синтетических путей для получения заданных малых молекул. Львиная доля времени (как человеческого, так и машинного) потрачена на подготовку данных и получение каких-либо инсайтов, а построение моделей — своего рода «десерт». Будет рассказано о проблемах, встречающихся вне классификации пород котиков, и о способах их решения.

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

Аппаратное обеспечение в эпоху Artificial Intelligence (AI)

Владимир Алексеев

Вопросы, которые обсудим в рамках доклада:
* Ликбез: какое "железо" нужно для создания AI?
* Чем "железо для AI" отличается от "обычного": с какими проблемами сталкиваются производители?
* Достаточно ли вставить GPU в рабочую станцию, чтобы стать data scientist 80-го уровня?
* PCI Gen 4: что дальше? Нам нужен новый интерконнект!
* FPGA для исполнения моделей: "все новое - это хорошо забытое старое".

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

купит или нет? нейронные сети против логистической регрессии для предсказания конверсий по истории пользователя

Олег Тишутин

Одна из главных задач в интетрент-рекламе: по истории поведения пользователя на сайте понять, с какой вероятностью он совершит покупку. Какая модель подойдет лучше для таких предсказаний - простая логистическая регрессия или модные нейронные сети?

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

Женские сети: как нейронные сети помогают в индустрии красоты

Артем Просветов

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

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

Результат рекомендательной системы повысил Open Rate регулярных рассылок на 80%, а Conversion Rate почти в два раза. Дополнительным преимуществом нашего решения стала нейронная сеть, кодирующая последовательность поведений получателей рассылки в значимые признаки, которые затем использовались для предсказания вероятности скорой покупки. Рассылкой писем применение предлагаемого подхода не ограничено, закодированное поведение объектов можно использовать в других задачах, требующих работы с поведением человека: поиск мошеннических действий, предсказания оттока, поиск аномалий и т.д.

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

Как нейронные сети графике помогали

Евгений Туманов

Как вы думаете, сколько нужно машино-часов, чтобы нарисовать все спецэффекты в Аватаре? Достоверные данные неизвестны, но, например, на geek.com пишут, что кластеры Weta Digital считали это больше месяца. Можно ли такую задачу отнести к сфере HighLoad? Я думаю, что да.

В графике есть несколько вычислительно трудных задач. Мы поговорим:
- о нескольких из них и об их решениях, конечно (Bird's-eye view);
- об одной конкретной задаче, которую решали мы - как рисовать облака с помощью нейронных сетей.

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

Dbrain: автоматизация ретуши фотографий для KUPIVIP

Артур Кузин

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

В докладе будет рассказано о процессе сбора дата-сета для решения этой задачи. Затем будет краткий обзор лучших решений на примере соревнования Kaggle - Carvana Image Masking Challenge по сегменации изображений. Будет рассказано об адаптации лучших приемов. Также будет рассказано про цветокоррекцию и удаление дефектов.

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

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

Centralized Logging Patterns

Philipp Krenn

Most organizations feel the need to centralize their logs — once you have more than a couple of servers or containers, SSH and tail will not serve you well any more. However, the common question or struggle is how to achieve that.

This talk presents multiple approaches and patterns with their advantages and disadvantages, so you can pick the one that fits your organization best:
* Parse: Take the log files of your applications and extract the relevant pieces of information.
* Send: Add a log appender to send out your events directly without persisting them to a log file.
* Structure: Write your events in a structured file, which you can then centralize.
* Containerize: Keep track of short lived containers and configure their logging correctly.
* Orchestrate: Stay on top of your logs even when services are short lived and dynamically allocated on Kubernetes.

Each pattern has its own demo with the open source Elastic Stack (previously called ELK Stack), so you can easily try out the different approaches in your environment. Though the general patterns are applicable with any centralized logging system.

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

История одного апгрейда протокола взаимодействия.

Александр Боргардт

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

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

Как начать использовать статический анализ в своём проекте?

Сергей Васильев

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

Однако, решив внедрить статический анализ в свой проект, вы наверняка столкнётесь с различными вопросами. Что делать с существующими предупреждениями? Стоит ли исправлять все существующие ошибки? Как контролировать качество проекта? Какова динамика роста / исправления ошибок?

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

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

Серверный Swift - Pros & Cons

Сергей Житинский

Возможность использовать Swift в серверных приложениях под Linux открывает новые возможности не только для iOS/tvOS/watchOS-разработчиков, но и для команд, ищущих повышения производительности своих приложений и повышения производительности процесса разработки.

Swift, как Язык Программирования общего пользования, впитал в себя многие весьма ценные концепции и опыт мирового лидера и флагмана по производству "гаджетов" - компании "Apple".

Уровень качества ПО, который требует Apple для распространения приложений сторонних разработчиков обеспечивается не только строгой системой контроля, но и многоуровневой системой защиты от (дурака - зачеркнуто) ошибок средствами самого языка.

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

Pros & Cons использования Swift на бэкенде будут освещены в этом докладе.

Фреймворки
,
Миграции данных
,
Прочие языки
,
Бэкенд / другое
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Архитектурные паттерны
,
Оптимизация производительности
,
Профилирование
,
Разработка библиотек, включая open source библиотеки
,
Оптимизация популярных CMS
,
Технологии и языки для iOS: ObjectiveC, Swift
,
Бэкенд мобильных приложений
,
Кросплатформенная разработка
Программный комитет ещё не принял решения по этому докладу

Serverless Functions на примере Lambda от Amazon

Алексей Колесников

Современные архитекторы ПО все чаще склоняются к использованию облачных решений. Одним из самых “свежих” и популярных решений является сервис Lambda от Amazon, который позволяет реализовать полезный функционал и не заботиться о поддержке “железа”.

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

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

Building microservices using Kafka

Anugrah S

At GO-JEK, we handle daily order volume that is the largest in the world except for China. The restaurants depend on GO-RESTO, our merchant facing app. As we scaled, the merchant order report generation became slow. This talk is about how we built a microservice using our Kafka pipeline to solve it.

Microservices are the building blocks that power a post-cloud digital landscape. They help us in building services which are scalable and eases the deployment and development process. As scale rises, simple, direct HTTP calls from service to service become bottlenecks, and cascade failures through the system. A distributed, horizontally scalable bus like Kafka becomes essential.

At GO-JEK, we handle 2X of India’s total food tech daily order volume. The restaurants that make the food depend on GO-RESTO, our merchant facing app. As we scaled, GO-RESTO started having slow queries for displaying the complete order report for a merchant in a day. We could not delete the underlying table as the table was used by other queries. We needed to move this data and the query away from the main service to uphold our SLA.

In order to move this data away from the main service, we started to publish the data to Kafka. Using the ESB Generic Log Consumer that was written for streaming data from Kafka to Postgres, we were able to get the data required to the backend database of the new microservice that we were writing. Then we wrote the backend service capable of handling the queries. In the end, we were able to reduce the latencies as well as take out the load on the main service.

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

Разрабатываем свой браузер с нуля. Часть первая: HTML

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

Расскажу, как создать самый быстрый и полноценный HTML-парсер с DOM. А также, чем отличается настоящий HTML-парсер от остальных. Как парсить по 100MB+ HTML в секунду и на выходе иметь правильный DOM (HTML Interfaces, DOM Interfaces).

Разберу тонкие места в HTML-спецификации и расскажу, что мешает создать лучшее решение.
Затрону тему namespace'ов в HTML, и как они влияют на построение HTML-дерева.

Расскажу, зачем создавать собственный браузер/браузерный движок и почему именно на Си.

Браузеры
,
API
,
C/C++
,
Прочие языки
,
Бэкенд / другое
,
Оптимизация производительности
,
Разработка библиотек, включая open source библиотеки
,
Импортозамещение
,
Встраиваемые системы
Доклад принят в программу конференции

Serverless – are you ready for the revolution?

Michał Jankowski

Hi, I would like to share my knowledge and experience about the serverless approach. I would like to show how this approach revolutionised our approach to software architecture and development. I believe that revolution has just begun.

Have you ever think about how out approach for software development will be affected by this trend? During the session, I will try to answer this question. We will start with a short introduction to this idea and then we will try to figure out what should be our approach to software development. I will base my narration on Azure environment and show you how you can compose your solution in a more effective way.

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

Как разрабатывать поддерживаемые приложения: переносимые блоки,контракты взаимодействия, проблемы GoF и иллюзии стоимости

Артем Кудряшов

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

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

Фаззинг или тестирование мусорными данными

Максим Бакиров

Поисковый запрос в 2ГИС содержит 25+ параметров, начиная c введенного текста и заканчивая персональными предпочтениями пользователя. Чтобы обеспечить стабильную работу приложения, мы решили не ограничиваться тестовыми запросами, сгенерированными человеческой логикой. Так в нашей жизни появился фаззинг — тестирование приложения на неправильных, неожиданных или случайных данных.

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

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

Разработка в ненадежной нагруженной среде

Алексей Акулович

Расскажу, как в ВК идет разработка при постоянных отказах и проблемах софта и железа, приправленных соусом высоких нагрузок.

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

Много компромиссов и велосипедов, всё, как мы любим :)

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

Проектирование с использованием Eventstorming и DDD

Евгений Пешков

Я расскажу про Event Storming - отличный способ проектировать, используя Domain Driven Design.

Мы поговорим про DDD и обсудим опыт использования. Попробуем спроектировать систему с использованием Event Storming.

Чем хорош Event Storming?
* Простота: все, что надо - стикеры и несколько метров стены.
* Общение: эксперты присутствуют на встрече и готовы ответить на все вопросы.
* Визуализация: в итоге видно, как устроена система с точки зрения бизнеса.
* Полезность: результаты можно использовать для детализации и планирования.



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

Делаем бэкенд нового поколения на FoundationDB

Олег Илларионов

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

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

На пути к быстрой многопоточной хэш-таблице

Никита Коваль

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

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

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

Golang: специфические вопросы производительности

Даниил Подольский
Кирилл Даншин

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

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

Есть и свои, специфические, иногда весьма специфические способы их решения и обхода.

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

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

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

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

700 дней или три поколения балансировщиков

Алексей Учакин

Кажется, что Load balancers - это просто. Поставил nginx или HAProxy - и полетел.

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

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

История о том, как мы живём с BGP (без) Anycast, почему MTU - это важно, и почему нужно постоянно проверять свою DDoS-защиту.

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

Децентрализованная технология прохода межсетевых экранов

Евгений Сафронов

В 2018 большинство разрабатываемых децентрализованных peer-to-peer-приложений ощущают острую необходимость коммуницировать между собой через Интернет, в то время как истинное расположение обоих пиров остается неизвестным. Если вам посчастливилось отхватить публичный IPv4- или просто глобальный IPv6-адрес, вы - счастливчик. Остальным же нужно искать пути обхода сетевых ограничений провайдеров и их файерволов. В частности, NAT.

Эта проблема давно известна и решена под названием hole-punching… но большинство решений применимо только для UDP.

В СОНМ мы придумали и реализовали технологию, которую можно использовать, чтобы пробивать различные конфигурации NAT'а, получая в итоге настоящее P2P-TCP-соединение через Интернет, даже если оба пира находятся в приватной сети за файерволом. Но чтобы реализовать ее, необходимо понимать, как работают современные сети, как устроены линуксовые ядерные модули контроля соединений, и чем отличаются разные виды NAT, короче, изучить “врага” досконально.

В докладе мы расскажем о том, в чем же истинное различие NAT, какие есть обходные пути, настройки и, попросту говоря, дыры в TCP, которые помогут в решении проблемы установки P2P-соединения, как мы это используем в СОНМ, а также представим готовое решение, которое может быть переиспользовано для ваших нужд.

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

Monitoring: From Duty OPS to SRE

Дмитрий Куприянов

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

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

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

Scale Your Metrics with Elasticsearch

Philipp Krenn

"Only accept features that scale" is one of Elasticsearch's engineering principles. So how do we scale metrics stored in Elasticsearch? And is that even possible on a full-text search engine?

This talk explores:
* How are metrics stored in Elasticsearch and how does this translate to disk use as well as query performance?
* What does an efficient multi-tier architecture look like to balance speed for today's data against density for older metrics?
* How can you compress old data and what does the mathematical model look like for different metrics?

We are trying all of this hands-on during the talk, since this has become much simpler recently.

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

Отказоустойчивость сети. M-LAG

Максим Раевский

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

Я собираюсь рассказать о разных технических (и не очень) вариантах защиты от отказов сети на примере опыта ivi.ru. Расскажу о нашем состоянии в 2017 году, почему мы захотели перемен и что мы в итоге сделали.

Расскажу, почему мы выбрали не "холодильники" и не стеки для нашего ядра. Расскажу о преимуществах и недостатках MLAG в оборудовании Huawei CloudEngine и ExtremeNetworks. А напоследок покажу тизер о наших планах развития сети в этом году.

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

Ansible — «маховик времени» для админов, или как автоматизировать автоматизацию

Виталий Прокофьев

Привет! Я тимлид инженеров Managed Services в Selectel. И я расскажу вам, как мы используем Ansible, и как его магия позволяет нам делать рутинную работу легко и быстро.

— Сравнение Ansible с более популярными инструментами — Chef и Puppet. Почему Ansible оказался для нас самым удобным решением.
— Автоматизация автоматизации — собираем широкий спектр конфигураций из готовых «кирпичиков» в два клика с помощью Jenkins.
— Кастомные конфигурации с минимальным количеством кода.
— «Живые» бэкапы инфраструктуры — не тратим время на обновление после создания сервера.
— Ansible + Terraform — лестница в облака.
— Преимущества Ansible и конкретные результаты. Теперь отдел обслуживает больше клиентов теми же ресурсами — чем больше однотипных задач, тем больше времени можно сэкономить.

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

Блокчейн

Как мы писали dappp-игру на Solidity

Иван Красников

Раскажу о практическом опыте написания крипто-игры (по мотивам crypto kitties), на какие грабли пришлось наступить, какие проблемы решить.

В докладе будут рассмотрены вопросы:
* написание смарт-контракта на Solidity(Ethereum);
* средства разработки и тестирования;
* можно ли все данные хранить в смарт-контракте;
* хостинг приложений;
* особенности разработки под Solidity;
* типичные уязвимости смарт-контрактов;
* обеспечение работоспособности приложения у клиентов, не подключенных к Ethereum;
* миграции смарт-контрактов, совершенные ошибки;
* разбор логов (events) контракта.

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

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

Алексей Бурылов

Я расскажу как можно сделать свою криптовалюту на один миллион транзакций в секунду. Опишу основные подходы к построению таких систем. Расскажу почему не возможно сделать в такую криптовалюту в лоб, и как ее все-таки создать. Опишу решения типовых проблем таких криптовалют. Таких как:
1) На каком процессоре считать миллион цифровых подписей в секунду;
2) Как обеспечить подтверждение транзакции за одну секунду;
3) Где хранить 40 терабайт данных в день.

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

Внимание: Если вы не знаете что такое Merkle tree, если вы затрудняетесь ответить на вопрос что такое распределенный децентрализованный процессинг с аутентификацией по цифровой подписи - то вы не чего не поймете из этого доклада!

Платёжные системы, обработка платежей
,
Оптимизация производительности
,
Распределенные системы
,
Блокчейн-технология
Программный комитет ещё не принял решения по этому докладу
Rambler's Top100