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

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

С++

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

За основу мы взяли mbed TLS, которую мы практически полностью переписали, чтобы сделать в 40 раз быстрее. В разработке мы также заимствуем части кода WolfSSL — более быстрой, чем OpenSSL-реализации. WolfSSL использует алгоритмы, аналогичные OpenSSL, которым уже более 5-7 лет. Мы обнаружили, что недавно появились более эффективные алгоритмы, которые мы реализуем в Tempesta TLS.

Работа по оптимизации производительности Tempesta TLS все еще не закончена, но Tempesta TLS уже устанавливает на 40-80% больше TLS-соединений, чем OpenSSL/Nginx, и в некоторых тестах дает до 4 раз меньшее время задержки.

В докладе будут рассмотрены:
* базовые принципы эллиптических кривых и основные "горячие точки";
* возможные side channel attacks (SCA) и методы защиты от них;
* новые и быстрые алгоритмы, используемые в эллиптических кривых;
* альтернативные решения, принимаемые разработчиками OpenSSL, WolfSSL, mbed TLS и Tempesta TLS.

А еще будет много бенчмарков и забавного кода, который на C выглядит сложнее, чем на ассемблере.

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

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

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

Рассказ же будет о том, как нам с этим всем жить.

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

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

Расскажу об основных методах балансировки трафика и о том, как это можно сделать «бесплатно» (почти, с точки зрения закупки оборудования и существующих ресурсов) на основе nftables.

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

Производительность мобильных приложений

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

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

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

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

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

Базы данных и Stateful Apps активно мигрируют в Kubernetes, неся с собой уникальные Persistent Data, требующие персонального отношения, тем самым возрождая дискуссии на тему "pets vs cattle".

Оказывается, что Persistent Data — это именно pets, но никак не cattle!

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

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

Сколько доменов у вас в оперировании? 50? 100? 1000?
А сколько записей в каждом?
А как часто вам приходится их менять?
Устали? Тогда проходите и присаживайтесь, я расскажу вам, как перестать уставать :)

В докладе пойдет речь об автоматизации рутинной работы с DNS-записями, начиная от автоматических релизов и заканчивая выписыванием Let's Encrypt-сертификатов для всех наших доменов без участия человека.

Исходных кодов не будет, к сожалению.

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

Расскажу об успешном внедрении bleeding edge технологии автоматического мониторинга на основе Prometheus Operator.
Prometheus Operator – это "практически" коробочное решение, позволяющее покрыть большинство потребностей Experienced DevOps/SRE аудитории.
Позволяет исключить bottleneck в виде отдела Operationals, автоматизировать рутину мониторинга и уменьшить time to market бизнесовых метрик.
Вы узнаете о возможности автоматического выкатывания метрик без участия админов.
И если раньше от действия вас удерживал скепсис относительно большого пласта работ, то с новыми знаниями вы сможете практически безболезненно внедрить решение у себя.
Что будет внутри? Разберем детали
конструктивных особенностей современного инструментария мониторинга
архитектуры решения, покрывающего все необходимые требования к мониторингу, которые выдвигают пользователи современных кластерных платформ
конфигурирования и деплоймента оператора при помощи Ansible / Helm
мониторинга инфраструктуры вне K8S
ci/cd практики для алертов и дашбордов
P.S. Взлеты и падения в продакшене и подводные камни – все, как вы любите

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

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

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

Мы также рассмотрим возможность использования eBPF для постоянного мониторинга производительности в Kubernetes и рассмотрим ограничения eBPF для такого применения.

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

В докладе мы поговорим про то, из чего состоит latency между вашими юзерами и сервером и пройдемся по каждому пункту (DNS, TCP, TLS, HTTP) в поисках современных проколов, позволяющих ускорить Time to first byte (TTFB).

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

Когда речь заходит об автоматизации, особенно сетевой, очень быстро встаёт проблема с "Source Of Truth" — источником достоверных сведений. Когда-то давным-давно, когда даже термина NetDevOps ещё не было, а скрипты на php и expect уже были, источником правды мог выступать, например, биллинг провайдера — и все железки настраивались на основе данных из него.

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

Сейчас, когда слова NetOps, NetDevOps и прочий network automation у всех на слуху, возникает потребность в достоверном источнике данных о сети, её топологии, сущностях как никогда сильна. Но часто такую систему путают то с CMDB, то с Asset Management, то ещё с чем-нибудь.

Давайте разбираться (с)

Поговорим, зачем нам вообще сетевая автоматизация и какие шаги нужно пройти на пути к Network as a Code и при чём тут Source of Truth.

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

Рассказ о том, как дать кому-то кнопку деплоя в production.

Два года назад мы перенесли первое приложение в только что поднятый с нуля кластер kubernetes и запустили в него клиентский трафик. Kubernetes решил множество проблем и принёс ворох новых. После первых попыток микросервисы передаются в эксплуатацию десятками. Чтобы отдел эксплуатации перестал быть узким местом, мы изменили наши процессы с помощью GitOps-оператора от компании Weaveworks.

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

Вам будет интересно это узнать, если:
- вы хотите, чтобы NoOps стал реальностью в вашей компании;
- kubernetes дал возможность деплоить микросервисы десятками, а вы к этому оказались не готовы;
- на одного ops приходится 30+ dev;
- у вас много команд разработки и они используют разные инструменты CI/CD;
- вы только начинаете осваивать k8s, а глаза разбегаются от количества инструментов;
- вы считаете, что in git we trust.

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

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

В своем докладе я поделюсь с вами полезными знаниями об использовании статического анализа в проектах с открытым исходным кодом. Для лучшей демонстрации я дополню свой доклад практическими примерами, предоставленными разработчиками проекта ClickHouse – СУБД с открытым исходным кодом от компании Яндекс.

Мой доклад дополнит Алексей Миловидов — руководитель группы разработки ClickHouse. Он расскажет о впечатлениях своей команды об использовании статического анализатора PVS-Studio в течение полутора лет.

Вы услышите:
* полезные советы: как правильно использовать статический анализ, если над вашим проектом работает open-source-сообщество;
* практические примеры: как разработчики ClickHouse интегрировали PVS-Studio в свой проект;
* результаты применения: примеры реальных ошибок, найденных в ClickHouse при помощи статического анализа.

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

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

В рамках моего доклада я расскажу:

- Что делать, если во время Rolling Update проскакивают кратковременные 500-ые ошибки?
- Как бороться с человеческим фактором, когда одна неправильная буква или цифра в манифесте может привести к аварии?
- Как админам обновлять версию кластера или ядра ОС прямо в середине рабочего дня, не зацепив продакшн?

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

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

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

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

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

Бизнес нашей компании заключается в приеме и обработке платежей во множестве стран в режиме 365/24/7.
Одной из ключевых целей для нас является доступность наших сервисов 99,999%.
К CI/CD в таких условиях предъявляются особые требования.

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

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

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

Опять боль и страдания!!! Внедряя NoOps в большой компании я услышал много разного от простых эмоций:
- Да вы теперь просто операторы приватного облака…!
- У нас кончилось админстово в компании!!!
- А что я теперь и в мидлваре должен разбираться...

До вполне интересных вопросов:
- Оптимизацией СУБД кто теперь занимается?
- Кто отвечает за бэкап?
- А кто теперь отвечает за инциденты?

Есть безусловно полезные вещи которые очень трудно оспорить, например автоматизация запросов на обслуживание(любые действия имеющие обкатанный скрипт исполнения) где вы интегрируете свою инфраструктуру с роботами и нет больше лагов и ошибок при исполнение. Все "энтерпрайз вахтёры" (политики и регламенты безопасности) тоже эффективно автоматизируются и самое прикольное тут, что никто вам даже спасибо не скажет, все привыкнут к хорошему через неделю даже не вспомнят что может быть по другому. Самое тонкое место это передача компетенций, как быть Томом Сойером, а не "вертухаем" заставляющим делать «чужую» работу. Все это мы прошли, причём в серьезном масштабе 500 дев на 10 опс.
По классике жанра, мы собрали все возможные "грабли", где то пошлось пойти на компромиссы ибо любая концепция требует обработки напильником под себя, что бы максимально решать свои задачи. У нас есть все и NoOps и DevOps и просто Ops. Хочу рассказать про свой опыт погони за хайпом!

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

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

We’ve been building software/hardware systems in a centralized manner for decades, no matter whether they were mainframes with thin clients, clients+server, or web 2.0 — there was always a central place of data storage and execution control. However, time changes and the new uprising trend is all about systems with no central point of control. Blockchain was the first solution, which most programmers still don’t understand. There will be many more solutions in the future, which some of us are yet to design and build.

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

