Экономика облачных приложений
Поставщики облачных решений (CSP) прилагают большие усилия, чтобы привлечь пользователей из традиционных развертываний. Цены на общедоступные облачные службы IaaS стремительно и неуклонно падают с момента их запуска. В среднем для большинства крупных CSP цены снижались на 20–30 % в год начиная с 2013 года.
Тем не менее, несмотря на снижение цен, внедрение облачных технологий все равно необходимо проводить осторожно. Чтобы в полной мере воспользоваться преимуществами облачных средств, нужно понимание, бюджетирование, планирование, мониторинг и тщательный анализ их использования. Кроме того, сложно выбрать CSP для отдельных вариантов использования, так как нет стандартного способа для упаковки ресурсов поставщиками, и они не всегда следуют одинаковым моделям ценообразования.
Модели ценообразования
Поставщики облачных служб обычно взимают плату за ресурсы на основе одного из следующих трех типов параметров.
- На основе времени: плата за ресурсы взимается в зависимости от времени их подготовки пользователю. Например, вы платите за определенный объем в часах, днях, месяцах или годах за использование виртуальной машины, работающей в облаке IaaS. Степень детализации периода оплаты меняется от одного поставщика облачных служб к другому. Amazon, например, взимает плату с пользователей в час на непропорциональной основе.
- На основе емкости: плата взимается на основе объема определенного ресурса, который используется или используется. Это популярная модель тарификации для систем облачных хранилищ. Например, с пользователей взимается определенная сумма за хранение одного гигабайта в системах хранения облачных объектов, таких как хранилище BLOB-объектов Azure.
- На основе производительности: во многих облачных поставщиках пользователи могут выбрать более высокий уровень производительности для ресурсов, заплатив более высокую ставку. Для виртуальных машин более крупные, более мощные компьютеры с большим объемом ресурсов ЦП, памяти и дисков могут быть подготовлены по высокой почасовой ставке.
На основе этих параметров оплаты CSP используют одну из следующих распространенных моделей ценообразования.
- Цены по запросу и оплате по мере использования: это, как правило, самая дорогая модель ценообразования для долгосрочного использования. Счета выставляются за очень короткий период использования (обычно измеряемый в минутах или часах). Преимущество заключается в том, что не требуется долгосрочный контракт, что делает эту модель очень гибкой для масштабирования в зависимости от текущих потребностей. Нечасто, но встречается практика, когда CSP могут поднимать цены во время высокого спроса и уменьшать их во время низкого спроса. Это отличная модель для поставщиков услуг, а также для облачных пользователей, которые только начали использовать облако.
- Зарезервированные экземпляры и цены на основе подписки: вместо оплаты почасовой или минутной ставки пользователь может выбрать предварительную оплату и зарезервировать ресурс в течение довольно длительного периода времени (недель или месяцев). Это часто сопровождается большим снижением цены (20–50 %), но требует долгосрочных обязательств. В зарезервированных моделях ценообразования схемы оплаты могут варьироваться от предоплаты до обязательных периодических платежей.
- Точечные цены: точечные цены — это способ для поставщиков услуг по борьбе с избыточной неиспользуемой емкостью, предлагая ее на продажу по значительно более низким ценам, чем ресурсы по запросу. Цены определяются на аукционе пользователей, где пользователи предлагают максимальную сумму, которую они готовы заплатить за ресурс. Самый большой недостаток заключается в том, что зачастую ресурсы могут быть завершены в любое время, если спотовая цена превысит фактическую цену предложения. Спотовые ресурсы идеально подходят для кратковременных, некритических заданий, которые можно выполнять спекулятивно.
Как правило, зарезервированные экземпляры должны использоваться в соответствии с базовыми требованиями системы. Если приложению требуется 2 экземпляра в течение 80 % времени, 3 экземпляра в течение 15 % времени и 4 экземпляра в течение 5 % времени, то обычно резервируется 2 экземпляра в течение всего времени существования приложения и выполняется масштабирование с помощью экземпляров по требованию или спотовых экземпляров. Как уже упоминалось, экземпляры по требованию нужно выбирать при горизонтальном масштабировании только в том случае, если приложение является критически важным или если разница между ценой по запросу и спотовой ценой перекрывается риском внезапного завершения. Решение часто зависит от конкретной бизнес-ситуации.
Оптимизация использования затрат
Чтобы использовать облако экономически эффективным образом, предприятия должны разработать полноценный процесс выбора ресурсов для развертывания, мониторинга и визуализации использования, а также четкий механизм, позволяющий выявить потери и оптимизировать использование.
Рис. 11. Процесс оптимизации затрат
Прежде чем рассматривать требования к затратам, организация должна спланировать объем работы, которую она может завершить в определенный период на основе фиксированных ресурсов, таких как объем персонала, при работе с физическими ограничениями, такими как управление инвентаризацией, накладные расходы из-за транспорта, обработки материалов и т. д. Подготовка ИТ-ресурсов должна быть разработана для удовлетворения или превышения физической емкости организации. Это чрезвычайно важно, так как эластичность, предоставляемая в облаке, побуждает разработчиков просто добавлять ресурсы по мере необходимости, не учитывая затраты на такие решения.
Первым шагом в попытке снизить расходы на облако является сопоставление типов ресурсов с фактическим требованием для приложения. Это может означать выбор между виртуальными машинами с разными конфигурациями памяти или количеством ядер. Нет простого способа сделать это, помимо тестирования и изучения производительности приложения в различных типах ресурсов.
Даже если приложение работает лучше в более дорогих классах ресурсов, важно проверить, пропорционально ли повышение производительности увеличению стоимости. Например, если в приложении наблюдается прирост в 1,2 раза при использовании виртуальной машины, которая дороже в 7,5 раз, чем базовая, может оказаться более разумным для повышения производительности использовать горизонтальное масштабирование базового ресурса.
Важно создать систему мониторинга и визуализации для мониторинга использования различных ресурсов. Система мониторинга должна быть разработана так, чтобы запускать события масштабирования в ответ на наблюдаемые шаблоны перегрузки или простоя. Часто специалисты по инфраструктуре предпочитают выполнять масштабирование вверх или вширь агрессивно, в то время как масштабирование вниз и сужение — более консервативно. Хотя этот подход является более затратным в плане подготовки ресурсов, теоретически он обеспечивает более высокий уровень качества обслуживания, чем постоянная работа на околопиковой мощности.
С другой стороны, организации часто недооценивают потребность в масштабировании вниз и выводе из работы редко используемых ресурсов. При планировании запуска различных компонентов приложения важно распределить использование по категориям в зависимости от приблизительного времени, в течение которого он будет использоваться. Например, любые задания, выполняемые в течение короткого времени еженощно или еженедельно, не должны использовать ресурсы 24/7. Свободные ресурсы также должны помечаться и завершаться (на основе определенных правил) системой мониторинга.
Важный метод,связанный с оптимизацией затрат, заключается в маркировке ресурсов. Маркировка — это процесс назначения меток ресурсам, которые позволяют идентифицировать их с помощью средств мониторинга и анализа. Маркировка также позволяет определять пользовательские правила для каждой метки, включая списки управления доступом к ресурсам, оповещения о выставлении счетов и конкретные политики масштабирования. Часто используемые теги указывают владельца (пользователя или группы) определенного ресурса, среды, к которой он принадлежит (например, рабочей среде, резервному копированию, промежуточному и тестированию), центр затрат, отвечающий за оплату счета и т. д. При анализе расходов это позволяет создавать сгруппированные представления на основе конкретных приложений, а также для конкретных групп разработки или тестирования.