通过负载平衡优化应用延迟

本文档讨论负载平衡选项,并说明您在 Google Cloud 上选择的特定负载平衡器如何影响端到端延迟时间。

负载平衡选项

根据发送到您应用的流量类型,您可以选择多种外部负载平衡方法。您的可用选项如下表所述:

选项 说明 流量 范围
HTTP(S) 负载平衡 支持 HTTP(S) 流量和高级功能,例如网址映射和 SSL 分流
支持将 TCP 代理负载平衡SSL 代理负载平衡用于特定端口上的非 HTTP 流量。
TCP 或 SSL (TLS) 会话在 Google 网络边缘 的 Google Front End (GFE) 前端终止,并且流量被代理到后端。 全球
网络负载平衡 允许 TCP/UDP 流量使用任何端口通过负载平衡器。 利用 Google 的 Maglev 技术将流量分配到后端。 地区

由于内部负载平衡器和 Traffic Director 不支持面向用户的流量,因此不在本文讨论范围之内。

本文的测量结果使用 Network Service Tiers 中的优质层级,因为全球负载平衡需要此服务层级。

测量延迟时间

在访问 us-central1 中托管的网站时,德国的用户使用以下方法来测试延迟时间:

  • Ping:虽然 ICMP ping 是衡量服务器可达性的一种常用方法,但 ICMP ping 不会衡量最终用户延迟。如需了解详情,请参阅 HTTP(S) 负载平衡的额外延迟效应
  • Curl:Curl 测量收到第一个字节的时间 (TTFB)。向服务器重复发出 curl 命令。

在比较结果时,请注意,光纤链路上的延迟时间受到距离和光纤中光速(约为 200000 公里/秒,或 124724 英里/秒)的限制。

德国法兰克福与爱荷华州康瑟尔布拉夫斯(us-central1 地区)之间的距离约为 7500 公里。在位置之间采用笔直的光纤,往返延迟如下:

7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)

用户和数据中心之间的光纤线缆不会遵循笔直的路径。光纤线缆上的光线沿途要经过有源和无源设备。观察到的延迟约为理想值的 1.5 倍,即 112.5 毫秒,即表明接近理想的配置。

比较延迟时间

本部分比较了以下配置中的负载平衡:

  • 无负载平衡
  • 网络负载平衡
  • HTTP(S) 负载平衡或 TCP 代理负载平衡

在此方案中,应用是由 HTTP 网络服务器的地区代管实例组所组成的。由于该应用依赖于对中央数据库的短延迟时间调用,因此必须将各个网络服务器托管在一个位置。该应用部署在 us-central1 地区,用户分布在全球各地。德国用户在此方案中观察到的延迟时间说明了全球用户都可能会遇到的情况。

延迟时间场景图(点击放大)
延迟时间场景图(点击放大)

无负载平衡

当用户发出 HTTP 请求时,除非配置负载平衡,否则流量会直接从用户的网络流向 Compute Engine 上托管的虚拟机。对于优质层级,流量会在靠近用户位置的边缘入网点 (PoP) 处进入 Google 的网络。对于标准层级,用户流量会在靠近目标地区的 PoP 进入 Google 的网络。如需了解详情,请参阅网络服务层级文档

没有负载平衡的架构(点击放大)
没有负载平衡的架构(点击放大)

下表显示了德国用户在没有使用负载平衡的情况下测试系统延迟时间的结果:

方法 结果 最短延迟时间
对虚拟机 IP 地址进行 Ping 操作(网络服务器直接响应)

  ping -c 5 compute-engine-vm
  

  PING compute-engine-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms
  [...]
  --- compute-engine-vm ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4004ms
  rtt min/avg/max/mdev = 110.818/110.944/111.265/0.451 ms
  
110 毫秒
TTFB

  for ((i=0; i < 500; i++)); do curl -w  /
  "%{time_starttransfer}\n" -o /dev/null -s compute-engine-vm; done
  

  0.230
  0.230
  0.231
  0.231
  0.230
  [...]
  0.232
  0.231
  0.231
  
230 毫秒

TTFB 延迟是稳定的,如下图(含有前 500 个请求)所示:

到虚拟机的延迟时间(毫秒)图(点击放大)
到虚拟机的延迟时间(毫秒)图(点击放大)

