Saint HighLoad++ 2024. Заметки путешественника

Высокие нагрузки во всей своей красе!

Высокие нагрузки во всей своей красе!

«Работает? Не трогай!» Но только не в HighLoad! Расти нужно постоянно. Всё менять и переделывать. Но как? И с помощью каких практик? А может и так сойдёт? Поехал искать ответ на Saint HighLoad++.

Начало небольшого путешествия.

Начало небольшого путешествия.

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

Будущий space engineer, который собирается защитить master degree в Италии, рассказывал о своём путешествие, итальянских блюдах и родной Турции.

Открытие конференции

Зажигательный старт.

Зажигательный старт.

По приезду рано утром заехал в отель. А после направился в локацию DESIGN DISTRICT DAA in SPB, где и должна была состоятся двухдневная конференция по высоким нагрузкам. Доклады в программе казались разнообразными и интересными. В том числе присутствовала тематика AI.

Чтобы гости не заскучали до открытия, которое должно было состояться в огромном зале «Башня» с 48 метровым потолком, на сцену вышли барабанщики. Музыканты отбивали бодрый бит, задавая ритм всему предстоящему мероприятию.

К этому моменту я уже начал выполнять одну из 3ёх основных активностей конференции — знакомство.

Доклады

Что выбрать?

Что выбрать?

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

Доклад №1. Запуск заданий по расписанию на бэкенде

Планировщик как обычный сервис, которому нужна вся

Рассказ строился от простого к сложному. Начать можно с cron на одной ноде. И далее по мере роста заданий и увеличения гео распределенности переходить к целевым решениям типа — Cluster Scheduled tasks, Quartz Clustering, Dkron, JobRunr. Встречали такие?

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

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

Обработка ошибок. Если задание не выполнилось, что нужно делать? Выполнять повторно? Для stateless & idempotent операции это сделать можно. Для statefull & run once уже нужно хранить состояние на случай падения планировщика. Чтобы он мог корректно восстановиться и понять что уже было выполнено и это повторять не нужно.

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

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

Этот доклад напомнил мне размышление на тему «что такое работающий код?». Это лишь код, который работает на проде? Или же нечто большее — сам код, тесты на него, использованные архитектурные паттерны, мониторинг, инструменты вокруг?

Были также освещены элементы планировщика:

  1. Экземпляры

  2. Планировщики

  3. Задания

  4. Триггеры

Доклад помог мне сделать следующие выводы:

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

  • Положиться на коробочное решение с интенцией — «Само работает, и так сойдёт» можно лишь после хорошего изучения специфики работы самого планировщика и рассмотрения различных кейсов его применения.

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

Доклад №2. Опыт перевода банковского продукта в риалтайм

affbd21ed05edab5e35e2a3d6ff67c64.png

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

Рассказана продуктовая история:

Собрали требования -> Сформировали команду -> Оценили технологии -> Выбрали архитектуру -> Сделали MVP -> Требования изменились на 180 градусов -> Всё или почти всё переделали -> Словили баги -> Отладились -> Всё работает

Я рассказал эту историю меньше, чем за минуту, докладчики за 30 минут, само создание с нуля, с отсутствующей командой, отсутствием опыта в выборе HighLoad решений под такие realtime задачи, удовлетворением всех devsecops активностей компании, встраиванием в смежные контуры заняло 9 месяцев.

Заметил, что на конференции доклады рассказывались бодро. В основном, умещались в отведенное время. Поэтому можно было задать достаточно вопросов в конце.

Как относитесь к затягиванию доклада? Создаётся впечатление, что держат в силках/время пары кончилось, а уже наступил законный перерыв? Или же, если очень интересно можете слушать все 50–70–120 минут?

Параллельно общему продуктовому рассказу освещалась тема оценки применимости возможных технологий:

  • Redis или Tarantool для высоких нагрузок для резидентного хранения?

  • Незнакомый Lua, Scala в добавок к знакомому Java. Стоит ли делать мультиязычность? Lua — своя экосистема. Необходимо настраивать отдельно от активно используемого банковского Java.

  • Apache Flink. Нужная масштабируемость из коробки. Ведь нужно масштабироваться до 1 млн rps. Но мало экспертизы.

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