Аппаратное обеспечение, инфраструктура

1. HPC оборудование в десть раз производительней обычного
2. HPC среда в разы, а иногда в десятки раз, проще обычного Enterprise/Highload
3. Как писать приложения в HPC стиле
4. Техники для трансформации обычного/highload приложения в HPC
5. Пример трансформированного приложения, ставшего в 83 раза производительней

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

Архитектура процессора Эльбрус 2000 существенно отличается от практически всех известных нам процессоров. Близок к нему, пожалуй, только Интеловсий Итаниум, но он, по сути, является последователем Эльбруса и в известной степени реализует наработки СССР.

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

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

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

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

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

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

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

Мы 10 лет занимались софтом для видеостриминга и увидели возможность спроектировать и разработать программно-аппаратный комплекс для транскодирования. Т.е. железо+софт.

Что нас подвигло на это? Насколько страшно влезть в такую разработку? Обязательно ли надо минимизировать стоимость железа до последней копейки? Можно ли ввязываться в такой проект, если стартовая партия меньше миллиона экземпляров?

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

Как проектировать материнку в расчете на автоматизацию тестирования?

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

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

Альтернативное решение — собрать собственный сервер из доступного железа и применить подход eXpress Data Path (XDP), который позволит извлекать и анализировать именно те данные, что нужны именно вам и при этом удерживать близкий к нулю дроп-рейт на скорости 40-100Gbps.

В ходе доклада про XDP:
- коснемся нескольких случаев применимости подобного анализа (а вот и не DDoS-детект, хотя он тоже возможен);
- расскажу, что получилось реализовать (и что еще хотели), используя концепт XDP, какие трудности сопряжены с концептом и настройкой операционной системы;
- рассмотрим варианты использования карт от Intel и Mellanox, а также коснемся вариантов и целесообразности применения карт от Napatech.

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

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

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

Хранилище данных (DWH) – фундамент любой data-driven кампании, источник обработанных данных для аналитиков и платформа для расчета метрик и показателей, вместилище накопленной информации по всем источникам внутри компании. Но что, если одним из источников данных будет само DWH – та информация, которая создается в процессе работы пользователей с хранилищем? На базе этой простой и даже очевидной идеи можно реализовать огромный пласт интересных и практически полезных решений.
В своем условно разбитом на три части докладе я покажу, как в Я.Такси покрыли работу пользователей (более 500, DAU 200) с данными (2Пт в YT и 0.5Пт в GP в пределе) в DWH и какую практическую пользу мы из этого извлекли.
В первой части кратко расскажу про хранилище Я.Такси – архитектурно классическое во многих смыслах – и заострю внимание на некоторых его особенностях, например, специфике детального слоя или нашем инструментарии.
Затем перейду к реализации metaDWH как еще одного набора процессов внутри DWH и покажу, что это легко реализуется в любом хранилище.
В основной части доклада рассмотрю практические реализованные нами примеры применения metaDWH:
- создание систему метрик и отчетности по использованию DWH;
- постановка и отслеживание KPI продуктовым командам DWH;
- оценка качество доменов данных по разнообразным критериям;
- оптимизация хранение данных в детальном слое;
- и многое другое.

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

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

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

В рассказе буду опираться на свой опыт, а я прокачивался по ветке разработчика пройдя за 15 лет путь от junior'а до роли CTO в одном из больших управлений в Tinkoff.

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

1. Контрибуция, Разработка и Армяне: что означает жить в комьюнити
2. Почему важно учавствовать в жизни комьюнити
3. Как с помощью комьюнити решать сложные задачи на примере большой загадки "Цикада 3301"
4. Опыт использования комьюнити внутри компании

Привет Highload!

Меня зовут Айк, я представляю компанию WiseBits которая базируется в прекрасном городе Лимассол.

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

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

Увидимся с вами на Highload++ 2020!

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

Блокчейн

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

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

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

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

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

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

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

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

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

Hyperledger Fabric is an enterprise-grade permissioned distributed ledger platform that offers modularity for a broad set of industry use cases. One modular component is a pluggable ordering service that establishes consensus on the order of transactions and batches them into blocks. However, there is still no production-grade Byzantine Fault-Tolerant (BFT) ordering service for Fabric, with the latest version (v2.1) supporting only Crash Fault-Tolerance (CFT). This presentation will discuss crucial aspects of BFT integration into Fabric that were left unsolved in all prior works, making them unfit for production use.

Moreover, the presentation will describe the design and implementation of a BFT ordering service for Fabric, employing a new BFT consensus library. The new library, based on the BFT-Smart protocol and written in Go, is tailored to the blockchain use-case, yet is general enough to cater to a wide variety of other uses. We evaluate the new BFT ordering service by comparing it with the currently supported Raft-based CFT ordering service in Hyperledger Fabric.

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

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

В докладе расскажем про эволюцию разработки высоконагруженного сетевого кластера отправки пуш-уведомлений с использованием технологий от unix/bash и PHP до асихнронных неблокируемых многопоточных соединений на базе Rust/Tokio. Поговорим о тонкостях разработки на Rust, особенностях языка, подводных камнях и способах его быстрого изучения и использования веб-разработчиками с навыками LAMP. Поговорим также о Go, Java и причинах принятых технологических решений.

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

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

А рассказать хочется про совершенно другие структуры данных.

Существует несколько СД, которые немного сложнее и интереснее вектора; вполне себе практически применимы; но при этом в среднем (среднем!) скорее неизвестны. Heaps, tries, B-trees/LSMs, Bloom filters, CountMin + HyperLogLog, KLL + T-digest. А ещё для как бы стандартных СД существуют всякие интересные реализации или техники. И тоже вполне практически применимые. Judy arrays, parallel_hashmap, google/btree, facebook/rocksdb.

Вот про эти прикладные эзотерические СД и/или реализации и хочется хотя бы обзорно рассказать. Что в природе ещё есть. Какие (нечастые, зато интересные) задачи может помочь решать и с какими ходовыми характеристиками. И если времени (уже в коридоре) хватит, как хотя бы в очень общих чертах чего устроено внутри.

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

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

Единственное, что остается в таких случаях — это анализировать текст сообщения.

В своем докладе я расскажу про то, как мы исследовали миллионы спам-писем и разработали систему под названием Spam Term Generator. Эта технология объединила в себе использование CTPH (Context Triggered Piecewise Hashing), DBSCAN (Density-Based Spatial Clustering of Applications with Noise) и LCS (Longest Common Substring) алгоритм для того, чтобы автоматически определять похожие спам-письма и извлекать из них кусочки повторяющегося текста, которые могут быть использованы для детектирования спам-рассылок.

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

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

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

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

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

Прямая работа с диском при файловом I/O — не самая дешевая операция и современные ОС применяют различные оптимизации, такие как кэширование и readahead, чтобы уменьшить ее влияние на производительность. В некоторых случаях обращений к диску можно почти полностью избежать, читая большую часть данных из кэша.

В докладе мы рассмотрим методы оптимизации I/O в JVM и копирования памяти в ядре Linux и как это позволяет увеличить пропускную способность передачи данных на 20%.

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

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

Наш доклад будет наполнен знаниями, поработав над которыми в практике, вы начнёте писать более эффективный код, просто потому что так привыкли. Тут не будет какой-то преждевременной оптимизации а-ля "пишите for(var x = length; x > 0; x -= 4) вместо прямого цикла i++". Мы поговорим о том, чем можно пользоваться ежедневно и не задумываясь: обсудим алгоритмы работы с памятью в .NET: от кучи до стека и поговорим, так ли страшны кучи и как правильно (и в каких случаях) мигрировать в стек: ref structs, Стримы и прочие нововведения платформы, до которых у многих либо не "дошли руки", либо просто не было практики использования, а оттого — и полного понимания, "когда и как".

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

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

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

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

