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

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

负载平衡选项

根据发送到您应用的流量类型,您可享受多种负载平衡选项。您的可用选项如下表所述:

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

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

本文中的所有测量均通过优质网络服务优先级进行,因为全局负载平衡仅适用于此服务级。

测量延迟时间

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

  • Ping:虽然这是衡量服务器可达性的一种常用方法,但 ICMP ping 并不能很好地表示最终用户的延迟时间。您可以阅读 HTTP(S) 负载平衡的额外延迟时间影响部分中的说明。
  • 首字节时间 (TTFB):测量第一个 HTTP 响应时间的好办法是反复向服务器发出 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 负载平衡或 TCP 代理

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

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

无负载平衡

当用户发出 HTTP 请求时,除非配置负载平衡,否则流量会直接从用户的网络流向 Compute Engine 上托管的虚拟机。对于优质层级,流量会在靠近用户位置的边缘入网点处进入 Google 的网络。对于标准层级,用户流量会在靠近目标地区的入网点进入 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 请求图(点击放大)

网络负载平衡

使用网络负载平衡器,用户请求仍会在最近的边缘入网点(在优质层级)进入 Google 网络。在项目的虚拟机所在的地区中,流量首先流经 Maglev 负载平衡器。然后,系统在不做任何更改的情况下将其转发到目标后端虚拟机。Maglev 负载平衡器根据稳定的哈希算法分配流量。该算法结合使用来源和目标端口、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)/TCP/SSL 代理负载平衡

借助 HTTP 负载平衡,流量经代理穿过 GFE 前端(通常位于 Google 全球网络的边缘)。GFE 前端终止 TCP 会话并连接到有能力为流量提供服务的最近地区的后端。

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

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

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

 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 负载平衡的结果明显有所不同。对 HTTP 负载平衡器执行 ping 操作时,往返延迟时间仅会超过 1 毫秒。但是,此结果表示到最近的 GFE 前端的延迟时间,在本例中,该 GFE 前端与用户位于同一城市。当用户尝试访问托管在 us- central1 地区的应用时,此结果与实际的延迟时间没有任何关系。这表明使用与您应用通信协议 (HTTP) 不同的协议 (ICMP) 进行实验可能会产生误导。

在测量 TTFB 时,初始请求表现出的响应延迟时间大致相同。在请求过程中,额外的请求达到了 123 毫秒的最短延迟时间,如下图所示:

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

但即使使用完全笔直的光纤,客户端和虚拟机之间的两次往返也将花费超过 123 毫秒。延迟时间较短的原因是流量通过 GFE 前端代理,而 GFE 前端始终打开着与后端虚拟机之间的持久连接。因此,只有从特定 GFE 前端到特定后端的第一个请求才需要三次握手。

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

每个位置有多个 GFE 前端。您可以在延迟时间图表中看到,在流量首次到达每个 GFE 前端-后端对初期,延迟时间有多个波动峰值。这反映了不同的请求哈希。到达所有 GFE 前端后,后续请求会显示较短的延迟时间。

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

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

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

当运行状况良好的应用定期为某个特定地区中的用户提供服务时,该地区中的所有 GFE 前端通常应当对所有服务后端打开一个持久连接。因此,如果该地区中的用户离应用后端很远,他们将发现第一个 HTTP 请求的延迟时间明显缩短。如果用户靠近应用后端,则由于两者距离太近,用户不会观察到延迟时间有任何改善。

对于后续请求(例如点击页面链接),用户不会观察到延迟时间有任何改善,因为现代浏览器已经与要重复使用的服务保持持久连接,这与用户从命令行发出的 curl 命令有所不同。

HTTP(S) 负载平衡的额外延迟时间影响

HTTP(S) 负载平衡还有一些视流量模式而定的可观察到的额外影响。

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

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

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

优化 HTTP(S) 负载平衡

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

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

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

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

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

  • 如需减少应用内的延迟时间,请检查在虚拟机之间进行通信的任何远程过程调用 (RPC)。当应用在层级或服务之间进行通信时,通常会出现这种延迟。Stackdriver Trace 等工具可帮助您最大限度地减少由应用传送请求导致的延迟时间。

  • 由于 TCP 和 SSL 代理也基于 GFE 前端,因此其对延迟时间的影响与使用 HTTP 负载平衡时观察到的影响一样。由于 HTTP(S) 负载平衡具有比 TCP/SSL 代理更多的功能,因此我们建议始终对 HTTP(S) 流量使用 HTTP(S) 负载平衡。

后续步骤

我们建议您将应用部署在大多数用户附近,并选择最适合您使用场景的配置。如需详细了解 Google Cloud 上的不同负载平衡选项,请参阅以下文档: