Рейтинг@Mail.ru

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

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

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

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

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

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

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

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

Разделение frontend и backend с сохранением взаимопонимания

Денис Сумбаев
Александр Звозников

Использование монолита из backend+frontend приводит к невозможности развивать продукт требуемыми темпами и часто ведет к жесткой связанности или "перетягиванию одеяла" в разработке. Современный интерфейс часто модифицируется под нужды клиентов, что приводит к постоянным изменениям в структуре отображаемых данных. Это в свою очередь приводит к необходимости менять логику backend'а, хотя структура самих данных чаще всего остается неизменной.

В своей команде мы пробовали разные подходы и технологии: создавали отдельные GraphQL-сервера с независимыми схемами, писали аддоны на C++ для Node.js и организовывали взаимодействие с сервисами на gRPC. Собрав воедино полученный опыт использования C++, TypesSript, GraphQL и gRPC, мы получили архитектуру приложения, позволяющую гибко развивать backend и frontend, продолжая при этом создавать единый программный продукт.

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

Взаимодействие с серверной стороной (API)
,
Node.js и io.js
,
JavaScript
,
API
,
C/C++
,
Асинхронное программирование, реактивное программирование
Программный комитет ещё не принял решения по этому докладу

Разработка под WebAssembly: реальные грабли и примеры

Андрей Нагих

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

Я расскажу вам, какие реальные грабли мы собрали при переносе нашего большого приложения на C++ в браузер.

Мы обсудим:
— какие есть инструменты и что они могут;
— как пробрасывать объекты между JS и Wasm;
— какие при этом возникают проблемы и как их решить;
— что может Wasm, и чего он не может;
— как увидеть код C++ в отладчике браузера;
— на сколько Wasm быстрее JS.

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

Фронтенд-приложения как микросервисы

Владимир Санников

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


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

Если делать enterprise-SPA, все современные фреймворки в дружбе с webpack предоставляют механизм lazy-loading отдельных модулей, но он имеет минус, от которого нам хотелось избавиться. Этот минус - tree-shaking. Необходимость запуска webpack для пересборки всего приложения ради изменения одного модуля не дает нам деплоить, откатывать, включать/выключать модули независимо.

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

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

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

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

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

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

Make passwords great again!

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

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

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

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

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

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

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

Денис Лукаш

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

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

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

(почти) Объективная оценка людей в IT

Георгий Могелашвили

Правильно ли художник кладёт краску на холст? А может ли поэт слагать стихи в два раза быстрее? Достаточно ли эффективно программист пишет код?

Все эти вопросы поднимают одну общую проблему - как оценить деятельность творческих людей? К сожалению, пока ещё никому не удалось дать на это однозначный ответ и предложить универсальное решение. В Booking.com мы придумали и выстроили свои процессы, которые работают для более чем 1500 сотрудников в IT. Мы оцениваем людей не только по тому, что они делали, но и как они это делали, полагаясь на мнение не одного единственного руководителя/тимлида, а множества людей вокруг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нагрузочное тестирование. Динамический профиль нагрузки при тестировании интеграционной шины

Сергей Журин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Internationaliz(s)ation m(p)ain points

Manvel Saroyan

When it comes to the Multilingual websites or project creation, the lack of complete standards for Internationalization(i18n) implementation makes Framework, CMS and/or tools choice not a trivial task. Managing translations might become pain in the ass if you won’t make it right from the beginning.
Avoiding common localization(l10n) issues when developing Multilingual websites will lead into huge growth opportunities for your project, understanding crucial l10n and i18n details, will help you choose the right architecture solution for your project and understand why most of the existing solutions are "not a go" for your project.

My background.
I'm experienced in developing project(s) that does support more than 80 different languages and I’m deeply involved in defining translations management process for that project (which is active on more than 100 million devices), so I'm ready to share with you all the main and pain points of #i18n, #l10n and #a11y.

