Вычисления в облаке: ВМ, spot, managed k8s
Выбор способа запуска сводится к трём вопросам: как быстро появляется новая мощность, за что вы платите в простое и сколько эксплуатации остаётся на вас. Виртуальная машина появляется минуты и оплачивается всегда, даже когда ничего не делает. Контейнер в управляемом кластере - секунды, но кластер оплачивается постоянно. Функция появляется мгновенно и в простое стоит ноль.
Стержень: платите вы либо за время владения, либо за фактические вызовы; выбор определяется профилем нагрузки, а не модой.
// Формулировки: «когда брать функции?», «зачем прерываемые машины?», «что снимает управляемый кластер?»
Что чем оплачивается
Виртуальная машина оплачивается за время существования. Ровная предсказуемая нагрузка на ней дешевле всего, особенно с обязательством на год - обычно это скидка в полтора-два раза. Плохо она подходит для редких пиков: платите за пиковую мощность круглосуточно.
Функции оплачиваются за число вызовов и потраченное время работы. Для редких задач это буквально копейки, потому что в простое вы не платите вовсе. Плата - холодный старт (первый вызов после паузы медленнее), предел времени выполнения и ограниченный контроль над окружением.
// Прерываемые машины - отдельный приём: та же мощность за 30-70% цены, но провайдер вправе отобрать её в любой момент с коротким предупреждением. Годится для того, что переживает внезапную остановку: пакетная обработка, сборка, обучение моделей с сохранением промежуточных результатов, часть экземпляров приложения, не хранящих у себя состояние. Не годится для баз и для того, что нельзя перезапустить.
- оплата за владение
- платите за время существования машины, независимо от нагрузки
- оплата за вызовы
- платите за число обращений и время работы; в простое ноль
- прерываемая машина
- дешевле в разы, но может быть отобрана в любой момент
Как выбрать по профилю нагрузки
Ровная нагрузка круглосуточно - машины с обязательством, это самый дешёвый вариант за единицу мощности. Дневной профиль с ночным провалом - машины плюс автоматическое масштабирование или расписание. Редкие всплески раз в час - функции, потому что 23 часа в сутки вы не платите ни за что.
Отдельно считается фоновая обработка: очереди, отчёты, перекодирование. Она обычно терпит задержку и остановку, а значит, идеально ложится на прерываемые машины и даёт самую большую экономию из всех решений.
// Полезная проверка: посмотреть загрузку за неделю и посчитать, какую долю времени мощность реально используется. Если машина занята 8% времени - это кандидат на функции или на расписание. Если 70% и ровно - кандидат на обязательство со скидкой. Это разговор на цифрах, а не на предпочтениях.
- обязательство
- договор на год вперёд в обмен на скидку в полтора-два раза
- холодный старт
- первый вызов функции после паузы заметно медленнее
Что снимает управляемый кластер
Кластер - это группа машин, которые работают как одна и сами раскладывают по себе приложения. Управляемый кластер снимает с вас его управляющую часть: точку входа, хранилище состояния, планировщик, их обновление и отказоустойчивость. Это ровно та часть, где ошибка стоит дороже всего и где своими силами приходится держать людей с редкими знаниями.
Что остаётся вашим: рабочие узлы и их размер, обновления версий кластера (запускаете вы, по своему графику), правила размещения, права, сеть внутри кластера, мониторинг и, конечно, сами приложения. То есть кластер перестаёт быть проектом по эксплуатации, но не перестаёт быть вашей ответственностью.
// Практическая деталь про обновления: у управляемого кластера есть окно поддерживаемых версий, и старую версию однажды перестают поддерживать принудительно. Планировать обновления надо заранее, потому что между версиями меняются интерфейсы описаний, и однажды применение старого описания просто перестанет работать.
- управляющая часть
- точка входа, хранилище состояния, планировщик; их берёт на себя провайдер
- окно версий
- набор поддерживаемых версий; старые отключают принудительно
Как отвечать: «Когда брать функции вместо обычных машин?»
Когда нагрузка редкая и рваная. Машина оплачивается за время существования, поэтому под всплеск раз в час вы платите круглосуточно за пиковую мощность. Функция оплачивается за вызовы и время работы, и в простое стоит ноль - для задачи, которая срабатывает пару минут в час, разница на порядок. Плата за это известная: холодный старт, то есть первый вызов после паузы заметно медленнее; предел времени выполнения; ограниченный контроль над окружением и версиями. Поэтому под ровную круглосуточную нагрузку функции обычно дороже машин, а под фоновую обработку, которая терпит остановку, я вообще беру прерываемые машины - та же мощность за треть цены с риском, что её отберут. Проверяю выбор просто: смотрю за неделю, какую долю времени мощность реально используется.
Ответ сравнивает по модели оплаты, честно называет минусы функций и добавляет третий вариант для фоновой работы. Проверка через долю использования переводит спор в цифры.
На чём валятся
- −Берут функции под ровную круглосуточную нагрузку и платят больше, чем за машину.
- −Не учитывают холодный старт там, где важна задержка первого запроса.
- −Ставят базу на прерываемую машину.
- −Считают, что управляемый кластер снимает всю эксплуатацию: узлы, права и обновления остаются.
- −Не планируют обновление версии кластера и упираются в принудительное отключение старой.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 6, остальные разбираются в тренажёре.
- Когда для задачи берут функцию (serverless), а не контейнер в кластере?A)Когда нужна максимальная предсказуемость задержки под нагрузкойB)Когда нагрузка редкая и рваная, а холодный старт терпимC)Когда сервису нужен постоянный пул соединений к базеD)Когда требуется полный контроль над рантаймом и версиями
показать ответ и разбор
+B)Когда нагрузка редкая и рваная, а холодный старт терпим// разбор: Функции хороши там, где нагрузка появляется эпизодически: обработчики событий, вебхуки, редкие задания. Платите за вызовы, инфраструктуры не держите. Расплата — холодный старт, ограничения по времени и памяти, отсутствие состояния и сложности с пулами соединений к базе. Ровный поток запросов и жёсткие требования к задержке дешевле и предсказуемее обслуживать контейнерами.
- Прерываемые машины дешевле в разы. Какие нагрузки на них ставят?A)Базы данных: репликация всё равно защитит от потери узлаB)Входные балансировщики: их легко пересоздатьC)Управляющие узлы кластера: они не держат пользовательский трафикD)Пакетные задачи и обработчики очередей
показать ответ и разбор
+D)Пакетные задачи и обработчики очередей// разбор: Провайдер вправе отобрать такую машину за считанные секунды предупреждения. Значит, годится всё, что можно прервать и повторить: пересчёт отчётов, обработка очередей, сборки, тестовые окружения. Нагрузку с состоянием и точки входа туда не ставят. На практике держат смешанные группы: базовая часть на обычных машинах, пиковая — на прерываемых, с корректной обработкой сигнала об отзыве.
- Перешли на управляемый Kubernetes. Что всё равно остаётся вашей заботой?A)Обновление версий, ресурсы и лимиты, сетевые политики, стоимостьB)Доступность управляющего слоя и резервные копии его состоянияC)Установка и обновление компонентов управляющего слояD)Ничего существенного: провайдер отвечает за кластер целиком
показать ответ и разбор
+A)Обновление версий, ресурсы и лимиты, сетевые политики, стоимость// разбор: Провайдер берёт на себя управляющий слой: доступность, обновления, копии состояния. Всё, что выше, остаётся вам — планирование обновлений версий и совместимость нагрузок, запросы и лимиты подов, сетевые политики, права доступа, наблюдаемость, обслуживание узлов при обновлении и, отдельной строкой, расходы: кластер легко превращается в самый дорогой счёт месяца.
- Что даёт группа автомасштабирования (autoscaling group), кроме изменения числа машин по нагрузке?A)Ускоряет отдельную машину, поднимая ей частоту CPUB)Самолечение: заменяет упавшую/непрошедшую проверку машину новойC)Сгоняет машины группы в одну AZD)Хранит данные упавшей машины и переносит на новую
показать ответ и разбор
+B)Самолечение: заменяет упавшую/непрошедшую проверку машину новой// разбор: Группа автомасштабирования держит заданное число здоровых инстансов и по политикам меняет его под нагрузку. Помимо масштабирования это ещё и самолечение: если инстанс упал или не прошёл health-check, ASG выводит его и поднимает новый по шаблону — состав группы сходится к desired capacity. Раскидывание по нескольким AZ даёт отказоустойчивость. Данные при этом должны жить вне инстанса (диски/хранилище), потому что инстансы эфемерны.
- Есть стабильная круглосуточная базовая нагрузка на on-demand машинах. Как законно сократить счёт?A)Перевести базовую нагрузку на прерываемые (spot) машиныB)Просто удалить часть машин и терпеть перегрузкуC)Взять обязательства (reserved / savings plan) на базовый объёмD)Почаще перезапускать машины, чтобы сбрасывать тариф
показать ответ и разбор
+C)Взять обязательства (reserved / savings plan) на базовый объём// разбор: Стабильную, предсказуемую базовую нагрузку выгодно покрывать обязательствами: reserved instances / savings plans / committed use дают заметную скидку к on-demand в обмен на коммит по объёму на 1–3 года. On-demand оставляют под переменную часть, а прерываемые (spot) — под то, что переживёт отзыв (батчи, обработчики очередей). Комбинация «коммит на базу + on-demand/spot на пики» и есть типичная оптимизация под профиль нагрузки.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.