Конференция завершена. Ждем вас на Highload++ в следующий раз!
Москва, СКОЛКОВО
8 и 9 ноября 2018

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы узнаете, как обеспечивается управление сложнейшими объектами автоматизации в мире. В режиме жесткого реального времени обеспечивается работа более 150 специальных подсистем, управляющих различными технологическими процессами АЭС, таких как система управления реактором мощностью выше 1000 МВт и турбиной весом более 2000 тонн. Более 100К источников данных от датчиков и до 500К расчетных параметров. 5 разновидностей физических процессов: нейтронная кинетика, гидродинамика, химия и радиохимия и физика прочности.

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

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

Но мы все же про кодинг. Никаких SSD и HDD, только InMemory, структуры данных из десятков миллионов элементов, забудьте про кэш процессора, он не работает. Ваш новый Xeon 4-го поколения потерял все преимущества и превратился в "тыкву", поэтому закатываем рукава и ковыряемся в таймингах, жесточайшей асинхронике и выжимаем из железа максимум. Кто слабое звено - процессор, память, ОС или сеть. Выясняем это.

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

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

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++

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

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

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

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

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

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

Как быстро разрабатывать программное решение на C++ и Lua, чтобы за это ничего не было

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

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

При этом никто не отменял требования по масштабируемости, отказоустойчивости, времени отклика API-вызовов.

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

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

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

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

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

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

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

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

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

Я расскажу о нашем опыте использования игрового кода на бэкенде и фронтенде. Мы использовали OpenResty с Lua в качестве серверной платформы и Defold, который тоже поддерживает Lua, как 2D-движок.

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

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

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

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

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

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

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

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

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

Лев Екасов

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

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

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

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

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

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

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

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

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

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

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

Архитектура стабильности — как внятность оценки задачи материализует результат

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

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

Объект - логический представитель явления (предмета / сущности) в нашем мышлении. При работе с любым существующим предметом мы удерживаем представление (мыслительную версию) о нем в голове.

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

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

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

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

Зачем CTO кодить и как он может сделать сильную организацию еще сильнее

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

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

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

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

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

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

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

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

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

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

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

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

Фабрика по выпеканию кода или как мы оптимизируем процессы в заказной разработке

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

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

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

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

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

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

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

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

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

В процессе реализации имеющегося решения росла и команда, реализующая это решение. Рост команды требовал изменения процессов и роста культуры внутри команды. Я раскрою тему, как эти процессы взаимосвязаны, и сделаю отсылку к закону Конвея (M. Conway) - "Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации".

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

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

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

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

Что из себя должна представлять функция управления сотрудниками в разработке, когда организация растет, и топ-менеджер рассматривает возможность делегировать функцию HR-профессионалу?

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

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

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

Enterprise-системы

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Павел Довбуш

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

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

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

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

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

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

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

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

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

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

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

Ян Лещинский

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

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

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

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

Филипп Кулин

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

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

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

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

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

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

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

Make passwords great again! Как победить брутфорс и оставить хакеров ни с чем

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

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

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

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

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

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

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;
- проблемы: куки, собственные уникальные "браузеры", прокси.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сергей Журин

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

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

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

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

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

Пётр Зайцев

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

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

Монолит для сотен версий клиентов: как мы пишем и поддерживаем тесты

Владимир Янц

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

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

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

В рамках доклада мы рассмотрим весь арсенал инструментов, доступных разработчику для быстрого и удобного написания тестов:
- SoftMocks/DbMocks/RemoteMocks — наши библиотеки для моков, для чего они нужны и какие проблемы они помогают нам решить;
- пул тестовых пользователей;
- что такое QA API и как мы используем его в тестах;
- как мы считаем и используем code coverage;
- наше облако для запусков тестов, как работает и зачем нужно;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассказ будет про 3 Тбит/сек или Видеостриминг в 4К.

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

В докладе я расскажу про платформу стриминга:
* pipeline видеостриминга в 4К на миллионы онлайн;
* архитектура системы доставки контента;
* тюнинг TCP для раздачи 4K;
* как и зачем нужно отказаться от ffmpeg и нарезка видео на GPU;
* расскажу что делать, если мощности кончились, а пользователи продолжают приходить;
* поговорим о проблемах стриминга на TCP;
* обсудим будущее видео стриминга.

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

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

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