В этой статье мы предлагаем новый подход для оценки схожести входных данных с использованием предварительно обученной нейронной сети. В отличие от предыдущего подхода, который использует градиент для сравнения объектов, мы используем только выходные значения из последнего скрытого слоя нейронной сети и не используем градиент для векторизации ввода. Предлагаемая методика явно учитывает исходную задачу и значительно сокращает размер векторного представления, а также время вычислений. Ключевым моментом является минимизация потерь информации между слоями. Как правило, нейронная сеть отбрасывает информацию, не связанную с проблемой, что делает представление последнего скрытого слоя бесполезным для задачи анализа входных данных. В этой работе мы рассмотрим две основные причины потери информации: корреляция между нейронами и недостаточный размер последнего скрытого слоя. Чтобы уменьшить корреляцию между нейронами, мы используем ортогональную инициализацию для каждого слоя и модифицируем функцию потерь, чтобы обеспечить ортогональность матриц весов во время обучения. Кроме того, мы показываем, что функции активации могут потенциально способствовать корреляции. Чтобы решить эту проблему, мы применяем модифицированную Батч-нормализацию с дропаутом. Использование ортогональных матриц весов позволяет нам рассматривать такие нейронные сети как применение метода случайной проекции и получать оценку нижней границы для размера последнего скрытого слоя. Мы проводим эксперименты с набором данных MNIST. Сначала мы обучаем нейронную сеть определять, является ли число нечетным или четным, а затем используем эту сеть для измерения сходства между входными изображениями. Наши экспериментальные результаты показывают, что предлагаемый подход достигает сравнительных результатов в задаче анализа входных данных при одновременном сокращении как времени вычислений, так и размера входного представления.

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

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

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

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

Задачи Natural Language Processing в последнее время становятся локомотивом исследований всего глубокого обучения в целом. Это неизбежно порождает внимание ML-сообщества и разумную долю хайпа вокруг новых моделей. И мы в антиспаме Почты Mail.ru тоже не остаемся в стороне и радостно предвкушаем адаптацию SOTA-достижений.

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

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

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

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

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

Мы в ОК построили процесс, в котором
- все параметры обучения, зависимости и артефакты фиксируются в git
- модели обучаются автоматически в контролируемом окружении
- модели проходят ревью и попадают в мастер
- из мастера улетают в прод

В докладе на примерах реальных задач:
- Подробнее расскажу о процессе и используемых инструментах
- Как организовали версионируемое хранилище датасетов
- Проследим путь модельки от поставленной задачи в JIRA до прода и обратно
- Поговорим о том, как организовали автоматическое переобучение(не теряя воспроизводимости и возможности отката)

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

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

Презентация - https://docs.google.com/presentation/d/1amBu57gzR4z7vqfHUXB_umTpH9hPycQcg3_glON91EI/edit?usp=sharing

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

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

• Зачем Data в ритейле, и где Леруа Мерлен нашёл свой особый путь (Cloud native, Open Source, API First, Scalable by default, Fault tolerance)?
• Не весь Open Source одинаково полезен. Карго культ в опенсорсе
• Мета-принципы для даты в Леруа Мерлен: Cloud native, Open Source, API First, Scalable by default, Fault tolerance.
• Как и зачем доносить мета-принципы до линейных сотрудников?
• Технологии и подходы к эволюции технологий.
• Из чего состоит наша платформа и как она строится? Как мы работаем с клиентами в ее построении - Customer Development.
• Таймлайн совершенствования платформы.
• Как мерить эффективность? Деньгами? Нет – довольными клиентами!
• Как уравновесить хотелки клиента и базовые мета-принципы?
• Fail fast Fail cheap подход

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

Год назад мы выбирали open-source платформу машинного обучения для заказчика, чтобы их специалисты (а так же специалисты IBM) могли вести коллаборационную работу в совместных data science проектах.
В докладе будет рассказано про основные решения, которые были рассмотрены нами в качестве кандидатов, их минусы и плюсы. Перечислены основные выученные уроки, подводные камни и функциональные требования, выведенные нами к ходе работы над данным проектом.

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

Опыт создания одного из самых успешных BigData сервисов Microsoft, который начинался с небольшой команды разработки специализированного Data solution для сервиса телеметрии и аналитики логов. Отталкиваясь от нескольких нестандартных идей, объединяющих технологии column stores, search engines и классических реляционных баз данных, мы сделали платформу BigData, которая сейчас не только используется многими продуктовыми командами в Azure, но и представляет собой самостоятельный продукт, который успешно продвигается на рынке. В рамках сессии от создателей Azure Data Explorer, будет представлен опыт разработки и лучшие практики взаимодействия в командах, которые сделали Kusto полноценной платформой Big Data с поддержкой AI/ML не только для Log Analytics, но и в областях IoT, BI, Security, Time Series, Finance и Gaming

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

• Зачем Data в ритейле и где Леруа Мерлен нашёл свой особый путь (Cloud native, Open Source, API First, Scalable by default, Fault tolerance)?
• Как поставить прививку принятия решения на основе данных?
• Как развивать в компании second opinion подход, основанный на машинном обучении и AI?
• Как сделать это безубыточно и прибыльно?
• Как не создать иерархическую централизованную культуру? Как сделать это всё децентрализованно?
• Как выбирать гипотезы, и с чего начинать? Как мы разрабатывали гипотезы первого и второго года. В чём отличия?
• Data-Driven компания через пять лет – сколько стоит, сколько принесёт?
• Построение платформы через решение болей клиента. Эволюционное построение платформы и культуры
• Data, как катализатор доменной структуры. Data-днк во все подразделения компании.
• Win-win ситуация для сотрудников.
• Заменяем push на pool в data.

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

Мы реализуем продукт, который позволяет преобразовать пользовательскую историю web-браузера в n-значный числовой вектор (embedding). Для преобразования неструктурированной информации о пользователе в векторный вид используется совокупность методов и моделей машинного обучения.

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

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

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

Автоматизация и алгоритмизация — один из векторов развития Delivery Club. Мы стремимся минимизировать ручной труд, сократить субъективное принятие решений и максимально опираться на данные в построении процессов.

Умение правильно работать с геоданными является одним из ключевых факторов для создания качественного сервиса. «Алгоритмические зоны доставки ресторанов» — один из проектов, который позволил выйти нам на новый уровень автоматизации, прозрачности и скорости.

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

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

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

В отведенные 45 минут обсудим:
- отличия концепции ETL и ELT на примере нашего стека технологий;
- базовые концепции инструмента для преобразования данных DBT;
- как мы используем DBT для построения сложных моделей, а также осуществляем тестирование данных;
- как масштабируется такое решение.

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

Такси, Еда и Лавка - компания с устойчивой Data Driven культурой, где все решения анализируются и проверяются с оглядкой на данные, а скрипт на Python или SQL может написать любой. Мы начали строить централизованное Хранилище Данных (Data Warehouse, DWH) в Такси порядка 4-х лет назад. Год назад провели масштабный ребрендинг и стали себя гордо именовать DMP, Data Managment Platform. На текущий момент у нас порядка 5 сотен бизнес-пользователей, пара сотен продвинутых потребителей данных - аналитиков, data scientist'ов и бекенд разработчиков из смежных команд. Объем Data Lake на YT (in-house аналог Hadoop, https://habr.com/ru/company/yandex/blog/311104/) более 1ПБ и ежемесячный прирост по 100ТБ. Целевое эффективное пространство в DWH на Greenplum 0.5ПБ. Каждый день в нашей инфраструктуре запускается сотни тысяч ETL процессов. Мы поддерживаем ETL на MapReduce, Spark, 3-х диалектах SQL и голом Python. Мы выстроили свои процессы и инфраструктуру таким образом, что к нам могут контрибьютить аналитики данных и бекенд разработчики.

В своем докладе я расскажу:

1. Немного деталей про DMP в Яндекс.Такси, Еде и Лавке: какие данные хранятся в Data Lake и в каком формате, какие слои и потоки данных есть в DWH: как мы несем данные от десятков различных источников до дашбордов в Tableau и OLAP кубов в MS SSAS.
2. Почему мы решили вместо готового ETL инструмента написать свой, и как он работает с такими вычислительными системами, как Spark, Greenplum, ClickHouse и YT.
3. Как устроена наша монорепа из ETL сервисов и процесс разработки, отладки и деплоя.
4. Технические подробности: запуск ETL процессов в 2-х дата центрах, организация тяжелых потоков данных между большими хранилищами, мониторинг наших процессов, проверки качества данных и многое другое.
5. Про взаимодействие между дата инженерами и бекенд-разработчиками и аналитиками данных на уровне кода.

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

Many powerful Machine Learning algorithms are based on existing graphs and text retrieval algorithms, e.g., Page Rank (Pregel), Recommendation Engines (collaborative filtering), text summarization and other NLP tasks.
There are even more applications once we consider data pre-processing and feature engineering which are both vital tasks in Machine Learning Pipelines.

But how can we combine Databases with Machine Learning Systems such as TensorFlow or Pytorch? How do Databases fit in more complex Machine Learning Pipelines such as TensorFlow Extended (TFX)? How can we scale Graph-based Machine Learning to the data sizes typically involved in Machine Learning?

