為什麼 Elastic Load Balancing 會不平等地路由我的負載平衡器流量？

簡短描述

ELB 在下列情況下可能會不平均地將流量路由到您的目標：

• 用戶端會將請求路由至包含過期 TTL 之 DNS 記錄的負載平衡器節點的錯誤 IP 地址。
• 為負載平衡器啟用粘性會話 (工作階段親和性)。粘性會話使用 Cookie 協助用戶端在 Cookie 的生命週期內保持與相同執行個體的連接，這可能會隨著時間的推移而導致不平衡。
• 可用的健康執行個體不會平均分佈在可用區域。
• 特定容量類型的執行個體不會平均分佈在可用區域。
• 用戶端與執行個體之間存在長期的 TCP 連線。
• 連線使用 WebSocket。

解決方法

確認流量不平衡

分析 ELB 存取日誌 (如果可用) 以確認流量不平衡。使用命令列工具尋找負載平衡器路由至特定應用程式的請求數量。

對於 Application Load Balancer：

awk '{print $5}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r

對於 Classic Load Balancer：

awk '{print $4}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r

ELB 將每個 ELB 節點的個別檔案新增至儲存貯體。您可以比較特定時段內存取日誌中的行數。

排清 DNS 快取

基於過期 DNS 項目的路由會導致不同可用區域中不平衡的 RequestCount 模式。如需詳細資訊，請參閱 Application Load Balancer 指標或 Classic Load Balancer 指標。排清用戶端的 DNS 快取，以確保它使用負載平衡器節點的目前 DNS 記錄。

**注意：**啟用跨區域負載平衡後，負載平衡器仍可在執行個體層級均勻分佈平衡請求。

對於使用 nscd 進行 DNS 快取的 Linux 用戶端，請執行下列其中一個命令：

sudo /etc/init.d/nscd restart

# service nscd restart

# service nscd reload

對於使用 dnsmasq 進行 DNS 快取的 Linux 用戶端，請執行下列其中一個命令：

$ sudo /etc/init.d/dnsmasq restart

# service dnsmasq restart

對於使用 BIND 進行 DNS 快取的 Linux 用戶端，請執行下列其中一個命令：

# /etc/init.d/named restart

# rndc restart

# rndc exec

對於 Windows 用戶端，請執行下列命令：

ipconfig /flushdns

**注意：**如果您清除了用戶端的 DNS 快取，但仍然遇到快取問題，請確定您的用戶端應用程式並未快取 DNS 記錄。

檢查粘性會話的組態

如果您使用基於持續時間的工作階段黏性，請針對您的特定使用情況設定適當的 Cookie 到期時間。如需詳細資訊，請參閱：

• 粘性會話 (Application Load Balancer)
• 基於持續時間的工作階段黏性 (Classic Load Balancer)

如果您從個別應用程式設定工作階段黏性，請盡可能使用工作階段 Cookie 而非持久性 Cookie。如需詳細資訊，請參閱應用程式控制的工作階段黏性 (Classic Load Balancer)。

檢查可用區域之間健康的執行個體分佈

如果可用區域中可用的健康執行個體數目不相等，且跨區域負載平衡已停用，則 ELB 必須平衡受影響可用區域中較少執行個體之間的請求。其餘健康的執行個體會處理較多的請求來進行補償，這可能會對效能產生負面影響。

**注意：**執行個體或可用區域之間的流量負載不平衡並不一定表示資源使用率也不平衡。例如，當負載平衡器處理程序後方的一個或多個執行個體請求速度比其他執行個體快時，就可能會發生不平衡。

在每個已啟用的可用區域中保持相同數量的執行個體。若要將更多執行個體新增為負載平衡器目標，請參閱：

• 向目標群組註冊目標 (Application Load Balancer)
• 註冊或取消註冊目標 (Network Load Balancer)
• 註冊或取消註冊 Classic Load Balancer 的 EC2 執行個體

對於 Classic Load Balancer 和 Network Load Balancer，請考量啟用跨區域負載平衡，以便在執行個體層級而非可用區域層級分配請求。如需詳細資訊，請參閱跨區域負載平衡 (Network Load Balancer) 或為 Classic Load Balancer 設定跨區域負載平衡。Application Load Balancer 一律啟用跨區域負載平衡。

檢查執行個體類型分佈

具有 HTTP 或 HTTPS 接聽程式的 Classic Load Balancer 可能會將更多流量路由到容量更高的執行個體類型。此分配的目的是防止較低容量的執行個體類型有太多未完成的請求。如需詳細資訊，請參閱執行個體類型。最佳做法是使用類似的執行個體類型和設定，以減少容量差距和流量不平衡的可能性。

如果您在不同的 Amazon Machine Image (AMI) 上執行類似容量的執行個體，也可能會發生流量不平衡。在這種情況下，支持更高容量執行個體類型的流量不平衡是合適的。

檢查是否有長期 TCP 連線

Elastic Load Balancing 會使用循環配置資源演算法路由 TCP 流量。根據設計，用戶端與執行個體之間的長期 TCP 連線會導致流量負載分配不均勻。因此，新執行個體需要更長的時間才能達到連線平衡。確保檢查可能導致問題的長期 TCP 連線的指標。另請注意，使用 TCP 接聽程式時，負載平衡器只會在連線層級分配流量。例如，這表示經常重複使用連線以傳送和接收多個 HTTP 請求的用戶端可能會在執行個體層級產生不平衡的流量。如果您的應用程式支援更高層的網路通訊協定 (例如 HTTP、HTTPS、WebSocket 或 HTTP2)，請考量移至第 7 層負載平衡器。

檢查負載平衡器的 RequestCount 模式和其他相關指標。如需詳細資訊，請參閱：

• Application Load Balancer 指標
• Network Load Balancer 的 CloudWatch 指標
• Classic Load Balancer 指標

檢查 WebSocket 連線

搭配使用負載平衡器與 WebSocket 連線的用戶端會在用戶端與目標之間使用 1:1 連線。在 WebSocket 連線期間，此連線仍會停留在目標上，從而導致流量分配不平等。Application Load Balancer 提供對 WebSocket 的原生支援。只有升級至 WebSockets 的新 HTTP 請求才會移至新目標。WebSockets 還可以與具有第 4 層接聽程式的 Classic Load Balancer 及 Network Load Balancer 搭配使用。

如需詳細資訊，請參閱接聽程式組態。

---