Доклады секции "Архитектуры и масштабируемость"

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

А насколько легко добавить изоляцию в такой базовый и давно сформировавшийся сервис, как DNS? Как быть с идентичными зонами?

Расскажем о нашем опыте создания multi-tenant private DNS для использования его в SDN собственной разработки без вендорных решений, без дополнительных мощностей, без большого штата разработки. Подытожим рабочие подходы к быстрому созданию полностью изолированных мультитенантных систем для облачных решений.

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

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

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

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

Я расскажу про технические и архитектурные решения, которые принципиально отличают StatsHouse от существующих OpenSource-решений — в том числе его уникальную Бесконечную® Масштабируемость™. И еще — сделаю пока секретный анонс.

На докладе расскажу о технических сложностях, с которыми мы столкнулись при разработке своего хранилища.
Задачи, которые решали:
* эффективная утилизация больших HDD (меньше iops на терабайт хранилища);
* переезд на более cost-effective серверную платформу (сокращение количества занимаемых юнитов в ДЦ);
* обеспечение SLA 99.999% доступности данных в течение года;
* переживание отключения ДЦ (ряда/стойки/сервера) без ручного вмешательства;

Архитектура потребовала распила письма на несколько составляющих и 2 вида индексов, чтобы хранилище смогло утилизировать диски в 18 ТБ полностью. Индексы не помещаются в память, поэтому применяются разные приемы для ускорения их загрузки в кэш. Для обеспечения более линейной записи группы юзеров объединяются в шарды, внутри которых ведется один xlog на всех. Собственное BLOB-хранилище с кворумной записью.
И другие приемы.

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

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

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

Мы — команда, которая долгое время принимала участие в разработке и поддержке NGINX. Сейчас мы делаем свой fork.

В докладе мы расскажем про drop-in replacement NGINX, веб-сервер Angie, фичах, необходимость которых давно назрела, но по ряду причин они не были занесены в сервер, и покажем, что уже сделали.

Будет интересно :)

Выносим сервис расчёта цен для 20 тысяч магазинов из SAP, чтобы:
* снять с SAP нагрузку (100% загрузки серверов с 21 до 3 часов) — мешает другим процессам, требует постоянной поддержки из-за частого достижения потолка ресурсов, работает на пределе возможностей SAP;
* вывести из зоны риска остановки mission critical процесс.

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

В докладе на примере ВКонтакте — проекта с 16-летней историей, 100 млн пользователей в месяц и 8 млн строк кода бизнес-логики — рассмотрим принципы построения техстратегии и методы принятия стратегических решений.

А также разберём, как техстратегия и архитектура влияют друг на друга и что у нас получается в результате:
* как строить техстратегию на несколько лет вперед;
* портерианский и ресурсный подходы к стратегированию;
* требования, которые мы предъявляем к архитектуре, и их связь с time2market;
* как обеспечиваем отказоустойчивость и балансируем нагрузку;
* как эксплуатируем систему с более чем 20 000 серверов;
* какие решения позволяют делать 3,5 тысячи деплоев в год с winrate 97,7%;
* как устроена система сборки, которая позволяет собрать 8 млн строк кода и раскатить на 10 000 серверов за 7 минут;
* и как, собственно, сейчас выглядят техстратегия и архитектура ВКонтакте.

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

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

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

За 2 месяца внедрили пилот на базе открытого KeyCloak и начали постепенно масштабировать его на всю страну. При 300000 сессиях получили даунтайм при обновлениях: пользователи не могли войти в систему около 15 минут. Мы снизили время простоя настройками кэширования и модификацией схемы базы данных до 3 минут, но дальше нас ждал первый миллион сессий…

Сейчас биллинг Yandex Cloud обрабатывает около 4,2 миллиарда метрик от сервисов в сутки, а задержка с момента, когда что-то случилось, до того, как это отразится в детализации, составляет единицы минут.

Расскажу, как мы проектировали биллинг, какие вопросы задавали сами себе, какие архитектурные решения выдержали проверку временем, а какие нет. В частности, рассмотрим:
* как строить объектную модель;
* масштабируемость: что будет, если пользователей, продуктов или данных станет больше в 100 раз (спойлер: так и вышло);
* механизмы доставки данных о потреблении: push, pull, message queue;
* OLTP для потоковой обработки и OLAP для тяжёлой аналитики.

Lakehouse — это современная архитектура построения аналитических платформ компаний, которая совмещает лучшие качества data warehouse и data lake. Одним из популярных продуктов для построения lakehouse-систем является Presto — массивно-параллельный распределенный SQL-движок для выполнения федеративных запросов.

В данном докладе мы обсудим основные сценарии использования и построения lakehouse-архитектур, после чего посмотрим, как техническая реализация Presto помогает создавать масштабируемые корпоративные аналитические платформы:
* дезагрегация storage и compute, которая позволяет масштабировать вычислительные ресурсы без перемещения данных;
* коннекторы к большому количеству целевых систем с возможностью гибких pushdown-вычислений;
* продвинутая работа с сырыми данными с использованием современных технологий Apache Iceberg и Delta Lake;
* кэширование сырых данных на воркерах для уменьшения latency и стоимости работы с object storages;
* высокопроизводительный массивно-параллельный компилируемый SQL-движок.

В докладе будет рассказано об архитектуре сервиса, который позволяет отправлять пуш-уведомления на мобильные устройства с минимальной задержкой, подобно Google Firebase. Расскажем, как сделали сервис надежным (горизонтально масштабируемым на базе Redis Cluster и Scylla, устойчивым к DDoS через публичные API), как можно держать в фоне открытый Web Socket на Android, пользуясь доступными возможностями ОС. Покажем, как пользоваться нашими публичными API и SDK, поделимся опытом интеграции в "Почту Mail.Ru" на Android и бэкенде.

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

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

Расскажем о том, как вывести трафик из изолированных сетей, построенных на базе Neutron Openstack, без большого штата разработки, без заливания железом, без нагоняев от службы ИБ.

В составе платформы YDB мы вывели в Open Source сервис очередей сообщений — Topic Service. Это решение поверх YDB, которое обладает надёжностью, масштабируемостью, даёт управляемые гарантии FIFO-порядка и семантики доставки.

В этом докладе я расскажу, как устроен YDB Topic Service, чем похож и чем отличается от других популярных продуктов, в частности Apache Kafka®. Также я расскажу про реальное применение этой технологии в инфраструктуре и сервисах Яндекса, на инсталляции масштаба тысячи хостов и десятков ГБ/с на запись.