🖐 Не пропустите доклады, которые начинаются в 17:10
⠀
🏰 «00 Зал - Башня». Архитектура биллинга: как не стать единой точкой отказа. Илья Иванов (Яндекс 360)

Интересный архитектурный кейс от Яндекса по созданию высоконагруженного биллинга.
⠀
🔘 Зал «08 Шатер Голубой». Быстро — не всегда хорошо: рейтлимиты в мультикластерном окружении. Дмитрий Виноградов (Wildberries)

Для контроля входящего RPS в сервисах применяют rate limit. Вот только он реализуется или как простой in-memory-счетчик, или более продвинуто — как счетчик во внешнем K/V. В докладе Дмитрий пошел в своей работе дальше — к более сложным решениям.
⠀
🔹 «03 Зал Синий». Продолжение мастер-класса «Разделим данные». Алексей Лосев (Яндекс Маркет)

Продолжение серии мастер-классов от Алексея. В этот раз будет разобран кейс создания системы с разделенными и слабо связанными мастер-системами.
⠀
🟣 «04 Зал Красный». Как научить MongoDB делать горячие физические бэкапы. Юрий Фролов (Yandex Cloud)

История о том, как Яндекс возвращал возможность физических бэкапов в MongoDB. Будет много подробностей про движок базы, про подход MongoDB к хранению данных и про то, как написать собственную логику бэкапа.
⠀
🟢 «06 Зал Зеленый». Как мы сделали собственный Software-Defined Storage для публичного облака Cloud.ru. Сергей Лысанов (Cloud.ru)

Глубоко технический доклад про реализацию собственного хранилища в условиях больших нагрузок и критических систем вокруг. Если вам нравится разбираться во внутрянке таких систем и специфике хранения данных — этот доклад для вас.
⠀
🔵 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса «Создание модульной (и желательно эффективной) RAG-системы». Антон Белоусов (Raft AI Labs)

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

#Highload Филипп Дельгядо. Enterprise deploy: почему это больно. Рассказ о технике повышения безопасности деплоя. Особенно важно это для enterprise-решений, которые разворачиваются у клиента: мы не контролируем процесс обновлений и их использование.

Когда-то были монолиты, которые для обновлений останавливали. Сейчас у нас много экземпляров серверов, которые работают с общей базой данных, которая тоже может быть в нескольких экземплярах, и остановить работу для изменения невозможно. Изменения правильно делить не на совместимые и несовместимые, а по безопасности: почти безопасные, возможно опасные и точно опасные. Создать новую таблицу - безопасно. Добавить поле - практически безопасно, но требует краткой блокировки таблицы, и на смеси olap и oltp транзакций под высокой нагрузкой это может выстрелить: oltp задержат дольше допустимого. А создание индекса во многих базах блокирует таблицу надолго, а в PostgreSQL есть специальные методы, как это сделать безопасно, ими надо владеть. Добавление нового значения в enum - опасность больше, надо разбираться с работой старых сервисов с объектами, у которых новое значение. Может быть, что такие записи в них в принципе не попадут, но это всегда не точно.

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

Теперь от базы данных к взаимодействию сервисов. В случае синхронного взаимодействия (http, grpc) применяем:
* Версионирование по методам, а не целиком.
* Изменения окружаем флагами для котроля нового поведения
* Используем тольо безопасные изменения внутри endpoint
* Маршрутизация запросов - чтобы метод получал только понятное
* Контроль жизненного цикла: состояния draft, unstable, deprecated. C разными обязательствами.
* Нужен инструмент управление фича-флагами: рассылка по сервисам, контроль зависимостей, канареечные флаги вместо разнесения по узлам сети, удаление неактуальных флагов

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

А еще - можно не делать асинхронное. Вам нужно сглаживать пики - уберите этот буфер внутрь сервиса, а не располагайте между.

🖐 Друзья, в 18:20 мы ждём вас на заключительных докладах Saint HighLoad++ 2024:
⠀
🏰 «00 Зал - Башня». Как мы шли к 5000 RPS на запись. Ян Силов (Ozon)

Хорошая история повышения нагрузки на запись и борьбы с ней. Вместе с докладчиком погрузимся в анализ проблем и оптимизацию.
⠀
🔘 Зал «08 Шатер Голубой». Как воспитать себе помощника: применение локального ИИ для разработки. Алексей Цветков (Независимый эксперт)

Трудно делать содержательный доклад на горячую тему: ожидания высоки, готовность аудитории низкая. И Алексей справился блестяще! Это интересный и полезный доклад, рекомендован всем, кого интересует практическое применение AI в повседневной работе.
⠀
🟣 «04 Зал Красный». Как мы монгу физически бэкапили. Владимир Гошев (Yandex Cloud)

Рассказ о том, как Яндекс учился бэкапить кластеры MongoDB для своих клиентов: чтобы бэкапы занимали адекватное количество места, с ними было легко работать, а главное — чтобы из них можно было восстановить консистентный кластер!

Первая в России PostgreSQL Pre-Commitfest Party: итоги!

✔️100+ слушателей на публичном ревью патчей в PostgreSQL 18 
✔️900+ гостей в шатре Postgres Professional!
✔️4 демонстрации BiHA и Shardman 
✔️600+ участников квиза
✔️15 коробок разыгранного мерча 

Спасибо всем, кто провел с нами эти два дня и до встречи на следующей вечеринке российского постгрес-сообщества!

Вместе мы – Postgres! 

Ловите фоточки 🙌

День первый

День второй

💥 Друзья, Saint HighLoad++ 2024 завершилась!
⠀
Мы благодарим каждого из вас за участие: кто был на площадке, в онлайн, спикеров и партнёров! Эти два дня были очень насыщенные и мы надеемся, что для вас они прошли плодотворно и интересно. Будем рады вашей обратной связи 💚
⠀
До встречи на HighLoad++ 2024 🙌

Как бороться с типовыми причинами отказа? Для начала их нужно обнаружить.

Рассмотрим элементы инженерной практики, которые обеспечивают высокую доступность системы и оперативное расследование инцидентов. Коснёмся памяти, разберём базу данных, поговорим про ТСР-соединения. Посмотрим, как разрабатывают, эксплуатируют и отлаживают высоконагруженные системы в Газпромбанке.

Константин Козловский из Газпромбанк.Тех расскажет про проблемы backend разработки на Java и Kotlin.

Подробности в статье: https://habr.com/ru/companies/oleg-bunin/articles/823498/

Дорогие участники конференции Saint HighLoad++ 2024☀️

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