Using real-world examples we show how Multi-Model Databases and Machine Learning System (supporting Graph and Search natively) form a very powerful combination. In particular, we will focus on graph-based Machine Learning models and graph-based data pre-processing and feature engineering (which can, in turn, serve as input for a deep neural network).

In this talk you learn about:
* How graphs and text retrieval can help us to model complex Machine Learning tasks in practice.
* How to leverage Databases for graph-based Machine Learning Models.
* How to leverage graphs and search for data pre-processing and feature engineering.
* How Databases integrate into existing Machine Learning Pipelines such as TensorFlow Extended.

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

В Delivery Club есть много задач, которые успешно решаются при помощи алгоритмов машинного обучения (например, планирование количества курьеров, которых мы выводим на смены). Эти алгоритмы используются в off-line режиме.

Однако есть целый класс задач, для которых требуется наличие в production-инфраструктуре сервисов, способных отдавать предсказания ML-моделей в режиме on-line.

Мы расскажем, как создавали в Delivery Club первые сервисы, использующие под капотом ML-модели, как мы обеспечиваем безопасность деплоя таких сервисов и как оцениваем качество их работы.

Обсудим следующие темы:

1. Особенности ML-сервисов в сравнении с обычными микросервисами;
2. Построение инфраструктуры для обучения ML-моделей в production;
3. Особенности деплоя и тестирования ML-приложений;
4. Как организовать процесс совместной работы Data Science и ML-инженеров.

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

Несколько лет назад в одном из крупных мобильных операторов переживали рост в части аналитики данных. В компании внедрялись BigData технологии и мы переводили ETL-процессы в хранилище DWH на коробочное решение от Informatica. Изначально у нас были классические ETL-процессы в хранилище DWH на Oracle c ночной загрузкой из источников с помощью настроенных db-link-ов и Oracle Loader.
Объем данных - 10-30 Гб/день. После этого мы начали внедрять большое хранилище с МРР архитектурой размером 150ТБ. А в качестве архитектурного решения для ETL-процессов купили инструмент репликации данных Golden Gate(GG) и Informatica Power Center( IPC ). И настраивали отказоустойчивую систему интеграции данных (High Availability)


В этом докладе хочу поделится:
- причинами внедрения Golde Gate и его преимущества
--специфика промежуточного(STAGE) слоя при загрузке в DWH
- преимущества и недостатки ручных и коробочных ETL решений (на примере Informatica Power Center)
- реальные кейсы ETL процессов загрузки "больших" объемов данных в хранилища. И примеры масштабирования загрузок на IPC.
- с какими сложностями столкнулись при переходе на GG и IPC
- технической архитектурой решения отказоустойчивой системы для IPC.
- архитектура движения потоков данных dataflow от источников к хранилищам
- сформированная методология разработки, отладки и деплоя на IPC и добавления новых источников в Golden Gate

Цель доклада:
--рассказать основные преимущества и недостатки разных ETL-решений и частично помочь зрителю с выбором инструмента интеграции данных.
--Дать представление зрителю с какими вопросами придется столкнутся при переходе на решение IPC
--Показать примеры реальных кейсов загрузки "больших" объемов
--Показать текущий процесс движения потоков данных в хранилище

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

Apache Airflow широко используется для оркестрации ETL data-пайплайнов.
Давайте более детально взглянем на Airflow с точки зрения разработки и эксплуатации: какие особенности помогут избежать проблем, а какие могут потенциально привести к отказу работы распределенных систем.

Кроме того, обсудим:
- Какие есть альтернативы и почему именно Airflow?
- Как выглядит типичный Airflow pipeline и какую функциональность предоставляет?
- С какими трудностями предстоит столкнуться при разработке?
- Можно ли иметь гибкую оркестрацию as a code, с тестами, CI/CD и документацией?
- Способы мониторинга и восстановления после отказов.
- Как можно упростить процесс поддержки кода?
- Интеграция с облачными сервисами и внешними системами: стоит ли пробовать?

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

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

Я расскажу о своём опыте прикручивания Spark к проприетарному хранилищу Яндекса YT. На примерах покажу, с какими трудностями пришлось столкнуться, какие есть тонкости и подводные камни. Расскажу, как написать свой коннектор: просто и быстро, или сложнее, но более эффективный. Я объясню внутреннее устройство Spark'а в этой области, обращая внимание на неочевидное поведение и места для расширения.

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

В этой презентации мы представим DeepQuarantine, облачную технологию для обнаружения и карантина потенциальных спам сообщений. Спам атаки становятся все более разнообразными и могут нанести существенный вред пользователям электронной почты. Стандартные методы борьбы со спамом основаны на создании сигнатур, которые описывают уже известный спам, например, пойманный в специальные ловушки. В большинстве случаев такой подход позволяет обнаружить и описать атаку быстрее, чем она дойдет до клиентов. Однако, иногда это условие не выполняется и часть нежелательных сообщений может дойти до пользователей. Для того чтобы выиграть время для обнаружения спама в ловушках, мы создали решение, которое определяет подозрительные письма и откладывает их в карантин на некоторый срок для повторной проверки. Благодаря высокой точности классификатора большая часть почты, помещенной на карантин, является спамом, что позволяет клиентам использовать электронную почту без задержки. Наше решение основано на применении сверточных нейронных сетей на заголовках MIME для извлечения нетривиальных признаков из большого объема исторических данных. Мы оценили предложенный метод на реальных коллекциях и показали, что решение снижает False-Negative на 30%.

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

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

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

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

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

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

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

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

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

В этом докладе я расскажу о методике online-оценки ёмкости сервиса и планирования ресурсов, применяемой в Яндекс.Маркете.

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

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

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

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

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

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

Мы покажем только интересное о том, как:
1. смоделировать большую распределенную сеть на одном узле?
2. подключить внешние сервисы?
3. смотреть за сообщениями в протоколе?
4. интерактивно динамически мучить сервисы и сеть;
5. описать процесс в виде воспроизводимого теста (из кода).

Вся эта магия средствами ПО с открытым исходным кодом. С автоматизацией процесса за 300 строк или меньше!

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

Нагрузочное тестирование в играх - обширная и в то же время мало изученная тема.
Цель доклада - поделиться опытом создания собственного инструмента на основе Vert.x и Kotlin coroutines для нагрузочного тестирования бэкенда мобильных игр студии IT Territory.

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

Не тормозить -- основное продуктовое качество ClickHouse, которое возникает как результат целостной работы по многим направлениям: подходящих архитектурных решений, алгоритмической оптимизации, и небольшого количества связующей магии. За последний месяц в основную ветку ClickHouse добавилось 650 самостоятельных изменений -- всевозможные улучшения, новая функциональность, исправления багов. Как при такой скорости разработки не потерять достигнутого? Ответ известен: автоматические тесты. Любое важное продуктовое качество необходимо тестировать, чтобы не потерять его в постоянном потоке изменений. Это верно и для производительности. Я расскажу, как мы тестируем производительность каждого коммита в ClickHouse. К тестам есть три основных требования: тест должен измерять правильную величину, результат должен быть воспроизводим, и тест должен давать достаточно информации, чтобы его можно было интерпретировать, и исправить или улучшить результат. Мы обсудим, как эти требования реализуются на практике: какие данные и запросы используем для тестирования, как строим эксперимент и обрабатываем результаты, и как используем встроенные в ClickHouse инструменты интроспекции, такие как профайлер запросов.

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

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

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

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

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

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

Есть нагруженная SQL-база данных известного вендора, есть потребность: получать изменения из этой базы в realtime, желательно, не переписывая все сервисы, которые пишут в эту базу данные, и отправлять их дальше. Расскажем, как мы сделали Change Data Capture из Oracle, какие способы опробовали, какие грабли собрали и как их обошли.

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

Мы сделали change data capture и стриминг событий из Oracle в витрины на Tarantool с использованием GoldenGate и Tarantool. У нас получилось довольно простое и производительное решение, которое встало в существующую архитектуру.

Расскажем:
- что такое и зачем нужен change data capture;
- варианты встраивания в существующую архитектуру;
- как мы делали загрузку и репликацию данных из Oracle в Tarantool;
- про грабли и как мы их побороли.

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

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

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

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

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

Реляционные СУБД нанесли очередной удар NoSQL — это стандартизация работы с JSON на языке SQL, что открывает богатые возможности для разработчиков приложений. Я расскажу про то, что уже реализовано в постгресе, что ожидается в ближайшем релизе и каким мы видим будущее JSON.

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

Обзор подходов к версионированию данных, сравнение достоинств и недостатков. Примеры реализации на Tarantool, погружение в детали работы данной СУБД (транзакции, vinyl, триггеры)

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

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

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

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

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

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