Шаблонизаторы и препроцессоры
,
Адаптивные дизайн и вёрстка
,
Генераторы статики
,
Node.js и io.js
,
JavaScript
,
Браузеры
,
Accessibility
,
Совместная работа дизайнеров и верстальщиков
,
Фронтенд / другое
,
Фреймворки
,
Бэкенд / другое
,
Архитектурные паттерны
,
Оптимизация популярных CMS
,
Критерии выбора технологий для проекта
,
Архитектуры / другое
,
Выбор стратегии долгосрочного развития, KPI
,
Работа с зарубежным заказчиком/рынком
,
Продуктовая разработка
,
SMM (маркетинг в соцсетях)
,
SEO-оптимизация
,
Юзабилити, дизайн интерфейсов
,
A/B-тестирование
Программный комитет ещё не принял решения по этому докладу

Unveiling Linux Kernel Load Balancing Performance

Laura Garcia Liebana

nftlb is a new load balancer core that uses the nftables infrastructure (iptables successor) to build highly scalable services from the Linux kernel side improving the performance of current load balancers.

The aim of this talk is to explain why nftlb is needed, how it works and show some performance figures comparing to other solutions.

We will explain how the nftlb small footprint design allows to be easily integrated in commodity servers, virtual machines and containers.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DNS в Facebook

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

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

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

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

Nikolay Rodionov

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.

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

Событийная архитектура распределенных систем на базе NServiceBus

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

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

В теории распределенных систем есть несколько типичных ошибок, приводящих в лучшем случае к потере данных, а в худшем - к потере заказов и денег и, как следствие, работы. Чтобы такого не случалось, разработчикам нужно руководство и инструменты, которые уберегут от этих ошибок. К счастью разработчиков на платформе .NET, такой инструмент существует: NServiceBus - “The most developer-friendly service bus for .NET”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

High-availability без потери в производительности

Сергей Пак

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

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

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

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

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

1. Почему мы выбрали Asterisk.
1.1 Asterisk vs Avaya
1.2 Asterisk vs Freeswitch

2. Компоненты системы телефонии колл-центра.
2.1 PDS - система автоматического обзвона
2.2 WebRTC-клиент для приема звонков
2.3 Proxy для сигнализации и голосового трафика

3. Работа с большим количеством звонков и файлов.
3.1 Балансировка телефонных вызовов
3.2 Запись разговоров
3.3 Мониторинг

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

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

CatBoost - градиентный бустинг для больших данных

Анна Вероника Дорогуш

CatBoost - библиотека градиентного бустинга, выложенная в открытый доступ компанией Яндекс. Главные особенности этой библиотеки - она позволяет эффективно работать с категориальными данными, дает повышенную точность за счет методов борьбы с переобучением, реализует возможность быстро считать значения модели для time-critical-сервисов, а также дает возможность обучать модели на больших объемах данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иван Раков

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

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

Нам пришлось научиться:

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

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

Will Postgres Live Forever?

Bruce Momjian

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

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

The cost of MongoDB ACID transactions in theory and practice

Henrik Ingo

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

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

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

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

Document oriented vs relational data modeling

Henrik Ingo

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

This session contains code examples both from MongoDB and PostgreSQL.

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

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

Андрей Бородин

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

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

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

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

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

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

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

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

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

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

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

Как мы ищем по всем атрибутам всех объектов системы или немного Oracle In-Memory

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

Один из наших Заказчиков поставил следующее требование к программному продукту: возможность поиска по любой комбинации атрибутов объектов всей системы в едином интерфейсе. Когда мы спросили о скорости, ответ был не менее прост: "Как у Amazon". Задачу усложняло то, что одновременно с данным функционалом работает не менее 1000 пользователей, а другие части приложения не менее 5000 раз в секунду запрашивают данный функционал через REST API.

Очевидным решением для данного функционала является faceted search.

Наше приложение реализовано с использованием СУБД Oracle, и мы решили использовать встроенные возможности, чтобы минимизировать доработку кода на стороне сервера приложений.

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

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

Продолжая тренд OpenSource, я расскажу, что вышло бы по скорости и объему изменений, если бы мы использовали в качестве СУБД Tarantool и Apache Ignite.

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

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

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

Из-за того, что у нашего сервиса мониторинга (okmeter.io) достаточно специфичные требования к timeseries базе данных, мы обречены разрабатывать/поддерживать собственное решение. Мы постоянно совершенcтвуем наше хранилище, иногда значительно ее переписывая.

