Как выбрать подходящую модель закупки вычислительных ресурсов (on-demand, reserved/committed use, spot/preemptible) для разных частей системы: веб-фронтенд с постоянной базовой нагрузкой, батч-обработка данных ночью и редкие нагрузочные тесты?

Короткий ответ

Для предсказуемой базовой нагрузки фронтенда выгоднее reserved/committed-ёмкость, для разовых непредсказуемых всплесков — on-demand, а для прерываемой batch-обработки, устойчивой к перезапуску, — spot/preemptible по значительно более низкой цене; решение зависит от критичности непрерывной работы каждой части.

Как это работает подробнее

committed-модели дают скидку в обмен на обязательство платить за ёмкость, поэтому оправданы только для стабильно используемой базовой нагрузки; spot-ёмкость может быть отозвана провайдером с коротким предупреждением, что требует от задачи устойчивости к прерыванию (чекпоинты, повторный запуск).

Пример кода

example.txtКопировать

Web frontend baseline (24/7, предсказуемо):     Committed use / Reserved
Web frontend burst (непредсказуемые пики):      On-demand autoscaling
Nightly batch ETL (устойчив к рестарту):        Spot / Preemptible
Разовый нагрузочный тест (несколько часов):     On-demand

Что использовать на практике

• Рекомендация. распределяют нагрузку по «слоям» — базовый уровень трафика покрывают committed-ёмкостью, пиковую часть добавляют on-demand или spot, batch-джобы запускают на spot с логикой чекпоинтов и повторной постановки в очередь при прерывании.
• Проверка. суммарная стоимость вычислений за месяц должна снизиться по сравнению со сценарием «всё на on-demand» при сохранении требуемого уровня доступности критичных частей.

Подводные камни

• Риск. покупать committed-ёмкость под пиковую нагрузку «про запас», переплачивая за простаивающие ресурсы
• Риск. запускать на spot единственный критичный инстанс без резервирования на случай отзыва
• Риск. не закладывать в batch-джобы обработку сигнала прерывания spot, теряя прогресс выполнения.