Использование AWS Compute Optimizer для непрерывной оптимизации размеров и снижения затрат

Оптимизация размеров AWS звучит как финансовое упражнение до тех пор, пока первое неудачное изменение не приведет к падению рабочей нагрузки в production. Полезная версия более осторожна: найти ресурсы, которые явно слишком велики, явно слишком малы или работают на неудобном поколении инфраструктуры, затем внести изменения с учетом шаблонов трафика, состояния, отката и поведения приложения.

AWS Compute Optimizer помогает в этой работе, анализируя конфигурацию ресурсов и метрики использования, а затем формируя рекомендации для таких сервисов, как экземпляры EC2, группы Auto Scaling, тома EBS, сервисы ECS на Fargate и функции Lambda. Рекомендации полезны, но к ним следует относиться как к поддержке принятия решений, а не как к автоматической истине. Compute Optimizer видит метрики. Он не всегда видит календари релизов, обязательства клиентов, лицензионные особенности или странную пакетную задачу, которая запускается только в конце месяца.

---

Понимание AWS Compute Optimizer

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

ACO оценивает несколько факторов, включая загрузку ЦП, использование памяти (если установлен соответствующий агент CloudWatch), пропускную способность сети и дисковый ввод-вывод, генерируя рекомендации, которые ставят во главу угла как экономическую эффективность, так и производительность.

Ключевые метрики, предоставляемые ACO

1. Результаты оптимизации: Категоризация ресурса (например, избыточно обеспеченный, недостаточно обеспеченный, оптимизированный).
2. Предполагаемая ежемесячная экономия: Прогнозируемое снижение затрат при внедрении рекомендации.
3. Риск для производительности: Оценка низкого, среднего или высокого уровня, указывающая на вероятность того, что внедрение рекомендации негативно повлияет на производительность рабочей нагрузки.
4. Рекомендуемые варианты: Конкретные альтернативные конфигурации ресурсов (например, типы экземпляров, настройки памяти, характеристики томов EBS).

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

Оптимизация размеров экземпляров Amazon EC2

Экземпляры EC2 часто являются крупнейшим единственным драйвером затрат на облачные вычисления. ACO предоставляет индивидуальные рекомендации для отдельных экземпляров и экземпляров в группах Auto Scaling (ASG).

Выявление избыточно и недостаточно обеспеченных экземпляров

ACO категоризирует экземпляры EC2 на основе своего анализа:

• Избыточно обеспеченные: Экземпляры, демонстрирующие постоянно низкую загрузку по метрикам, которые видит Compute Optimizer. Он может предложить перейти на меньший или другой тип экземпляра.
• Недостаточно обеспеченные: Экземпляры, показывающие высокую загрузку или давление на ресурсы. Он может предложить больший экземпляр, другое семейство или конфигурацию с лучшими характеристиками ЦП, памяти, сети или хранилища.

Внедрение рекомендаций по оптимизации размеров EC2

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

Пример: Изменение избыточно обеспеченного экземпляра через CLI

Если Compute Optimizer рекомендует изменить экземпляр с m5.large на t3.large, механические шаги для экземпляра на базе EBS:

1. Остановите экземпляр:

   aws ec2 stop-instances --instance-ids i-1234567890abcdef0
   

2. Измените тип экземпляра:

   aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --instance-type "{'Value': 't3.large'}"
   

3. Запустите экземпляр:

   aws ec2 start-instances --instance-ids i-1234567890abcdef0
   

Лучшая практика: Всегда выполняйте эти изменения в периоды низкого трафика и внимательно отслеживайте метрики экземпляра (ЦП, задержку, журналы приложения) в течение 24-48 часов после внедрения, чтобы убедиться, что новый размер может обрабатывать пиковую нагрузку без ухудшения производительности.

Перед изменением типа проверьте, является ли экземпляр частью группы Auto Scaling, использует ли тома instance store, есть ли требования к группам размещения, использует ли ENA или предположения об именовании NVMe, или привязан ли к лицензионной модели. Для сервисов в production часто безопаснее встроить новый размер в шаблон запуска, постепенно заменять экземпляры и позволить балансировщикам нагрузки дренировать соединения.

Оптимизация томов Amazon EBS