Иван Круглов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:
* Общая архитектура взаимодействия наших серверов.
* Если ли у нас "обычный" PHP, где и почему. А какие еще ЯП используем?
* Как обновить код на десятках тысяч серверов за секунды.
* Отказоустойчивость кластеров мемкэша при постоянно ломающихся серверах.
* Зачем нам свои движки (БД), сколько их, и как мы с ними живем.
* Чем бинлог отличается от снэпшота, и как "откатить DELETE".
* Чем можно все это мониторить.

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

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

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

MVNx-биллинг виртуального оператора Дримсим: архитектура микросервисов, специализированные БД и вопросы консистентности, нагрузочное тестирование.

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

DNS в Facebook

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

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

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

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

Рюрик Крылов

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

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

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

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

В своем докладе мы расскажем, как достичь высокой производительности системы телефонии на базе Asterisk.

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

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

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

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

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

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

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

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

Function as a Service in private cloud

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

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

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

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

Replicated service mesh: hardening systems against failure modes in load balancing, distributed state, lifecycle management, configuration and release pushes

Oleg Klyudt

This talk goes into failure modes observed in practical distributed applications in Google over years, and best practices to prevent or handle them. We consider first typical containerized service mesh (replicated vertical application services stack) and delve into potential failure modes, how to handle them and best practices for:
* L7 load balancing accounting for failures with utilization equalization;
* overload handling, circuit breaking and throttling;
* config, experiment and binary pushes;
* critical data state management & consistency;
* across the stack work conserving;
* replicated application state & cacheability;
* cross stack requests routing;
* dependencies degradation or unavailabiltiy.

Throughout the talk I'll be giving pointer to existing open source tooling and frameworks incorporating the best practices or giving you knobs to get close.

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

Достигаем субмиллисекундного времени отклика в торговой системе на Java под Linux

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

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

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

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

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

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

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

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

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

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

Антон Горин

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

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

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



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

Порекомендую, как стоит двигаться, если вдруг понадобится за пару вечеров сделать аналогичную production-ready систему для своего проекта. И расскажу, когда с ней начнутся проблемы.

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

Плоской или крестовой? Выбираем правильный инструмент для развертывания контейнеризованных приложений в облаке Amazon Web Services

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

На сегодняшний день Amazon Web Services предлагает 125 базовых облачных сервисов. Некоторые из них, на первый взгляд, конкурируют друг с другом. Например, для управления, развертывания и масштабирования приложений на основе контейнеров вы можете выбирать из двух сервисов - Amazon ECS (Elastic Container Service) и Amazon EKS (Elastic Container Service for Kubernetes). Различные режимы использования еще больше запутывают ситуацию.

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

В рамках доклада мы ответим на эти вопросы. Поспорим о достоинствах, недостатках и ограничениях Amazon ECS, Amazon EKS и Amazon Fargate. Рассмотрим интересные варианты реализации.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

«Очки верткальной реальности»: исправляем опечатки в поисковых запросах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Prod, do stack: production-ready-решения через data science-конкурсы

Андрей Киселев

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

Место 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.

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

Так как в далёком будущем планируется миграция приложения с Oracle на PostgreSQL, будет затронута тема встроенной в Posgtress реализации row level security.

Темы, поднятые в докладе, будут интересны не только тем, у кого security реализована в СУБД, но и тем, кто реализовал её уже на сервере приложений, так как в целом подходы и проблемы одинаковы.

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

Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы вашей БД без риска «уронить прод»

Николай Самохвалов

Администрирование баз данных в будущем будет полностью автоматизировано. Это уже так для базовых операций 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-конвейер?

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

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

Иван Раков

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

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

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

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

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

Кирилл Юхин

С выходом версии 2.0 в Tarantool появилась поддержка языка запросов SQL, ориентированная на соответствие спецификации стандарта ANSI.

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

При этом SQL поддерживает работу как с in-memory движком memtx, так и с дисковым vinyl.

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

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

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

MyRocks deep dive and production deployment at Facebook

Yoshinori Matsunobu

