Всем, привет! Это не глубокая техническая статья и не исследование. Тема просто не влезла в формат поста в моём Telegram-канале https://t.me/starrocks_selena, поэтому мы с вами тут. Это пятничный лёгкий длиннопост про автоскейлинг StarRocks. Без глубокого погружения в архитектуру, с мЭмами и несколькими наблюдениями из практики.
Проблематика
Представьте, 28 дней в месяц аналитический кластер/БД потребляет ресурсы равномерно. Регламентные отчеты, привычные дашборды, пересчеты витрин. В среднем около 60% ресурсов. И вот наступают самые тяжелые три дня месяца. Закрытие периода, массовые выгрузки, аналитики разом открывают отчеты. В этот момент кластеру нужно в разы больше мощности, чем обычно.
Держать тройной запас постоянно дорого, потому что большую часть месяца он простаивает. Без запаса пик упирается в потолок и запросы встают в очередь.
Долгое время эту задачу решали через сайзинг под пиковую нагрузку. Если расчет делал опытный архитектор, инженер или DBA, пики просто закладывались в конфигурацию. То, что большую часть времени серверы работают с низкой загрузкой, считалось платой за спокойный отчетный период. Особенно заметно это было с Exadata и похожими ПАК. Конфигурации фиксированы, шаг масштабирования крупный, поэтому нередко приходилось покупать больше ресурсов, чем требуется для повседневной нагрузки.
Режим Shared-data в StarRocks отчасти появился как раз для того чтобы эту проблему решить, полностью или частично.
StarRocks и K8s спешат на помощь
Классический режим StarRocks, shared-nothing, хранит данные на локальных дисках BE-узлов: каждый узел и хранит, и считает. Добавить узел — значит перенести на него tablets и выполнить rebalance. Это небыстрая операция.
Shared-data — это режим развертывания StarRocks, при котором у вас данные лежат на едином удаленном хранилище (S3-хранилище или HDFS), а вычислительные компоненты развернуты отдельно от хранения.
Вычислительные компоненты в Shared-data режиме называются Compute Node (CN). Сами по себе они stateless, так как предназначены только для вычислений. У CN есть локальный кэш, обычно на SSD или NVMe. В него попадают данные, прочитанные из S3-хранилища, поэтому повторные запросы выполняются быстрее, так как читать из S3-хранилища — это всегда доп. нагрузка на сеть и, соответственно, лишняя latency (больше/меньше зависит от пропускной способности сети и профиля запросов).
Работать StarRocks в K8s помогает StarRocks Operator. Это контроллер, который живет внутри Kubernetes и управляет StarRocks сам. Он вводит свой тип объекта StarRocksCluster: в нем описан весь кластер — роли (FE, BE, CN), число узлов, образы, ресурсы, хранилище, настройки. По этому описанию оператор разворачивает компоненты как StatefulSet, поднимает сервисы и конфигурации, раскатывает обновления и постоянно приводит кластер к заданному виду. Масштабировать руками не нужно, достаточно поменять описание. Для CN оператор берет на себя и автоскейл: по секции autoScalingPolicy он создает HPA, а при сокращении сначала корректно выводит ноду из кластера и только потом останавливает под. Но дальше, я подробней опишу механику.
И здесь две вещи складываются вместе. CN ничего не хранят, pod с CN поднимается и гасится за секунды, переносить на него нечего. А Kubernetes как раз умеет менять число подов под нагрузку. Stateless-вычисления над общим хранилищем плюс оркестратор, который добавляет и убирает поды. На этой связке и стоит автоскейлинг StarRocks.
StarRocks ничего не решает
Решает когда мастштабироваться, а когда нет не сам StarRocks. Решает Kubernetes, а точнее его встроенный автоскейлер, HPA (Horizontal Pod Autoscaler). Разворачивает и настраивает кластер оператор: служебная программа, которая ставит StarRocks и держит его в заданном виде. В настройках оператора мы один раз задаем параметры и границы: нод CN от 1 до 12, ориентир по загрузке 60%. Дальше оператор сам поднимает автоскейлер и привязывает его к группе CN, руками ничего трогать не нужно.
Работает все на простом цикле. Рядом крутится metrics-server (в k3s он есть сразу) и каждые 15 секунд снимает загрузку CPU с каждой ноды. Автоскейлер берет эти цифры, усредняет по всем CN и сравнивает с ориентиром 60%.
Если среднее ушло выше 60%, то нод не хватает, и он добавляет новые, по паре за раз, чтобы быстро снять пик. Сколько добавить, считается так: текущее число нод умножается на то, во сколько раз загрузка выше верхней планки. Загрузка под 200% при цели 60% — значит, нужно примерно втрое больше нод, чтобы та же работа размазалась до спокойных 60% на каждую.
Если упало среднее надолго ниже 60%, то лишние ноды убираются по одной. Тут автоскейлер действует осмотрительней: сначала ждет около минуты и только потом начинает сворачивать. Без этой паузы кластер скакал бы числом нод на каждом коротком затишье.
Включается это в одном блоке описания кластера, секция CN (добавил описание каждого параметра):
starRocksCnSpec: # секция compute-нод (CN) в описании кластера
# replicas здесь НЕ указываем: фиксированное число спорит с автоскейлом — количеством нод рулит HPA
requests:
cpu: 1 # 1 ядро в брони; именно от requests считается % загрузки
memory: 3Gi # 3 GiB памяти в брони
limits:
cpu: 2 # максимум 2 ядра на под
memory: 6Gi # максимум 6 GiB памяти
autoScalingPolicy:
minReplicas: 1 # ниже одной ноды не опускаемся
maxReplicas: 5 # выше пяти не поднимаемся — верх коридора
hpaPolicy:
metrics: # показатель, по которому скейлим
- type: Resource # ресурсная метрика самого пода (CPU/память)
resource:
name: cpu # смотрим на CPU
target:
type: Utilization # считаем в процентах от requests
averageUtilization: 60 # цель: средний CPU по всем CN держать около 60%
behavior: # скорость и осторожность реакции
scaleUp: # как растем под нагрузкой
policies:
- type: Pods # шаг считаем в подах
value: 2 # добавляем по 2 пода
periodSeconds: 15 # каждые 15с, пока CPU выше цели — быстро снять пик
scaleDown: # как сворачиваемся на спаде
stabilizationWindowSeconds: 60 # ждем минуту низкой нагрузки, чтобы не мигать числом нод
policies:
- type: Pods # шаг в подах
value: 1 # убираем по 1 поду
periodSeconds: 30 # не чаще раза в 30сА в чем тогда экономия?
Вопрос всплывает почти сразу: какая экономия, если под расширение все равно надо держать ресурсы зарезервированными? Идея пришла из облаков, и там все сходится: оплата по факту, pay-as-you-go. Если поды растут, то облако поднимает виртуалки, нагрузка ушла виртуалки гасятся, в счете остаются только часы, что машины реально работали.
На локальной инфраструктуре у заказчика все зависит от того, что еще живет в кластере. Если на k8s крутится один только StarRocks, экономия действительно сомнительная: машины под пик из пяти CN все равно должны стоять, иначе новым подам некуда разворачиваться, и как говорится в простое они просто простаивают.
Другое дело, если общий кластер компании, где рядом живут десятки систем, разнесенных по namespace со своими квотами. Железо там берут под совокупный пик, и он меньше суммы отдельных пиков: разные нагрузки взлетают в разное время. StarRocks занял пять CN на свои три дня в месяц, а в остальные дни эти ресурсы забирают соседи: ночные батчи, отчетность другого отдела, dev-стенды. Автоскейл экономит здесь заметнее: одно и то же железо успевает поработать на разных проектах.
А работает ли автоскейлинг у StarRocks?
Да, работает. Быстро покажу, что видно при настроенном автоскейлинге:
Шаг 1. До запуска запросов:
Шаг 2. Нормальная работа, работает один CN:
Шаг 3. Автоскейлинг, до 5 CN:
Шаг 4: Остановка и полный цикл:
Мне показалось, что будет круто исследовать пограничный случай и посмотреть, что будет с запросами в БД, когда автоскейлинг съест все доступные ресурсы.
Стенд и данные
k3s, 3 ноды, суммарно ~24 vCPU и ~93 GB.
Selena 2.0.7 (это наш дистрибутив, взял его, потому что он под k8s-инфраструктуру уже готов). Данные — coffee.sales: 2 097 152 строки продаж кофе по шести городам. Это мой старый датасет, я его часто показываю в разных демосценариях.
Перед прогоном я командой cordon запретил Kubernetes ставить новые поды на control-plane-ноду, поэтому новые CN поднимаются только на двух рабочих нодах. Так я, во-первых, не нагружаю управляющий слой кластера (apiserver и etcd), во-вторых, заранее знаю предел: два воркера — это примерно 16 ядер, и автоскейл упрется именно в них.
Автоскейл CN включается прямо в описании кластера: requests 2 ядра / 4 GiB, limits 3 ядра / 6 GiB, коридор 1–12 нод, цель по CPU — 60%. Оператор по этому описанию сам создал HPA и подключил его к группе CN.
Сам тест
Генерация нагрузки состояло из двух частей.
64 параллельных дашборд-запроса по coffee.sales (выручка по городам, топ позиций, средний чек) без пауз.
80 CPU-тяжелых запросов с математикой (pow/sin/cos/sqrt/ln) по всем двум миллионам строк.
Пока есть запас, скейлинг работает
Под первой нагрузкой CN рос ступенями: 1 → 3 → 6. И латентность при этом падала — примерно с 1000 до 350 мс. Больше нод, та же работа размазывается по ним, каждый запрос отвечает быстрее. Ровно то, ради чего автоскейл и нужен.
Потолок
Дальше пошла тяжелая нагрузка. CPU уперся в ~117% при цели 60%, и HPA поднял число нод до 12 (максимума). Но на два воркера поместилось только шесть CN, по ~2.5 ядра каждый. Остальные шесть повисли в Pending с понятной причиной:
FailedScheduling: 0/3 nodes are available: 1 node(s) were unschedulable, 2 Insufficient cpu.
Автоскейлер хочет двенадцать нод, а получает шесть. Расширяться некуда: свободные ядра кончились, новые поды не на что поставить. На графике это видно одним кадром — current упирается в 6, desired уходит к 12, а разрыв между ними и есть потолок.
Что стало с запросами?
Я взял audit-лог: в нем записана длительность каждого запроса.
Картина оказалась очень интересной. Обычный запрос остался быстрым: и до пика, и на потолке половина запросов отвечала примерно за 130–150 мс. Замедлились только самые тяжелые. До пика даже редкие медленные укладывались в ~0.8 с, а на потолке растянулись до ~2 с (самый долгий 2.6 с); средняя по всем запросам выросла с 0.24 до 0.63 с.
Причина тут простая: новых нод нет, процессора на всех разом не хватает. Легкие запросы проскакивают, тяжелые встают в очередь и ждут свободный CN. Мой probe гонял как раз тяжелый запрос, поэтому и показывал 1.5–2.5 с, он попадал в эту медленную группу.
Ошибок при этом почти не было ,а тут кстати дашборд меня чуть не обманул. Счетчик ошибок рос до ~170 в секунду (видно на графике), и сначала я решил, что запросы отваливаются. В логе оказалось другое: почти все это select $$ это служебный пинг, который mysql-клиент шлет на каждом подключении, а StarRocks его не понимает и отклоняет. Больше соединений под нагрузкой больше таких отказов, вот счетчик и реагировал на нагрузку.
А как только я снял нагрузку, probe снова отвечал за ~30 мс, CPU упал к нулю, и кластер свернул лишние CN обратно к одному. Замедление держалось ровно пока не хватало нод, и ушло вместе с нагрузкой.
Вывод по тесту
Автоскейл CN эластичен ровно до предела самого кластера. Пока на узлах есть свободные ядра, он добавляет ноды и держит latancy в норме. Кончились ядра (у нас было два воркера, 16 ядер) — задержка упирается в потолок: HPA продолжает просить ноды (хочет 12), а ставить их некуда, поды висят в Pending, и CPU так и стоит выше цели.
Важно, КАК это проявляется. Не падениями и не ошибками. Успешность запросов держится. Проявляется ростом задержки у тяжелых запросов: они встают в очередь за свободным узлом, а обычные запросы при этом отвечают как раньше.
Отсюда три практических вывода:
Автоскейл не отменяет сайзинг — на фиксированном кластере maxReplicas и ресурсы узлов надо ставить так, чтобы потолок был выше реального пика, иначе пик превратится в очередь на тяжелых запросах.
По-настоящему бесконечная эластичность появляется, только когда эластичны и сами ноды связка HPA и Cluster Autoscaler в облаке добавляет виртуалки под Pending-поды; на своем железе автоскейл экономит ресурсы между пиками, отдавая их соседям по кластеру, но не создает их сверх имеющихся.
Все что видите на графиках дашборда лучше перепроверить другими средствами.
Чтобы не пропустить:
🔹Подписывайтесь на этот блог на Habr
🔹Между статьями — новости StarRocks в Telegram-канале @starrocks_selena (https://t.me/starrocks_selena)