Мой вопрос был про нагрузки. Сейчас это сотни rps. Готовится тестирование в соответствие со всеми регламентами на сотни тысяч rps для каждого сервиса. Тарантул у них держит 1 млн rps.

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

А вас сложилась взаимная любовь с agile?

Доклад №3. Redis — такой простой и такой сложный!

База, тюнинг, сравнение с Dragonfly

База, тюнинг, сравнение с Dragonfly

Кто бы мог подумать, что 300 строк кода со временем разрастутся до продукта с мировым именем! База, с чего стартовал редис — быстрое кэширование. Скорость равна скорости доступа к ОЗУ.

Теперь же рассказывая о Redis уже можно говорить об:

  • Отказоустойчивости — Репликация, Sentinel

  • Безопасности — Access control, Data encryption

  • Администрирование — Configuration, Monitoring

Также о типовых сценариях использования — кэш, обработка сессий, распределенная блокировка. Даже Rate Limiter можно построить!

Разворачиваем 1 узел. Но это звучит немного неотказоустойчиво. Лучше кластер с мастерами и репликами. Асинхронная репликация будет осуществляться благодаря gossip протоколу.

Персистентность обеспечим либо с помощью Append-Only-File (AOF), либо с Redis DB (RDB). У каждого способа есть свои особенности. Помним, что редис однопоточный (!) в смысле работы с данными. По крайней мере, до недавнего времени был таковым.

Ближе к середине доклада рассказ зашёл о тюнинге — какие параметры можно докручивать в ОС. Далее следовало сравнение с «убийцей Redis» — Dragonfly. По-крайней мере, кому-то хотелось так выглядеть. Но разработчики Редиса провели свои тесты и показали, что старину Remote DIctionary Server рано отправлять на покой. Их тесты оказались круче.

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

А как Вы использовали Редис? Какие нагрузки держал 1 инстанс, кластер?

А теперь поиграем в прятки…

Тайное место

В одной черной-чёрной комнате... Нет. Здесь света достаточно. Что же это?

В одной черной-чёрной комнате… Нет. Здесь света достаточно. Что же это?

Докладная часть мероприятия является 2ой из 3ёх активностей конференции. В какой-то момент я понял, что хочу получать информацию с 2ух докладов одновременно. Трансляция с основного зала доступна в онлайн всем! Значит я смогу слушать её находясь в другом зале или шатре на другом докладе и распараллелить в 2 потока получение информации! Ведь мозг так умеет воспринимать?!

Уже ближе к концу конференции я вспомнил слова про реальный бункер на территории конференции. Оказалось, что в нём установлено оборудование для трансляции всех (ну, или почти) докладов! Снеки, пледы, наушники — всё в твоём распоряжение!

Игры, мерч, дискуссии

Здесь каждый найдёт активность по душе.

Здесь каждый найдёт активность по душе.

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

На мой взгляд, конференция интересна в том числе и тем, что в течение дня или в конце на after party можно обсудить со специалистами такие темы как «Что лучше — Redis или Tarantool? Почему взлетел Kotlin? Победит ли всех Go или это лишь хайп?». Что мы и делали) Кстати, а какое Ваше мнение по этим вопросам?

До свидания наш ласковый…

Хорошая погода - ещё один приятный бонус.

Хорошая погода — ещё один приятный бонус.

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

Думаю, если бы они руководствовались принципом «И так сойдёт» — такой лёгкости и уровня организации никак не получилось бы достичь. Впрочем, как и в системах, описанных докладчиками. В них подсвечивались очередные вызовы, детали и боли, с которыми пришлось столкнуться. А также чувствовалась радость от очередных побед и готовность к обработке всё больших нагрузок.

P.S. На своём tm канале, посвященном архитектуре высоконагруженных приложений провожу архитектурные каты с коллегами, пишем актуальные посты, веду System Design Interview. Если интересно, добро пожаловать в system_design_world:)

© Habrahabr.ru