Since we created MyRocks -- RocksDB storage engine for MySQL (https://github.com/facebook/mysql-5.6) a few years ago, we added various features like Blind Deletes, TTL, and at Facebook we deployed MyRocks in our two biggest database services in production -- our main database (UDB) and Facebook Messenger. In this session, the speaker will talk about how we migrated from InnoDB and HBase in our production environment, what features were added to make them happen, how they worked, what challenges we faced and how we addressed them.

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

ClickHouse тормозит

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

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

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

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

Построение аналитического хранилища на 100 петабайт

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

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

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

Доклад рассчитан на разработчиков, имеющих базовые знания о Hive и Mesos/Marathon.

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

Базы данных в облаках

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

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

В докладе речь пойдёт о том, как мы сначала построили инфраструктуру Database as a Service для собственных сервисов, а теперь масштабируем для внешних пользователей.

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

Анализ производительности запросов в ClickHouse

Алексей Миловидов

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

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

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

Последние изменения в IO-стеке Linux с точки зрения DBA

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

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

В этом докладе я расскажу о том, что происходит, почему IO-стек нуждается в срочном улучшении, к чему это может привести для баз данных. Как новые драйвера NVMe и blk-mq будут улучшены. В качестве полезной памятки я предложу контрольный список настроек PostgreSQL и Linux, чтобы максимизировать производительность подсистемы ввода-вывода в новых ядрах.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

ClickHouse доступен в open-source уже более двух лет, однако команда разработки Яндекс.Метрики перешла на эту СУБД еще в далеком 2014 году и с тех пор ни разу не пожалела об этом.

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

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

Забиваем телескопом гвозди, или Нестандартные способы использования ClickHouse

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

ClickHouse - open-source DBMS от Яндекса - традиционно используется для аналитики различного рода логов или потоков событий от онлайн-систем. Однако, гибкость ClickHouse позволяет применять его для более широкого класса задач.

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

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

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

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

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

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

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

Hadoop at scale: мы построили большой кластер, как его теперь сохранить?

Сергей Корсаков

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

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

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

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

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

Немного о нашей инфраструктуре:
* сейчас у нас два кластера, состоящие в сумме из более чем 4000 серверов;
* ежедневно наши приложения шлют более 500 миллиардов сообщений в Kafka, которые потом попадают на HDFS. В сумме это более 150 TB данных в день. Всего же в течение дня у нас появляется около 0.5 PB новых данных;
* более 30 команд активно используют нашу инфраструктуру;
* более 300 тысяч MapReduce- и 6 тысяч Spark-джобов запускается на кластере ежедневно.

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

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.

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

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

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

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

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

Руководство по выживанию с MongoDB

Сергей Загурский

MongoDB — это популярное NoSQL-решение для хранения данных. С MongoDB легко стартовать, и многие проблемы имеют решения "из коробки". Однако, по мере увеличения нагрузки вылезают грабли, о которых вас заранее никто не предупреждал... до сегодняшнего дня!

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

VShard - горизонтальное масштабирование в Tarantool

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

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

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

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

API
,
Архитектурные паттерны
,
Распределенные системы
,
Масштабирование с нуля
,
Lua
Доклад принят в программу конференции

Как Tinkoff.ru использует Greenplum

Дмитрий Немчин

Мы - одни из первых в России пользователей Greenplum и:
- написали свою систему репликации данных из Oracle и Postgres;
- каждый день 4к ETL-джобов обрабатывают больше 20 ТБ данных, а храним мы больше 70 ТБ данных;
- около 1000 пользователей ежедневно используют наш кластер, приходя из SAS, Zeppelin и напрямую в БД клиентами;
- свой DR с проверкой бэкапов и задержкой в 2 часа до попадания на бэкапную СХД;
- тонны сломанных копий (тех, которые оружие) и боли администраторов.

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

Apache Kafka как основа для велосипедостроения

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

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

Доклад не столько про нашу базу данных, сколько про то, как можно для данной задачи НЕ реализовывать часть сложнейшей логики, а взять это от Apache Kafka:
* как НЕ делать репликацию своими руками;
* как легко получить шардинг из коробки;
* как обеспечивать/контролировать целостность данных.

Также я поделюсь нашим опытом эксплуатации достаточно нагруженной кафки:
* ~20k produce ops/second;
* ~100k fetch ops/second;
* 1 major upgrade кафки в online;
* 3 переезда между серверами online;
* 2 факапа:)

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

