В идеале (если Nginx может быть отделен от определенных задач Node) вам нужна группа автоматического масштабирования, выделенная для каждой службы, и я бы предложил для этого использовать containerization , потому что это это именно то, для чего он предназначен, хотя все это, очевидно, потребует некоторых нетривиальных изменений в вашей программе ...
Это позволит ...
Эффективное распределение ресурсов
- Выбор типов экземпляров с идеальным сочетанием ЦП / ОЗУ / Сети / Хранилища для каждой услуги (Node или Nginx)
- Поддерживать детальный контроль над количеством выполняемых задач относительно их фактической потребности.
Интеллектуальное масштабирование
Пороговые значения, установленные для инициализации действий масштабирования, должны отражать ресурсы, которые они выполняют. Вы, возможно, не захотите сказать, удваивайте свою более интенсивную вычислительную мощность узла, когда в вашей программе возникают всплески простых операций чтения. Сегментируя сервисы по ресурсам, пороговые значения можно привязать к ресурсу, который больше всего требует ваш сервис. Вы можете масштабировать ...
- Nginx на основе максимального количества входящих запросов за период в 1 минуту
- Узел, основанный на средней загрузке ЦП за 5-минутный период
«Куски», на которые разбиты ваши экземпляры в зависимости от размера ваших задач, также имеют большое значение в том, насколько эффективно они будут масштабироваться. Вот преувеличенный пример только для одного сервиса ...
- 1 EC2 t3.large работает 5 узловых задач при 50% использовании ОЗУ.
- AS group Хиты 70% или любые другие заданные вами пороговые значения, масштабирование 1 экземпляр
- Сейчас запущено 2 экземпляра, скажем, 6 задач Node @ 30% использования оперативной памяти
Это вызывает 2 проблемы ...
- Теперь ты тратишь много денег
- Возможно, еще важнее ... каков ваш масштаб? 20% использование?
Чем теснее будут ваши верхние и нижние границы масштабирования, тем эффективнее вы будете. Когда все выполняемые вами задачи однородны, вы можете добавлять и удалять меньшие и более точные «куски» ресурсов.
В приведенном выше сценарии вы бы идеально хотели что-то вроде ...
- 3 t3.small экземпляров, выполняющих 5 задач Node
- AS группа достигает 70% использования, масштабируется 1 экземпляр
- Теперь у вас есть 6 заданий на 4 экземпляра с 50% -ной загрузкой
- Загрузка снижается до 40% в масштабе 1 экземпляр.
Очевидно, что вы все еще можете выполнять все эти запущенные Node и Nginx на одних и тех же базовых ресурсах, но математика всего этого становится довольно сумасшедшей и делает вашу систему хрупкой.
(Я упростил вышеупомянутое, чтобы настроить память Использование в группе AS, но в приложении у вас будет ECS, добавляющий задачи на основе Utillization, который затем добавляет в память Резервирование кластера, которое затем инициирует действия AS.)
Упрощенное и эффективное развертывание
- Вы не хотите повторно развертывать всю свою базу кода Node для каждого обновления конфигурации Nginx.
- Упрощает тестирование и откат развертываний Blue / Green.
- Сведите к минимуму ресурсы, которые вам нужно раскрутить для «синей» части ваших развертываний.
- При необходимости используйте настроенные AMI с предварительно установленными двоичными файлами только для зависящей от них службы
Независимо от того, хотите ли вы сделать это немедленно или нет (и вы захотите), эта конфигурация позволит вам перейти к точечным экземплярам для обработки большего количества переменных переменных нагрузок. Как и все это, вы все еще можете использовать точечные инстансы с выложенной конфигурацией, но эффективная обработка процедур прерывания и без сбоев - это совсем другой беспорядок, и когда вы добираетесь до этого, вы хотите, чтобы остальная часть этого была очень организованной и работала гладко .
ECS
NLB
Я не знаю, что вы используете для развертывания, но AWS CodeDeploy будет прекрасно работать с ECS , чтобы также управлять вашими кластерами контейнеров.