{"id":13465,"url":"\/distributions\/13465\/click?bit=1&hash=1e6228dc4e5e22730d5108e1c30ee96b3462205737e7a3fe7ce4c965aaacfe57","title":"\u041a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f Ozon \u2014 \u043a\u043e\u043c\u0443, \u0447\u0442\u043e \u0438 \u043a\u0430\u043a \u043f\u0440\u043e\u0434\u0430\u0432\u0430\u0442\u044c \u0432 \u043a\u0440\u0438\u0437\u0438\u0441","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"6b1e0c55-41d3-56c2-84e2-fe6f447e3825","isPaidAndBannersEnabled":false}
Dmitrij Morin Softline

Как предотвратить рост затрат на облачные ИТ-ресурсы?

Одним из драйверов роста внедрения облачных инфраструктур в течение последних двух лет стало увеличение числа сотрудников, работающих удаленно. Сегодня доля потребления публичных облаков крупными игроками российского рынка, такими как финтех-компании, ритейлеры, промышленные и ИТ-компании составляет порядка 60%. Вместе с тем, преимуществом использования облачных технологий и приоритетом для большинства организаций является сокращение расходов на инфраструктуру, оплата только того, чем реально пользуются сотрудники. Предотвращение роста затрат является актуальной темой, затрагивающей руководителей всех категорий от ИТ-директоров и администраторов до финансовых руководителей и DevOps-инженеров.

Существует несколько вариантов, с помощью которых можно настроить контроль расходов на облака и найти возможности для сокращения затрат минимум на 10 %.

Бюджет можно оптимизировать при грамотном подходе: мониторинге расходов в срезах “ресурсы - люди - бюджеты”, выявлении простаивающих ресурсов и их своевременной остановке, обеспечении прозрачности в бюджетах.

1.1. Контроль ресурсов = экономия средств

Ресурсами в данном случае, могут быть виртуальные машины, компоненты, диски, которые потребляют облачные ресурсы. Далее эти ресурсы можно разделить на полностью неиспользуемые, истекшие и частично используемые (неоптимизированные).

NB! Важно понимать, какие ресурсы используются, а какие остаются ненужными. Низкая утилизация не всегда указывает на ненужность.

Неиспользуемые ресурсы появляются в результате развертывания тестовых сред и проектов, в которых отсутствует корректное определение того, какие из временных ресурсов должны быть удалены по окончании работ.

Например, это могут быть сетевые интерфейсы, диски или хранилища с дистрибутивами. А также диски не подключенные к какому-либо инстансу или, другими словами, виртуальной машине. Тут может помочь, например, назначение тегов на временные ресурсы с указанием времени их удаления.

Истекшие ресурсы — это те ресурсы, которые уже не нужны, но сохраняются в системе.

Например, тестовые среды, в которых остаются после развертывания не нужные виртуальные машины. А также завершенные проекты и их не удаленные копии в облаке.

Под неоптимизированными ресурсами понимают нужные сервисы, которые присутствуют в ИТ-инфраструктуре в излишнем количестве.

Например, простаивающие или oversized виртуальные машины.

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

NB! Использование дисков меньших размеров является одним из способов сокращения расходов.

Отдельной моделью ценообразования считается резервация - использование в облаке инстанса или виртуальной машины определенного размера, который оплачен на некоторый срок вперёд. Зачастую, компании приобретают резервации, но в дальнейшем используют инстанс другого размера.

NB! Если вовремя не отслеживать подобные случаи, то оплата будет происходить за оба сервиса.

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

Например, в облаке AWS новые поколения семейств инстансов зачастую дешевле старой. Так вендор мотивирует клиентов мигрировать на новое оборудование, чтобы постепенно выводить из эксплуатации старое.

1.2. Процессы. Автоматическое избавление от лишних трат и ненужных сегментов.

Первым по приносимой пользе процессом является автоматизация.

Например, она дает возможность убрать административную нагрузку за счет автоматических скриптов.

Ещё один пример: AutoScaling позволяет гибко масштабировать инфраструктуру, автоматически управлять количеством инстансов EC2 в соответствии с потребностями и политикой пользователя. В частности, это архитектуры scale out/scale in, благодаря которым при масштабировании можно добавить дополнительные инстансы, экземпляры или виртуальные машины в группу и увеличить пропускную способность сервиса.

Сделать это можно с помощью планировщиков или Autoscaling решений, при этом они могут работать как по расписанию, так и по событиям или значениям метрик.

NB! Количество машин можно не только увеличивать, но и уменьшать.

Создание такого баланса возможно благодаря динамической структуре: необходимое количество ресурсов увеличивается в соответствии с ростом запросов от пользователей, а при уменьшении спроса не нужно платить за простаивающие ресурсы.

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

Автоматизировать процесс оптимизации ресурсов можно с помощью:

  • тегов - меток, которые не несут конфигурационной нагрузки, не меняют поведения объектов, но благодаря которым возможен поиск уже существующих объектов по имени. Также с тегами проще выглядит автоматизация процессов масштабирования и изменения инфраструктуры.

NB! Теги - очень мощный инструмент эффективной модели регулирования расходов в облаке. Они позволяют точнее определять основные точки расходов и контролировать их во всё возрастающем количестве используемых ресурсов;

  • ведения документации, благодаря которой повышается прозрачность инфраструктуры за счет визуализации архитектуры. Становится понятнее, какие компоненты нужны, а какие можно сократить;
  • регламентов или схемы наименований, с которых начинается разворачивание любой инфраструктуры. Схема именования позволяет упорядочить архитектуру. Если эти регламенты продуманы верно, параметры ресурса (например, местонахождение, отношение, степень необходимости) определяются быстро. Формирование понятной и легко интерпретируемой ИТ-системы - важный пункт сокращения затрат;
  • формирования бюджетов, благодаря которому можно видеть, хватает ли ресурсов на текущий проект или как денежный поток делится на отдельные блоки. Без бюджетов нет индивидуальных границ расходов, поэтому распределение общего потока на более мелкие дает не только прозрачность, но и и общее понимание каким образом используются денежные средства. Например, при развертывании ресурса для заказчика можно с помощью тегов, в которых указано, когда ресурс должен быть удален, контролировать его состояние. Или наблюдать, в каких тестовых средах запущены не используемые, но оплачиваемые машины.
  • грамотного удаления ресурсов, которое заключается в проверке важности сегмента. Например, у удаляемого ресурса могут быть другие зависимости, он может являться standby компонентом*. Или же это может быть ресурс, который отвечает за безопасность. Определить нежелательность удаления таких сегментов помогут имена и теги.
  • использования инструментов централизованного мониторинга, которые отвечают за утилизацию и использование ресурсов. Например, VMware Operations Manager или Zabbix.
  • установки сервиса, который позволяет видеть данные и затраты всех инфраструктур в едином дашборде. Это повышает экономическую эффективность использования облачных ресурсов. Дело в том, что облачные сервисы разных провайдеров имеют свои инструменты, которые также подразумевают внутренние деления финансовых потоков и групп ресурсов. Для объединения этой разрозненной информации и контроля прозрачности трат, необходим инструмент, способный собрать все источники и элементы вместе. С таким инструментом можно видеть, например, превышение границ отдельных бюджетов и предпринимать действия по сокращению издержек в той или иной области проектов или департаментов.

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

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

Например, с установки продукта Coster, который является автоматическим советником и помощником в прогнозировании расходов и более точной оценке бюджетов.

  • Установить сервис, с помощью которого компании, потребляющие виртуальные ресурсы и сервисы сразу нескольких облачных провайдеров, смогут решить проблему неуправляемых расходов, затянутых сроков разворачивания инфраструктур и хаотичного разрастания облачных подписок.
  • Подключить сервис к облачной реализации, создать мульти облачные дашборды.
  • Загрузить в сервисе бюджеты по подключенным инфраструктурам, либо использовать вариант автоматического формирования бюджетов с опцией ручной донастройки.

NB! Отличительной особенностью сервиса Coster является остановка (не удаление!) необходимого количества виртуальных машин для выполнения бюджета.

  • Посмотреть превышение бюджетов, понять, где можно провести оптимизацию.
  • Посмотреть сформированные отчеты, ресурсы, в которых присутствуют неиспользуемые диски.
  • Обратить внимание на backup-систему. Вспомнить правило резервного копирования 3-2-1, придуманное фотографом Питером Крогом, которое подразумевает:
  • Хранение 3 копий данных. Помимо оригинала необходимо иметь ещё две копии.
  • Использование 2 видов носителей. Для хранения данных следует использовать два разных вида носителей.
  • Хранение 1 копии за пределами предприятия. Это поможет защитить данные, если проблемы возникнут на самом предприятии.

NB! Если при использовании правила переводить слово “3 copies” как “3 экземпляра”, то можно получить экономию ресурсов ввиду того, что достаточно иметь всего 3 экземпляра данных - 2 копии и 1 оффсайт, не переплачивая при этом за хранение и обновление лишней копии.

  • Настроить систему тегирования и автоматическое удаление ненужных ресурсов.

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

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

* запасной компонент в режиме ожидания
**набор модулей визуализации, которые постоянно собирают и обновляют информацию

0
Комментарии
Читать все 0 комментариев
null