Compute Optimizer распространяет свои рекомендации на тома Elastic Block Store (EBS), подключенные к экземплярам EC2. Оптимизация здесь направлена на максимизацию производительности за доллар путем предложения современных типов томов и настройки параметров IOPS/пропускной способности.

Рекомендации по миграции

Одна из распространенных оптимизаций — миграция старых томов общего назначения, особенно gp2, на gp3, где это соответствует рабочей нагрузке.

Тип тома	Преимущество
gp2	Производительность масштабируется в зависимости от размера тома и кредитов burst.
gp3	Производительность можно настраивать отдельно от размера в пределах лимитов сервиса.

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

Практический шаг: Изменение тома

Изменения томов EBS обычно можно выполнять, пока том используется (в отличие от изменения типа экземпляра EC2), хотя следует учитывать влияние на производительность.

# Пример: Миграция тома на gp3 и установка конкретных IOPS/пропускной способности
aws ec2 modify-volume \
    --volume-id vol-fedcba9876543210 \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125

Следите за состоянием модификации после команды:

aws ec2 describe-volumes-modifications \
  --volume-ids vol-fedcba9876543210

Для критических баз данных сначала протестируйте изменение на реплике или staging-копии. Изменение типа тома может быть онлайн, но рабочая нагрузка все равно может ощутить изменения в поведении ввода-вывода, если новый параметр IOPS или пропускной способности слишком низок.

Оптимизация размеров функций AWS Lambda

Для бессерверных рабочих нагрузок Compute Optimizer предоставляет важные сведения о функциях AWS Lambda. В Lambda настройка памяти определяет объем vCPU, выделенный функции. Оптимизация размеров Lambda в первую очередь заключается в поиске наименьшей конфигурации памяти, которая все еще соответствует целевым показателям производительности.

Компромисс память/ЦП

Compute Optimizer анализирует шаблоны использования и длительности Lambda, чтобы рекомендовать настройки памяти. Функция может быть выделена 1024 МБ, но приемлемо работать при 512 МБ. Другая функция может стать дешевле при увеличении памяти, потому что добавленный ЦП сокращает длительность настолько, что компенсирует большее выделение памяти.

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

Внедрение оптимизации функций Lambda

Оптимизация Lambda обычно проста и требует простого обновления конфигурации функции.

Пример: Обновление конфигурации памяти Lambda

Если ACO рекомендует перевести функцию с 2048 МБ на 1024 МБ:

aws lambda update-function-configuration \
    --function-name MyOptimizedFunction \
    --memory-size 1024

Интеграция непрерывной оптимизации в ваш рабочий процесс

Оптимизация размеров не должна быть разовым аудитом, а непрерывной дисциплиной. Compute Optimizer облегчает это с помощью своего API и интеграции с AWS Organizations.

1. Централизованное управление

При использовании AWS Organizations назначьте делегированного администратора для Compute Optimizer. Это позволяет ACO предоставлять консолидированные рекомендации по всем учетным записям, предлагая целостное представление о потенциальной экономии на уровне предприятия.

2. Автоматизация и уведомления

Используйте API Compute Optimizer и интегрируйте его с AWS CloudWatch Events или Lambda для создания автоматизированных рабочих процессов:

• Планируемая отчетность: Настройте ежедневный или еженедельный триггер, который извлекает последние приоритетные рекомендации (например, с наибольшей предполагаемой экономией).
• Оповещения: Запускайте оповещения через SNS, когда ACO идентифицирует ресурсы с определенными результатами (например, недостаточно обеспеченные экземпляры с высоким риском для производительности).
• Полуавтоматизированное внедрение: Для низкорисковых рекомендаций с высокой экономией (например, миграция EBS gp3) используйте функции Lambda для автоматического создания запросов на изменение или даже прямого применения изменения после прохождения необходимого порога управления.

# Концептуальный фрагмент Python с использованием boto3 для получения рекомендаций
import boto3

aco_client = boto3.client('compute-optimizer')

response = aco_client.get_ec2_instance_recommendations(
    filters=[
        {'name': 'finding', 'values': ['Overprovisioned']}
    ]
)
# Обработайте и примените рекомендуемые варианты...

Держите внедрение отдельно от сбора рекомендаций. Еженедельный отчет может безопасно перечислить кандидатов. Бот, который останавливает экземпляры или изменяет память Lambda без контекста рабочей нагрузки, может создавать инциденты. Хорошая середина — открывать тикеты или pull request с рекомендацией, текущими метриками, предлагаемым изменением, предполагаемой экономией и планом отката.

