Телеграмм канал RU FinOps Новости FinOps на русском языке

Подкаст "Монетизация" Деньги в Tech

Основы FinOps: Резервирование облачных ресурсов

Основы FinOps: Резервирование облачных ресурсов

Резервирование ресурсов в облаке

Резервирование представляет собой эффективный инструмент, который может помочь снизить расходы в облаке или наоборот поможет потратить зазря огромную кучу денег, в зависимости от того насколько грамотно его применять. Поэтому сегодня нам предстоит разобраться в концепции резервирования, различиях между reserved instances и savings plans, а также обсудить возможные риски и подводные камни.

Что такое резервирование

Согласно официальной документации Яндекс.Облака резервируемое потребление — это соглашение на получение гарантированной скидки при использовании определенного объема сервисов в течение 6 месяцев или 1 года. Клиент соглашается на потребление определенных ресурсов в течение фиксированного времени, а провайдер предоставляет ему скидку на эти ресурсы. Это как если бы продавец из ближайшей булочной предложил вам возможность покупать хлеб всегда на 20% дешевле от сегодняшней розничной цены при условии, что вы будете брать по крайней мере 1 батон каждый день в течение года. Давайте запомним формулировку “вы обязаны покупать в этой булочной 1 батон каждый день”, далее она нам еще пригодится.

Почему резервирование ресурсов выгодно компаниям

Облачные провайдеры как и любой другой бизнес имеют постоянные и переменные расходы. А доходы провайдеров весьма нестабильны и зависят от потребления клиентами ресурсов. В этой ситуации, чтобы минимизировать возникновение кассовых разрывов, облачные провайдеры предпочитают условные гарантированные 80 копеек 1 негарантированному рублю. Более того, предоставление потенциальных скидок является способом конкурировать с другими поставщиками облачных услуг и привлечь больше клиентов на свою платформу.

Почему резервирование выгодно потребителям

Помимо очевидного снижения уровня затрат часто называются гарантированное предоставление мощности, предсказуемость затрат и фиксация цен. Если отбросить рекламные уловки, реальная ценность резервирования заключается в том, что это один из самых простых и очевидных способов экономить деньги на облаке. Однако важно держать в голове и подводные камни, из-за которых зарезервировав ресурсы вы потеряете деньги, а не сэкономите их.

Почему резервирование может быть не выгодно потребителям? ТОП-5 рисков резервирования

Перед тем, как взять на себя обязательства по потреблению, необходимо подумать о соответствующих рисках.

ТОП-5 рисков резервирования Пример из мира зарезервированных батонов
1 Отказаться от зарезервированных ресурсов нельзя. Если по каким-то причинам они перестанут быть нужными, вы не сможете их просто отключить или перестать платить за них. Не хотим больше покупать батоны, хотим сесть на диету.
Не выйдет, ведь:
Вы обязаны покупать в этой булочной 1 батон каждый день.
2 Зарезервированные ресурсы ограничивают возможность сменить облачного провайдера. Соседняя булочная теперь продает более вкусный хлеб, да еще и в 2 раза дешевле, будем покупать там?
Не выйдет, ведь:
Вы обязаны покупать в этой булочной 1 батон каждый день.
3 Избыточное резервирование. Так бывает, что зарезервировали допустим виртуальную машину (ВМ) определенного типа для какой-то цели, а потом в рамках оптимизации и последовательного применения различных finops практик выяснилось, что для этих целей хватило бы ВМ с более простой конфигурацией и вдвое меньшей ценой "из коробки" без всякого резервирования. Оказалось, что на утренние бутерброды хватит 6 кусочков хлеба. Будем покупать полбатона?
Не выйдет, ведь:
Вы обязаны покупать в этой булочной 1 батон каждый день.
4 Иногда убежденность "вот уж эти-то ВМ мы точно будем использовать именно в такой конфигурации ближайшие 3 года" разбивается о новые сервисы, технологии, быстрое развитие вашего бизнеса и IT сферы в целом. Вы будете вынуждены использовать оплаченные ВМ даже если они в какой-то момент окажутся для вашей ситуации не лучшим решением. У пекаря появились невероятно вкусные пирожные. Будем покупать их вместо батона?
Не выйдет, ведь:
Вы обязаны покупать в этой булочной 1 батон каждый день.
5 Резервирование предполагает использование ресурсов в течение 24 часов в сутки, 7 дней в неделю. Однако может выясниться, что некоторые ресурсы не используются постоянно. Например, возможно вы можете запускать дев серверы только в рабочее время и выключать их ночью и в выходные. Оказывается бутерброды вы едите только по будням перед тем как ехать на работу. Перестаем покупать хлеб в выходные?
Не выйдет, ведь:
Вы обязаны покупать в этой булочной 1 батон каждый день.

