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 уже нужно хранить состояние на случай падения планировщика. Чтобы он мог корректно восстановиться и понять что уже было выполнено и это повторять не нужно.
Пример такой задачи — заказ пластиковых карт сотрудникам компаний-клиентов банка. Такие заказы формируются на основе поступающих списков и передаются в другую систему периодически. Повторный заказ карт несёт дополнительные затраты для банка. Если же пропускаем выпуск, то клиент может очень расстроиться.
Также была затронута тема тестирования самого планировщика на одной ноде и распределенного.
Этот доклад напомнил мне размышление на тему «что такое работающий код?». Это лишь код, который работает на проде? Или же нечто большее — сам код, тесты на него, использованные архитектурные паттерны, мониторинг, инструменты вокруг?
Были также освещены элементы планировщика:
Экземпляры
Планировщики
Задания
Триггеры
Доклад помог мне сделать следующие выводы:
Планировщик можно рассматривать как обычный сервис, которому свойственны все стандартные боли распределенной работы, коммуникации с другими сервисами.
Положиться на коробочное решение с интенцией — «Само работает, и так сойдёт» можно лишь после хорошего изучения специфики работы самого планировщика и рассмотрения различных кейсов его применения.
Мой вопрос после доклада был про понимание перехода от планировщика на одной ноде к распределенному решению. В ответ получил рекомендацию не доводить дело до момента, когда переезжать нужно вдруг и на большой масштаб. Что лучше постепенно подготавливать архитектуру, отлаживать кейсы использования на больших масштабах. Подстелить себе соломку.
Доклад №2. Опыт перевода банковского продукта в риалтайм
История об особенностях создания проекта с нуля с жесткими дедлайнами. Это был комбо доклад с 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
Кто бы мог подумать, что 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:)
