AWS负载均衡器+ NginX + EC2 AutoScaling组

Question

当前，我尚未设置AWS Load Balancer。

请求到达单个ec2实例：首先命中nginx，然后将其转发到node / express。

现在，我想创建一个自动扩展组，并附加AWS负载均衡器以分发传入的请求。我想知道这是否是一个很好的设置：

Request -> AWS Load Balancer -> Nginx A + EC2 A
                             -> Nginx B + EC2 B
                             -> ... C   + ... C

Nginx安装在运行了node.js的同一EC2上。 Nginx配置具有使用geoip模块以及gzip压缩配置和ssl处理来检测用户位置的逻辑。

我还将ssl处理移至负载均衡器。

Answer 1

理想情况下（如果可以将Nginx与特定的Node任务分离），您需要一个专门用于每个服务的自动伸缩组，我建议为此使用containerization，因为这是尽管这显然需要对程序进行一些不平凡的更改……

这将启用...

有效的资源分配

• 选择每个服务（节点或Nginx）的CPU / RAM /网络/存储理想组合的实例类型
• 保持相对于实际需求运行的任务数量的精细控制。

智能扩展

设置为初始化缩放操作的阈值需要反映它们正在运行的资源。当您的程序的简单读取操作激增时，您可能不想说，将更多的计算密集型节点容量提高一倍。通过按资源划分服务，可以将阈值与您的服务最需要的资源联系在一起。您可能想要扩展...

• Nginx基于1分钟内的最大入站请求
• 基于5分钟内平均CPU使用率的节点

您的实例相对于您的任务的大小所分为的“块”也对它们扩展的效率产生了很大的影响。这是一个仅在一项服务上的夸大示例...

1. 1个EC2 t3.large运行5个节点任务@ 50％的RAM利用率。
2. AS组达到70％或您分配的任何阈值，向外扩展1个实例
3. 两个正在运行的实例说出6个节点任务@ 30％的RAM利用率

这会导致2个问题...

• 您现在在浪费很多钱
• 更重要的是，您的扩展阈值是多少？利用率为20％？

上限和下限缩放之间的差距越小，您的效率就越高。当您正在运行的任务完全相同时，您可以在更小且更精确的“块”中添加和删除资源。

在上述情况下，理想情况下，您需要...

1. 运行5个节点任务的3个t3.small实例
2. AS组的利用率达到70％，向外扩展1个实例
3. 现在您在4个实例上有6个任务，利用率为50％
4. 利用率下降到40％（在1个实例中）。
   

显然，您仍然可以在相同的基础资源上运行所有正在运行的Node和Nginx，但是它们的数学原理都变得非常疯狂，使您的系统脆弱。

（（我已将上面的内容简化为以AS组上的内存 Utilization 为目标，但是在应用程序中，您需要ECS基于Utillzation添加任务，然后将其添加到内存<集群的strong>预订，然后将启动AS操作。）

简化高效的部署

• 您不想为Nginx配置的每次更新重新部署整个Node代码库。
• 简化了蓝/绿部署测试和回滚。
• 最大程度地减少部署中“蓝色”部分所需的资源。
• 仅在依赖于它们的服务的情况下，才需要使用带有预安装二进制文件的定制AMI

无论您是否要立即执行此操作（并且您将要执行此操作），此配置都将允许您转到Spot Instances来处理更多的可变工作负载。像所有这些一样，您仍可以按已配置的配置使用竞价型实例，但是高效且无中断地处理终止程序又是另一回事，当您需要其余部分时，可以使其井井有条且工作顺利

ECS

NLB

我不知道您正在使用什么进行部署，但是AWS CodeDeploy可以与ECS一起很好地管理您的容器集群。