Необходимость осознавать, что при классическом резервировании мы получаем скидку, но платим за это серьезным уменьшением гибкости. При этом размер скидки растет вместе с увеличением срока резервирования, но одновременно с этим растет и риск наступления одного из описанных выше случаев. Размер скидки может зависеть также и от других параметров, например наличия предоплаты, региона, операционной системы резервируемых ресурсов и т.д. и т.п. в зависимости от облачного провайдера.

Reservation Bread

Как уменьшить риски? Что такое Savings Plans и в чем их отличие от reserved instances?

Обжигаясь на рисках резервирования клиенты облачных провайдеров все неохотнее резервировали ресурсы, ведь как мы уже выяснили это потеря гибкости, а именно гибкость является одним из ключевых преимуществ инфраструктуры в облаке. При этом облачным провайдерам все так же нужны были “гарантированные” деньги и вниманию потребителей была предложена концепция Savings Plans, своего рода резервирование 2.0. Используя всю ту же аналогию с пекарем, вы договариваетесь с ним не о том, что “вы обязаны покупать в этой булочной 1 батон каждый день”, а взамен для вас 1 батон стоит не 1 рубль, а 80 копеек, а о том, что “вы обязаны покупать в этой булочной что-то на сумму 80 копеек каждый день”, а взамен для вас вся продукция, которую вы наберете на эти 80 копеек, будет отдаваться со скидкой.

Подход Savings Plans предлагает потребителям значительно большую гибкость нейтрализуя 3 из 5 топовых риска описанных выше, ведь тип и количество ресурсов можно корректировать в зависимости от меняющейся ситуации. Чтобы проиллюстрировать разницу между классическим резервированием и savings plans, добавим еще один столбец к таблице выше.

ТОП-5 рисков резервирования Классическое резервирование, подход Reserved instances Резервирование 2.0, подход Savings Plans
1 Отказаться от зарезервированных ресурсов нельзя. Если по каким-то причинам они перестанут быть нужными, вы не сможете их просто отключить или перестать платить за них. Не хотим больше покупать батоны, хотим сесть на диету.
Не выйдет, ведь: Вы обязаны покупать в этой булочной 1 батон каждый день. Не выйдет, ведь: Вы обязаны покупать в этой булочной что-то на сумму 80 копеек каждый день.
2 Зарезервированные ресурсы ограничивают возможность сменить облачного провайдера. Соседняя булочная теперь продает более вкусный хлеб, да еще и в 2 раза дешевле, будем покупать там?
Не выйдет, ведь: Вы обязаны покупать в этой булочной 1 батон каждый день. Не выйдет, ведь: Вы обязаны покупать в этой булочной что-то на сумму 80 копеек каждый день.
3 Избыточное резервирование. Так бывает, что зарезервировали допустим виртуальную машину (ВМ) определенного типа для какой-то цели, а потом в рамках оптимизации и последовательного применения различных finops практик выяснилось, что для этих целей хватило бы ВМ с более простой конфигурацией и вдвое меньшей ценой "из коробки" без всякого резервирования. Оказалось, что на утренние бутерброды хватит 6 кусочков хлеба. Будем покупать полбатона?
Не выйдет, ведь: Вы обязаны покупать в этой булочной 1 батон каждый день. Легко: Теперь будем покупать полбатона, а на остаток денег будем покупать кофе.
4 Иногда убежденность "вот уж эти-то ВМ мы точно будем использовать именно в такой конфигурации ближайшие 3 года" разбивается о новые сервисы, технологии, быстрое развитие вашего бизнеса и IT сферы в целом. Вы будете вынуждены использовать оплаченные ВМ даже если они в какой-то момент окажутся для вашей ситуации не лучшим решением. У пекаря появились невероятно вкусные пирожные. Будем покупать их вместо батона?
Не выйдет, ведь: Вы обязаны покупать в этой булочной 1 батон каждый день. Легко: Отказываемся от батонов, на эти деньги покупаем пирожные.
5 Резервирование предполагает использование ресурсов в течение 24 часов в сутки, 7 дней в неделю. Однако может выясниться, что некоторые ресурсы не используются постоянно. Например, возможно вы можете запускать дев серверы только в рабочее время и выключать их ночью и в выходные. Оказывается бутерброды вы едите только по будням перед тем как ехать на работу. Перестаем покупать хлеб в выходные?
Не выйдет, ведь: Вы обязаны покупать в этой булочной 1 батон каждый день. Легко: По будням покупаем батоны, а по выходным пироги.

