PERF05-BP04 利用負載平衡和加密卸載 - AWS Well-Architected 架構
實作指引資源

PERF05-BP04 利用負載平衡和加密卸載

使用負載平衡器達成您的目標資源的最佳效能效率，並且改善系統的回應能力。

預期成果：減少為您的流量提供服務的運算資源數量。避免您的目標的資源取用失衡。將運算密集型任務卸載至負載平衡器。利用雲端彈性和靈活性來改善效能並且最佳化您的架構。

常見的反模式：

  • 您在選擇負載平衡器類型時不考慮工作負載要求。

  • 您不利用負載平衡器功能來進行效能最佳化。

  • 工作負載在不使用負載平衡器的情況下，直接公開到網際網路。

未建立此最佳實務時的風險暴露等級：高

實作指引

負載平衡器會做為您的工作負載的進入點，從那裡將您的流量分散到後端目標，例如運算執行個體或容器。選擇正確的負載平衡器類型是最佳化架構的第一步。

從列出您的工作負載特性開始，例如通訊協定 (例如 TCP、HTTP、TLS 或 WebSockets)、目標類型 (例如執行個體、容器或無伺服器)、應用程式要求 (例如長時間執行連線、使用者身分驗證或黏性) 和置放 (例如 Region、Local Zone、Outpost 或區域隔離)。

選擇正確的負載平衡器之後，您可以開始利用其功能來減少後端為流量提供服務需付出的工作量。

例如，同時使用 Application Load Balancer (ALB) 和 Network Load Balancer (NLB)，您可以執行 SSL/TLS 加密卸載，這是避免 CPU 密集型 TLS 交握由您的目標完成，並且改善憑證管理的機會。

在您的負載平衡器中設定 SSL/TLS 卸載時，它會負責往返用戶端的流量的加密，同時將未加密的流量交付給您的後端，釋放您的後端資源並且改善用戶端的回應時間。

Application Load Balancer 也可以為 HTTP2 流量提供服務，不需要在您的目標上支援它。這個簡單的決策可以改善您的應用程式回應時間，因為 HTTP2 更有效率地使用 TCP 連線。

負載平衡器也可以用來讓您的架構更有彈性，方法是在不同後端類型之間分散流量，例如容器或無伺服器。例如，Application Load Balancer 可以使用接聽程式規則進行設定，該規則會根據請求參數 (例如標題、方法或模式) 將流量轉送到不同目標群組。

定義架構時，也應該考慮您的工作負載延遲要求。例如，如果您有對延遲敏感的應用程式，您可能會決定使用 Network Load Balancer，它提供極低的延遲。另外，您可能會決定藉由利用 AWS Local Zones 中的 Application Load Balancer 或甚至是 AWS Outposts，讓工作負載更靠近您的客戶。

對延遲敏感的工作負載的另一個考慮是跨區域負載平衡。使用跨區域負載平衡，每個負載平衡器節點會將已註冊目標之間的流量分散到所有已啟用可用區域中。這樣可改善可用性，然而會對往返時間延遲增加一個位數的毫秒。

最後，ALB 和 NLB 都提供監控資源，例如日誌和指標。適當地設定監控可協助收集您的應用程式的效能洞察。例如，您可以使用 ALB 存取日誌來尋找哪個請求耗費較久的時間獲得解答，或哪個後端目標造成效能問題。

實作步驟

  1. 為您的工作負載選擇正確的負載平衡器。

    1. 針對 HTTP/HTTPS 工作負載使用 Application Load Balancer。

    2. 針對在 TCP 或 UDP 上執行的非 HTTP 工作負載使用 Network Load Balancer。

    3. 如果您想要利用兩個產品的功能，使用兩者個組合 (ALB 做為 NLB 的目標)。例如，如果您想要搭配使用 NLB 的靜態 IP 與來自 ALB 的 HTTP 標題型路由，或者如果您想要將您的 HTTP 工作負載公開到 AWS PrivateLink，您可以這麼做。

    4. 如需負載平衡器的完整比較，請參閱 ELB 產品比較。

  2. 使用 SSL/TLS 卸載。

    1. 設定 HTTPS/TLS 接聽程式，Application Load Balancer 和 Network Load Balancer 都與 AWS Certificate Manager 整合。

    2. 請注意，基於合規理由，某些工作負載可能需要端對端加密。在此情況下，在目標啟用加密是一項要求。

    3. 如需安全最佳實務，請參閱 SEC09-BP02 強制執行傳輸中加密。

  3. 選取正確的路由演算法。

    1. 路由演算法可以造成您的後端目標的妥善使用程度和它們影響效能程度的差異。例如，ALB 提供兩個路由演算法的選項：

    2. 最低未解決請求：針對當您的應用程式的請求因複雜性而異或您的目標因處理功能而異的情況時，用來讓負載更佳地分散到您的後端目標。

    3. 輪詢均衡：當請求和目標類似，或是如果您需要在目標之間平均分散請求時使用。

  4. 考慮跨區域或區域隔離。

    1. 針對延遲改善和區域失敗網域使用跨區域關閉 (區域隔離)。在 NLB 中預設為關閉，在 ALB 中您可以依據各個目標群組加以關閉。

    2. 使用跨區域開啟來增加可用性和彈性。根據預設，ALB 的跨區域為開啟，在 NLB 中您可以依據各個目標群組加以開啟。

  5. 為您的 HTTP 工作負載開啟 HTTP keep-alives。

    1. 針對 HTTP 工作負載，為您的後端目標在 Web 伺服器設定中開啟 HTTP keep-alive。使用這項功能，負載平衡器可以重複使用後端連線，直到 keep-alive 逾時到期，改善您的 HTTP 請求和回應時間，同時減少您的後端目標上的資源使用率。如需如何針對 Apache 和 Nginx 執行此操作的詳細資訊，請參閱使用 Apache 或 NGINX 做為 ELB 的後端伺服器的最佳設定是什麼？

  6. 使用 Elastic Load Balancing 整合來達到更佳的運算資源協同運作。

    1. 使用與您的負載平衡器整合的 Auto Scaling。效能效率系統的其中一個關鍵層面與適當調整後端資源大小有關。若要完成此操作，您可以利用後端目標資源的負載平衡器整合。使用與 Auto Scaling 群組整合的負載平衡器，目標會視需要從負載平衡器新增或移除，以因應傳入流量。

    2. 負載平衡器也可以針對容器化工作負載與 Amazon ECS 和 Amazon EKS 整合。

  7. 監控您的負載平衡器以尋找效能瓶頸。

    1. 為您的 Application Load Balancer 和 Network Load Balancer 啟用存取日誌。

    2. 針對 ALB 要考慮的主要欄位是 request_processing_time，request_processing_time，和 response_processing_time。

    3. 針對 NLB 要考慮的主要欄位是 connection_time 和 tls_handshake_time。

    4. 請準備好在您需要日誌時進行查詢。您可以使用 Amazon Athena 來查詢 ALB 日誌與 NLB 日誌。

    5. 建立如 的效能相關指標的警示TargetResponseTime 針對 ALB。

資源

相關的最佳實務：

相關文件：

相關影片：

相關範例：