透過負載平衡改善應用程式延遲

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

負載平衡選項

視傳送至應用程式的流量類型而定，您可以使用多種外部負載平衡選項。下表列出各種選項：

由於內部負載平衡器和 Cloud Service Mesh 不支援面向使用者的流量，因此不在本文討論範圍內。

本文章的評估採用網路服務級別中的進階級，因為全球負載平衡需要使用這個服務級別。

測量延遲時間

當德國使用者存取在 us-central1 代管的網站時，會使用下列方法測試延遲時間：

• 連線偵測 (ping)：雖然 ICMP 連線偵測是測量伺服器可及性的常用方法，但 ICMP 連線偵測不會評估使用者延遲時間。如需更多資訊，請參閱「外部應用程式負載平衡器的其他延遲影響」。
• Curl：Curl 會評估 Time To First Byte (TTFB)。重複向伺服器發出 curl 指令。

比較結果時，請注意光纖連結的延遲時間受限於光纖中的距離和光速，大約為每秒 200,000 公里 (或每秒 124,724 英里)。

德國法蘭克福和愛荷華州康索布魯夫 (us-central1 區域) 之間的距離約為 7,500 公里。如果兩地之間有直達光纖，往返延遲時間如下：

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

光纖電纜並不會沿著使用者和資料中心之間的直線路徑傳輸資料。光纖纜線上的光線會沿著路徑通過主動和被動設備。如果觀察到的延遲時間約為理想值的 1.5 倍，也就是 112.5 毫秒，表示設定已接近理想值。

比較延遲時間

本節將比較下列設定中的負載平衡功能：

• 不使用負載平衡
• 外部直通式網路負載平衡器
• 外部應用程式負載平衡器或外部 Proxy 網路負載平衡器

在這種情況下，應用程式包含 HTTP 網路伺服器的地區性代管執行個體群組。由於應用程式會向中央資料庫發出低延遲呼叫，因此網路伺服器必須在同一個位置代管。應用程式已部署在 us-central1 區域，使用者則分布在全球各地。德國使用者在這個情境中觀察到的延遲時間，說明瞭全球使用者可能會遇到的情況。

不使用負載平衡

使用者發出 HTTP 要求時，除非已設定負載平衡，否則流量會直接從使用者的網路流向在 Compute Engine 上代管的虛擬機器 (VM)。在進階級中，流量會透過距離使用者位置最近的邊緣網路連接點 (PoP) 進入 Google 網路。對於標準級，使用者流量會在靠近目的地地區的 PoP 進入 Google 網路。詳情請參閱網路服務級別說明文件。

下表顯示德國使用者測試系統延遲情形 (未使用負載平衡) 的結果：

  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
  

  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
  

TTFB 延遲時間穩定，如以下前 500 項要求的圖表所示：

當您對 VM IP 位址執行 ping 時，回應會直接來自網路伺服器。與網路延遲時間 (TTFB) 相比，網路伺服器的回應時間非常短。這是因為系統會為每個 HTTP 要求開啟新的 TCP 連線。在傳送 HTTP 回應之前，必須先進行初始三方握手，如下圖所示。因此，觀察到的延遲時間幾乎是連線偵測延遲時間的兩倍。

外部直通式網路負載平衡器

使用外部直通網路負載平衡器時，使用者要求仍會透過最近的邊緣 PoP (在進階級別) 進入 Google 網路。在專案 VM 所在的區域中，流量會先經過外部直通式網路負載平衡器。然後將其轉送至目標後端 VM，但不會變更。外部直通式網路負載平衡器會根據穩定的雜湊演算法分配流量。演算法會使用來源和目的地通訊埠、IP 位址和通訊協定的組合。VM 會監聽負載平衡器 IP，並接受未經修改的流量。

下表顯示德國使用者測試網路負載平衡選項的延遲時間結果。

  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
  

 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
 

由於負載平衡是在區域內進行，且流量只會轉送，因此與沒有負載平衡器相比，不會有明顯的延遲影響。

外部負載平衡

使用外部應用程式負載平衡器時，GFEs 會代理流量。這些 GFE 位於 Google 全球網路的邊緣。GFE 會終止 TCP 工作階段，並連線至可提供流量服務的最近後端。

下表顯示德國使用者測試 HTTP 負載平衡選項的延遲時間結果。

 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
 

 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
 

外部應用程式負載平衡器的結果則截然不同。當您對外部應用程式負載平衡器執行 PING 時，往返延遲時間略高於 1 毫秒。這項結果代表與最接近的 GFE 之間的延遲時間，該 GFE 位於與使用者相同的城市。這項結果並未反映使用者嘗試存取託管在 us-central1 地區的應用程式時，實際體驗到的延遲時間。使用與應用程式通訊協定 (HTTP) 不同的通訊協定 (ICMP) 進行實驗，可能會造成誤導。

測量 TTFB 時，初始要求會顯示類似的回應延遲時間。部分要求的延遲時間低於 123 毫秒，如下圖所示：

