" alt="">Сегодня мы поговорим об основных и наиболее часто используемых возможностях оптимизации затрат на сервисы AWS.
Основные варианты оптимизации затрат
К таким вариантам относятся в первую очередь:
- Зарезервированные инстансы (Reserved Instances) – для постоянных нагрузок;
- Scheduled Reserved Instances – для нагрузок, постоянно возникающих в четко определенные моменты времени;
- Спотовые инстансы (Spot Instances) – для получения во временное пользование простаивающих серверов на сотовом рынке (с существенной скидкой);
- Оптимизация времени использования ресурсов;
- Оптимизация объема использования ресурсов;
- Контроль неиспользуемых ресурсов.
Прежде чем начать рассматривать каждый из этих вариантов более подробно хочу обратить ваше внимание, что перечисленные способы оптимизации – отнюдь не единственные способы оптимизации затрат.
Зарезервированные инстансы (Reserved Instances)
Если вы точно знаете, что определенное количество EC2 машин будет использоваться постоянно в течение года или даже более длительного периода, RI – отличный способ сэкономить. Стоимость RI состоит из двух основных компонент – начальный платеж и платеж за час работы сервера. Кроме экономии вы получаете гарантию наличия мощности в вашем распоряжении на протяжении периода резервирования.
RI – это способ резервирования EC2 машин, который доступен в трех вариантах:
- No Upfront – нет начального платежа, наименьшая скидка в сравнении с другими RI;
- Partial Upfront – этот вариант предполагает достаточно существенный начальный платеж и, соответственно, существенную скидку на использование EC2;
- All Upfront – вся стоимость EC2 машины выплачивается сразу, однако итоговая годовая стоимость будет существенно ниже. Кроме существенного снижения стоимости эта опция может рассматриваться в качестве средства управления валютными рисками.
Кроме описанных выше вариантов относительно недавно появилась возможность резервирования части времени EC2 машин для выполнения периодических задач (например, ежемесячная обработка отчетности). Такой вариант резервирования называется Scheduled Reserved Instances. Стоимость таких машин несколько ниже, чем заказ виртуальных машин по требованию.
Посчитать стоимость RI можно с использованием Simple Monthly Calculator (не забудьте указать корректный регион).
Стоит добавить, что концепция резервирования применяется в AWS не только по отношению к EC2 машинам, но и ко многим другим сервисам, в том числе к DynamoDB, RDS, Redshift, ElasticCache.
Спотовые инстансы (Spot Instances)
Spot Instances – это, фактически, простаивающие на текущий момент виртуальные мощности.
Спотовые инстансы могут быть заказаны в двух основных вариантах:
- Обычные Spot Instances;
- Spot Instances для продолжительного использования (defined duration).
Механика очень простая – вначале вы делаете ставку. Запустить spot машину вы можете в тот момент, когда стоимость машины на спотовом рынке окажется ниже вашей ставки. Хорошая новость в том, что теоретически, при использовании Spot Instances, вы можете сэкономить до 90% стоимости от начальной стоимости ресурса. Обратная сторона медали – машина может быть остановлена в любой момент времени (если кто-то перебьет вашу ставку), однако при выключении машины вам будет дано две минуты на выполнение необходимых шагов перед выключением. Spot инстансы могут быть использованы в auto-scaling events либо, что встречается чаще, в качестве ресурсов для запуска больших вычислительных нагрузок.
Ниже приведем диаграмму жизненного цикла spot.
Также существует специальный инструмент для оценки вероятности потери спотового инстанса.
Спотовые инстансы с заданной продолжительнустью использования подразумевают, что, в отличие от обычных spot машин, они точно проработают заданное время (можно выбрать от одного до шести часов с шагом в один час). В случае использования таких машин вы гарантированно получаете 50% скидки.
Более подробно по стоимости spot instances можно узнать здесь (не забудьте указать нужный вам регион и тип spot или defined duration).
Ниже приведена сравнительная схема основных вариантов оплаты EC2.
Варианты оптимизации
Оптимизация времени работы
Оптимизация времени работы ресурсов dev/test среды – это интересная и часто недооцененная возможность экономии значительных средств. Кроме того, использовать эту возможность довольно просто – необходимо просто настроить машины таким образом, чтобы их можно было включать и выключать без потери данных, результатов тестирования и (если кто-то так делает) изменений в коде. Это вполне реализуемо с использованием таких функций, как EC2 AMI, EBS, CloudFormation и других, а также с использованием средств автоматизации. Отдельно нужно отметить, что технологически включение и выключение среды без потери состояния и данных – первый шаг к реализации HA & DR для ваших приложений.
Оптимизация времени работы может сэкономить вам много средств если вся ваша команда работает не 24/7.
Оптимизации объема ресурсов
Эта рекомендация носит вполне очевидный характер и, как все очевидные вещи, чаще других забывается. Всегда необходимо помнить, что AWS позволяет вам самостоятельно получить необходимые ресурсы в тот момент, когда у вас возникла потребность.
В момент, когда вам потребуются ресурсы вам не нужно будет выполнять сложные административные процедуры или ждать несколько дней, пока служба эксплуатации выделит вам необходимые мощности. Вы можете получить все сразу.
Скажу еще раз. Потребляйте ровно тот объем ресурсов, который вам нужен именно сейчас. Постарайтесь не:
- Не заказывать виртуальные диски со 100%м запасом – когда понадобится вы выделите новый диск и подключите к своей виртуальной машине;
- Не выделять мощные машины для рутинного функционального тестирования;
- Не использовать в рутинной работе гигантские объемы данных;
- Не устанавливать все заново каждый раз – используйте AMI;
- Не пренебрегать долгосрочными архивами и data lifecycle;
- Не злоупотреблять возможностью получить все сейчас – планируйте активности (анализ больших логов лучше проводить на Spot с минимальной ценой, проводить нагрузочное тестирование с on-demand EC2 в черную пятницу лучше перенести на более спокойное время и проч.);
- Не злоупотреблять ручными операциями – старайтесь использовать средства автоматизации;
- Не стесняться взаимодействовать – обратитесь в AWS и вам помогут если лимиты исчерпаны и кажется, что все пропало. Посмотрите на техническую поддержку – если нет времени ждать и, в особенности, если вы используете AWS для продуктивных сред.
Ошибаюсь? Сталкивались с ситуациями, когда нет capacity для выделения ресурса? Подождите полчаса. Не хотите ждать? Стартуйте новую машину похожего типа. Диск инициализируется слишком долго? Посмотрите документацию – скорость инициализации можно оптимизировать. Достигнут лимит? Обратитесь в службу поддержки – вам их увеличат. Все проблемы решаемы. Если чего-то действительно не хватает – мы включим это в наш roadmap.
Контроль неиспользуемых ресурсов
Неиспользуемые ресурсы нередко становятся существенным источником расходов в AWS. Чаще всего неиспользуемые ресурсы возникают из-за некорректных настроек отдельных сервисов (например, EBS не удалился при удалении EC2 машины, т.к. был установлен флаг сохранения диска при удалении инстанса), непонимания основных концепций платежей (к примеру, Elastic IP долго остается не привязанным к конкретному ресурсу) или же при выполнении большого количества действий в ручном режиме (например, ручной provisioning и bootstrapping распределенной системы с использованием Management Console).
Если спроецировать такую ситуацию на распределенную команду разработчиков, которая проводит множество экспериментов и одновременно работает над большим количеством проектов проблема неиспользуемых ресурсов может приобрести достаточно серьезный масштаб.
В AWS есть несколько основных способов определения наличия неиспользуемых ресурсов. К самым доступным можно отнести:
- Прогнозирование счета с помощью Cost Explorer;
- Trusted Advisor – инструмент, выдающий рекомендации по четырем основным направлениям (безопасность, производительность, надежность и оптимизация стоимости).
Кроме того, мы предлагаем вашему вниманию несколько основных рекомендаций при работы с AWS, которые позволят сократить вероятность появления неиспользуемых ресурсов:
- ограничивайте права разработчиков – выделяйте своим разработчикам права по мере необходимости, создайте каждому по отдельной подсети для экспериментов, используйте VPC и тэги для контроля scope проекта – это поможет понять, кто и сколько ресурсов потратил, а также сократит риск запуска ненужных ресурсов;
- используйте тэги – они помогут вам лучше разбираться и контролировать вашу среду. Правильно организовав тэги вы всегда сможете определить, что, кто, когда и кем было запущено, а также (что немаловажно) можно ли это выключить;
- используйте средства автоматизации для выделения и освобождения ресурсов (Amazon CloudFormation) – они позволяют не только создавать, но и корректно освобождать ресурсы стека. Вы можете создавать и удалять целые среды с использованием одного инструмента просто нажав одну кнопку;
- если вы используете собственные скрипты – не забывайте удалять ресурсы, обычно они связаны друг с другом. Ошибки при удалении позволят найти неиспользуемые ресурсы;
- не недооценивайте влияние правильно построенной архитектуры на итоговую стоимость решения – рассматривайте сервисы AWS уровня приложений.
Источник «Блог Amazon Web Services, Андрей Зайчиков, архитектор AWS»
