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

(15)

Полная изоляция клиентов в облаке для сервисов без изоляции на примере DNS

Распределенные системы
Методы и техника разработки ПО
Масштабирование с нуля
Критерии выбора технологий для проекта
Архитектуры / другое
Управление конфигурацией
Работа с облачными сервисами
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Микросервисы
Инфраструктура
Сеть

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

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

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

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

Архитектура ВКонтакте: там, где данные

Илья Щербак

ВКонтакте, VK

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

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

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

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

StatsHouse: метрики ВКонтакте

Григорий Петросян

ВКонтакте, VK

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

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

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

Хранилище для Почты

Миграции данных
Электронная почта
Бэкенд / другое
Базы данных / другое
Отказоустойчивость
Оптимизация производительности
Распределенные системы
Оптимизация
Хранилища
Обработка данных
Виктор Могилин

Почта Mail.ru, VK

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

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

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

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

Богдан Гаркушин

VK, ВКонтакте

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

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

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

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

Дорогая, я форкнул NGINX

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

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

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

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

Как вынести расчет цен для 20 тысяч магазинов из SAP, чтобы сохранить 4 девятки

Микросервисы, SOA
Отказоустойчивость
Распределенные системы
Архитектура данных, потоки данных, версионирование
Критерии выбора технологий для проекта
Работа с облачными сервисами
ClickHouse

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

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

Техстратегия и архитектура highload-проекта на примере ВКонтакте

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

ВКонтакте, VK

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

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

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

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

H264 жив

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

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

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

SSO-решение на 5 млн пользователей. Масштабирование от пилотного проекта до федерального уровня

Java
Защита информации
Организация системы кеширования
Отказоустойчивость
Масштабирование с нуля
Управление конфигурацией
Непрерывное развертывание и деплой
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Поддержка и развитие legacy систем
Надёжность продакшена
Оптимизация
Хранилища
Микросервисы
DevOps / Кубер
Ирина Блажина

Оператор Газпром ИД

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

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

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

С чего начинается биллинг облачных сервисов

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

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

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

Построение современных lakehouse-архитектур с помощью Presto

Распределенные системы
Архитектура данных, потоки данных, версионирование
Хранилища
Обработка данных

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

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

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

Пуш-уведомления в RuStore: как мы сделали свой транспорт на замену Google Firebase

Базы данных / другое
Микросервисы, SOA
Отказоустойчивость
Распределенные системы
Разработка библиотек, включая open source библиотеки
Архитектура платформы Google Android
Технологии и языки для Android: Java, Kotlin
Клиент-серверное приложение, REST API, protobuf
GO
Кирилл Алексеев

Почта Mail.ru, VK

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

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

Побег из Шоушенка в мире сетей

Распределенные системы
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Облака
Инфраструктура
Сеть

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

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

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

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

YDB Topic Service: надёжная и масштабируемая очередь сообщений

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

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

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