Основы 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 батон каждый день. |
Необходимость осознавать, что при классическом резервировании мы получаем скидку, но платим за это серьезным уменьшением гибкости. При этом размер скидки растет вместе с увеличением срока резервирования, но одновременно с этим растет и риск наступления одного из описанных выше случаев. Размер скидки может зависеть также и от других параметров, например наличия предоплаты, региона, операционной системы резервируемых ресурсов и т.д. и т.п. в зависимости от облачного провайдера.
Как уменьшить риски? Что такое 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% от общей стоимости облачных ресурсов и перенаправить эти средства на другие важные бизнес-задачи.
Примечания:
- Статья написана в феврале 2024 года и имеет актуальные данные на эту дату. Основные принципы резервирования еще долго будут оставаться такими же, а вот любую техническую информацию, представленную для наглядности, рекомендуется перепроверить в официальной документации облачных провайдеров.
- В статье используются термины и определения соответствующие официальной документации aws и яндекс.облако. У других провайдеров терминология может отличаться, но суть резервирования остается такой же.