即使使用直式光纖，用戶端與 VM 之間的來回兩次傳輸時間也超過 123 毫秒。由於 GFE 會代理流量，因此延遲時間較短。GFE 會持續連線至後端 VM。因此，只有從特定 GFE 傳送至特定後端的第一個要求，才需要三方握手。

每個地點都有多個 GFEs。延遲圖表會顯示多次波動尖峰，這些尖峰會在流量首次抵達每個 GFE 後端組合時出現。接著，GFE 必須建立與該後端的新連線。這些尖峰反映不同的要求雜湊。後續要求的延遲時間較短。

這些情境說明瞭使用者在實際環境中可體驗的延遲時間縮短情形。下表總結了結果：

當正常運作的應用程式為特定地區的使用者提供服務時，該地區的 GFE 會維持與所有服務後端的持續連線。因此，如果使用者距離應用程式後端的距離較遠，該地區的使用者會發現，首次 HTTP 要求的延遲時間會縮短。如果使用者位於應用程式後端附近，就不會注意到延遲時間的改善情形。

對於後續要求 (例如點選網頁連結)，由於新式瀏覽器會持續與服務保持連線，因此延遲時間並未改善。這與從指令列發出的 curl 指令不同。

外部應用程式負載平衡器的其他延遲影響

外部應用程式負載平衡器的其他可觀察效果取決於流量模式。

• 外部應用程式負載平衡器的複雜資產延遲時間比外部直通式網路負載平衡器短，因為在回應完成前，前者需要的往返次數較少。舉例來說，如果德國使用者透過重複下載 10 MB 檔案，來測量相同連線的延遲時間，外部直通網路負載平衡器的平均延遲時間為 1911 毫秒，而外部應用程式負載平衡器的平均延遲時間為 1341 毫秒，因此每個要求可節省約 5 次往返時間。GFE 和服務後端之間的持續連線可減少 TCP 緩慢啟動的影響。

• 外部應用程式負載平衡器可大幅降低 TLS 握手的額外延遲時間 (通常是額外 1 至 2 次來回處理)。這是因為外部應用程式負載平衡器使用 SSL 卸載功能，因此只有邊緣 PoP 的延遲時間才有相關性。對於德國的使用者而言，使用外部應用程式負載平衡器時，觀察到的最小延遲時間為 201 毫秒，而透過外部直通網路負載平衡器使用 HTTP(S) 時，則為 525 毫秒。

• 外部應用程式負載平衡器可讓使用者面向會話自動升級至 HTTP/2。HTTP/2 可利用二進位通訊協定、標頭壓縮和連線多工處理的改善功能，減少所需的封包數量。這些改善措施可進一步縮短觀察到的延遲時間，甚至比切換至外部應用程式負載平衡器時觀察到的延遲時間還要短。目前使用 SSL/TLS 的瀏覽器支援 HTTP/2。對於德國使用者，如果改用 HTTP/2 而非 HTTPS，最小延遲時間會進一步從 201 毫秒降至 145 毫秒。

改善外部應用程式負載平衡器

您可以使用外部應用程式負載平衡器，按照下列方式改善應用程式延遲時間：

• 如果您提供的部分流量可快取，可以整合 Cloud CDN。Cloud CDN 會直接在 Google 網路邊緣提供素材資源，藉此縮短延遲時間。Cloud CDN 也會使用「外部應用程式負載平衡器的其他延遲效果」一節中提到的 HTTP/2 中的 TCP 和 HTTP 最佳化功能。

• 您可以使用任何 CDN 合作夥伴與 Google Cloud。使用 Google 的CDN 互連網路合作夥伴，即可享有資料移轉費用折扣。

• 如果內容為靜態內容，您可以透過外部應用程式負載平衡器，直接從 Cloud Storage 提供內容，藉此減輕網路伺服器的負載。這個選項與 Cloud CDN 搭配使用。

• 在靠近使用者的多個地區部署網路伺服器，可減少延遲時間，因為負載平衡器會自動將使用者導向最近的地區。不過，如果應用程式是部分集中式，請在設計時減少區域間往返的次數。

• 如要減少應用程式內的延遲時間，請檢查 VM 之間通訊的任何遠端程序呼叫 (RPC)。這種延遲通常會發生在應用程式在層級或服務之間通訊時。Cloud Trace 等工具可協助您減少應用程式服務要求造成的延遲時間。

• 由於外部 Proxy 網路負載平衡器是以 GFEs 為基礎，因此對延遲的影響與外部應用程式負載平衡器相同。外部應用程式負載平衡器的功能比外部 Proxy 網路負載平衡器多，因此建議您將外部應用程式負載平衡器用於 HTTP(S) 流量。

後續步驟

建議您將應用程式部署在靠近大多數使用者的地點。如要進一步瞭解Google Cloud中的不同負載平衡選項，請參閱下列文件：

• 外部直通式網路負載平衡器
• 外部應用程式負載平衡器
• 外部 Proxy 網路負載平衡器