Экономия затрат — одна из основных причин переноса рабочей нагрузки в «облако». При правильном использовании «облачная» инфраструктура может снизить совокупную стоимость владения (TCO) по сравнению с локальной инфраструктурой. Однако это не означает, что простой перенос приложений и данных в «облако» неизбежно ведет к экономии затрат. Переход к «облаку» — это не то, что, скажем, принятие решения о консолидации долга или рефинансировании ипотеки ради лучшей процентной ставки. Такие меры почти всегда способствуют экономии затрат, если только вы не допустите явную оплошность. А вот оптимизация «облачных» затрат и сохранение предсказуемости затрат на «облачные» вычисления напрямую зависят от способности находить разумные решения относительно того, как распределить рабочие нагрузки. Давайте рассмотрим стратегии, позволяющие не только сэкономить средства за счет «облака», но и довести экономию до максимума.
Оптимальные размеры экземпляров виртуального сервера
Самый очевидный шаг в оптимизации затрат на «облачные» вычисления состоит в том, чтобы использовать экземпляры виртуального сервера, адаптированные к реальным потребностям.
Каждое общедоступное «облако» предоставляет различные категории и разновидности экземпляров виртуальных серверов. Объем вычислительных ресурсов и памяти у каждого экземпляра варьируется в широких пределах, равно как и его цена.
Чтобы оптимизировать экономию затрат, при выборе типа экземпляра необходимо учитывать два основных соображения.
- Не приобретайте ненужных ресурсов. Если ваша рабочая нагрузка требует 4 Гбайт памяти, то приобретение 8 Гбайт будет непроизводительной тратой средств. Конечно, необходимо предусмотреть достаточный размер буфера для обработки резких скачков объема загрузки (по крайней мере, на время создания новых экземпляров, если требуется поддерживать обработку повышенной загрузки в течение длительного времени).
- Выбирайте экземпляр с учетом специфических потребностей рабочей нагрузки. Обеспечение надежной работы некоторых приложений требует в равной мере вычислительных ресурсов и памяти. Для других приложений требуется больше памяти, но меньше процессорного времени, и наоборот. Есть приложения, которым нужен графический процессор. Независимо от особенностей приложения, почти наверняка существует тип экземпляра, полностью отвечающий его потребностям. Поэтому, прежде чем приобретать универсальный экземпляр с одинаковыми ресурсами виртуальных процессоров и памяти, проверьте, нет ли специализированного варианта, более целесообразного с точки зрения баланса между ресурсами и затратами. Возможно, это потребует нагрузочного тестирования самого приложения с целью определения оптимального сочетания различных типов ресурсов. Можно также воспользоваться средствами оптимизации затрат на «облачные» вычисления, созданными специально для правильного определения подходящих размеров экземпляра.
«Облачные» экземпляры по сниженной цене
Еще один очевидный способ снизить затраты на «облачные» вычисления реализуется с использованием экземпляров по сниженной цене, например зарезервированных экземпляров на платформе AWS. Для экземпляра по сниженной цене обычно требуется резервировать «облачные» ресурсы заранее, до начала его использования. Следовательно, этот вариант требует планирования и не подходит для динамических рабочих нагрузок.
Однако, если пойти на организационные меры по обеспечению прогнозирования потребностей «облачного» экземпляра, то можно за счет использования зарезервированных экземпляров AWS сэкономить до 75% средств.
Многоуровневые «облачные» хранилища
В случае «облачных» рабочих нагрузок с высокими потребностями в хранении данных сэкономить средства можно за счет использования многоуровневых хранилищ.
Основные поставщики общедоступного «облака» предлагают различные классы хранилищ. Подробную информацию о классах хранилищ можно найти на сайтах поставщиков услуг. Конкретные особенности различаются в зависимости от используемого «облака», однако в любом случае затраты на «облачное» хранилище можно снизить, поместив данные в «холодное» или «архивное» хранилище. Такие хранилища доступны по более низкой цене.
Недостаток такого подхода в том, что доступ к данным, размещенным в более дешевых хранилищах, занимает больше времени, чем при использовании стандартной службы. Это означает, что недорогое хранилище может работать слишком медленно в случае рабочих нагрузок, связанных с быстрым и постоянным получением данных. Однако для таких задач, как архивация и резервное копирование, обычно не требующих частого доступа к данным, недорогие «облачные» хранилища — отличная возможность снизить затраты на «облачные» вычисления.
Выбор подходящих «облачных» сервисов
Виртуальный сервер и хранилище данных — наиболее распространенный тип «облачной» службы. Однако современные общедоступные «облака» предлагают множество других вариантов, например решение AWS Fargate для запуска приложений внутри контейнеров, Microsoft Azure Blockchain Workbench или «облачные» функции Google Cloud.
В зависимости от того, как именно работает приложение, требуемой производительности можно добиться при меньших затратах, развертывая приложение с помощью службы, отличной от стандартных «облачных» экземпляров, использующих виртуальный сервер. Например, если приложение потребляет большой объем вычислительных ресурсов на непредсказуемой и непостоянной основе, то более подходящим вариантом для его развертывания может стать бессерверная вычислительная платформа. Бессерверная платформа позволяет экономить средства, поскольку обычно в этом случае нужно платить только за реально используемое приложением время вычислений. И напротив, при использовании традиционного виртуального сервера платить приходится за все время, пока экземпляр находится в рабочем состоянии, независимо от того, выполняет ли он реальные действия. Кроме того, бессерверные вычисления могут даже повысить безопасность.
Вопрос выбора правильной «облачной» службы для конкретной рабочей нагрузки выходит за рамки этой статьи, но основной вывод состоит в том, что можно сэкономить средства, если выйти за рамки базовых вариантов, использующих виртуальный сервер.
«Многооблачная» архитектура
Задачу достижения максимальной оптимизации затрат на «облачные» вычисления отчасти решает «многооблачная» архитектура.
Безусловно, использование нескольких «облаков» увеличивает трудозатраты, связанные с настройкой и обслуживанием, однако общие затраты на «облачные» вычисления могут быть заметно снижены, так как развертывание различных сервисов в разных «облаках» позволяет достичь идеального баланса между затратами и производительностью. Например, AWS позволяет воспользоваться более дешевым хранилищем, а развертывание бессерверных функций выгоднее реализовать на платформе Azure, или наоборот (этот пример не следует рассматривать как реальную сравнительную оценку стоимости служб AWS и Azure). Используя два «облака» одновременно, можно добиться наилучших результатов в отношении оптимизации затрат.
Следует иметь в виду, что существуют ограничения на масштабы интеграции «облачных» служб от разных поставщиков. Например, прямое подключение бессерверной функции, развернутой в Azure, к хранилищу S3 невозможно, и результат интеграции, вероятно, не стоит усилий, затраченных на непрямое подключение (не говоря уже о потенциальных рисках с точки зрения безопасности).
Однако для обособленных рабочих нагрузок (например, если предполагается выполнить развертывание веб-приложения на платформе AWS, а для резервного копирования данных использовать Azure) экономически выгодная «многооблачная» стратегия легко реализуется с технической точки зрения.