В докладе я расскажу о текущей версии нашего хранилища метрик, которое использует Apache Kafka в качестве WAL (write ahead log) и многоуровневое хранение данных (in-memory для свежих данных, cassandra для архивных). При этом часть задачи по обеспечению высокой доступности и консистентности мы возложили именно на кафку, сильно упростив при этом наше приложение.

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

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

Концепция логического хранилища данных

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

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

Речь в докладе пойдет о том, что к системе больших данных предьявляются достаточно жесткие, часто конкурирующие требования. Удовлетворить их все на существующем техническом уровне сложно, и получается монолит - медленно развивающийся, сложный в поддержке. Логическое хранилище данных предполагает три части - поддерживающее SQL основное хранилище (ядро монолита) + допускающие микросервисный подход озера данных (на document store базах) и Agile ODS (быстро разрабатываемые и работающие витрины на in-memory/виртуализируемых базах). В таком виде это будет быстро развиваться и покрывать самые разнообразные хотелки продуктовых команд, что бы они ни захотели - 50ms-отставание, real time-аналитику по живым данным, сложные Machine Learning-алгоритмы, огромные объемы и/или недопустимость потери ни единой копейки. Даже, если эти хотелки противоречат друг другу.

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

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

Andy Pavlo

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

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

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

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

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

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

PostgreSQL
,
Администрирование баз данных
,
MySQL (MariaDB, Percona Server)
,
ETL
Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

Основы мониторинга баз данных

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

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

В этом докладе на примере СУБД PostgreSQL (при этом не погружаясь в её дебри) я расскажу о ключевых моментах мониторинга БД, и почему они должны присутствовать в мониторинге; о том, какие графики должны быть в мониторинге и как их интерпретировать. Я постараюсь раскрыть такие темы связанные с мониторингом, как доступность и общее состояние базы, взаимодействие с клиентами, характер нагрузки и многое другое.

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

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

Advanced generalized search

Андрей Бородин

Я работаю над усовершенствованием обобщённых поисковых деревьев (Generalized index Search Trees - GiST), сделал несколько патчей и работаю над тем, чтобы они были приняты в upstream. Но для демонстрации функциональных возможностей решил сделать fork GiST в виде расширения "Advanced generalized search" [0]. Создаваемый индекс полностью совместим с GiST, вы можете передать функции вашего типа данных GiST в опкласс AGS и он будет работать. Но для новых фич, таких как массовая загрузка и многокортежный индекс, потребуется писать дополнительные функции опкласса. Обсуждение происходит тут [1]

[0] https://github.com/x4m/ags
[1] https://lists.osgeo.org/pipermail/postgis-devel/2018-July/027260.html

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

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

Александр Рубин

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

Типичный пример - запрос с join, group by, order by. Типичное решение - создать индексы. Однако не все так просто - в некоторых случаях MySQL не использует индекс или использует не тот индекс, который нам бы хотелось. Чтобы разобраться с такими случаями и понять, что происходит, мы будем использовать новые возможности MySQL 5.7 и 8.0 - optimizer trace, performance_schema (новые таблицы) и другие возможности.

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

MongoDB
,
MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

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

Terraform best practices with examples and arguments

Anton Babenko

This talk is for the developers who want to learn best practices in using Terraform at companies and projects of various size (from small to very large), get pros&cons on code structuring, composition. Also, attendees will be able to learn Terraform (and Terragrunt) tricks and gotchas.

It is easy to get started with Terraform to manage infrastructure as code. Just read the documentation on terraform.io, and you are done. Almost.

The harder part begins when infrastructure grows in all directions (several AWS/GCP accounts, regions, teams, projects, environments, external integrations). One of the most frequent questions is "how to structure code".

In this talk, I will explain many of challenges related to that, what works, what does not work, why so, and most importantly I will show all the code which works from small projects to very-large infrastructures (featuring multi-cloud and multi-region setup).

This talk is best suitable for people who have been using Terraform at least for some time and already have practical questions.

All the code and solutions presented at the workshop will be open-sourced.

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

DevOps: важность статических анализаторов кода

Андрей Карпов

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

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

Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency

Henning Jacobs

