В 2020 году Saint HighLoad++ проводиться не будет.
В Санкт-Петербурге мы с вами встретимся в июне 2021

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Блокчейн

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

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

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

Есть нагруженная 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для реализации backend сервиса Wink - высоконагруженной платформы IPTV Ростелеком мы разработали собственную in-memory базу данных. Разработка и эксплуатация собственной базы данных, особенно, работающей под высокой нагрузкой - не тривиальное занятие, в процессе которого пришлось сталкиваться с ожидаемыми, а местами - совсем не ожидаемыми проблемами.

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

Кроме этого, я расскажу про инструментарий, который мы используем для автоматизированного нагрузочного и стресс тестирования как непосредственно самой in-memory БД, так и связки in-memory БД и backend c бизнес логикой Wink.

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

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

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

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

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

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

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

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

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

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

Стандартно разработчик при поиске проблем в RDBMs подозревает медленные запросы. А что, если дело не в медленных запросах, и на самом деле виноваты совсем другие запросы?

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

Думаете, это невозможно? Возможно, и я расскажу, как мы это делаем изо дня в день и какими инструментами для этого пользуемся.

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

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

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

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

В этом докладе мы обсудим следующие вопросы на примере Nginx, Varnish, Apache Traffic Server, HAProxy, H2O и Tempesta FW:
* Как прокси управляют соединениями с клиентом и к бэкенд-серверам;
* Очереди HTTP-сообщений и фейловеринг соединений с бэкендами в стандартах HTTP и реализациях прокси, и как это влияет на безопасность;
* Работа и взаимодействие декодеров и парсеров HTTP/1.x, HTTP/2 и HTTP/3 (QUIC);
* HPACK и QPACK компрессии в HTTP/2 и HTTP/3 (QUIC), соответственно, и как они влияют на производительность;
* Что, как и в каких случаях можно кэшировать;
* Различные архитектуры кэширования: mmap(), файловый кэш и база данных;
* Оптимизации на уровне сетевого I/O и TLS, доступные в некоторых web-акселераторах и современных Linux-ядрах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В докладе пойдет речь про то, как профилировать выполнение моделей на Tensorflow, чтобы увеличить скорость обработки запросов. Разберём, нужен ли вам GPU или CPU достаточно. Если GPU все же нужен, то как понять какую часть вашей модели все-таки стоит оставить на CPU и можно ли это сделать не трогая код модели. Расскажу про архитектуру вокруг машинного обучения в рекламной платформе Unity Technologies. И про проблемы производительности при переезде на Tensorflow2 тоже поговорим.

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

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

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

Опыт создания одного из самых успешных 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

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

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

Кроме того, обсудим:

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

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

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

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

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

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

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

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

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

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

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

В приложении inDriver пассажир сам ставит цену поездки и получает ответный торг от водителя. Но при высоком спросе (непогода, часы пик) цена в других агрегаторах резко растет вверх. Было принято решение уведомлять пассажира соответствующей иконкой с молнией, которая отображается при высоком спросе. В докладе мы пытаемся понять что такое высокий спрос на основе собранных исторических данных. Построена и проверена модель, которую потом подключили к продакшену. Для изучения эффективности модели были проведены сравнительные тесты в нескольких городах.
Технологии: python, scikit-learn, lightgbm, pandas

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

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

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

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

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

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

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

Ежедневная проблема крупной службы доставки: как развести 5000 заказов с помощью 200 водителей. Чтобы начать решать такую задачу, нужно за 2 минуты посчитать 300 млн маршрутов. Затем за 10 минут нужно найти оптимальное размещение этих заказов по водителям. Хорошая новость в том, что у вас есть вычислительный кластер. Плохая новость в том, что даже с одним водителем вариантов объехать все заказы 5000! — это число с 16327 знаками. Хорошая новость в том, что самое оптимальное решение искать не нужно, достаточно решить эту задачу лучше человека (логиста). Логист находит решение этой задачи на 1 млн рублей логистических расходов. Если вы найдёте решение на 10% лучше, то сэкономите клиенту 100 тыс. рублей. И это за 12+ минут вы обработали только один запрос.

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

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

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

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

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

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

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

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

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

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

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

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

Мы создаем и развиваем внутреннюю платформу, помогаем командам отправлять уведомления пользователям через различные каналы: sms, email, push и внутренний центр уведомлений. Разрабатываем сервисы: единая точка отправки, настройки уведомлений, шаблонизации, аналитики, отправки в каналы и защиты.

В докладе расскажу о пройденном нами пути, о проблемах, о будущих планах.

Данное архитектурное ревью поможет реализовать похожую платформу, развивать свою или позаимствовать идеи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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