MariaDB и MySQL — какую статистику использует оптимизатор, или Как обойтись без индексов

Сергей Голубчик

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

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

И, конечно, как не нужно использовать индексы, когда достаточно адекватной статистики.

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

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

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

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

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

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

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

Репликация между разными СУБД: для чего мы написали репликатор MySQL-Tarantool

Михаил Буйлов

* Где у нас закончились возможности MySQL.
* Кэширование базы данных в memcache - не такая тривиальная задача, как это выглядит на первый взгляд.
* В чем Tarantool действительно превосходит memcache.
* Подводные камни выноса части MySQL-функционала в Tarantool.

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

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

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

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

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

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




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

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

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

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

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

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

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

Репликация в Tarantool: конфигурация и использование

Георгий Кириченко

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

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

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

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

Топ ошибок со стороны разработки при работе с PostgreSQL

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

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

Я и мои коллеги из Data Egret - PostgreSQL-консалтеры, и мы регулярно наблюдаем как команды разработки осознанно или нет, но допускают ошибки при работе с Постгресом.

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

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

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

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

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

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

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

Мастер-класс "Диагностические инструменты JVM"

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

Для участия в мастер-классе понадобится ноутбук.

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

Java Developer’s Kit (JDK) из коробки включает несколько полезных инструментов. Причины, ведущие к неадекватному поведению Java-компонента, могут быть разными: недостаток ресурсов, проблемы в коде, некорректные настройки JVM. В рамках мастер-класса будет продемонстрировано использование этих инструментов для оценки состояния Java-процесса и выявления потенциальных проблем. Также в рамках мастер-класса будет затронут вопрос мониторинга.

Для участия в мастер-классе вам потребуется компьютер (Windows, Linux или MacOS) и следующее ПО:
- JDK 8 от Oracle;
- Apache Maven 3.4 (или выше);
- git-клиент.

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

Автоматизация замены дисков с помощью Ansible

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

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

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

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

Базы данных и Kubernetes

Дмитрий Столяров

Нам, компании Флант, множество раз задавали вопрос: "Можно ли базу в Kubernetes?".

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

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

Feature Toggles, или Как выкатывать фичи без релиза

Ян Ашенкампф

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

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

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

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

Zabbix, 100kNVPS на одном сервере

Михаил Макуров
Максим Чернецов

* Мониторинг - онлайн и аналитика.
* Основные ограничения платформы ZABBIX.
* Решение для масштабирования хранилища аналитики.
* Оптимизация сервера ZABBIX.
* Оптимизация UI.
* Опыт эксплуатации системы при нагрузках более 40k NVPS.
* Коротко выводы.

Логирование и мониторинг
,
Аппаратное обеспечение
,
Сетевое администрирование
Доклад принят в программу конференции

Лучшие практики нативных облачных сервисов

Елена Граховац

Написать и запустить «Hello, World» — дело нескольких секунд даже для новичка. А что, если «Hello, World» должен быть представлен в виде микросервиса, удовлетворяющего требованиям нативной облачной инфраструктуры? Что это, вообще, за требования такие и откуда они взялись? Разбираемся по порядку.

Доклад рассматривает практические вопросы написания нативных облачных (cloud native) приложений:
— проектирование сервиса и структурирование кода;
— проверка качества кода с помощью тестов и анализаторов;
— управление зависимостями и взаимодействие с внешними ресурсами;
— задание конфигурации и «секретов»;
— контейнеризация;
— наблюдаемость и безопасность: почему это важно;
— непрерывные интеграция и развертывание;
— эксплуатация в рамках системы управления контейнерами.

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

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 сам себя починит.

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

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.

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

Чему мы научились, пока делали собственную систему уведомлений о нештатных ситуациях

Алексей Кирпичников

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

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

Другой пример. Если на диске 90% свободного места — это хорошо. Если 1% — наверное, плохо. А если нет данных? Пожалуй, это хуже, чем если свободного места много. Но лучше ли это, чем если его совсем нет?

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

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