Как просмотреть рекомендацию перед действием

Для каждой рекомендации задайте несколько практических вопросов:

1. Используется ли ресурс еще, или удаление — лучший ответ, чем изменение размера?
2. Включает ли период ретроспективного анализа нормальный пиковый трафик, окна пакетной обработки и недавние релизы?
3. Доступны ли данные о памяти для EC2, или рекомендация в основном основана на ЦП и сети?
4. Является ли экземпляр сохраняющим состояние, лицензированным, привязанным к оборудованию или настроенным вручную?
5. Можно ли выполнить развертывание изменения за группой Auto Scaling, развертыванием blue/green или репликой?
6. Какая метрика докажет, что изменение сработало или провалилось?

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

Шаблоны развертывания, снижающие риск

Самый безопасный путь внедрения зависит от ресурса.

Для экземпляров EC2 без сохранения состояния за балансировщиком нагрузки предпочтительнее заменять экземпляры через группу Auto Scaling или конвейер развертывания, а не останавливать работающий экземпляр вручную. Обновите шаблон запуска, добавьте один экземпляр нового типа, следите за проверками здоровья и метриками приложения, затем постепенно обновите остальные. Это дает естественный откат: верните старую версию шаблона запуска и замените новые экземпляры.

Для хостов EC2 с сохранением состояния выберите более медленный путь. Подтвердите резервные копии, поймите подключенные тома, проверьте окна обслуживания и убедитесь, что приложение может выдержать цикл остановки/запуска. Некоторые старые семейства экземпляров и новые семейства по-разному предоставляют диски или сетевые устройства, поэтому сценарии запуска, которые предполагают имя устройства, могут сломаться после изменения типа.

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

Для Lambda публикуйте новую версию или развертывание на основе псевдонимов, когда функция важна. Отправьте небольшую долю трафика на новую настройку памяти, сравните длительность, ошибки, холодные старты и давление на нижестоящие системы, затем переключите больше трафика. Функция, которая становится быстрее с большим объемом памяти, может оказывать большее давление на базу данных или API, которые она вызывает, поэтому следите за всем путем.

Четкое представление рекомендаций

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

Отклоненные рекомендации все еще полезны. Сервер базы данных может выглядеть избыточно обеспеченным, потому что он рассчитан на отказ, а не на средний трафик. Сервер лицензий может нуждаться в фиксированном семействе экземпляров. Хост с низким использованием может ожидать запланированной миграции. Фиксация этих причин предотвращает повторное обсуждение той же рекомендации каждый месяц.

Лучшие практики использования Compute Optimizer

Область	Лучшая практика
Период мониторинга	Убедитесь, что ресурсы работали под типичной нагрузкой не менее 14 дней, прежде чем доверять рекомендациям.
Тестирование производительности	После внедрения рекомендации по уменьшению размера всегда запускайте нагрузочные тесты, чтобы убедиться, что приложение поддерживает требуемые SLO (целевые уровни обслуживания).
Специализированные рабочие нагрузки	Будьте осторожны с приложениями с сохранением состояния, базами данных или серверами лицензий сторонних производителей, которые могут требовать определенных типов экземпляров или минимальных ресурсов, даже если ACO рекомендует меньший размер.
Метрика памяти	Для EC2 установите агент CloudWatch для сбора подробных данных об использовании памяти. Без этого рекомендации ACO по оптимизации размеров в основном полагаются на ЦП и сеть, что может быть неполным.
Непрерывный пересмотр	Относитесь к панели управления ACO как к живому документу. Рабочие нагрузки постоянно меняются, требуя регулярной переоценки размеров ресурсов.

---

Финальная проверка

AWS Compute Optimizer наиболее ценен, когда становится частью привычки пересмотра. Используйте его для поиска потерь, выявления недостаточно обеспеченных ресурсов и оспаривания старых предположений. Затем добавьте контекст, который AWS не может вывести: сроки релизов, пиковые события, обещания клиентам, домены отказов и пути отката. Лучшая программа оптимизации размеров — это не та, которая принимает больше всего рекомендаций. Это та, которая экономит деньги, не делая production более хрупким.