大多數的負載平衡器都使用循環配置演算法，或以流量為基礎的雜湊演算法來分配流量。然而，使用這兩種演算法的負載平衡器，在遇到尖峰需求超過可用服務容量的情況時卻很難應變。本文說明如何使用 Cloud Load Balancing 來解決這些問題，並且最佳化您的全域應用程式容量。與傳統的負載平衡實作方法相比，這種實作方法通常能提供更優質的使用者體驗並節省費用。
針對 Google Cloud Load Balancing 產品有一系列最佳做法指南，而本文也是該系列的一部份。本文亦附有相關教學課程，請參考「利用負載平衡進行容量管理」教學課程。如要深入瞭解延遲相關資訊，請參閱「透過負載平衡改善應用程式延遲」一文。
全域應用程式的容量挑戰
為全域應用程式調度資源可能非常具有挑戰性；特別是如果您的 IT 預算有限、而工作負載又難以預測且可能瞬間爆發。在 Google Cloud等公開的雲端環境中，您可以利用自動調度資源和負載平衡這類功能所提供的靈活性，應付這項挑戰。但就如同本節所述，自動配置器本身也有一些限制。
啟動新執行個體時的延遲
自動調度資源最常遇到的問題在於，要求的應用程式無法及時為流量提供服務。依您的 VM 執行個體映像檔而定，VM 執行個體通常會在執行指令碼並載入資訊後才會準備就緒。因此，負載平衡通常需要在幾分鐘之後，才能夠將使用者導向至新的 VM 執行個體。在這段期間，流量會被分配到現有的 VM 執行個體，而這些 VM 執行個體上的流量可能已經超出負載。
應用程式受限於後端容量
有些應用程式則根本無法自動調度資源。例如，資料庫的後端容量通常有其限制。因此，只有特定數目的前端能夠存取不具水平擴充能力的資料庫。如果您的應用程式仰賴於每秒支援要求數有限的外部 API，您的應用程式也就無法自動調度資源。
非彈性授權
當您使用授權軟體時，授權通常會限制您使用預設的容量上限。由於您無法即時新增授權，您的自動調度資源能力也可能因而受限。
VM 執行個體空間餘量太少
為因應突然暴增的流量，自動配置器應具有充裕的空間餘量 (例如，在達到 CPU 容量的 70% 時觸發自動配置器)。為了節省成本，您可能會想要將此目標值調高一點，例如調成 CPU 容量的 90%。但是，調高觸發值可能會使得您在遇到流量暴增 (例如需求因廣告活動而突然增加的情況) 時，面臨資源調度上的瓶頸。您必須根據流量的暴增程度及新 VM 執行個體準備就緒的速度來平衡空間餘量的大小。
地區配額
如果某個地區出現未預期的流量暴增情況，現有的資源配額可能會限制您可以調度的執行個體數量，使您無法應付當前流量暴增的情況。不僅如此，調高資源配額的處理程序可能需要花費數小時或數天的時間才能完成。
利用全域負載平衡來應對這些挑戰
外部應用程式負載平衡器和外部 Proxy 網路負載平衡器均為透過全域同步化的 Google Front End (GFE) 伺服器經由 Proxy 傳送的全域負載平衡產品，讓您可以更輕鬆地解決上述各種負載平衡挑戰。這些產品之所以能夠解決負載平衡挑戰，原因在於這些產品分配流量給後端的方法與大多數的地區性負載平衡解決方案不同。
我們將在下面的章節中說明其中的不同之處。
其他負載平衡器使用的演算法
大多數的負載平衡器都使用同樣的演算法在後端之間分配流量：
- 循環配置演算法。不論封包的來源和目的地為何，均會在所有後端之間平均分配封包。
- 雜湊演算法。封包流量會根據流量資訊 (包括來源 IP、目的地 IP、通訊埠和通訊協定) 的雜湊值進行辨識。所有雜湊值相同的流量都會被導向至同一個後端。
雜湊負載平衡是 外部直通式網路負載平衡器目前採用的演算法。此負載平衡器支援 2 個元組雜湊 (根據來源和目的地 IP)、3 個元組雜湊 (根據來源 IP、目的地 IP 和通訊協定) 和 5 個元組雜湊 (根據來源 IP、目的地 IP、來源通訊埠、目的地通訊埠和通訊協定)。
透過使用這兩種演算法，可將健康狀態不良的執行個體從分配作業中移除。然而，後端上的現有負載卻鮮少成為負載分配的考慮因素。
有些硬體或軟體負載平衡器會使用以其他衡量指標 (如加權循環配置、最低負載、最快回應時間或有效連線數) 做為流量轉送依據的演算法。但當負載增加量因流量突然暴增而超過預期的程度時，流量仍會被分配到超載的後端執行個體，導致延遲情況加重。
有些負載平衡器可設定進階規則，將超出後端負載容量的流量轉送至其他集區或重新導向至靜態網站。此方法可讓您有效拒絕這類流量，並且傳送「服務無法使用，請稍後再試」的訊息。還有一些負載平衡器可讓您將要求排入佇列。
全域負載平衡解決方案通常採用以 DNS 為基礎的演算法，根據使用者的位置與後端負載提供不同的地區負載平衡 IP。這些解決方案可為地區部署提供容錯移轉至另一個地區的所有或部分流量。然而，任何以 DNS 為基礎的解決方案通常也都需要幾分鐘的時間才能執行容錯移轉，具體時間取決於 DNS 項目的存留時間 (TTL) 值。一般來說，仍會有少量的流量會持續被導向至存留時間早已過期的舊伺服器。因此，以 DNS 為基礎的全域負載平衡並非處理流量暴增情況的理想解決方案。
外部應用程式負載平衡器的運作方式
外部應用程式負載平衡器採用不同的方法。流量會透過部署於 Google 全球網路邊緣據點的 GFE 伺服器經由 Proxy 傳送。目前 Google 已在全球超過 80 個地點設有網路邊緣據點，而這些節點上的 GFE 伺服器均為負載平衡演算法的分配對象。
外部應用程式負載平衡器會透過於邊緣節點進行全域宣告的單一穩定 IP 位址提供，並且可由任何 GFE 終止其連線。
GFE 透過 Google 的全球網路相互連接。描述每個負載平衡資源的可用後端和可用服務容量的資料會透過全域控制層持續分送至所有 GFE。
流向負載平衡 IP 位址的流量會使用稱為「Waterfall by Region」的特殊負載平衡演算法，經由 Proxy 傳送至外部應用程式負載平衡器設定中所定義的後端執行個體。此演算法會依據執行個體與使用者的距離遠近、傳入的負載量及各區域和地區的可用後端容量來決定最適合為要求提供服務的後端。最後，也會一併將全球各地的負載情況和容量列入考量。
外部應用程式負載平衡器會依據可用的執行個體分配流量。如要根據負載情況新增執行個體，請將這項演算法與自動調度執行個體群組資源功能搭配使用。
地區內的流量
在一般情況下，所有流量都會被傳送至最接近使用者的地區，然後再依據下列準則進行負載平衡：
在各地區中，流量會在執行個體群組之間進行分配，依每個群組的容量而定，這些群組可能分屬多個區域。
如果各區域間的容量不相等，則會根據各區域可用服務容量按比例分配負載。
在同個區域內，要求會平均分配給各群組中的執行個體。
依工作階段相依性設定而定，工作階段會根據用戶端 IP 位址或 Cookie 值加以保留。
除非後端變得無法使用，否則現有的 TCP 連線絕不會移至另一個後端。
下圖說明此情況下的負載平衡分配方式，圖中每個地區都尚有容量能夠處理來自最接近該地區的使用者的負載。
溢流至其他地區的流量
如果整個地區的容量已到達後端服務所設定的服務容量，即會觸發 Waterfall by Region 演算法，並且將流量溢流到仍有可用容量的最近地區。當一個地區的容量到達上限時，流量即會分流至下個最接近的地區，依此類推。地區與使用者的距離遠近，由 GFE 到執行個體後端的網路往返時間界定。
下圖說明當一個地區收到超過其處理能力的流量時，流量溢流到下個最接近地區的情況。
因健康狀態不良的後端導致的跨地區溢流
如果健康狀態檢查發現某個地區有超過半數的後端都健康狀態不良時，GFE 會預防性地先將部分流量溢流到下一個最接近的地區。這是為了避免發生因地區變得健康狀態不良而造成流量完全失敗的情況。因此，即使具有健康狀態不良後端的地區中仍有充裕的剩餘容量，依然也會發生這種溢流情況。
下圖說明溢流的發生機制 (當某個區域中的大多數後端都健康狀態不良時)。
所有地區皆已超出容量
當所有地區皆已達到或超出容量時，則會依照與其容量相比的超出程度來分配各地區的溢流流量。舉例來說，當全域需求超出全域容量 20% 時，負載平衡會依照各地區接受的要求都超過其容量上限 20% 的準則來分配流量，並且盡量將流量保留在本地。
下圖說明套用這項全域溢流規則的情形。在本例中，某個地區收到的流量非常大，以至於根本無法分配全域可用的服務容量。
自動調度資源期間的暫時溢流
自動調度資源是以每個後端服務設定的容量上限為依據，並會在流量接近設定的容量上限時，調用新的執行個體。視要求增加的速度及新執行個體上線的速度而定，可能不需要溢流到其他地區。在其他情況下，在新的本地執行個體尚未上線並做好接收流量的準備之前，溢流可做為暫時的緩衝手段。當自動調度資源擴增的容量已足夠時，所有新的執行個體都會被分配到最近的地區。
溢流的延遲效應
根據 Waterfall by Region 演算法，外部應用程式負載平衡器可能會將部分流量溢流到其他地區。然而，TCP 工作階段和 SSL 流量依然會由最接近使用者的 GFE 終止。這將有助於縮短應用程式延遲的情況；詳情請參閱透過負載平衡改善應用程式延遲。
實作：衡量容量管理的效果
如要瞭解溢流的發生方式及如何使用 HTTP 負載平衡器來管理溢流，請參閱與本文有關的利用負載平衡進行容量管理教學課程。
使用外部應用程式負載平衡器解決容量問題
為解決前述的挑戰，外部應用程式負載平衡器和外部 Proxy 網路負載平衡器都具有將容量溢流到其他地區的功能。全域應用程式的回應延遲時間雖然稍微較長，但卻能帶來比使用地區後端更好的使用體驗。使用地區後端的應用程式，延遲時間通常會較短，但卻可能發生超載的情況。
現在，讓我們重新審視外部應用程式負載平衡器如何解決本文開頭所提及的挑戰：
啟動新執行個體時的延遲。如果自動配置器無法在本地流量暴增時迅速增加足夠的容量，外部應用程式負載平衡器會將連線流量暫時溢流到下個最近的地區。如此可確保原地區中的現有使用者工作階段能繼續在現有的後端以最佳速度進行處理，而且新的使用者工作階段也只會受到些微的延遲影響。等到原地區的額外後端執行個體成功擴增之後，新的流量就會再次路由到最接近使用者的地區。
應用程式受限於後端容量。當某個地區的需求超出一般流量所需的部署容量時，無法自動調度資源但可在多個地區使用的應用程式仍可溢流到下一個最接近的地區。
非彈性授權。如果軟體授權的數量有限，而且當前地區的授權集區已用盡時，外部應用程式負載平衡器可以將流量移往尚有可用授權的地區。使用此方法的前提是，您必須將執行個體的數量上限設為自動配置器的授權數量上限。
VM 空間餘量太少。地區性溢流有助於節省成本的原因在於，您可以透過調高 CPU 使用量觸發條件來設置自動調度資源功能。您也可以將可用的後端容量設為低於各地區的峰值，使流量溢流到其他地區，以確保全域容量隨時都有餘裕。
地區配額。如果 Compute Engine 資源配額不敷需求時，外部應用程式負載平衡器會自動將部分流量重新導向至仍有配額可供擴充的地區。
後續步驟
以下頁面提供 Google 負載平衡選項的更多資訊及背景：