Политика автомасштабирования AWS прерывает занятые экземпляры вместо простоя

У меня есть политика автомасштабирования, которая масштабирует мои экземпляры бэкэнда в зависимости от общего использования процессора группой. У AWS есть несколько различий, которые можно выбрать из Политики завершения, таких как OldestInstance, OldestLaunchConfiguration, NewestInstance и ClosestToNextInstanceHour.

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

У кого-нибудь есть предложения обойти? Также мои экземпляры не используют внутренний ELB.

Источник

3 ответа

Политики масштабирования используются для изменения требуемой емкости группы автоматического масштабирования. Эти политики масштабирования могут быть вызваны из сигнала тревоги AWS CloudWatch или могут быть вызваны через вызов API.

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

Есть несколько способов справиться с этим:

  • Разрешить прекращение, но восстановить работу, которая была потеряна
  • Использование ловушек группового автоматического масштабирования
  • Контролируйте завершение экземпляра самостоятельно

Разрешение прекращения вполне допустимо, если ваша группа автоматического масштабирования обрабатывает информацию из рабочей очереди, например Amazon Simple Queue Service (SQS). В этом случае, если экземпляр извлекает сообщение из очереди SQS, сообщение будет помечено как невидимое в течение определенного периода времени. Если экземпляр специально не удаляет сообщение в течение определенного периода времени, то сообщение снова появится в очереди. Таким образом, работа, которая была потеряна, будет переработана.

Использование ловушек группового автоматического масштабирования позволяет перемещать экземпляр, помеченный для завершения, в Terminating:Wait государство. Затем сигнал отправляется через SNS или SQS, и автоматическое масштабирование ожидает возвращения сигнала, прежде чем завершить экземпляр. См. Жизненный цикл группы автоматического масштабирования.

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

Вы можете использовать вызов API DetachInstances, чтобы удалить экземпляр из группы автоматического масштабирования, после чего вы завершите работу и затем завершите работу экземпляра.

Источник

Этот вопрос старый, но я не нашел ничего красивее, поэтому выскажу свою точку зрения.

В сценарии, где сервисные работники:

  • можно легко породить
  • подобрать работу из кучи
  • затем оставайтесь без дела, пока не появится дальнейшая часть работы

вы должны справиться с прекращением самостоятельно.

Итак, у нас есть группа автоматического масштабирования в одном направлении (вверх) и контролируемое масштабирование вниз. Способ контролировать это, как говорит Брэдли в комментариях:

https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html

Дизайн, который я придумал в той же ситуации, следующий.

      
    ┌──────────────────┐            ┌───────────────────────┐
    │ @EventBridge     │    2       │   CloudWatch          │
    │  ( every 1 min ) ├───────────►│ get-metric-statistics │
    │                  │            │                       │
    │     Lamdba       │            └───────────────────────┘
    └─┬──┬─────────────┘
      │  │
      │  │      ┌────────────────────────────────────────────┐
      │  │      │     AutoScaling Group                      │
      │  │  1   │                                            │
      │  └──────┼─►describe-auto-scaling-groups              │
      │     3   │                                            │
      └─────────┼─►terminate-instance-in-auto-scaling-group  │
                │    --should-decrement-desired-capacity     │
                │                                            │
                └────────────────────────────────────────────┘

И в упорядоченных шагах:

  1. Получите экземпляры внутри группы автоматического масштабирования ( aws cli )
  2. Получите статистику по каждому экземпляру ( aws cli ), например, среднее значение CPUUtilizationили другие в течение определенного периода времени.
  3. Решите внутри лямбда-функции, что завершать
  4. Установите для завершения нужные экземпляры ( aws cli ) и одновременно обновите желаемую емкость.

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

Источник

Вы также можете защитить определенные экземпляры от масштабирования

https://aws.amazon.com/blogs/aws/new-instance-protection-for-auto-scaling/

Сообщение в блоге устарело, но эта функция все еще доступна

Источник
Другие вопросы по тегам