对虚拟机 IP 地址执行 ping 操作时,响应直接来自网络服务器。与网络延迟时间 (TTFB) 相比,网络服务器的响应时间最短。这是因为每个 HTTP 请求都会打开新的 TCP 连接。发送 HTTP 响应前需要初始三向握手,如下图所示。因此,观察到的延迟时间接近 ping 延迟时间的两倍。

客户端-服务器 HTTP 请求图(点击放大)
客户端-服务器 HTTP 请求图(点击放大)

网络负载平衡

使用网络负载平衡器,用户请求仍会在最近的边缘 PoP(在优质层级)进入 Google 网络。在项目虚拟机所在的地区中,流量首先流经网络负载平衡器。然后,系统在不做任何更改的情况下将其转发到目标后端虚拟机。网络负载平衡器根据稳定的哈希算法分配流量。该算法结合使用来源和目标端口、IP 地址和协议。虚拟机侦听负载平衡器 IP 地址并原封不动地接受流量。

具有网络负载平衡的架构(点击放大)
具有网络负载平衡的架构(点击放大)

下表显示了德国用户针对 network-load-balancing 选项测试延迟时间的结果。

方法 结果 最短延迟时间
对网络负载平衡器进行 Ping 操作

  ping -c 5 net-lb
  

  PING net-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=44 time=110 ms
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=44 time=110 ms
  [...]
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=44 time=110 ms
  --- net-lb ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4007ms
  rtt min/avg/max/mdev = 110.658/110.705/110.756/0.299 ms
  
110 毫秒
TTFB

 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s net-lb
 

 0.231
 0.232
 0.230
 0.230
 0.232
 [...]
 0.232
 0.231
 
230 毫秒

由于负载平衡操作发生在地区内,并且流量只转发,因此与没有负载平衡器相比,延迟时间不会受到显著影响。

外部负载平衡

使用 HTTP(S) 负载平衡,GFE 代理流量。这些 GFE 位于 Google 全球网络边缘。GFE 终结 TCP 会话并连接到可处理流量的最近地区的后端。

HTTP(S) 负载平衡场景图(点击可放大)
HTTP(S) 负载平衡场景图(点击可放大)

下表显示了德国用户针对 HTTP-load-balancing 选项测试延迟时间的结果:

方法 结果 最短延迟时间
Ping HTTP(S) 负载平衡

 ping -c 5 http-lb
 

 PING http-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=1.22 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=1.20 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=56 time=1.16 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=56 time=1.17 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=56 time=1.20 ms
 --- http-lb ping statistics ---
 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
 rtt min/avg/max/mdev = 1.163/1.195/1.229/0.039 ms
 
1 毫秒
TTFB

 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s http-lb; done
 

 0.309
 0.230
 0.229
 0.233
 0.230
 [...]
 0.123
 0.124
 0.126
 
123 毫秒

HTTP(S) 负载平衡的结果截然不同。在 Ping HTTP(S) 负载平衡时,往返延迟时间略微超过 1 毫秒。此结果表示距离最近的 GFE 的延迟,该 GFE 与用户位于同一城市。当用户尝试访问托管在 us-central1 地区的应用时,此结果并不反映用户体验到的实际延迟时间。使用与您的应用通信协议 (HTTP) 不同的协议 (ICMP) 进行实验可能会产生误导。

在测量 TTFB 时,初始请求表现出的响应延迟时间相似。一些请求达到了 123 毫秒的最短延迟时间,如下图所示:

HTTP(S) 负载平衡的延迟时间(毫秒)图(点击可放大)
HTTP(S) 负载平衡的延迟时间(毫秒)图(点击可放大)

即使使用笔直的光纤,客户端与虚拟机之间的两次往返也会花费超过 123 毫秒。延迟时间更短,因为 GFE 代理流量。GFE 会保持与后端虚拟机的持久连接。因此,只有从特定 GFE 前端到特定后端的第一个请求才需要三次握手。

通过 GFE 前端的初始 HTTP 请求图(点击放大)
通过 GFE 前端的初始 HTTP 请求图(点击放大)

每个位置有多个 GFE。延迟时间图显示了首次到达每个 GFE 后端对时的多个波动峰值。然后,GFE 必须建立与该后端的新连接。这些峰值反映了不同的请求哈希。后续请求的延迟时间会更短。

通过 GFE 前端的后续 HTTP 请求图(点击放大)
通过 GFE 前端的后续 HTTP 请求图(点击放大)

这些方案演示了用户在生产环境中可体验到的减少的延迟时间。结果如下表所示:

