負載平衡
當流量增加時，將新的 VM 上線以進行相應放大，是調整以符合需求的有效策略。 可以快速佈建 VM 的事實，對於獲得彈性而言至關重要。 但是除非能將流量散發到額外的伺服器上，否則將那些伺服器上線並不會有太大的「幫助」。 整體來說，這有助於系統處理增加的負載。 這就是為什麼負載平衡對於獲得彈性而言如此重要，因為負載平衡能夠動態地調整專門用於某個工作的資源數目。
對負載平衡的需求源自兩個基本需求。 首先，輸送量可透過平行處理來改善。 如果單一伺服器每個時間單位可以處理 5,000 個要求，則 10 部完美負載平衡的伺服器每個時間單位就能處理 50,000 個要求。 其次，負載平衡的資源會產生較高的可用性。 負載平衡器不會將要求轉送到已難以跟上的伺服器，而是將要求導向至負載較輕的伺服器。 此外，如果伺服器離線且負載平衡器辨識出該情況，則可將要求導向其他伺服器。
什麼是負載平衡？
一種眾所共知的負載平衡形式是「循環配置資源 DNS」，許多大型 Web 服務會使用此形式，在多部伺服器之間散發要求。 具體而言，多部前端伺服器 (每部都具備唯一的 IP 位址) 會共用一個 DNS 名稱。 為了平衡每部 Web 伺服器上的要求數目，Google 等大型公司會維護並策展每個 DNS 項目的 IP 位址集區。 當用戶端提出要求 (例如針對 www.google.com) 時，Google 的 DNS 就會從集區中選取一個可用的位址，並將其傳送給用戶端。 採用來分派 IP 位址的最簡單策略就是使用迴圈配置資源佇列，其會在每個 DNS 回應之後，排列位址清單。
在雲端問世之前，DNS 負載平衡是一種可減少長距離連線延遲的簡單方式。 DNS 伺服器上的發送器是以程式設計的方式，以地理位置上最接近用戶端的伺服器 IP 位址來回應。 這麼做的最簡單方式就是以集區中的 IP 位址來回應，此 IP 位址是數字上最接近用戶端的 IP 位址。 由於 IP 位址未散發於全球階層，因此，這個方法並不可靠。 當前的技術更加精密，並會依賴 IP 位址到位置的軟體對應 (以網際網路服務提供者 (ISP) 的實體地圖為依據)。 由於此對應會實作為昂貴的軟體查閱，因此這個方法會產生更好的結果，但計算成本昂貴。 不過，因為只有當用戶端第一次連線到伺服器時才會執行 DNS 查閱，所以會分攤緩慢查詢的成本。 所有後續通訊都會在用戶端與擁有已分派 IP 位址的伺服器之間直接發生。 圖 9 即為一個 DNS 負載平衡配置範例。
「圖 9：雲端環境中的負載平衡。」
此方法的缺點是在伺服器失敗時，切換至不同的 IP 位址取決於 DNS 快取的存留時間 (TTL) 設定。 DNS 項目已知是長期存留的，而且已知更新需要一週以上的時間才能傳播。 這表示很難快速地對用戶端「隱藏」伺服器失敗。 減少快取中 IP 位址的有效性 (TTL) 可從效能成本方面改善這一點，並增加查閱次數。
新式負載平衡通常是指使用專用的執行個體 (或一對執行個體)，將連入要求分派至後端伺服器。 針對指定連接埠上的每個連入要求，負載平衡器會根據散發策略，將流量重新導向其中一部後端伺服器。 這樣做，負載平衡器就會維護要求中繼資料，包括應用程式通訊協定標頭 (例如 HTTP 標頭) 之類的資訊。 在此情況下，由於每個要求都會通過負載平衡器，因此不會有過時的資訊。
儘管所有類型的網路負載平衡器都會將要求連同所有內容轉送到後端伺服器，但在將回應提供回用戶端時，其可能會採用下列兩個基本策略的其中一個1：
通過 Proxy 處理：在此方法中，負載平衡器會接收來自後端的回應，並將其轉送回用戶端。 負載平衡器的作用和標準 Web Proxy 相同，且同時包含網路交易的兩個部分，也就是將要求轉送到用戶端和將回應傳送回來。
TCP 遞交：在此方法中，會將與用戶端的 TCP 連線遞交給後端伺服器，而伺服器會直接將回應傳送給用戶端，而不會經過負載平衡器。
圖 10 顯示上述策略中的後者。
圖 10︰從發送器到後端伺服器的 TCP 遞交機制。
負載平衡的優點
負載平衡的優點之一是其有助於為系統中的失敗設定遮罩。 只要將用戶端公開至代表數個資源的單一端點，就可以透過使用其他資源來服務要求，以對用戶端隱藏個別資源的失敗。 但是，負載平衡器本身現在會變成單一失敗點。 如果其因為任何原因而失敗，即使所有後端伺服器仍正常運作，也不會處理任何用戶端要求。 因此，為了達到高可用性，負載平衡器通常會成對實作。
更重要的是，負載平衡會透過將工作負載散發到雲端中的數個計算資源來改善回應能力。 在雲端中擁有單一計算執行個體有數個限制。 先前的課程模組已討論過效能的實體限制，其中需要更多資源，才能增加工作負載。 透過使用負載平衡，可將較大型工作負載散發到多個資源，讓每個資源都可獨立且平行地滿足其要求，以提高應用程式的輸送量。 負載平衡也會改善平均回應時間，因為有更多的伺服器可以處理工作負載。
健康情況檢查是實作成功負載平衡策略的關鍵。 負載平衡器需要知道資源何時變成無法使用，如此就能避免將流量轉送到該資源。 Ping-Echo 監視是用來檢查特定資源健康情況的最受歡迎策略之一，其中的負載平衡器會透過網際網路控制訊息通訊協定 (ICMP) 要求對伺服器進行 "ping" 測試。 除了在將流量轉送至資源時要考慮該資源的健康情況，某些負載平衡策略也會將輸送量、延遲和 CPU 使用率等其他計量納入考量。
負載平衡器通常必須保證高可用性。 若要這麼做，最簡單的方法就是建立多個負載平衡執行個體 (各有一個唯一的 IP 位址)，並將其連結到單一 DNS 位址。 每當負載平衡器因為任何原因而失敗時，就會以新的負載平衡器來取代，並以對效能影響最低的方式，將所有流量傳遞到容錯移轉執行個體。 同時，可設定新的負載平衡器執行個體來取代失敗的執行個體，而且必須立即更新 DNS 記錄。
除了在後端伺服器之間散發要求，負載平衡器通常會採用機制來減少伺服器上的負載，並改善整體輸送量。 其中一些機制包括：
SSL 卸載：HTTP 連線會產生額外的效能成本，因為其上的流量會經過加密。 您可以透過安全通訊端層 (SSL) 建立與負載平衡器的用戶端連線，同時透過未加密的 HTTP 將要求重新導向每部伺服器，而不是透過 SSL 來服務所有要求。 此技術可大幅降低伺服器上的負載。 此外，只要重新導向要求不是透過開放式網路所提出的，就會維護安全性。
TCP 緩衝：用來卸載與負載平衡器連線速度較慢之用戶端的策略，因而能夠緩解為這些用戶端提供回應的伺服器。
快取：在某些案例中，負載平衡器可以針對最熱門的要求 (或者不需要傳送至伺服器就能處理的要求，例如靜態內容) 維護快取，以減少伺服器上的負載。
流量成形：負載平衡器可以使用此技術來延遲封包的流量或重新排列優先順序，以將伺服器設定的流量最佳化。 這會影響某些要求的 QoS，但確保可提供連入的負載。
請務必記住，只有當負載平衡器本身沒有無法克服負載時，負載平衡才有作用。 否則，負載平衡器就會成為瓶頸。 幸運的是，負載平衡器通常不會處理所收到的要求，而是依賴後端伺服器來執行將要求轉換為回應的實際工作。
公平分派
雲端中使用數種負載平衡策略。 其中一個最常見策略是「公平分派」，其會使用簡單的迴圈配置資源演算法，將流量平均散發到所有節點。 其不會考慮系統中個別資源的使用率，也不會將要求執行時間納入考量。 此方法會嘗試讓系統中的每個節點保持忙碌，而且是最簡單的實作方法之一。
AWS 會在其 Elastic Load Balancer (ELB) 供應項目中使用此方法。 ELB 會佈建負載平衡器，以在連接的 EC2 執行個體之間平衡流量。 負載平衡器基本上就是 EC2 執行個體本身，並具備專門路由傳送流量的服務。 當負載平衡器後方的資源擴增時，新資源的 IP 位址就會在負載平衡器的 DNS 記錄上更新。 此程序要花費數分鐘才能完成，因為它需要監視和佈建時間。 這段調整期間 (負載平衡器準備好處理較高負載之前的等候時間) 即所謂的「準備」負載平衡器。
AWS 負載平衡器也會監視與其連接的資源，可用來進行工作負載散發，以維護健康情況檢查。 Ping-Echo 機制可用來確保所有資源均為狀況良好。 ELB 使用者可以透過指定延遲和重試次數，來設定健康情況檢查的參數。
雜湊型分散
這種方法會在工作階段持續期間，透過雜湊中繼資料來定義每個要求，並使用該雜湊來挑選伺服器，以確保每次都會將來自相同用戶端的要求導向相同的伺服器。 如果雜湊正確完成，則會在伺服器之間平均散發要求。 此方法的優點之一是，其適用於工作階段感知的應用程式，可將工作階段資料儲存於記憶體中，而不是將其寫出至共用資料存放區，例如資料庫或 Redis 快取。 缺點則是每個要求都必須經過雜湊處理，這會導致少量的延遲。
Azure Load Balancer 會使用雜湊型機制來散發負載。 此機制會根據來源 IP、來源連接埠、目的地 IP、目的地連接埠及通訊協定類型，為每個要求建立雜湊，以確保在普通情況下，來自相同工作階段的每個封包都會到達相同的後端伺服器。 選擇雜湊函式的原因，是為了隨機散發與伺服器的連線。
其他負載平衡策略
如果特定伺服器忙於處理一個要求 (或一組要求)，則利用迴圈配置資源或雜湊型分派演算法的負載平衡器仍會將要求轉送給該伺服器。 還有其他更複雜的策略可在多個資源之間平衡負載，以將容量納入考慮。 測量容量最常使用的兩個計量包括：
要求執行時間：根據此計量的策略會使用優先順序排程演算法，其中會使用要求執行時間來挑選個別要求的目的地。 使用此方法的主要挑戰是精確地測量執行時間。 負載平衡器可以使用 (並不斷更新) 記憶體中的資料表來猜測執行時間，這會儲存將要求轉送到每部伺服器的時間與它所傳回的時間之間的差異。
資源使用率：根據此計量的策略會使用 CPU 使用率來平衡節點間的使用率。 負載平衡器會根據其使用率來維護已排序的資源清單，並將收到的每個要求導向到負載最小的資源。
負載平衡是實作可調整雲端服務的關鍵。 如果沒有可在後端資源之間散發流量的有效方法，則會嚴重限制透過在需要資源時加以建立，而且在不使用時加以取消佈建所獲得的彈性。
參考資料
- Aron, Mohit and Sanders, Darren and Druschel, Peter and Zwaenepoel, Willy (2000). "Scalable content-aware request distribution in cluster-based network servers" (叢集型網路伺服器中的可調整內容感知要求散發)。2000 年度 USENIX 技術會議發表文章。