Горизонтальное и вертикальное автомасштабирование с AWS ECS Fargate - PullRequest
Новая
       36

Горизонтальное и вертикальное автомасштабирование с AWS ECS Fargate

2 голосов
/ 07 января 2020

У меня есть небольшой конкретный пример использования c. Мне нужно автоматически масштабировать распределенное веб-приложение, работающее на ECS Fargate. Подвох заключается в том, что все узлы должны хранить в памяти одни и те же данные (поэтому увеличение количества узлов не помогает при нагрузке на память). Таким образом, увеличивающаяся нагрузка может быть правильно обработана только в том случае, если она масштабируется как по горизонтали (добавление узлов), так и по вертикали (увеличение памяти узлов).

Горизонтальное автоматическое масштабирование очень просто. AWS CDK предоставляет хорошие высокоуровневые конструкции для задач Fargate с балансировкой нагрузки и позволяет очень просто добавлять дополнительные задачи для обработки нагрузки на процессор: 

service = aws_ecs_patterns.ApplicationLoadBalancedFargateService(
    self,
    'FargateService',
    cpu=256,
    memory_limit_mib=512,
    ...
)

scalable_target = service.service.auto_scale_task_count(max_capacity=5)
scalable_target.scale_on_cpu_utilization('CpuScaling', target_utilization_percent=60)

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

  1. Создать тревогу CloudWatch для использования памяти кластером. Запуск более 60%.
  2. Сигнал тревоги отправляет сообщение SNS topi c, которое запускает лямбда-функцию.
  3. Лямбда описывает текущее определение задачи и анализирует параметры процессора и памяти , Затем он создает новую версию определения задачи с увеличенной памятью (и ЦП, если это необходимо, поскольку ЦП и память не являются независимыми значениями в Fargate).
  4. Наконец, лямбда-код обновляет службу новым определением задачи. Это должно запустить непрерывное обновление и привести к кластеру с таким же числом узлов, но каждый с большей памятью.

Как вы думаете, это может работать? Есть ли лучшее решение? Любые потенциальные проблемы, которые вы можете обнаружить?

Заранее спасибо за любые идеи!

1 Ответ

1 голос
/ 07 января 2020

Это кажется разумным способом go об этом и может сработать.

Проблема может заключаться в том, что вы не отслеживаете увеличение потребности в памяти в своем шаблоне Ia C. Это может привести к «сбросу» службы к минимальному объему памяти при запуске обновления стека, которое изменяет что-либо в службе.

Чтобы решить эту проблему, вы можете создать SSM-Parameters , которые содержат значение ЦП и модулей памяти, на которое вы ссылаетесь в своем шаблоне . Ваша лямбда также должна будет обновить их новыми значениями. Таким образом, обновления службы через CloudFormation / CDK не должны запускать процесс масштабирования немедленно.

Вы только увеличиваете объем памяти, есть сценарий, в котором уменьшается спрос на память, и вы можно уменьшить также? (Это можно сделать с помощью того же / или аналогичного механизма, просто помните)

...