选项 Ping TTFB
无负载平衡 110 毫秒到达网络服务器 230 毫秒
网络负载平衡 110 毫秒到达地区内网络负载平衡器 230 毫秒
HTTP(S) 负载平衡 1 毫秒到达最近的 GFE 123 毫秒

当运行状况良好的应用为某个特定地区中的用户提供服务时,该地区中的 GFE 会保持对所有服务后端开放的持久连接。因此,如果该地区中的用户离应用后端很远,他们会注意到第一个 HTTP 请求的延迟时间缩短。如果用户靠近应用后端,则用户不会注意到延迟时间方面的改善。

对于后续请求(例如点击页面链接),延迟时间未得到改善,因为现代浏览器会保持与服务的持久连接。这与从命令行发出的 curl 命令不同。

HTTP(S) 负载平衡的额外延迟效应

HTTP(S) 负载平衡的其他可观察效应还取决于流量模式。

  • 与网络负载平衡相比,HTTP(S) 负载平衡对复杂资源的延迟时间更短,因为在响应完成之前需要的往返次数较少。例如,当德国用户在重复下载 10 MB 文件时通过同一连接测量延迟时间,网络负载平衡的平均延迟为 1911 毫秒,而 HTTP(S) 负载平衡的平均延迟为 1341 毫秒。每次请求可节省大约 5 次往返。GFE 和服务后端之间的持久连接减少了 TCP 缓慢启动的影响。

  • HTTP(S) 负载平衡可显著减少对 TLS 握手的额外延迟时间(通常为 1-2 次额外往返),因为 HTTP(S) 负载平衡使用 SSL 分流,而且只与边缘 PoP 的延迟时间相关。对于德国用户,使用 HTTP(S) 负载平衡观察到的最短延迟时间为 201 毫秒,而通过网络负载平衡器使用 HTTP(S) 观察到的最短延迟时间为 525 毫秒。

  • HTTP(S) 负载平衡允许将面向用户的会话自动升级到 HTTP/2,通过改进二进制协议、头文件压缩和连接多路复用来减少所需的数据包数量。这可以减少观察到的延迟时间,甚至比切换到 HTTP(S) 负载平衡所观察到的延迟时间减少得更多。使用 SSL/TLS 的当前浏览器支持 HTTP/2。对于德国用户来说,用 HTTP/2 代替 HTTPS 时,最短延迟时间进一步减少,从 201 毫秒减少至 145 毫秒。

优化 HTTP(S) 负载平衡

使用外部 HTTP(S) 负载平衡器可以优化应用的延迟,如下所示:

  • 如果您提供的部分流量可缓存,您可以将其与 Cloud CDN 进行集成。Cloud CDN 通过直接在 Google 的网络边缘为资源提供服务来减少延迟时间。Cloud CDN 还利用了 HTTP(S) 负载平衡的额外延迟时间影响部分中提到的来自 HTTP/2 的 TCP 和 HTTP 优化。

  • 您可以将任何 CDN 合作伙伴的服务与 Google Cloud 搭配使用。通过使用 Google 的 CDN 互连合作伙伴之一的服务,您可以从享受折扣的出站流量费用中受益。

  • 如果内容是静态的,您可以借助 HTTP(S) 负载平衡器直接从 Cloud Storage 提供内容,从而减少网络服务器上的负载。此选项与 Cloud CDN 结合使用。

  • 将您的 Web 服务器部署在靠近用户的多个地区中可以减少延迟时间,因为 HTTP(S) 负载平衡、SSL 代理负载平衡和 TCP 代理负载平衡会自动将用户定向到最近的地区。但是,如果您的应用是部分集中式,请将其设计为减少地区间往返次数。

  • 如需减少应用内的延迟时间,请检查在虚拟机之间进行通信的任何远程过程调用 (RPC)。当应用在层级或服务之间进行通信时,通常会出现这种延迟。Cloud Trace 等工具可以帮助您降低应用服务请求造成的延迟。

  • 由于 TCP 代理负载平衡和 SSL 代理负载平衡是以 GFE 为基础的,因此对延迟时间的影响与使用 HTTP(S) 负载平衡时相同。由于 HTTP(S) 负载平衡具有比 TCP 代理负载平衡和 SSL 代理负载平衡更多的功能,因此我们建议将 HTTP(S) 负载平衡用于 HTTP(S) 流量。

后续步骤

我们建议您在靠近大多数用户的位置部署应用。如需详细了解 Google Cloud 中的不同负载平衡选项,请参阅以下文档: