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

Доклады

Архитектура (6)

Apache Kafka как хранилище. Использование, проблемы, боль и последствия

Микросервисы, SOA
Отказоустойчивость
Синхронизация данных, параллельная обработка, CDN
Хранилища
Обработка данных

Вы хотите использовать Apache Kafka в своих системах? А может быть уже это делаете? Мы да и много, но местами мы ее используем ее не только как систему обмена сообщениями, но и как хранилище данных. Это хорошо или плохо? Удобно или только боль? На эти вопросы я отвечу в своем докладе, расскажу в каких вариантах мы используем Kafka, поведаю историю как мы столкнулись с проблемами бэкапа данных из Kafka и как решали их на 400 сообщений в треде в мессенджере.

Чтобы Вы не допускали ошибки в использовании Apache Kafka, мы сделали это за вас и я расскажу о них.

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

WASM: цель, устройство, перспективы

API
C/C++
Разработка библиотек, включая open source библиотеки

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

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

Как мы увеличили пропускную способность поиска картинок с помощью ML и изменения архитектуры

Картинки - это часть поиска Яндекса, работающий с визуальным контентом и обрабатывающий более 10 000 тяжёлых запросов в секунду с помощью десятков тысяч CPU в рантайме. Мы расскажем, как столкнувшись с необходимостью масштабирования сервиса, с помощью ML в сочетании с архитектурными изменениями смогли не только увеличить пропускную способность в ~2 раза на том же железе, но и дать инструмент для более гибких продуктовых внедрений.

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

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

api-gateway опыт эксплуатации

Расскажу про опыт создания и эксплуатации собственного решения api-gateway.
С какими столкнулись сложностями и как их решали.

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

Макро-оптимизация маршрутизации Доставки

Дмитрий Матрохин

Яндекс Доставка

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

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

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

Как масштабировать защиту от DDoS атак на десятки миллионов RPS. Опыт Яндекса

Отказоустойчивость
Распределенные системы
Архитектуры / другое
DDoS
Надёжность продакшена
Атаки
Безопасность

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

Много лет в Яндексе существует система "Антиробот", призванная защищать сервисы от DDoS-атак и парсинга. Это один из самых высоконагруженных сервисов в рунете по количеству обрабатываемых запросов в секунду. В этом докладе я постараюсь приоткрыть занавес и рассказать как построить такой масштабируемый, отказоустойчивый и надёжный сервис с низким latency. Расскажу как устроена многоуровневая балансировка трафика в Яндексе, покажу как устроена архитектура антиробота и какие приёмы мы используем для быстрого расчёта факторов для моделей машинного обучения. Также расскажу как устроена капча и как ещё можно издеваться над роботами.

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

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

Стоимостный оптимизатор в YDB - зачем и почему?

YDB
Павел Велихов

Yandex.Cloud (YDB)

Недавно мы добавили стоимостный оптимизатор в YDB, зачем мы это сделали и какие задачи он поможет решать?

YDB создавалась как OLTP система для поддержки высоко-нагруженных проектов с большим объемом транзакций. Обычно в таких системах запросы довольно простые, хотя все равно попадаются и аналитические запросы со значимым количеством соединений таблиц. Такие запросы довольно сложно оптимизировать вручную, и на помощь приходит стоимостный оптимизатор. Многие наши конкуренты, такие как CockroachDB, TiDB, Yugabyte добавили стоимостные оптимизаторы к своим продуктам.

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

В этом докладе мы расскажем о том как мы написали свой стоимостный оптимизатор для этих сценариев, какая у него текущая функциональность на данный момент, сравнимся с конкурентами в области OLTP (CockroachDB, Yugabyte), OLAP (GreenplumDB, Teradata, Oracle Exadata, Trino) и HTAP (TiDB) решений и расскажем о планах развития.

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

Эксплуатация систем (1)

Workshop: Контейнеры и сети. Изучаем, разбираемся, отлаживаем.

Технологии виртуализации и контейнеризации
Сетевое администрирование
Инфраструктура
Сеть

В наш век повсеместного распространения контейнеров все считают их привычной магией и забывают о том, что они построены на базе самых стандартных технологий, котором не один десяток лет. Особенно это касается организации сетевого взаимодействия. Пора снять завесу тайны с этих технологий и потрогать их руками!
Всегда хотели вжух-вжух и дебажить сети в этих ваших куберах и докерах, но не знали с чего начать? Приходите, покажем-расскажем и научим основополагающим вещам в этом нелегком деле!
На нашем Workshop мы разберем те кирпичики, из которых построены все сети как под k8s, так и под стандартными облаками. Проведем лабораторные работы и выдадим домашнее задание по следующим темам:
- Набор утилит iproute2 как основной способ взаимодействия с сетевым стеком linux
- Устройство сетевых namespace в ядре linux
- Виртуальные сетевые интерфейсы: виды, особенности, применение.
- OpenVSwitch: лучший сетевой швейцарский нож.

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

BigData и инфраструктура машинного обучения (data engineering) (1)

YTsaurus SPYT: как мы сначала форкнули и пропатчили Apache Spark, а потом от него избавлялись.

Разработка библиотек, включая open source библиотеки
Обработка данных
YTSaurus

Проекту SPYT, обеспечивающему интеграцию Apache Spark с YTsaurus уже больше 5 лет. Несколько лет назад мы уже рассказывали о том, как нам удалось их подружить так, чтобы всё работало эффективно (https://highload.ru/spring/2021/abstracts/7266). С тех пор в проекте произошел ряд важных событий, и самое главное из них – выход YTsaurus в OpenSource весной 2023 года.

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

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

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

В своём докладе я расскажу о том, зачем изначально нам потребовалось сделать форк и пропатчить Apache Spark, какие это вносило неудобства, и как мы справились с самыми главными вызовами после выхода проекта в OpenSource: отказ от форка Apache Spark, и поддержка работы SPYT используя произвольную версию Apache Spark.

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