В начале поговорим о базовых понятиях. Тариф — это стоимость единицы услуги (например, предоставляемых виртуальных процессоров или определенных операций) за единицу времени. Провайдер в основном продает собственные сервисы, создание которых требует вложений в оборудование, программное обеспечение, разработку и настройку систем, а также постоянных затрат на сопровождение. Все эти затраты нужно перенести на регулярные платежи, которые в свою очередь привязаны к некой виртуальной метрике (упомянутым выше единицам услуг). Помимо этого нужно учитывать, что никогда не бывает полной утилизации вычислительных мощностей, соответственно, на стоимость также влияют и возможные простои оборудования.

Кроме того, тариф должен быть удобным и понятным для клиента. Провайдеру рациональнее применять посекундную тарификацию, например, за реально потребленные единицы тактовой частоты физического ядра процессора. Но как заказчику работать с такой метрикой? Вопрос риторический. Поэтому приходится озвучивать стоимость в расчете на виртуальный процессор, включать переподписку (когда одно физическое ядро представляется как несколько виртуальных процессоров), понимая, что клиент никогда не задействует ресурс целиком.

 

 

Вот еще ряд примеров. Виртуальному ЦОДу можно выделить 16 ГБ оперативной памяти, но далеко не всегда весь этот объем будет задействован в полной мере, не говоря уже о том, что память можно сжимать. Заказчик может запросить диск на 100 ТБ, а занять только, скажем, 90 ТБ, к тому же на уровне дискового массива провайдер имеет возможность применить дедупликацию данных. С другой стороны, заказчик в любой момент может расширить свою инфраструктуру в несколько раз или начать передачу данных в свое хранилище. Это значит, что оператору услуги постоянно требуется запас мощностей.

В результате тариф — это постоянная игра со статистикой, попытка агрегировать десятки статей затрат и учесть модель реального потребления ресурсов клиентами. Как следствие — появляются два типа тарифов. Первый (назовем его условно «Простой») предлагает считать небольшое количество метрик за большие промежутки времени, скажем, за месяц. Провайдеру так проще, клиенту — понятнее. Второй тип («Сложный») напротив, предлагает много метрик с возможностью почасовой или поминутной тарификации.

 

Как с этим работать клиенту? Мой опыт подсказывает несколько простых шагов.

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

 

Шаг 2. На модели сделать прогноз потребления и посчитать стоимость за месяц или квартал по всем тарифам провайдера, сравнить полученные цифры. Иногда может получиться, что дешевле оплатить весь месяц использования ресурса, даже если фактически вы будете им пользоваться всего 20 дней.

 

Шаг 3. Постараться оптимизировать потребление. Часто можно эффективнее хранить данные, например перенести их часть на более дешевые медленные диски или просто использовать возможность сжатия. В ряде случаев можно разнести во времени пики нагрузки.

 

Шаг 4. Необходимо анализировать статистику за прошлые периоды, корректировать модель потребления и снова сравнивать тарифы.

 

И главное. Используемые тарифы следует время от времени пересматривать — это нормальный процесс, ведь ваш бизнес не стоит на месте. Также не стоит жалеть сил и времени на сравнение различных вариантов потребления облачных сервисов: иногда при некоторых моделях потребления правильный выбор тарифа позволяет сократить ежемесячный платеж в несколько раз.