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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Как мы балансируем нагрузку, и при чём тут 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-системы внутри Alibaba private cloud.
* Расскажем, с какими трудностями сталкиваемся при разработке платформы и как оптимизируем нагрузки.
* Поговорим о том, как предоставить максимально комфортную среду разработчику функций.
* Рассмотрим, почему для своего решения мы выбрали Kotlin и какими фичами языка активно пользуемся.

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом докладе я расскажу о том, как с помощью одной простой команды (oc create -f pxc.yml) можно развернуть целый MySQL-кластер (Percona XtraDB Cluster) из 3-х или более узлов + ProxySQL + мониторинг. Kubernetes & Openshift позволяют оркестрировать docker containers и быстро развертывать приложения.

Я также расскажу о том, что такое Percona XtraDB Cluster и ProxySQL, и как ProxySQL позволяет взаимодействовать с кластером.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-парсер с DOM. А также о том, чем отличается настоящий HTML-парсер от остальных. Как парсить по 200MB+ HTML в секунду и на выходе иметь правильный DOM (HTML Interfaces, DOM Interfaces).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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.