Kubernetes has the concept of resource requests and limits. Pods get scheduled on the nodes based on their requests and optionally limited in how much of the resource they can consume. Understanding and optimizing resource requests/limits is crucial both for reducing resource "slack" and ensuring application performance/low-latency. This talk shows our approach to monitoring and optimizing Kubernetes resources for 80+ clusters to achieve cost-efficiency and reducing impact for latency-critical applications. All shown tools are Open Source and can be applied to most Kubernetes deployments.

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

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

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

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

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

C/C++
,
PHP
,
Логирование и мониторинг
,
ETL
,
GO
Программный комитет ещё не принял решения по этому докладу

DevOps-трансформация Альфа-Банка

Антон Исанин

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

В своём докладе я хочу рассказать, как DevOps повлиял на показатели работы Альфа-Банка. Почему мы стремимся к надёжности выкатки, но при этом не теряем в скорости.

Что реально изменилось в компании в процессе развития DevOps и почему. Как мы организовали работу продуктовых команд. Какие метрики измеряются и зачем их измерять, ведь "продуктовые команды могут сами всё решить наилучшим образом, зачем какие-то метрики ?") .

Что такое методика 3-Amigo, какие плюсы мы реально видим от формирования "триад" в командах. Как мы пишем спецификации, как ведём разработку, тестируем и выкатываем в промышленную эксплуатацию.

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

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

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

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

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

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

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

Деплой в VM, Nomad и Kubernetes: опыт Lamoda

Павел Агалецкий

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

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

Сервисы-сироты: обратная сторона (микро)сервисной архитектуры

Андрей Никольский

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

Как распознать сироту? Как они получаются? Чем грозит присутствие сирот в инфраструктуре?
Можно ли этого избежать? И как - с примерами из 6-летнего жизненного цикла сервисной архитектуры Банки.ру.

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

Доставляем в Kubernetes. Непрерывно и по-своему

Евгений Дехтярёв

Два года назад нам не хватило готового решения для доставки приложений в Kubernetes, и мы придумали собственное. Взглянем на историю развития PaaS в 2ГИС, сравнив его со стандартным путём доставки приложений и инфраструктуры на бой. Вспомним, каким был Helm в конце 2016 года. И в итоге увидим, зачем нам понадобился свой способ доставки в Kubernetes.

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

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

Особенности реализации доступа по протоколу iSCSI к СХД Ceph

Алексей Костин

В случае, если у вас имеется СХД ceph, и ваши клиенты не поддерживают rbd (например, клиент - это windows или vmware), вам приходится искать решения, какими еще способами можно отдать устройство клиенту и обеспечить отказоустойчивость этого решения.

Я расскажу, какие варианты решения проблемы есть, и какие существуют ограничения, расскажу, что такое tcmu-runner и почему его стоит использовать. Рассмотрю решение ceph-iscsi и сравню его с решением компании SUSE. Объясню, почему может потребоваться передавать Persistent Reservation через rbd-устройство, где это может понадобиться, в каком случае лучше подождать с внедрением этих технологий.

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

TeamCity на высоких оборотах. Опыт Tinkoff.ru

Артем Шепелев

Как справляться с повышенной нагрузкой на сервер? Как организовать релизный цикл билд-агентов? Как сделать provisioning билд-агентов без потери кэшей билд-тулов?

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

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

Deploying MySQL on Kubernetes & Openshift

Александр Рубин

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

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

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

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

Terraform modules inside out

Anton Babenko

Terraform module is the smallest reusable component of an infrastructure. Getting started to use modules is easy, but keep them in a good shape and make them really powerful is harder.

Your infrastructure almost always starts simply: few resources managed by few developers. As time goes it grows in all possible directions. You found your ways around grouping resources into Terraform modules, so what can possibly go wrong? (famous last words)

During the talk, I will explain several unknown, hard to find and rather green-field solutions related to Terraform modules. More specifically:
- Types of modules (resource and infrastructure modules, compositions)
- How to specify dependencies between modules
- Workflow for various types of modules

More advanced topics like:
- Refactoring, upgrades, rollbacks (without recreation of the resources)
- Poor-man modules manager
- What are the limitations of the current implementation of Terraform modules and workarounds (eg, jsonnet, cookiecutter, terrapin)