Несмотря на то, что подсистема ввода-вывода PostgreSQL, вполне хорошо подходит для большинства решаемых задач, но все-таки она имеет несколько особенностей и проблем:

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

- пропускная способность ввода-вывода, особенно в быстрых подсистемах хранения (например, в NVMe дисках), недостаточно высока для использования на все 100%

- бэкэнды сами выполняют слишком много операций ввода-вывода, так как фоновый писатель(bgwriter) работает не очень оптимально

- генерируется ненужная случайный запись данных (bgwriter, backends)

- двойная буферизация между страничным кешем ОС и общими буферами(shared_buffers) памяти Postgres

- все операции на чтение данных являются синхронными (из страничного кеша ОС)

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

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

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

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

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

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

При использовании бекапов пользователь всегда надеется на 2 вещи: из бекапа можно гарантированно восстановиться, восстановление будет быстрым.
В данном докладе мы расскажем о том, с какими проблемами сталкивались в Яндексе, когда эти надежды не оправдывались, и как, благодаря этим проблемам, мы придумали и реализовали решения, позволяющие создавать с помощью WAL-G более надежные бекапы и восстанавливать их еще быстрее.

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

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

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

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

Правильное взаимодействие с распределенной системой не тривиальное занятие. Выучи наизусть что такое retry, ratelimit, throttling, circuit breaker до начала шардирования

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

Каждый владелец большой базы данных, разработчик и DBA должен понимать возможности по модификации структуры базы данных. В мире MySQL уже есть несколько технологий, которые помогают справиться с этой проблемой: online DDL, pt-online-schema-change, gh-ost, JSON поля. Репликация и синхронные кластеры (InnoDB Cluster, Galera) позволяют работать с отличиями в схемах на узлах и обновлять кластер постепенно узел за узлом. Презентация позволит детально понимать ограничения каждого из методов и научит не убивать боевую базу дурацким ALTER TABLE.

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

Вы когда-нибудь задумывались о том, чтобы сделать свою собственную SQL-базу данных? Или о том, чтобы запускать SQL-запросы в вашей NoSQL-базе данных? Это кажется очень непростой задачей: нужно научиться парсить, оптимизировать и исполнять пользовательские запросы. А если мы говорим о распределенной базе данных, то сложность задачи многократно возрастает. К счастью, благодаря фреймворку с открытым кодом под названием Apache Calcite, вы сможете сделать это довольно легко.

В докладе я расскажу об опыте интеграции Apache Calcite в распределенную in-memory-платформу Apache Ignite. Покажу примеры кода и поделюсь универсальным планом интеграции SQL на основе Apache Calcite в любую другую систему.

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

Один из самых простых и популярных способов «устроить highload на ровном месте» — это написать пару необдуманных строк, изменяющих схему БД, и выложить это в «прод» без обстоятельного тестирования.

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

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

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

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

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

Хранилище LINSTOR построено на свободных технологиях: ZFS, LVM, DRBD и ориентрировнно на максимальную производительность и высокую доступность данных.

В данном докладе я расскажу про наш опыт его использования в Kubernetes, Proxmox и OpenNebula:

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

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

GitLab.com has an aggressive SLA, that made us research and development for solutions to improve our performance in all the directions, on one of the most important components in our architecture, the PostgreSQL relational database.
During this talk, we would like to invite you to explore the details about how we improve the performance of the main PostgreSQL relational database of GitLab.com in a high demanding environment with a load between 40k to 60k transactions per sec.

We would share with you our projects, processes and tools, and all the components that we have developed with our partner Postgres.ai, which makes possible deep analysis in several aspects from our database ecosystem.

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

К конференции уже будет окончательно определено, какие фичи попадут в состав 13-й версии PostgreSQL. Мы обсудим те из них, которые повышают производительность СУБД и помогают создавать устойчивые к высоким нагрузками архитектуры систем.

Будут затронуты вопросы: вакуума, секционирования таблиц, настроек и другие.
Самое интересное будет снабжено практическими примерами и иллюстрациями.

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

Мы разрабатываем Badoo и Bumble — дейтинг-приложения для миллионов пользователей по всему миру. Для анализа такой нагрузки мы создали инструмент поиска аномалий на графиках.

Основная цель Anomaly Detection — зафиксировать аномалии в поведении метрик и сообщить об этом ответственным за них сотрудникам.

В этом докладе я буду делать упор на технологии, которые мы использовали: Clickhouse, алгоритмы предсказаний и процесс портирования этих алгоритмов на SQL. Такой стек позволяет нам процессить миллионы графиков в сжатые сроки.

Я расскажу:
Что такое аномалии, основные термины
Как мы выбирали стек технологий;
Как работают алгоритмы предсказаний;
Выбор доверительного интервала
Выбор лучшей модели
Последующий анализ аномалий

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

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

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

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

Okko — один из самых больших легальных онлайн-кинотеатров в России. В нашем каталоге представлено 60 000 фильмов, мультфильмов и сериалов. С момента запуска сервис посетили более 20 млн пользователей. Ежемесячная аудитория составляет 2,8 млн человек Все эти цифры говорят о надежном высоконагруженном сервисе.
В своем докладе я, как DBA, буду говорить преимущественно о базах данных (PostgreSQL, Cassandra, Redis), которые используются в компании. Подробно рассмотрим темы высоких нагрузок, мониторинга, оптимизации, резервного копирования и восстановления.

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

Tarantool - это база данных и сервер приложений. В данном случае мы будем рассматривать Tarantool именно как базу данных, а в частности движок для хранения данных в оперативной памяти - memtx. Tarantool - open source проект: исходный код находятся в открытом доступе, что открывает большие возможности для изучения того, как организованы базы данных, а также дает возможность для написания своих решений и их последующего встраивания.
Рассказ пойдет о попытке написать свою структуру данных для поиска (Z-order curve) и её встраивании в существующую экосистему Tarantool.

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

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

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

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

Мы рассмотрим модель типа "матрешка", в которой используется Kubernetes для управления кластерами СУБД в публичных облаках (AWS, GCP), и какие дополнительные штуки нужны, чтобы сделать СУБД "дружественной" к облакам. Возможности всех трех уровней -- публичного облака, Kubernetes и СУБД -- должны быть согласованы друг с другом для надежной работы облачного сервиса. В принципе это работает, но напоминает то ли "прокрустово ложе" из греческой мифологии, то ли "испанский сапог" из Средних веков. Мы обсудим, что требуется от СУБД, чтобы она чувствовала себя удобно и комфортно в Облаке. Это включает в себя разделение вычисления и хранения, интеграция с сетевыми системами хранения, другая модель репликации и и.д. Ну и в конце немного помечтаем о будущих бессерверных (serverless) СУБД.

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

Опыт реализации выборов лидера на основе протокола RAFT

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

При внедрении протокола RAFT в Tarantool мы столкнулись с несколькими трудностями, связанными в основном с особенностями существующей архитектуры репликации и журналирования в нашей СУБД:
Tarantool поддерживает master-master репликацию, что отражено в структуре журнала WAL (Write Ahead Log). Вместо монотонно возрастающего id, каждый инстанс поддерживает “векторные часы”, которые нужно будет сравнивать на этапе выборов в RAFT.
В момент бутстрапа кластера нельзя провести выборы, поскольку начальную конфигурацию выполняет один инстанс, выбранный без использования RAFT, а RAFT запускается только после начальной конфигурации.
Необходимо вживить системные сообщения RAFT в протокол общения между инстансами, который до сих пор поддерживал только пересылку данных и возврат ошибок.

Рассказ пойдёт о преодолении этих трудностей и трюках, которые мы применили чтобы подружить Tarantool и RAFT.

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

Мы в Badoo уже довольно долго и успешно используем Kafka. И для нас она — не только брокер сообщений.

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

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

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

Indexes are a basic feature of relational databases, and PostgreSQL offers a rich collection of options to developers and designers. To take advantage of these fully, users need to understand the basic concept of indexes, to be able to compare the different index types and how they apply to different application scenarios. Only then can you make an informed decision about your database index strategy and design. One thing is for sure: not all indexes are appropriate for all circumstances, and using a ‘wrong’ index can have the opposite effect to that you intend and problems might only surface once in production. Armed with more advanced knowledge, you can avoid this worst-case scenario!

We’ll take a look at how to use pg_stat_statment to find opportunities for adding indexes to your database. We’ll take a look at when to add an index, and when adding an index is unlikely to result in a good solution. So should you add an index to every column? Come and discover why this strategy is rarely recommended as we take a deep dive into PostgreSQL indexing.

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

