Azure Load Balancer 上的 Well-Architected Framework 視角
負載平衡程式會將網路流量分散到兩部或多部後端伺服器群組。 Azure Load Balancer 是一項 Azure 原生服務，可針對使用者數據報通訊協定 （UDP） 和傳輸控制通訊協定 （TCP） 執行第 4 層負載平衡。 Load Balancer 有助於為區域和全域部署提供低延遲和高可用性。
本文假設您身為架構設計師，已在 Azure 中檢閱 負載平衡選項，並為您的工作負載選擇了負載平衡器。 本文中的指引提供架構建議，這些建議會對應至 Well-Architected Framework 支柱的原則。
重要
如何使用本指南
每個區段都有一個 設計檢查清單，該清單呈現關注的架構領域，以及針對技術範疇所調整的設計策略。
此外，也包含可協助具體化這些策略的技術功能建議。 建議並不代表適用於Load Balancer及其相依性之所有組態的完整清單。 他們不做前項而是列出主要建議，並將其對應至設計觀點。 使用建議來建置概念證明，或將現有的環境優化。
示範重要建議的基礎架構：
Azure 虛擬機基準架構。
技術範圍
此檢閱著重於下列 Azure 資源的相關決策：
- 負載均衡器
本指南著重於標準負載平衡器 SKU。 基本型負載均衡器和閘道負載均衡器的 SKU 不包括在本文範圍內。
注意
針對 HTTP 應用程式，請考慮使用 Azure 應用程式閘道或 Azure Front Door，而不是 Load Balancer。 這些替代方案會管理負載平衡，並提供 Web 應用程式防火牆 （WAF） 和傳輸層安全性 （TLS） 終止等功能。
如需詳細資訊，請參閱：
- Azure Front Door 上的Well-Architected Framework 檢視方塊
- Well-Architected Azure 應用程式閘道架構觀點
可靠性
可靠性支柱的目的是藉由 建置足夠的復原能力，以及從失敗快速復原的能力，來提供持續的功能。
可靠性設計原則 提供適用於個別元件、系統流程和整個系統的高階設計策略。
設計檢查清單
請根據 設計檢閱檢查清單中的可靠性，開始您的設計策略。 請確定其與您業務需求的相關性，同時請記住虛擬機（VM）的層級和功能。 擴充策略，以視需要包含更多方法。
瞭解Microsoft支援之保證的影響。 除了架構中的其他元件之外，將服務等級協定 （SLA） 因素納入工作負載的可靠性目標。 請記住下列重點：
如果負載平衡的端點無法連線到所有狀況良好的後端伺服器一整分鐘，該分鐘就會被視為無法使用。 不過，如果至少一個要求在相同分鐘內成功，即使其他要求失敗，該分鐘也不會被視為停機時間。
停機時間不包含來源網路位址轉換 （SNAT） 埠耗盡所造成的分鐘數。 請確定您已設定工作負載來處理預期的連線數目，並據以開啟埠。
支援工作負載架構中的區域備援。 我們建議使用標準負載平衡器SKU。 它具有可靠性功能，例如可用性區域支援、跨多個區域的流量分佈，以及能夠處理後端集區中的更多實例。 這些功能可協助承受區域性、區域和個別 VM 實例層級的失敗。 請注意限制，例如後端集區大小上限。
注意
在 Load Balancer 中，您可以管理負載平衡的 VM 數目，但無法管理 Load Balancer 實例的數目。 您可以將 Load Balancer 實例設定為區域備援，或將它固定到某個區域，如果工作負載需要將 VM 放置在單一區域內。 前端IP位址的區域性或多區域設定會指定負載平衡備援。
支援工作負載架構中的區域備援。 您可以將 Load Balancer 設定為全域負載平衡器。 在此設定中，Load Balancer 具有靜態任播公用 IP 位址，該位址可廣播至多個區域。 當用戶端要求此IP位址時，要求會移至最接近的伺服器實例。 Load Balancer 會連線到區域負載平衡器，以有效率地分散流量。
評估網路通訊堆疊中的變更以支援可靠的擴展。 請考慮使用自動調整規則來擴展後端集區。 請注意輸出流量可能導致 SNAT 埠耗盡。 若要解決此問題，請使用 Azure NAT 閘道來簡化設定，但瞭解其缺少可用性區域備援。 或者，使用Load Balancer來新增區域備援。 如需詳細資訊，請參閱 輸出連線。
降低潛在的失敗。 執行失敗模式分析並識別風險降低措施。 下表顯示失敗的類型，以及如何減輕失敗。
失敗 緩解 流量會被導向至不健康的應用程式實例。 監控工作負載實例的健康狀況。 實作 HTTP 健康情況探查，其中包含工作負載相依性的檢查。 流量會被路由至發生中斷的區域。 在另一個區域中部署額外的實例。 新增全域負載平衡器，以將流量重新導向至新區域。 工作負載的使用者基底已擴充，以支援新區域中的使用者，而且延遲很高。 應用程式現在遇到大量的超時和失敗。 在新的區域中部署額外的實例，並在服務組態中加以新增。 作為一個全域負載平衡器，Azure Load Balancer 會將流量路由到更接近使用者的位置。 將流量路由傳送至狀況良好的實例。 您可以使用 HTTP 或 TCP 進行健康探測。 若要提供更豐富的狀態回應，請考慮為健康檢查建立一個 HTTP 端點，即使對於非 HTTP 應用程式也是如此。 此方法特別適用於檢查相依性和資料庫。 若沒有 HTTP 探查，負載平衡器會依賴 TCP 連線，而 TCP 連線可能無法正確反映 VM 健康情況。
您可以在負載平衡器上設定健康探針。 如需詳細資訊，請參閱 健康情況探查的設計指引。
建議
| 建議 | 效益 |
|---|---|
| 選取標準的「Load Balancer SKU」。 如需詳細資訊，請參閱 SKU 比較。 |
此 SKU 支援可靠性功能，例如可用性區域和多重區域負載平衡。 |
| 設定 規則，將前端IP位址對應至後端伺服器的IP位址，以啟用負載平衡。 後端位址池至少應該有兩個後端端點，才能進行備援的負載平衡。 |
規則是負載平衡演算法的核心。 如果沒有此設定，則會停用散發模式。 |
|
設定健康情況探查。 - 設定探查間隔和臨界值。 請考慮偵測失敗的速度與端點要求數目之間的取捨。 - 評估當所有實例的狀態都狀況不良時，是否要將流量傳送至實例。 您可以使用此組態來實作正常降級體驗。 如需詳細資訊，請參閱 AllProbedUp。 |
只有狀況良好的後端集區實例才會接收新的連線。 此設定有助於維護高可用性和可靠性，因為它會將流量從狀況不佳的實例重新導向。 |
| 將私人和公用IP位址設定為 區域備援。 IP 位址會決定Load Balancer的區域備援。 | 區域冗餘可協助工作負載抵禦區域故障。 當某個區域失敗時，服務可以故障轉移至其中一個其餘區域。 |
安全
安全性要素的目的是為工作負載提供 機密性、完整性和可用性 保證。
安全性設計原則 藉由將方法套用至Load Balancer的技術設計，為達成這些目標提供高階的設計策略。
設計檢查清單
根據 設計檢閱檢查清單開始您的設計策略，識別安全性 的弱點和控制措施，以改善安全性狀態。 擴充策略，以視需要包含更多方法。
檢閱安全性基準。 若要增強 Azure Load Balancer 所平衡應用程式的安全性狀態，請檢閱 Load Balancer 安全性基準。
保護後端伺服器。 在沒有直接因特網暴露的虛擬網路中部署資源。 在虛擬網路前面加上負載平衡器。 在理想情況下，負載平衡器應該具有防火牆功能。 針對 HTTP 應用程式，請考慮應用程式閘道或 Azure Front Door。 針對非 HTTP 應用程式，請考慮使用私人 IP 位址的 Load Balancer（內部負載平衡器），並透過 Azure 防火牆路由傳送流量，以取得新增的安全性。 如需詳細資訊，請參閱 內部負載平衡器。
您也可以使用負載平衡器作為反向代理伺服器。 在此情況下，負載平衡器具有具有 SNAT 的公用 IP 位址，這會在遮罩其 IP 位址時公開資源。
注意
若要篩選後端伺服器的流量，請在包含前端和後端的子網上使用網路安全組 （NSG）。 請勿將 NSG 直接套用至 Load Balancer 服務。 當 NSG 強制執行規則時，他們會考慮來源埠、目的地埠和來源和目的地電腦的位址範圍，而不是負載平衡器。
私人連線的設計。 Load Balancer 可與 Azure Private Link 搭配運作。 如果您將應用程式資源分散到虛擬網路，您可以連接不同虛擬網路中的資源。 使用虛擬網路對等互連，或將 Private Link 放在內部負載平衡器前面。 Private Link 選項提供更安全的存取，而不需要公用IP位址。 它也會限制來自非對等網路的存取。
您可以透過 角色型訪問控制來授權私人連結，以限制只存取所需的身分識別。
保護您的應用程式免於網路邊緣的威脅。 針對使用Load Balancer作為進入點的設計，請在端點層級實作流量檢查。 此設計沒有 WAF 之類的內建安全性功能，因此您必須新增額外的量值，以協助保護 HTTP 應用程式。 如需詳細資訊，請參閱 公用負載平衡器。 也請確定您保護負載平衡器端點免於分散式阻斷服務 （DDoS） 攻擊。
加密網路流量。 Load Balancer 適用於第 4 層，且完全支援負載平衡 TCP 和 UDP 流量。 Load Balancer 不支援安全套接字層 （SSL） 和 TLS 終止。 針對應用層的 HTTPS 負載平衡，請使用應用程式閘道。
建議
| 建議 | 效益 |
|---|---|
| 將前端IP位址 設定為虛擬網路中的私人IP位址。 | 這種方法有助於確保前端IP位址和虛擬網路與直接因特網暴露保持隔離。 內部負載平衡器無法接受來自因特網的連入流量，這可減少潛在的攻擊媒介。 |
| 使用 Azure DDoS Protection 保護公用負載平衡器。 | DDoS 保護計劃提供進階保護，包括監視端點的威脅和濫用跡象的偵測功能。 |
成本優化
成本優化著重於 偵測支出模式、將投資放在重要領域，並將其他 優化，以符合組織的預算，同時符合商務需求。
成本優化設計原則 提供高階設計策略，以達成這些目標，並在與Load Balancer及其環境相關的技術設計中視需要進行取捨。
設計檢查清單
以 設計檢閱檢查清單作為基礎開始您的設計策略，以進行投資成本優化。 微調設計，讓工作負載符合為工作負載配置的預算。 您的設計應該使用正確的 Azure 功能、監視投資，以及尋找經過一段時間優化的機會。
將負載平衡費用納入成本模型。 請考慮主要因素，例如 Load Balancer 處理的數據量，以及輸入和輸出負載平衡規則的數目。 如需精確的成本估計，請使用流量記錄來量測輸入和輸出流量需求。
設定支出限制。 記錄和分析負載平衡器成本。 若要有效地管理成本，請使用 Microsoft 成本管理 來 建立預算 並設定警示。 成本可以根據記錄的數據量和記憶體持續時間累積，這會影響頻寬和記憶體費用。
拿掉未使用的資源。 識別和移除未使用的負載平衡器實例。 分析記錄以評估使用量。 刪除與後端 VM 無關的負載平衡器實例。 檢查流量記錄以尋找未使用的資源。
將流程成本優化。 使用有效率的通訊協議和數據壓縮來減少流量的負載，並將成本降至最低。
若要將成本優化，您可以減少規則數目。 與其針對每個端點使用個別的IP地址和埠的規則，不如為前端中連接到後端集區的埠範圍定義一條規則。
在後端流程中實作優化。 例如，負載平衡器攔截的多個資料庫查詢可能會增加每個查詢的成本。 若要避免這項額外成本，請考慮實作預存程式來合併查詢順序。
評估作業成本。 請考慮資源費用和營運成本，例如維護、調整和合規性。 負載平衡器規則可能會大幅影響成本。 減少規則數目，以優化財務和管理成本。
建議
| 建議 | 效益 |
|---|---|
| 使用 Azure 定價計算機 來預估成本。 | 您可以將預期的流量使用量轉換為成本估計值，以方便規劃和預算。 |
| 可能的話，請評估規則數目並加以減少。 評估您是否可以使用一個規則來摘要一系列埠，而不是為個別IP位址定義數個規則。 例如，您可以使用 輸入 NAT 規則 將 IP 位址和埠對應至後端集區，而不是對應至個別 VM。 |
合併規則可將成本優化並簡化作業。 調整規模時，您可以在不更改任何規則的情況下，新增或移除後端集區中的 IP 位址。 |
卓越營運
卓越運營主要著重於 開發實務、可觀察性和發布管理的程序。
營運卓越設計原則 提供高階設計策略，以達成工作負載作業需求的目標。
設計檢查清單
根據營運卓越 設計檢閱檢查清單來開始您的設計策略，以定義與 Load Balancer 相關的可檢視性、測試和部署程式。
使用基礎結構即程式碼。 部署和設定 Load Balancer 以及其他網路元件，例如虛擬網路、網路對等互連、私人端點和 NSG。 熟悉 Microsoft.Network loadBalancers 的資源類型。
針對中樞和輪輻架構使用分層部署。 先部署集線器，因為與輪輻網路中部署的工作負載相比，它的變更頻率較低。 與工作負載一起部署負載平衡器。 如果您在多個工作負載之間重複使用單一負載平衡器，請考慮將其放在中樞。
實作完整的網路監視系統。 實施診斷功能，例如即時深入解析和警示的多維度度量、以健康事件架構為基礎的資源記錄，以及用於全面負載平衡器監控的 Azure Monitor Insights 儀表板。
建議
| 建議 | 效益 |
|---|---|
| 使用 多維度計量。 若要將過多的警示降到最低，請將匯總類型設定為 Average，並使用具有 95% 閾值的五分鐘數據視窗。 如需詳細資訊，請參閱 設定多維度計量的警示。 檢閱輸入和輸出可用性的範例。 |
完整的即時深入解析和警示設定可提供增強的問題偵測，並啟用提示回應。 |
| 擷取資源記錄。 Load Balancer 條目依賴於 健康事件架構。 | 記錄會提供事件的詳細記錄，讓您可以快速找出並解決問題。 |
| 使用內建的 Azure Monitor 洞察儀錶板，用於 Load Balancer。 | 視覺效果可協助您做出明智的設計選擇，並協助您快速識別、診斷和修正問題。 |
在維護作業期間，將 系統管理狀態設定為 Down，以將後端實例從輪替中取出，而不會中斷現有的連線。 此組態可協助確保沒有任何新的連線轉送至後端實例，而現有連線則會正常終止。 |
此 系統管理狀態 組態可協助您在將 VM 從負載平衡輪替中取出以進行一般維護或修補時，降低額外負荷和複雜度。 作為將後端實例從輪替中取出的替代選項，您可以套用網路安全性群組（NSG），以封鎖來自負載平衡器的健康探測或用戶端IP位址和端口的流量。 此選項會增加複雜性。 |
效能效率
效能效率與 維護用戶體驗有關，即使藉由管理容量來增加負載 也一定。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。
效能效率設計原則 提供針對預期使用量達成這些容量目標的高階設計策略。
設計檢查清單
根據 設計檢查清單之效能效率，開始您的設計策略，為負載平衡器定義基於關鍵效能指標的基準。
判斷網路效能目標。 負載平衡器對可支援的流量沒有限制。 但是，當您定義效能目標並規劃容量時，您應該測試網路效能。
使用壓力測試來瞭解工作負載的頻寬需求。 在那些測試中包含負載平衡器。 如果具有多個 VM 的單一虛擬機擴展集不夠，您可以使用相同的負載平衡器來新增另一個擴展集。 如果 VM 收到要求的速度不夠快，您可能需要調整網路元件，例如新增更多負載平衡器。 但不要變更負載平衡器，請考慮進行設計變更，並將工作負載優化，以更妥善地處理負載。
當您設計調整策略時，請瞭解限制。 若要符合效能需求並調整工作負載，請從後端集區新增或移除 VM。 標準 Load Balancer 中的單一後端集區最多可以處理 5,000 部 VM。
Load Balancer 不會套用輸送量限制。 但 VM 和虛擬網路的輸送量限制仍適用。 如需詳細資訊，請參閱 VM 網路頻寬。
快速處理請求。 標準 Load Balancer 有一層功能，可根據流量來源與使用者的地理鄰近性，將流量路由傳送至後端服務端點。
Load Balancer 也支援以會話持續性為基礎的負載分佈。 當您啟用這項功能時，來自相同用戶端的要求會一致導向至處理先前會話的相同後端伺服器。
收集數據以分析效能。 Load Balancer 多維度計量 可以分析服務的效能。 設定警示以偵測效能變更。 使用 Azure Monitor Insights 儀錶板等工具， 來可視化 Load Balancer 的狀態。 請確定資源健康狀態功能會監視健康情況狀態，並隨時掌握效能問題和中斷情況。
優化網路流量。 請勿在不同的步驟中多次處理相同的數據。 請改為在批次中執行所有必要的計算，然後保存數據。 此方法可減少延遲並將網路流量降到最低，進而改善整體效能。
建議
| 建議 | 效益 |
|---|---|
| 如果您有全域使用者，請選取標準 Load Balancer 中的 全域層。 | 此層的地理鄰近分配模式會從最近的區域端點為使用者請求提供服務，以改善效能。 |
| 當您希望來自相同使用者的要求導向至相同的後端伺服器時，評估是否應該啟用 會話持續性。 從可靠性的觀點來看，我們不建議使用此方法。 如果您使用此選項，應用程式應該正常復原，而不會中斷用戶會話。 負載平衡方面也存在一種取捨，因為這樣會限制將流量均勻地分配到多個後端的靈活性。 |
會話持續性可以優化效能，並維護使用者會話的持續性，特別是當應用程式依賴在本機維護狀態資訊時。 然而，存在取捨。 |
| 在向外延展期間，傳送 探查向下訊號，直到應用程式完全初始化並準備好處理要求為止。 在縮減期間，向正在縮減的端點上的新連線傳送探查縮小信號。 現有連線上的待處理要求會繼續處理。 |
健康探測器可協助優化擴展操作。 它們可協助確保向外延展期間，應用程式可以處理連入負載。 在執行縮減操作之前，它們可讓實例數量順利減少，而不會中斷進行中的作業。 |
Azure 原則
Azure 提供一組與 Load Balancer 及其相依性相關的大量內建原則。 您可以透過 Azure 原則稽核上述一些建議。 例如，您可以檢查是否：
- 負載平衡器，不包括基本 SKU 負載平衡器，在其前端中啟用公用 IP 位址的復原功能。
- 資源日誌已啟用，可追蹤資源上發生的活動和事件，並提供對變更的可見性和洞察力。
為確保全面治理，請檢閱負載平衡器的 Azure Policy 內建定義 和，以及其他可能影響流量分配安全性的政策。
Azure Advisor 建議
Azure Advisor 是個人化的雲端顧問，可協助您遵循最佳做法來優化 Azure 部署。 顧問的建議與Well-Architected框架的支柱相一致。
如需詳細資訊，請參閱 Azure Advisor中的建議。