I will demonstrate and run the code which handles advanced problems based terraform-aws-modules from the Terraform Registry and explain why hundreds of developers are using those modules already (btw, they were downloaded 1 million of times already).

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

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

Аппаратное обеспечение в эпоху Artificial Intelligence (AI)

Владимир Алексеев

Вопросы, которые обсудим в рамках доклада:
* Ликбез: какое "железо" нужно для создания AI?
* Чем "железо для AI" отличается от "обычного": с какими проблемами сталкиваются производители?
* Достаточно ли вставить GPU в рабочую станцию, чтобы стать data scientist 80-го уровня?
* PCI Gen 4: что дальше? Нам нужен новый интерконнект!
* FPGA для исполнения моделей: "все новое - это хорошо забытое старое".

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

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

Артем

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

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

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

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

Deep Learning с Apache Ignite в качестве источника данных для Tensor Flow

Юрий Бабак

Что делать, когда нужно deep learning, а данных больше, чем может поместиться на одной машине? Чтобы не изобретать велосипед, научили распределенную In-Memory базу данных работать с Tensor Flow.

План доклада:

Обзор Apache Ignite
Ignite Thin Client Dataset for TensorFlow: работа со сложными структурированными данными
Apache Ignite как инфраструктура для распределенного обучения на TensorFlow
Демо

Java
,
Python
,
Распределенные системы
,
Machine Learning
,
ETL
Программный комитет ещё не принял решения по этому докладу

Dbrain: автоматизация ретуши фотографий для KUPIVIP

Артур Кузин

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

В докладе будет рассказано о процессе сбора датасета для решения этой задачи. Затем будет краткий обзор лучших решений на примере соревнования Kaggle - Carvana Image Masking Challenge по сегменации изображений. Будет рассказано об адаптации лучших приемов. Также будет рассказано про цветокоррекцию и удаление дефектов.

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

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

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

Артем Кудряшов

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

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

Фаззинг или тестирование мусорными данными

Максим Бакиров

Поисковый запрос в 2ГИС содержит 25+ параметров, начиная c введенного текста и заканчивая персональными предпочтениями пользователя. Чтобы обеспечить стабильную работу приложения, мы решили не ограничиваться тестовыми запросами, сгенерированными человеческой логикой. Так в нашей жизни появился фаззинг — тестирование приложения на неправильных, неожиданных или случайных данных.

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

C/C++
,
Поисковые системы
,
Бэкенд / другое
,
Отказоустойчивость
,
Оптимизация производительности
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Профилирование и отладка кода
,
Big Data и Highload в Enterprise
Программный комитет ещё не принял решения по этому докладу

Разработка в ненадежной нагруженной среде

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

Расскажу, как в ВК идет разработка при постоянных отказах и проблемах софта и железа, приправленных соусом высоких нагрузок.

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

Много компромиссов и велосипедов, всё, как мы любим :)

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

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

Даниил Подольский
Кирилл Даншин

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

Например, о проблемах производительности.

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

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

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

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

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

На пути к быстрой многопоточной хэш-таблице

Никита Коваль

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

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

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

Serverless Functions на примере Lambda от Amazon

Алексей Колесников

Современные архитекторы ПО все чаще склоняются к использованию облачных решений. Одним из самых “свежих” и популярных решений является сервис Lambda от Amazon, который позволяет реализовать полезный функционал и не заботиться о поддержке “железа”.

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

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

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

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

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

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

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

Отказоустойчивость сети. M-LAG

Максим Раевский

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

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

Расскажу, почему мы выбрали не "холодильники" и не стеки для нашего ядра. Расскажу о преимуществах и недостатках MLAG в оборудовании Huawei CloudEngine и ExtremeNetworks. А напоследок покажу тизер о наших планах развития сети в этом году.

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

Блокчейн

Как мы писали dappp-игру на Solidity

Иван Красников

Раскажу о практическом опыте написания крипто-игры (по мотивам crypto kitties), на какие грабли пришлось наступить, какие проблемы решить.

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

Организация системы кеширования
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Архитектурные паттерны
,
Распределенные системы
,
Разделение представления и бизнес-логики, шаблонизация
,
Архитектура данных, потоки данных, версионирование
,
Смарт-контракты
Программный комитет ещё не принял решения по этому докладу
Rambler's Top100