PostgreSQL is one of the leading open-source databases. Out of the box, the default PostgreSQL configuration is not tuned for any workload. Thus, any system with the least resources can run it. PostgreSQL does not give optimum performance on high permanence machines because it is not using all available resources. PostgreSQL provides a system where you can tune your database according to your workload and machine specifications. In addition to PostgreSQL, we can also tune our Linux box so that the database load can work optimally. In this webinar on High-Performance PostgreSQL, Tuning, and Optimization, we will learn how to tune PostgreSQL and we'll see the results of that tuning. We will also touch on tuning some Linux kernel parameters.

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

Актуальность анализа исторической нагрузки СУБД трудно переоценить - это и нагрузочное тестирование, и расследование деградации производительности, и поиск перспективных мест для оптимизации.
Расширение pg_profile - простой и удобный модуль, предназначенный для поиска проблем производительности и оценки исторической нагрузки на СУБД PostgreSQL. Модуль написан на pl/pgsql, легко устанавливается и для своей работы не требует установки или настройки другого программного обеспечения.
В докладе опишу принципы и особенности работы модуля, его новые возможности и перспективы развития, неожиданные метрики в отчете, возникшие в результате расследований некоторых инцидентов. Расскажу о расширенных статистиках производительности, разрабатываемых нашей командой PostgresPro и о том какие дополнительные возможности такие статистики предоставляют модулю pg_profile.

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

Tarantool - изначально персистентная noSQL СУБД в памяти с хранимыми процедурами на языке Lua, впоследствии обросшая SQLем, дисковыми движком, хранимыми процедурами на Си и множеством модулей (на lua), получив гордое название “База данных и сервер приложений”.
Если говорить только об СУБД в памяти, то Tarantool с давних времен поддерживал выполнение транзакций, однако с некоторыми ограничениями. Поскольку Tarantool использует ровно один вычислительный поток для работы с данными, создавая на каждый запрос персональный файбер (зеленый поток в среде с кооперативной многозадачностью), в нем возможно выполнять транзакцию буквально атомарно. Хранимой процедуре, выполняющей транзакцию, запрещено передавать управление до фиксации транзакции, поэтому никакая другая транзакция не может вмешаться в ход событий.
Такой подход имеет очевидное преимущество: он очень простой и быстрый. Нет необходимости блокировать данные и следить за конфликтами. Однако есть и недостатки. Во-первых такой подход работает только в хранимых процедурах (ну или для транзакций всего с одним выражением), об интерактивных и распределенных транзакциях сразу можно забыть. Во-вторых, есть короткий промежуток времени после того как транзакция была уже зафиксирована пользователем, стала видна прочим читателями, но еще не была записана в журнал. Такое поведение является сериализуемым с точки зрения уровня изоляции транзакций пока журнал транзакций работает безотказно; однако первый же сбой журнала и откат транзакции по этой причине могут привести к грязному чтению.
Осознавая эти недостатки, особенно их губительность для синхронной репликации и шард-кластера, мы поставили перед собой амбициозную цель: создание менеджера транзакций, который позволит передавать управление из выполняющейся транзакции, начинать и фиксировать другие транзакции и затем корректно возвращать управление обратно.
Такой менеджер должен обеспечивать различную видимость для различных транзакций (MVCC) и контролировать возникновение конфликтных ситуаций при выполнении различных транзакций. При этом очень хочется, чтобы он был достаточно быстрой хотя бы для случая, когда конфликта транзакций не происходит.
Этот доклад об этом новом менеджере транзакций Tarantool.

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

Мы долго и разными способами выстраивали процесс очистки, предобработки и сохранения больших данных для работы аналитической службы, пока не открыли для себя эффективный, ясный и недорогой стек технологий в Amazon Web Services, удобный в разных сценариях. В начале расскажем о наших интенсивных экспериментах с ClickHouse/PowerBI/MySQL, плюсах и минусах подхода. Затем поговорим, как мы начали хранить сырые данные в Amazon S3 и почему их предобработка в формат Apache Parquet с разумным шардированием так кардинально повлияла на возможности аналитиков и других подразделений компании и так сильно удешивила работу с bigdata. Остановится на типах сжатия больших данных и тонкостях их многопоточной обработки и сделаем правильные выводы. Расскажем, почему нам так нравится предобработка и фильтрация данных в Amazon Glue (на базе Apache Spark) и почему мы так активно используем Amazon Athena (на базе Presto) в связке с аналогом Apache Hive для SQL-выборок из нашего Data Lake в s3. Технологий для работы с большими данными немало, но выбрать эффективный и лаконичный, быстрый и недорогой стек - непростая задача, но, как мы считаем, у нас получилось и мы с удовольствием поделимся опытом!

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

В этом докладе пойдет речь о малоизвестной утилите под названием cluster-copier, которая включена в стандартную поставку ClickHouse.

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

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

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

Мы написали плагин для Postgres, который перехватывает dml пользователя, логирует его действия, проверяет dml на предмет несанкционированных действий, реализует стратегию авто отката.

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

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

PostgreSQL is one of the leading open-source databases. Out of the box, the default PostgreSQL configuration is not tuned for any particular workload. The default configuration is designed in such a way that PostgreSQL can run on any system using minimum resources. Consequently, a default installation of PostgreSQL does not give optimum performance on the high-performance machine because it is set up to use all available resources.

PostgreSQL provides mechanisms that allow you to tune your database according to your workload and machine specification. Outside of PostgreSQL, though, we can tune the Linux kernel to allow the database load to work optimally. In this talk, we will learn how to tune some of the PostgreSQL’s parameters, and we will see the effect of that tuning, but we will focus on demonstrating how to tune Linux for better Postgres performance. As there are so many Linux kernel parameters that can be tuned to improve the performance of PostgreSQL, I will also share the results of benchmarks obtained when tuning some of the Linux parameters.

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

PostgreSQL provides a way to communicate with external data sources. This could be another PostgreSQL instance or any other database. The other database might be a relational database such as Clickhouse, MySQL, or Oracle; or any NoSQL database such as MongoDB or Hadoop. To achieve this, PostgreSQL implements ISO Standard call SQL-MED in the form of Foreign Data Wrappers (FDW). This presentation will explain in detail how PostgreSQL FDWs work. It will include a detailed explanation of simple features and will introduce more advanced features that were added in recent versions of PostgreSQL. Examples of these would be to show how aggregate-pushdown and join-pushdown work in PostgreSQL.

The talk will include working examples of these advanced features and demonstrating their use with different databases. These examples show how data from different database flavors can be used by PostgreSQL, including those from heterogeneous relational databases, and showing NoSQL joins.

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

Running databases in Kubernetes attracts a lot of attention today. Orсhestration of MySQL on Kubernetes is no way a straightforward process. There are several good MySQL based solutions in the open-source world, made by Oracle, Presslabs, and Percona. Having a common base, they differ in self-healing capabilities, consistency guarantees, storage capabilities, monitoring, proxying and backup / restore support, etc. So, let’s make a fair comparison to figure out the pros and cons of their current state.

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

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

Но если главный узел выполнил транзакцию, успешно ответил клиенту, и не успел отправить транзакцию на реплики до своего отказа, то после переключения на резервную реплику с точки зрения клиента транзакция потеряна. Была и пропала.

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

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

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

* Не предполагается наличие мастер-мастер репликации ни в каком виде;
* Журнал транзакций (WAL, Write Ahead Log) должен удовлетворять определенным свойствам.

Это сильно усложняет внедрение Raft в существующую БД, без поломок обратной совместимости в журнале, и без запрета мастер-мастер репликации.

Именно эта задача появилась в СУБД Тарантул. Годами продолжались попытки реализовать чистый Raft или что угодно на его замену. Задача нетривиальна, так как мастер-мастер в Тарантуле поддерживается, из-за чего его журнал имеет очень специфичный формат использующий векторные часы.

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

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

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

Аналитика в Авито постоянно развивается, и сейчас активно развивается её риалтайм-направление. Мы провели исследование разных СУБД и выбрали для себя ClickHouse под эти задачи.
Из доклада слушатели узнают, какие возможности предоставляет ClickHouse в качестве риалтайм-хранилища, как организовать пайплайн и какие трудозатраты для этого потребуются. Я в деталях расскажу о своем опыте проектирования и разработки пайплайна данных Kafka — Flink — ClickHouse, с помощью которого мы проливаем поток неструктурированных данных в 150 000 RPS в 1500+ колонок в широкую таблицу. При этом лаг составляет считанные секунды, а сеть и кластер хранилища остаются стабильными.

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

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

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

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

