Практически каждая компания или организация (это относится и к новичкам, и к опытным пользователям облачных технологий) признает, что управлять приложениями в облаке гораздо сложнее, чем ожидалось. Труднее всего оптимизировать производительность приложения при минимальных расходах. Так как производительность крайне важна, наименее рискованное решение — выделение излишних ресурсов на ее обеспечение. Но без понимания того, какие ресурсы действительно нужны приложению, компаниям приходится полагаться на коэффициент использования ресурсов как основной ориентир.
Ниже приведем три распространенных подхода к управлению ресурсами приложения в облаке.
Это наиболее распространенный подход, который обычно требует совместных усилий со стороны ИТ-служб, владельцев облачных приложений и финансового департамента.
Включает глубокий анализ счетов, учет расходов и прочие формы отчетности и аналитики drill-down. Отлично подходит для демонстрации масштаба проблемы и в некоторых случаях помогает выявить аномалии в биллинге.
Этот подход включает два типа инструментов: встроенные, которые предлагаются поставщиком облачного решения, и сторонние, которые предоставляются независимым поставщиком ПО, специализирующимся на оптимизации затрат на облако.
Сколько бы людей ни трудилось над задачей оптимизации расходов на облако, они не смогут добиться таких результатов, как интеллектуальное программное обеспечение. И, несмотря на усилия поставщиков облачных решений и независимых поставщиков ПО, сложность решения (и следующие за ней чрезмерные расходы на облако) только усугубляется для многих организаций. Рекомендации людей, принимающих вручную решения в отношении оптимизации облачных ресурсов не пригодны для автоматизации. Почему? Потому что они не понимают, какие ресурсы в действительности нужны приложению и, соответственно, не могут определить, что именно требуется.
Так что оптимизация инвестиций в облачную среду — это одновременно и приоритет, и проблема. Разберемся, почему все так сложно?
Масштабирование приложения под правильное соотношение тип экземпляра к размеру виртуальной машины требует тщательного учета всех метрик, относящихся к приложению: вычислений (памяти, CPU), хранения (IOPS, производительности) и пропускной способности сети, включая пиковые и средние значения.
В облаке вы можете выбрать, в каком семействе (инстансе) будут выполняться ваши приложения. Однако при попытке перемещения приложений из одного семейства в другое (например, из compute-optimized в general-purpose) возникают трудности. Важно также понимать преимущества, которые дает каждый из типов инстансов (старого и нового поколения) в отношении производительности и расходов. Наконец, самый точный и безопасный способ масштабирования приложения и определения необходимой производительности приложения, особенно когда оно критически важное, требует понимания потребностей облачного приложения. Добиться этого можно, собирая и анализируя важные метрики, такие как хип приложения, потоки выполнения и время отклика.
Зарезервированные экземпляры (RI) — один из лучших способов сокращения расходов на общедоступные облачные среды. RI — это долгосрочные обязательства по обеспечению определенной производительности сроком на 1 или 3 года. Однако сложно определить, сколько приложениям требуется в каждый данный момент, не говоря уже о потребностях через 1–3 года. Управлять RI еще сложнее, если в облачной среде более одной учетной записи.
Поставщики облачных решений предлагают различные уровни хранения, у каждого из которых свои уникальные возможности. Например, на AWS тома EBS разбиты на шесть уровней: io1, io2, gp2, gp3, st1 и sc1. Каждый из них предполагает разный уровень IOPS, пропускную способность, размеры, модель разбивки и стоимость.
По мере развертывания новых приложений в облачной среде организации будут пользоваться платформами как услугой (PaaS). Некоторые сервисы на них стоят дороже, поскольку поставщик отвечает за управление большим количеством элементов технологического стека.
Ни один человек (или команда) не может масштабно и эффективно оптимизировать приложения в общедоступных облачных средах, поскольку это слишком сложно, требует времени и постоянной работы. Но есть платформа, которая непрерывно анализирует потребности приложений в ресурсах. А полная автоматизация действий по обеспечению бесперебойной работы приложений выполняется ею в строгом соответствии с требованиями бизнес-политик.
При подготовке материала был использован блог на английском компании Turbonomic, которая была приобретена IBM в 2021 году.
Распространенные подходы к оптимизации облачных приложений
Ниже приведем три распространенных подхода к управлению ресурсами приложения в облаке.
Ручная оптимизация
Это наиболее распространенный подход, который обычно требует совместных усилий со стороны ИТ-служб, владельцев облачных приложений и финансового департамента.
Контроль расходов и ведение отчетности
Включает глубокий анализ счетов, учет расходов и прочие формы отчетности и аналитики drill-down. Отлично подходит для демонстрации масштаба проблемы и в некоторых случаях помогает выявить аномалии в биллинге.
Инструменты для оптимизации расходов
Этот подход включает два типа инструментов: встроенные, которые предлагаются поставщиком облачного решения, и сторонние, которые предоставляются независимым поставщиком ПО, специализирующимся на оптимизации затрат на облако.
Почему ручная оптимизация затрат обречена на провал
Сколько бы людей ни трудилось над задачей оптимизации расходов на облако, они не смогут добиться таких результатов, как интеллектуальное программное обеспечение. И, несмотря на усилия поставщиков облачных решений и независимых поставщиков ПО, сложность решения (и следующие за ней чрезмерные расходы на облако) только усугубляется для многих организаций. Рекомендации людей, принимающих вручную решения в отношении оптимизации облачных ресурсов не пригодны для автоматизации. Почему? Потому что они не понимают, какие ресурсы в действительности нужны приложению и, соответственно, не могут определить, что именно требуется.
Так что оптимизация инвестиций в облачную среду — это одновременно и приоритет, и проблема. Разберемся, почему все так сложно?
1 – Эффективное масштабирование приложений требует комплексного анализа
Масштабирование приложения под правильное соотношение тип экземпляра к размеру виртуальной машины требует тщательного учета всех метрик, относящихся к приложению: вычислений (памяти, CPU), хранения (IOPS, производительности) и пропускной способности сети, включая пиковые и средние значения.
2 – Масштабирование между различными семействами машин — сложная задача, поэтому большинство инструментов не решают ее
В облаке вы можете выбрать, в каком семействе (инстансе) будут выполняться ваши приложения. Однако при попытке перемещения приложений из одного семейства в другое (например, из compute-optimized в general-purpose) возникают трудности. Важно также понимать преимущества, которые дает каждый из типов инстансов (старого и нового поколения) в отношении производительности и расходов. Наконец, самый точный и безопасный способ масштабирования приложения и определения необходимой производительности приложения, особенно когда оно критически важное, требует понимания потребностей облачного приложения. Добиться этого можно, собирая и анализируя важные метрики, такие как хип приложения, потоки выполнения и время отклика.
3 – Для масштабного управления зарезервированными экземплярами (RI) потребуется много людей
Зарезервированные экземпляры (RI) — один из лучших способов сокращения расходов на общедоступные облачные среды. RI — это долгосрочные обязательства по обеспечению определенной производительности сроком на 1 или 3 года. Однако сложно определить, сколько приложениям требуется в каждый данный момент, не говоря уже о потребностях через 1–3 года. Управлять RI еще сложнее, если в облачной среде более одной учетной записи.
4 – Не забывайте об оптимизации хранилища
Поставщики облачных решений предлагают различные уровни хранения, у каждого из которых свои уникальные возможности. Например, на AWS тома EBS разбиты на шесть уровней: io1, io2, gp2, gp3, st1 и sc1. Каждый из них предполагает разный уровень IOPS, пропускную способность, размеры, модель разбивки и стоимость.
5 – А, ведь еще есть PaaS
По мере развертывания новых приложений в облачной среде организации будут пользоваться платформами как услугой (PaaS). Некоторые сервисы на них стоят дороже, поскольку поставщик отвечает за управление большим количеством элементов технологического стека.
За пределами человеческих возможностей — как в итоге оптимизировать облачные приложения?
Ни один человек (или команда) не может масштабно и эффективно оптимизировать приложения в общедоступных облачных средах, поскольку это слишком сложно, требует времени и постоянной работы. Но есть платформа, которая непрерывно анализирует потребности приложений в ресурсах. А полная автоматизация действий по обеспечению бесперебойной работы приложений выполняется ею в строгом соответствии с требованиями бизнес-политик.
При подготовке материала был использован блог на английском компании Turbonomic, которая была приобретена IBM в 2021 году.