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

时间:2019-01-08 01:07:13

标签: amazon-web-services nginx amazon-ec2 amazon-elb aws-load-balancer

当前,我尚未设置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处理移至负载均衡器。

1 个答案:

答案 0 :(得分:1)

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

enter image description here

这将启用...


有效的资源分配

  • 选择每个服务(节点或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一起很好地管理您的容器集群。