負載平衡選項
視傳送至應用程式的流量類型而定，您有幾種外部負載平衡選項。下表摘要列出各種選項：
| 選項 | 說明 | 流量 | 範圍 |
|---|---|---|---|
| 外部應用程式負載平衡器 | 支援 HTTP(S) 流量和進階功能，例如網址對應和 SSL 卸載 針對特定通訊埠上的非 HTTP 流量，請使用外部 Proxy 網路負載平衡器。 |
TCP 或 SSL (TLS) 工作階段會在 Google 網路邊緣的 Google Front End (GFE) 終止，流量會 Proxy 至後端。 | 全球 |
| 外部直通式網路負載平衡器 | 允許使用任何通訊埠的 TCP/UDP 流量通過負載平衡器。 | 使用 Google 的 Maglev 技術將流量分配至後端。 | 區域 |
由於內部負載平衡器和 Cloud Service Mesh 不支援面向使用者的流量，因此不在本文的討論範圍內。
本文的測量結果使用網路服務級別的進階級，因為全球負載平衡需要這個服務級別。
測量延遲時間
存取 us-central1 中代管的網站時，德國使用者可透過下列方法測試延遲時間：
- 連線偵測 (ping)：ICMP 連線偵測是測量伺服器可連線狀態的常見方式，但 ICMP 連線偵測無法測量使用者端延遲。詳情請參閱「外部應用程式負載平衡器的額外延遲影響」。
- Curl：Curl 會測量「第一個位元組時間」(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)。如果是進階級，流量會從靠近使用者所在位置的邊緣連接點進入 Google 網路。如果是標準級，使用者流量會在靠近目的地區域的連接點進入 Google 網路。詳情請參閱「網路服務級別說明文件」。
下表顯示德國使用者測試沒有負載平衡的系統延遲時的結果：
| 方法 | 結果 | 最短延遲時間 |
|---|---|---|
| 連線偵測 (ping) VM IP 位址 (回應直接來自網頁伺服器) |
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 毫秒 |
如下圖所示，前 500 項要求的 TTFB 延遲時間穩定：
在 ping VM IP 位址時，回應會直接來自網路伺服器。 相較於網路延遲 (TTFB)，網路伺服器的回應時間極短。這是因為每個 HTTP 要求都會開啟新的 TCP 連線。如以下圖表所示，傳送 HTTP 回應前，需要先進行初始的三向交握。因此，觀察到的延遲時間接近連線偵測延遲時間的兩倍。
外部直通式網路負載平衡器
使用外部直通式網路負載平衡器時，使用者要求仍會從最接近的邊緣連接點進入 Google 網路 (進階級別)。在專案 VM 所在的區域中，流量會先流經外部直通式網路負載平衡器。然後轉送至目標後端 VM，不會進行任何變更。外部直通式網路負載平衡器會根據穩定的雜湊演算法分配流量。演算法會使用來源和目的地通訊埠、IP 位址和通訊協定的組合。VM 會監聽負載平衡器 IP，並接受未經修改的流量。
下表顯示德國使用者測試網路負載平衡選項的延遲時間時，得到的結果。
| 方法 | 結果 | 最短延遲時間 |
|---|---|---|
| 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 毫秒 |
由於負載平衡是在區域內進行，且只會轉送流量，因此與沒有負載平衡器相比，延遲時間不會受到顯著影響。
外部負載平衡
使用外部應用程式負載平衡器時，GFE 會代理流量。這些 GFE 位於 Google 全球網路的邊緣。GFE 會終止 TCP 工作階段，並連線至最接近的區域中可處理流量的後端。
下表顯示德國使用者測試 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 毫秒 |
外部應用程式負載平衡器的結果明顯不同。對外部應用程式負載平衡器執行 Ping 時，往返延遲時間略高於 1 毫秒。這項結果代表與最接近 GFE 的延遲時間，該 GFE 與使用者位於同一城市。這項結果無法反映使用者嘗試存取 us-central1 地區代管的應用程式時，實際感受到的延遲。如果實驗使用的通訊協定 (ICMP) 與應用程式通訊協定 (HTTP) 不同，可能會產生誤導作用。
測量 TTFB 時，初始要求會顯示類似的回應延遲。如下圖所示，部分要求達到 123 毫秒的最低延遲時間：
即使使用光纖，用戶端與 VM 之間的兩次來回行程仍需超過 123 毫秒。由於 GFE 會代理流量，因此延遲時間較短。GFE 會維持與後端 VM 的永久連線。因此，只有從特定 GFE 到特定後端的第一個要求，才需要三向交握。
每個位置都有多個 GFE。流量首次抵達每個 GFE 後端配對時，延遲圖表會顯示多個波動尖峰。GFE 必須建立與該後端的新連線。這些尖峰反映了不同的要求雜湊。後續要求會顯示較低的延遲時間。
這些情境可展現使用者在正式環境中可體驗的延遲時間縮短情形。下表彙整了結果：
| 選項 | 乒乓 | TTFB |
|---|---|---|
| 沒有負載平衡 | 110 毫秒至網路伺服器 | 230 毫秒 |
| 外部直通式網路負載平衡器 | 110 毫秒至區域內外部直通式網路負載平衡器 | 230 毫秒 |
| 外部應用程式負載平衡器 | 1 毫秒到最近的 GFE | 123 毫秒 |
當運作正常的應用程式在特定區域為使用者提供服務時，該區域的 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 最佳化功能。
您可以搭配 Google Cloud使用任何 CDN 合作夥伴。使用 Google 的 CDN 互連網路合作夥伴，可享有資料移轉費用折扣。
如果內容是靜態的，您可以透過外部應用程式負載平衡器直接從 Cloud Storage 提供內容，藉此減輕網路伺服器的負載。這個選項會與 Cloud CDN 結合。
在靠近使用者的多個地區部署網路伺服器，可減少延遲時間，因為負載平衡器會自動將使用者導向最近的地區。不過，如果應用程式是部分集中式，請設計應用程式，減少區域間的往返次數。
如要縮短應用程式內的延遲時間，請檢查 VM 之間通訊的所有遠端程序呼叫 (RPC)。應用程式在層級或服務之間通訊時，通常會發生這種延遲。Cloud Trace 等工具可協助您減少應用程式服務要求造成的延遲。
由於外部 Proxy 網路負載平衡器是以 GFE 為基礎，因此對延遲的影響與外部應用程式負載平衡器相同。外部應用程式負載平衡器比外部 Proxy 網路負載平衡器具備更多功能，因此建議使用外部應用程式負載平衡器處理 HTTP(S) 流量。
後續步驟
建議您將應用程式部署在靠近大多數使用者的位置。如要進一步瞭解Google Cloud中的不同負載平衡選項，請參閱下列文件：