AWS Load Balancer + 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可以与特定节点任务分离），您需要一个专用于每个服务的自动缩放组，我建议使用containerization，因为这正是它的意思，尽管所有这些显然需要一些非对您的计划进行重大改变......

这将使......

有效的资源分配

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

智能缩放

设置为初始化扩展操作的阈值需要反映它们正在运行的资源。当程序的简单读取操作出现峰值时，您可能不想说，计算密集型节点容量增加一倍。通过按资源划分服务，阈值可以与您的服务最需要的资源相关联。你可能想要扩展......

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

你的实例相对于你的任务大小而被破坏的“块”也会对它们的扩展效率产生很大的影响。这是一个夸张的例子，只有一个服务......

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

这导致2个问题......

• 你现在浪费了很多钱
• 可能更重要的是......你的入门门槛是多少？ 20％的利用率？

你上下缩放界限越紧，你的效率就越高。当您运行的任务都是同质的时，您可以在更小，更精确的“块”资源中添加和删除。

在上面的场景中，你理想地想要像...

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

你显然仍然可以在相同的底层资源上运行所有这些运行Node和Nginx，但是它的数学都变得相当疯狂并且使你的系统变得脆弱。

（我已将上述内容简化为AS组上的内存利用率，但在应用程序中，您可以使用ECS添加基于Utillzation的任务，然后将其添加到群集的内存预留中，然后启动AS操作。）

简化和高效的部署

• 您不希望为Nginx配置的每次更新重新部署整个Node代码库。
• 简化蓝/绿部署测试和回滚。
• 最大限度地减少为部署的“蓝色”部分启动的资源。
• 如果需要，仅使用依赖于它们的服务，将定制的AMI与预先安装的二进制文件一起使用

无论您是否想立即执行此操作（并且您将），此配置将允许您移至Spot Instances以处理更多可变工作负载。像所有这些一样，您仍然可以使用现有实例配置您已经布置的配置，但是有效且无中断地处理终止程序是另一个混​​乱，当您达到这一点时，您希望其余部分非常有条理并且工作顺利。

ECS

NLB

我不知道你用于部署的是什么，但AWS CodeDeploy将与ECS合作，以管理你的容器集群。