Работа в распределенной экосистеме это наш осознанный путь. Он позволяет Ламода развиваться и расти.

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

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

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

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

Раньше, для создания self-hosted автомасштабируемого кластера Kubernetes приходилось иметь какой-то управляющий инструмент снаружи, его приходилось поддерживать отдельно от кластера. Сообщество подготовило Cloud Provider AWS до такого состояния, когда изнутри k8s можно управлять всеми элементами AWS инфраструктуры, необходимыми для функционирования кластера. Это позволило нам создать решение, разворачивающее динамически меняющийся в зависимости от нагрузки кластер на экономичных spot instances, который автономно управляет собой. Из доклада можно будет узнать как устроен k8s cluster autoscaler и какие плюсы можно получить от его использования.

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

API Gateway - тема которую обсуждают давно, технологию которую применяют уже многие компании по всему миру. Но все еще возникают вопросы: а какие функции в себе должна содержать эта технология? Зачем этим функции нужны? Что они дают, что отнимают?

В этом докладе я расскажу о том:
- какие функции API Gateway должен иметь;
- что они дают;
- когда API Gateway нужно применять, а когда это вредно.

И напоследок, рассмотрим несколько популярных API Gateway, и поймем какая роль у данной технологии в Mesh Oriented Архитектуре.

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

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

Многие мобильные игры работают с использованием сервера. Причем серверная логика может быть достаточно сложной, требования к онлайну игры могут быть в десятки
тысяч конкурентных пользователей. Как написан такой сервер? Какие технологии используются при его разработке?
В докладе я расскажу:
- что вообще должен делать типичный игровой сервер, из каких частей он состоит
- на каких технологиях мы остановились для разработки игровых серверов (спойлер Vert.X Hazelcast, Postgres, Kafka, Prometheus + Grafana, Consul, Photon Cloud),
- как мы их используем (спойлер не все по прямому назначению)
- каким образом мы устанавливаем обновления.
- несколько интересных ошибок, которые мы словили при работе с Vert.X и Hazelcast

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

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

При разработке программного решения для придания продукту конкурентоспособности
все чаще применяется машинное обучение. Отдел RnD разрабатывает ключевые элементы продукта, используя современные инструменты: apache airflow, apache spark и dask.
Последние два года машинное обучение без gpu не модно, но мало кто знает, что такой подход значительно все усложняет. А airflow тормозит на 2м+ задачах не делая ситуацию легче.
Любой высокотехнологический продукт нуждается в слаженной работе всех отделов.
Но пока продукт хорошо продается/используется никто не замечает проблем, а когда они начнуться - потребуется много хладнокровия для их решения.
Отвечая на вопрос “Кто?”, “Сколько?”, “Когда?”, “Где?” и “Как?” можно решить многие проблемы и выбрать подходящие стратегии.
Отказавшись от модных подходов и перейдя к проверенным, можно за реальные сроки сделать окупаемым программное решение.

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

At AppsFlyer we ingest more than 100 billion events daily through our Kafka operation, which is then stored in a data warehouse hosted on Amazon S3. With AppsFlyer's increasing growth & scale, latency of data and resilience of the system began to pose complexities, and we found that we had to start rethinking our current approach and provide a better way to do our raw data processing.

This talk will focus on how we migrated the current raw data ingestion system to a solution based on Spark structured streaming.

I'll discuss what Spark structured streaming even is, some of the motivators for the migration, and why it was the right solution for us. You will get to see some of the challenges we faced during implementation, such as picking the correct data partitioning, how we ensured continued compliance with our GDPR solution, and the tooling we built to support the migration while providing our exactly-once solution.

The solution and the approaches that will be presented in this talk can be applied in your own data pipelines to create more resilient systems and correct data flows.

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