Все решения были выстраданы и опробованы при разработке системы Moira (https://github.com/moira-alert), которая используется в Контуре, Avito и Яндекс.Деньгах.

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

Мониторинг — разработчикам! Технологии — сообществу! Профит — всем!

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

Инженерная команда Авито сегодня — это более 350 специалистов, разделенных на десятки кросс-функциональных команд. У нас более 5 миллионов входящих метрик в минуту и около миллиона бизнес-ивентов в секунду. Как сделать так, чтобы внимательно отслеживать состояние всех наших сервисов, монолита, инфраструктуры, и при этом не нанимать армию DevOps-инженеров?

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

Наш сервис построен на популярных OpenSource-решениях: Graphite, Clickhouse, Prometheus, Moira. Мы активно используем StatsD-агрегаторы и в какой-то момент написали свой, который выложили для общего пользования. Поэтому, прослушав доклад, вы сможете частично или полностью реализовать такое решение у себя.

План доклада:
1. Необходимость в системе мониторинга в виде сервиса.
2. Как мы строили сервис мониторинга.
3. Как на данный момент выглядит схема работы нашего сервиса мониторинга.
4. Какой результат мы сейчас имеем.
5. Проблемы, с которыми мы столкнулись.

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

eBPF для анализа производительности Linux

Пётр Зайцев

eBPF - на сегодняшний момент самый продвинутый интерфейс для инструментации ядра Linux и приложений.

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

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

Как VK вставляет данные в ClickHouse с десятков тысяч серверов

Юрий Насретдинов

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

Основные тезисы:
— Как VK использует ClickHouse (логи / статистика).
— Производительность ClickHouse в наших условиях, конфигурация кластеров.
— Буфер-таблицы.
— Проблемы в эксплуатации.
— kittenhouse: локальный прокси для ClickHouse.
— LightHouse: легкий веб-интерфейс для просмотра содержимого таблиц.
— GreenHouse: интерфейс на основе LightHouse, позволяющий просматривать сразу все кластеры, заведенные в kittenhouse.

C/C++
,
PHP
,
Логирование и мониторинг
,
ETL
,
GO
Доклад принят в программу конференции

Описание инфраструктуры в Terraform на будущее

Антон Бабенко

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

Ваша инфраструктура почти наверняка начинается просто: несколько ресурсов + несколько разработчиков. Со временем она растёт во всевозможные стороны. Вы находите способы сгруппировать ресурсы в Terraform-модули, организовать код по папкам, и что здесь вообще может пойти не так? (известные последние слова)

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

После трёх лет управления на Github коллекцией community-модулей Terraform для AWS и долгосрочном поддержании Terraform в продакшене, я готов поделиться своим опытом: как писать TF-модули, чтобы не было больно в будущем.

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

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

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

From Ansible to SaltStack - как и зачем

Дмитрий Самохвалов

- Расскажу про проблемы, с которыми мы столкнулись при использовании Ansible для раскатки и поддержки инфраструктуры в Альфа-Банке.
- Что показалось интересным в SaltStack, и как мы думали решить возникшие проблемы.
- С чем пришлось столкнуться при внедрении Salt.
- Как мы делали Salt удобным для привыкших к Ansible.
- Наш опыт использования возможностей Salt-api.
- Поделюсь опытом написания модулей для Salt.

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

Что делать, когда минута простоя стоит 100000$

Евгений Кузовлев

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

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

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

Нейронные сети, искусственный интеллект

Как нейронные сети графике помогали

Евгений Туманов

Как вы думаете, сколько нужно машино-часов, чтобы нарисовать все спецэффекты в Аватаре? Достоверные данные неизвестны, но, например, на geek.com пишут, что кластеры Weta Digital считали это больше месяца. Можно ли такую задачу отнести к сфере HighLoad? Я думаю, что да.

В графике есть несколько вычислительно трудных задач. Мы поговорим:
- о нескольких из них и об их решениях, конечно (Bird's-eye view);
- об одной конкретной задаче, которую решали мы - как рисовать облака с помощью нейронных сетей.

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

Женские сети: как нейронные сети помогают в индустрии красоты

Артем Просветов

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

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

Результат рекомендательной системы повысил Open Rate регулярных рассылок на 80%, а Conversion Rate почти в два раза. Дополнительным преимуществом нашего решения стала нейронная сеть, кодирующая последовательность поведений получателей рассылки в значимые признаки, которые затем использовались для предсказания вероятности скорой покупки. Рассылкой писем применение предлагаемого подхода не ограничено, закодированное поведение объектов можно использовать в других задачах, требующих работы с поведением человека: поиск мошеннических действий, предсказания оттока, поиск аномалий и т.д.

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

Учим машину варить парацетамол

Артем Кондюков

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

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

В рамках доклада хочется разобрать один use case машинного обучения в фармацевтике: построение синтетических путей для получения заданных малых молекул. Львиная доля времени (как человеческого, так и машинного) потрачена на подготовку данных и получение каких-либо инсайтов, а построение моделей — своего рода «десерт». Будет рассказано о проблемах, встречающихся вне классификации пород котиков, и о способах их решения.

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

Tips & Tricks for Fast Neural Net Inference in Production

Дмитрий Коробченко

Сегодня нейронные сети с успехом решают множество задач, демонстрируя более высокое качество по сравнению с классическими алгоритмами машинного обучения. Однако, при использовании нейронных сетей в реальном бизнесе не менее важно, чтобы после внедрения они работали быстро (иногда даже в real-time). В докладе будет рассказано, за счёт чего можно достичь повышения скорости работы нейронных сетей при минимальных или нулевых потерях в качестве.

Зачастую на этапе моделирования и экспериментирования внимание Data Scientist’ов приковано к повышению качества модели, а оптимальность её работы в промышленном использовании (production) отходит на второй план. В докладе будет дан набор советов о том, как продумать оптимальность еще на ранних стадиях моделирования.

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

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

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

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.

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

Разрабатываем свой браузер с нуля. Часть первая: HTML

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

Расскажу, как создать самый быстрый и полноценный HTML-парсер с DOM. А также о том, чем отличается настоящий HTML-парсер от остальных. Как парсить по 200MB+ HTML в секунду и на выходе иметь правильный DOM (HTML Interfaces, DOM Interfaces).

Разберу тонкие места в HTML-спецификации и расскажу, что мешает создать лучшее решение. Затрону тему namespace'ов в HTML, и как они влияют на построение HTML-дерева.

Расскажу, зачем создавать собственный браузер/браузерный движок и почему именно на Си.

Браузеры
,
API
,
C/C++
,
Прочие языки
,
Бэкенд / другое
,
Оптимизация производительности
,
Разработка библиотек, включая open source библиотеки
,
Импортозамещение
,
Встраиваемые системы
Доклад принят в программу конференции

Делаем бэкенд нового поколения на FoundationDB

Олег Илларионов

FoundationDB – это sorted key-value СУБД с поддержкой ACID-транзакций.

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

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

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

Golang: специфические вопросы производительности

Noam Tenne
Кирилл Даншин

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

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

Есть и свои, специфические, иногда весьма специфические способы их решения и обхода.

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

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

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

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

Децентрализованная технология прохода межсетевых экранов

Евгений Сафронов

В 2018 большинство разрабатываемых децентрализованных peer-to-peer-приложений ощущают острую необходимость коммуницировать между собой через Интернет, в то время как истинное расположение обоих пиров остается неизвестным. Если вам посчастливилось отхватить публичный IPv4- или просто глобальный IPv6-адрес, вы - счастливчик. Остальным же нужно искать пути обхода сетевых ограничений провайдеров и их файерволов. В частности, NAT.

Эта проблема давно известна и решена под названием hole-punching… но большинство решений применимо только для UDP.

В СОНМ мы придумали и реализовали технологию, которую можно использовать, чтобы пробивать различные конфигурации NAT'а, получая в итоге настоящее P2P-TCP-соединение через Интернет, даже если оба пира находятся в приватной сети за файерволом. Но чтобы реализовать ее, необходимо понимать, как работают современные сети, как устроены линуксовые ядерные модули контроля соединений, и чем отличаются разные виды NAT, короче, изучить “врага” досконально.

В докладе мы расскажем о том, в чем же истинное различие NAT, какие есть обходные пути, настройки и, попросту говоря, дыры в TCP, которые помогут в решении проблемы установки P2P-соединения, как мы это используем в СОНМ, а также представим готовое решение, которое может быть переиспользовано для ваших нужд.

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

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.

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