Обратите внимание, что на примерах 3 и 5 хорошо видно, что мы не сможем отказаться от трат ни в случае классического резервирования, ни в случае Savings Plans. Однако в случае классического резервирования мы должны будем потреблять строго то, что зарезервировали, а в случае Savings Plans мы можем перераспределить эти средства на другие нужды и поменять тип и количество используемых ресурсов.

Что же выбрать, Savings Plans или Reserved instances? Однозначного ответа на этот вопрос нет. Чтобы принять правильное решение, необходимо обсудить вопрос с командой, тщательно оценить свою ситуацию, выгоду и риски. В большинстве случаев наиболее выгодным вариантом является комбинация классического резервирования ресурсов и использование savings plans либо применение только savings plans.

Стоит учесть, что некоторые облачные провайдеры вообще не предоставляют возможности для резервирования ресурсов, а у других есть только классические reserved instances. Например, в яндекс.облаке аналогом reserved instances является “резервируемое потребление”, а аналога Savings Plans на момент написания статьи нет.

Очень важный нюанс

Чтобы минимизировать риски резервирования ресурсов, перед его включением важно убедиться, что вы уже провели rightsizing (райтсайзинг). Райтсайзинг - это процесс подбора оптимальных параметров используемых ресурсов, в соответствии с требованиями бизнеса к производительности при изменчивой рабочей нагрузке при минимально возможных затратах. Используя полюбившуюся нам аналогию с пекарем, это процесс поиска ответа на вопрос, что лучше купить, чтобы было вкусно, сытно и одновременно недорого? Действительно нужно ли нам каждый день покупать один батон, или лучше покупать полбатона и чашечку кофе по будням, а на выходные - пироги? В профессиональной среде известны случаи, когда компании сначала проводили резервирование на потенциальные сотни тысяч долларов, потом проводили райтсайзинг и выяснялось, что на самом деле для выполнения тех же бизнес-задач необходимы ресурсы на вдвое меньшую сумму. Чтобы не повторять таких ошибок, проведите райтсайзинг и выберите вариант резервирования с минимальными рисками для вашего бизнеса. Этот подход потенциально позволит сэкономить 10-30% от общей стоимости облачных ресурсов и перенаправить эти средства на другие важные бизнес-задачи.

Примечания:

  1. Статья написана в феврале 2024 года и имеет актуальные данные на эту дату. Основные принципы резервирования еще долго будут оставаться такими же, а вот любую техническую информацию, представленную для наглядности, рекомендуется перепроверить в официальной документации облачных провайдеров.
  2. В статье используются термины и определения соответствующие официальной документации aws и яндекс.облако. У других провайдеров терминология может отличаться, но суть резервирования остается такой же.