新版 Network Load Balancer 推出

Elastic Load Balancing (ELB) 于 2009 年作为三件组合包的一部分推出（另外两件是 Auto Scaling 和 Amazon CloudWatch），自推出以来一直都是 AWS 的重要组成部分。从那时开始，我们已经添加了很多功能，同时引入了 Application Load Balancer。Application Load Balancer 设计用于支持基于内容的应用程序级路由和运行在容器中的应用程序，非常适用于微服务、流式处理和实时工作负载。这些年来，我们的客户使用 ELB 支持以几乎任意规模运行的网站和应用程序，从在一个或两个 T2 实例上运行的简单站点到在大型高端实例队列上运行的复杂应用程序，并处理海量流量。ELB 还可以在后台监控流量，并自动扩展以满足需求。多年来，这一过程（包括巨大的缓冲空间）的速度更快、响应更迅捷，甚至非常适合那些使用 ELB 来支持直播、闪购和假日季的客户。但是，在某些情况下，例如区域之间的瞬时故障转移或高峰期突增的工作负载，我们会与客户一起预配置 ELB，以应对流量激增。 新版 Network Load Balancer
今天，我们要介绍的是新版 Network Load Balancer (NLB)。它设计用于每秒处理数千万个请求，同时以超低延迟保持高吞吐量，无需您执行任何操作。Network Load Balancer 与 Application Load Balancer 保持 API 兼容，包括对目标组和目标的完全编程控制。以下是它的一些最重要的功能： 静态 IP 地址 – 每个 Network Load Balancer 均可为其权限范围内的每个可用区提供单个 IP 地址，与该 IP 地址的连接将在相应可用区中所有 VPC 子网的实例之间传输流量。如果您同时在 us-west-2a 和 us-west-2c 中有目标，NLB 将创建和管理两个 IP 地址（每个可用区一个）。您也可以为每个可用区指定现有的弹性 IP，以实现更好的控制。通过完全控制 IP 地址，Network Load Balancer 可以用于需要将 IP 地址硬编码为 DNS 记录、客户防火墙规则等的情况。 区域性 – 每可用区一个 IP 地址的功能可以通过提高性能来降低延迟，通过隔离和容错提高可用性，并使 Network Load Balancer 对客户端应用程序透明。此外，Network Load Balancer 还可将来自特定源的一系列请求路由到单个可用区中的目标，并在这些目标不可用时仍然提供自动故障转移。 源地址保留 – 借助 Network Load Balancer，传入连接的初始源 IP 地址和源端口将保持不变，因此，应用程序软件不需要支持 X-Forwarded-For、代理协议，或其他解决方法。这也意味着您可以在目标上使用常规防火墙规则，包括 VPC 安全组。 长时间运行的连接 – NLB 可处理具有内置容错的连接，并且可以处理已打开数月或数年的连接，使其适用于物联网、游戏和消息收发应用程序。 故障转移 – NLB 由 Route 53 运行状况检查提供支持，支持区域内和跨区域的 IP 地址之间的故障转移。

创建 Network Load Balancer
要创建 Network Load Balancer，请打开 EC2 控制台，选择 负载均衡器，然后单击 创建负载均衡器：

选择“Network Load Balancer”，单击创建，然后输入详细信息。为目标 VPC 中的每个子网选择一个弹性 IP 地址，然后标记 Network Load Balancer：

然后单击 配置路由，创建一个新的目标组。输入名称，然后选择协议和端口。我还可以设置要在流量端口或我选择的备用端口上进行的运行状况检查：

单击注册目标和要接收流量的 EC2 实例，然后单击添加到已注册目标：

确保所有设置正确无误，然后单击创建：

新负载均衡器的状态为正在预置，并将在一分钟左右切换到活动状态：

出于测试目的，我直接从控制台获取了负载均衡器的 DNS 名称（在实际操作中，您需要使用 Amazon Route 53 和更友好的名称）：

然后，我向该负载均衡器发送了大量流量（我原本打算让它运行一两秒即可，但是我走神了。结果它创建了大量进程，这是一个有趣的小意外）：

$ while true;
> do
>   wget http://nlb-1-6386cc6bf24701af.elb.us-west-2.amazonaws.com/phpinfo2.php &
> done

当然，更严格的测试会使用 Bees with Machine Guns 之类的工具！

我快速断开了一下，让一些流量传输，然后查看了 Load Balancer 的 CloudWatch 指标，发现它可以轻松应对这种突然的流量冲击：

我还查看了 EC2 实例，看看它们在加载期间的运行状况（事实证明，运行状况非常好）：

后来，我的同事执行了一次更为严格的测试。他们设置了一个 Network Load Balancer，并使用自动扩展的实例队列为其提供支持。然后，他们设置了第二个由数百个 EC2 实例组成的队列，每个实例均运行 Bees with Machine Guns，并被配置为生成具有高度变化的请求和响应大小的流量。从每秒 150 万个请求开始，他们迅速提高拨入，在测试资源耗尽之前，每秒达到了 300 多万个请求和 30Gbps 的总带宽。

选择负载均衡器
与往常一样，在选择负载均衡器时，您应考虑应用程序的需求。下面是一些准则：

Network Load Balancer (NLB) – NLB 每秒能够处理数百万个请求，同时保持超低延迟，非常适合 TCP 流量的负载均衡。NLB 还经过优化，能够处理不稳定的流量模式，同时在每个可用区使用单个静态 IP 地址。

Application Load Balancer (ALB) – ALB 提供支持现代应用程序体系结构（包括微服务和基于容器的应用程序）的高级请求路由，非常适合 HTTP 和 HTTPS 流量的高级负载均衡。

Classic Load Balancer (CLB) – 非常适合在 EC2-Classic 网络中构建的应用程序。

有关并排的功能比较，请参阅 Elastic Load Balancer 详情表。

如果您当前使用的是 Classic Load Balancer，希望迁移到 Network Load Balancer，请参阅我们的负载均衡器复制实用工具。这一 Python 工具可帮助您创建与现有 Classic Load Balancer 配置相同的 Network Load Balancer。它还可以使用新的负载均衡器注册现有 EC2 实例。

定价和可用性
和 Application Load Balancer 一样，新版 NLB 的定价以负载均衡器容量单位 (LCU) 为基础。根据以下几项中的最高值，每 LCU 为 0.006 USD：

带宽 – 1GB/ LCU。
新连接 – 800 个/LCU。
活动连接 – 100,000 个/LCU。

大多数应用程序都有带宽限制，在与 Application Load Balancer 或 Classic Load Balancers 对比时，成本（负载均衡）应减少约 25%。

目前，由 AWS CloudFormation、Auto Scaling 和 Amazon ECS 提供支持的 Network Load Balancer 已面向所有 AWS 商业区域提供，中国（北京）地区除外。

— Jeff；

亚马逊AWS官方博客

新版 Network Load Balancer 推出