Ключевой составляющей инфраструктуры Яндекса является система YT, позволяющая распределенно и надежно исполнять вычисления над большими объемами данных. YT (https://habr.com/ru/company/yandex/blog/311104/, https://www.youtube.com/watch?v=VQGfH0sZi18) - это собственная разработка компании. Данная система предоставляет пользователям распределенное отказоустойчивое хранилище данных, а также богатые возможности для выполнения Map-Reduce вычислений над этими данными.

В нашем докладе мы поговорим про планировщик – компоненту, которая отвечает за оперативное выделение ресурсов под задачи пользователей и соблюдение гарантий, данных пользователям. В одном из предыдущих докладов (https://www.highload.ru/moscow/2019/abstracts/6085) мы рассказывали про архитектуру планировщика и используемые подходы к масштабируемости и отказоустойчивости. В этот раз мы поговорим про то, как решать непосредственно задачу планирования.

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

Описанная ситуация накладывает на планировщик следующие требования:

1. Отказоустойчивость: любой даунтайм планировщика – это простой десятков тысяч серверов в кластере и нарушение гарантий на время выполнения production-задач.

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

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

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

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

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

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

We created inspectable and monitored automatic distribution and scheduling system with multiple failovers from scratch, and I want to talk about issues and features.
Or How do we run 10M tasks in a day

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

Почти все встречались с упоминанием процесса выбора нового мастера при отказе существующего, многие слышали о распределенных транзакциях, некоторые даже знают страшные слова "Paxos" и "Raft".
Здесь я расскажу о том, как это всё работает и зачем нам, рядовым разработчикам, это знать.
А потом вы можете показать запись этого доклада своей маме и она тоже всё поймёт :)

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

Мы в Delivery Club активно используем Kafka.
Но как отправлять сообщения в Kafka, если у вас 10-летний legacy монолит, который является ядром продукта?
Я расскажу
- как в этом нам помог Kafka Connect;
- что такое Kafka Connect, как его настроить и как с ним работать;
- особенности деплоя, логирования и мониторинга;
- Jdbc Sink Connector, Debezium MySql Connector.

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

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

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

В докладе расскажу, как в Авито перешли от программирования формочек до полноценной Metadata Management System или, как мы ее называем - Infomodel. Цель доклада - поделиться опытом построения архитектуры управления метаданными. Наша система объединяет все этапы работы с метаданными сайтов объявлений и маркетплейсов: от построения форм, построения url для SERP до индексации данных и поисковых фильтров. Раскрою технические детали системы, которая обрабатывает десятки тысяч запросов в секунду. Расскажу, зачем мы написали свою read only базу данных с интерпретируемым DSL и как у нас выглядит EAV.
Система уже ведена в эксплуатацию, и я расскажу о ее плюсах и минусах. Доклад будет интересен разработчикам и архитекторам схожих проектов для перенятия нашего опыта в построении подобных систем.

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

С конца прошлого года фокус развития всего сервиса объявлений Юла направлен на социализацию и в связи с этим у нас было два крупных релиза: мы первые в мире запустили видеозвонки внутри сервиса и мы первые на российском рынке классифайдов запустили P2P-звонки и сториз. Именно о реализации последнего расскажем подробнее.

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

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

Размещение логики и технологии принятия решений
Зоны ответственности в модулях систем принятия решений
Cost saving при внедрении новых технологий в кредитном конвейере

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

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

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

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

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

Пользователи Hazelcast давно просили нас добавить поддержку SQL. Мы потратили год на создание первой версии масштабируемого распределенного SQL-движка, beta-версия которого вошла в состав Hazelcast IMDG 4.1.

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

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

Ассортимент туров у туроператоров - очень динамичная штука, цены и наличие туров меняются каждую минуту. При этом пользователи Левел Тревел совершают до 35 тысяч поисков каждую минуту, а в сутки наш поиск обрабатывает до 50 ТБ данных. Мы разработали сервис, который способен не только поддерживать такую нагрузку, но и в режиме реального времени управлять результатами поиска, которые видит пользователь: добавлять спецпредложения, показывать важные примечания, известные только нашим менеджерам, убирать из выдачи сомнительные предложения - и много другое.
* Супер-динамический ассортимент и проблемы хранения - работа с кэшем, Redis и долговременные хранилища
* Высоконагруженные клиентские сервисы и общая инфраструктура продукта, включающая в том числе монолит на Ruby - проблемы интеграции
* Highload на поиске и динамическое распределение нагрузки с помощью AWS-инфраструктуры

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

С ростом пандемии и самоизоляции возросла потребность в удаленном общении, многие люди перевели в онлайн коммуникацию, которую раньше не могли себе там представить.
Сейчас трудно представить соц сеть без сервиса видеоконференций.
Мы поговорим о том, как сделать свой высоконагруженный сервис конференц звонков до 128 участников в одном звонке своими руками, а попутно рассмотрим как устроены звонки, как их реализовать и как сделать ваши звонки лучше звонков конкурентов. Основной челендж высоконагруженного сервиса видеоконференций - баланса между кол-вом серверных мощностей и качеством сервиса (нагрузкой на устройства пользователя) .
Нас ждет:
* разбор технологий и сравнение сервисов конференций
* разберем как внедрить групповые звонки на WEB, iOS, Android
* реализуем конференции на 128 участников
* поработаем со звуком и шумоподавлением
* рассмотрим как искусственный интеллект делает звонки лучше
* добавим шумоподавление, скриншаринг, AR-фоны
* а так же поговорим о будущем технологического развития конференц сервисов

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

При недоступности приложения Такси пользователь в пару кликов уходит к конкуренту. Поэтому отказоустойчивость — наш приоритет.

Я расскажу:
- как мы незаметно переживаем отказ почти любых сервисов: сервиса конфигов, A/B-тестов, оплаты поездок и других;
- как мы незаметно переживаем отказ различных СУБД;
- как и зачем мы сделали свой circuit breaker;
- как наша микросервисная архитектура помогает отказоустойчивости и она же постоянно провоцирует факапы;
- как hot-reload-конфиги и A/B-тесты спасают;
- зачем мы обернули основные API endpoints в декларативно конфигурируемый API Gateway.

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

Мой доклад осветит набор инструментов для перехода к микросервисной архитектуре, инструменты из cloud native compute fundation для создания надежной микросервисной архитектуры. Что не забыть сделать, какие проблемы появятся (от изменений в орг структуре компании, до смены парадигм в разработке)

Кратко поговорим про api-gateway, управление трафиком, Orchestration & Management, Service Mesh, тестирование

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

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

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

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

Ошибки с которыми столкнулись разработчики (Ruby, Golang, Python) при масштабировании финтех стартапа в странах Азии.

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

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

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

Юла активно переходит на микросервисную архитектуру и год назад начала использовать GraphQL, внедрив её в новый gateway. Однако за год мы столкнулись с определенными проблемами: растущее число внутренних сервисов и команд уже не позволяло так же быстро и гибко внедрять новый функционал, а изначально легкий gateway начал превращаться в очередной монолит.
Исследовав варианты решения, мы пришли к Apollo Federation – технологии, которая с одной стороны позволила нам разбить монолитную схему основного gateway, а с другой – объединиться со схемами других бизнес-юнитов.

Мы поделимся своим опытом использовани GraphQL на примере большого сервиса: от внедрения первого легковесного gateway до распределенной схемы с использованием Apollo Federation.

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

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

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

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

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

Иногда серверы “умирают”.

Все начинается с необычного скачка нагрузки на веб-сервере - повышенное потребление памяти и CPU. У клиентов сайт грузится медленно, DevOps наблюдают увеличение задержек на графиках. Через несколько минут база данных дает сбой, и вскоре еще несколько серверов “отваливаются” один за другим. Перезапуск серверов не помогает, поскольку при запуске сервер сразу попадает в аварийный цикл, и становится понятно, что хотя изначальный всплеск нагрузки давно позади, ситуация уже не исправится сама собой. Характерно то, что в коде нету очевидного “бага”, и трудно понять, почему возник аварийный цикл перезагрузок.

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

> Вопрос на миллион долларов - должен-ли сервер умирать из за нагрузки?

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

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

Кратко познакомимся с концепцией: Не абстрактный Дизайн Больших Систем (NALSD).
Научимся защищать сервер от аварийного цикла с помощью Примитивов Мгновенной Отказоустойчивости. Поймем, как примитивы сочетаются между собой, и как их настраивать.
Классифицируем виды отказов сервера, и для каждого типичного сценария вникнем в суть проблемы досконально:
* Проанализируем состояние сервера с помощью математики и Теории Очередей
* Проведем численное моделирование каждого вида отказа
* Сравним лабораторные результаты с реальной системой
* Обсудим возможное решение
* Разберем примеры кода

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

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

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

Когда пропадает простой способ масштабировать сервис под нагрузкой — появляется хайлоад. Но случается такое не сразу, не у всех и не всегда. Многие сервисы годами работают на "нехайлоадных" PHP, Python и Ruby, обрабатывая тысячи веб-запросов в секунду и не чувствуя необходимости писать свой компилятор PHP или переходить на Go с Rust.

В докладе я расскажу о том, когда именно наступает переломный момент для Python и Ruby, двух "хипстерско-хайповых" стеков, первый из которых нам регулярно приносят дейта-сайентисты, а второй все никак не может умереть и время от времени демонстрирует проекты вроде "hey.com".

Взяв за основу "типовые" Python- и Ruby-проекты, как их модно делать в 2020 году, я покажу, что именно происходит после nginx, как современные application-сервера для этих языков взаимодействуют с виртуальными машинами, что дают и отнимают веб-фреймворки и чем это все отличается по скорости от "си-шного" хайлоада, способного выдавать сотни тысяч запросов в секунду. Python и Ruby действительно медленные и с GIL, но при правильном использовании это не проблема, а статья расходов — и я расскажу, что мы можем получить за эти деньги.

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

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

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

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

План доклада:
1. Что такое публичное облако в 2020 году.
2. Какие парадигмы меняет публичное облако.
3. Зачем публичное облако действительно нужно.
4. Рекомендации для обеспечения масштабирования, высокой доступности и мультитенантности.

1. IaaS.
2. PaaS — Databases.
3. PaaS — Containers.
4. PaaS — Serverless.

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

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

В докладе я расскажу, какие вызовы может встретить компания при использовании Kafka в нескольких ДЦ и как эти вызовы решили мы в Авито. Также пройдемся по возможностям Kafka (версия 2.4+) и технологиям из Kafka-экосистемы, помогающим организовать мультиДЦ-кластеры.

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

В OZON мы разработали и успешно внедрили инструмент DMP (Data Management Platform), который автоматизирует процесс создания сегментов через фильтрацию пользовательских событий. DMP — программная платформа для сбора, хранения, систематизации и анализа данных о взаимодействии пользователей с OZON.

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

В своем докладе я расскажу:
- как мы пришли к необходимости разработки собственной платформы DMP;
- об архитектуре платформы;
- как обеспечивается время ответа < 10 мс;
- как мы используем ClickHouse для хранения пользовательских событий;
- каким было сегментирование до внедрения конструктора и как используем сегменты для повышения бизнес-метрик.

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

Чем популярнее термин, тем меньше человек действительно понимает, что он означает. Доступность, Надежность, Отказоустойчивость и пр. уже давно стали мантрой, в реальную суть которой особенно не вникают. Да и зачем? И так все ясно - чем больше «девяток», тем лучше. Факт, что мы часто сравниваем мокрое с соленым, ускользает. Это приводит к неадекватной оценке сложности проектов и появлению «сверх-быстрых», «мега-масштабируемых» и пр. решений, которые, по факту, оказываются очень хрупкими.

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

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

Хочешь делать каталог - применяй битовые матрицы (roaring bitmap). Это позволяет строить фасеты, делать range запросы и top n выборки, обеспечивающие компактное хранение и быстрое взаимодействие

Главный фактор быстрой работы битмап - векторизация. В golang добиться этого очень сложно. Бенчмарк реализаций каталогов golang vs rust показал, что хайповый go не панацея.

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

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

Все эти факторы подстёгивают нас искать новые решения и улучшать старые: оптимизируем и меняем базу и запросы, переписываем сервисы на Go, прикручиваем Kafka, пробуем H3 гексагоны и денормализацию данных.

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

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

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

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

Создать stateless платежный шлюз это реально. Достаточно кодировать данные о платежной транзакции в подписанный url

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

etcd это хорошее решение для недопущения двойных списаний со счетов клиентов по одной платежной транзакции

Кролики это не только ценный мех, но и еще и хороший инструмент для реализации паттерна retry (с использованием RabbitMQ)

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

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

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

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

JIT (Just in Time) компиляция – неотъемлемая часть многих популярных платформ (JavaScript, Java). Задача компиляции в момент выполнения существенно отличается от классической AOT (Ahead of Time) компиляции.

Эволюция технологий JIT- и AOT-компиляции во многом идут параллельными путями.

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

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

Мы используем распределенное хранилище Apache Ignite в продакшне, как следствие — предъявляем к нему высокие требования по надежности и доступности.

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

В докладе рассмотрим:
- как Apache Ignite реплицирует данные и гарантирует консистентность реплик в случае инцидентов,
- каковы гарантии времени отклика и чем они обусловлены,
- что и как было улучшено в процедуре восстановления после сбоев,
- почему старый вариант восстановления остался в продукте, когда он отрабатывает,
- какие доработки еще предстоят.

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