Инфраструктура
SeniorКакой размер кластера и политика автомасштабирования подходят для этой нагрузки?
Правильный размер кластера — не число, которое вы выбираете один раз, а политика, которую вы настраиваете исходя из того, как нагрузка реально себя ведёт, и пересматриваете по мере изменения этого поведения.
«Насколько большим должен быть кластер» — неверный вопрос. Правильный: «какая кривая утилизации реально характерна для этой нагрузки, и какая политика ей соответствует» — у батчевой задачи с резким часовым пиком ответ совершенно другой, чем у стабильной потоковой задачи.
Задавайте нижнюю границу от стабильной нагрузки, а не от пика
Минимум автомасштабирования должен покрывать базовую нагрузку с запасом на нормальные колебания — не тот пик, который вы иногда видите. Установка нижней границы по пиковой нагрузке означает оплату мощности, которую вы используете лишь малую часть времени — это в точности та же проблема «фиксированного размера кластера», ради решения которой существует автомасштабирование, просто воссозданная другим способом.
Задавайте верхнюю границу исходя из реального разговора о стоимости, а не «насколько потребуется»
Неограниченный максимум автомасштабирования защищает доступность, но убирает всякий потолок по стоимости — неудачный запрос, шторм повторов или неожиданный всплеск трафика могут разогнать кластер (и счёт за него) далеко за пределы задуманного. Устанавливайте максимум исходя из явного «сколько мы готовы платить в худшем случае», а не только из технической возможности.
Настраивайте чувствительность масштабирования под форму задачи
Батчевая нагрузка с резким, предсказуемым пиком (например, почасовой ETL-прогон) выигрывает от агрессивного масштабирования вверх — лучше кратковременно переоценить мощность, чем дать задаче встать в очередь за медленным масштабированием. Стабильная потоковая задача выигрывает от обратного: более медленное, консервативное масштабирование вверх избегает «дребезга» (масштабирование вверх и сразу обратно вниз) на нормальных минутных колебаниях, что само по себе несёт расходы на провижининг/депровижининг.
Цифра, которая на самом деле должна определять это решение: средняя утилизация CPU/памяти по executor'ам во время реальных прогонов, а не синтетического нагрузочного теста. Правило числа инстансов в opti-pipe сравнивает настроенное число executor'ов с реально наблюдаемой утилизацией в вашем event log и срабатывает повторно с скорректированным числом, если более поздняя загрузка покажет, что утилизация сместилась с момента последнего одобренного изменения — оно не предполагает, что форма вашей нагрузки статична больше, чем следует.
Посмотрите, как это выглядит на вашем собственном пайплайне.
Загрузите реальный event log Spark, run_results.json от dbt или экспорт метрик Flink — и получите конкретные рекомендации, которые нужно одобрить, а не ещё одно эмпирическое правило.