共用方式為


Azure 架構良好的架構檢閱 - Azure 應用程式閘道 v2

本文提供 Azure 應用程式閘道 v2 系列 SKU 的架構最佳做法。 本指南以架構卓越五大要素為基礎:

我們假設您有 Azure 應用程式閘道 的工作知識,且熟悉 v2 SKU 功能。 如需詳細資訊,請參閱 Azure 應用程式閘道 功能

必要條件

可靠性

在雲端中,我們知道失敗在所難免。 此目標不是試著完全避免失敗,而是將單一故障元件的影響降至最低。 使用下列資訊將失敗的實例降到最低。

設計檢查清單

當您為 應用程式閘道 做設計選擇時,請檢閱可靠性設計原則

  • 在可用區域感知組態部署實例。
  • 在虛擬網路內搭配 Web 應用程式防火牆 (WAF) 使用 應用程式閘道 來保護來自因特網的輸入HTTP/S流量。
  • 在新部署中,除非有令人信服的理由使用 Azure 應用程式閘道 v1,否則請使用 Azure 應用程式閘道 v2。
  • 規劃規則更新
  • 使用健康情況探查來偵測後端無法使用
  • 檢閱間隔和閾值設定對健康情況探查的影響
  • 透過健康情況端點確認下游相依性

建議

探索下表的建議,以優化可靠性 應用程式閘道 設定。

建議 優點
規劃規則更新 在存取 應用程式閘道 或進行進一步變更之前,規劃足夠的時間進行更新。 例如,從後端集區移除伺服器可能需要一些時間,因為它們必須清空現有的連線。
使用健康情況探查來偵測後端無法使用 如果使用 應用程式閘道 來平衡多個後端實例的連入流量,建議您使用健康情況探查。 這些可確保流量不會路由傳送至無法處理流量的後端。
檢閱間隔和閾值設定對健康情況探查的影響 健康情況探查會以設定的間隔將要求傳送至設定的端點。 此外,後端標示為狀況不良之前,將會容許的失敗要求閾值。 這些數位呈現取捨。

- 設定較高的間隔會對您的服務帶來較高的負載。 每個 應用程式閘道 實例都會傳送自己的健康情況探查,因此每 30 秒 100 個實例表示每 30 秒 100 個要求。
- 設定較低的間隔會在偵測到中斷之前留下更多時間。
- 設定低狀況不良閾值可能表示短暫的暫時性失敗可能會關閉後端。
- 設定高閾值,可能需要更長的時間才能讓後端退出輪替。
透過健康情況端點確認下游相依性 假設每個後端都有自己的相依性,以確保失敗是隔離的。 例如,裝載在 應用程式閘道 後的應用程式可能會有多個後端,每個後端都連線到不同的資料庫(複本)。 當這類相依性失敗時,應用程式可能會運作,但不會傳回有效的結果。 基於這個理由,健康情況端點在理想情況下應該驗證所有相依性。 請記住,如果健康情況端點的每個呼叫都有直接相依性呼叫,該資料庫會每隔 30 秒收到 100 個查詢,而不是 1。 若要避免這種情況,健康情況端點應該快取相依性狀態一小段時間。
使用 Azure Front Door 和 應用程式閘道 來保護HTTP/S應用程式時,請使用 Front Door 中的 WAF 原則並鎖定 應用程式閘道,只接收來自 Azure Front Door 的流量。 某些案例可以強制您在 應用程式閘道 上特別實作規則。 例如,如果需要ModSec CRS 2.2.9、CRS 3.0或 CRS 3.1 規則,則這些規則只能在 應用程式閘道 上實作。 相反地,速率限制和地理篩選僅適用於 Azure Front Door,而不是在 AppGateway 上。

Azure Advisor 可協助您確保並改善業務關鍵應用程式的持續性。 檢閱 Azure Advisor 建議

安全性

安全性是任何架構中最為重要的部分。 應用程式閘道 提供功能來同時採用最低許可權和防禦防禦原則。 建議您檢閱 安全性設計原則

設計檢查清單

  • 設定 TLS 原則以增強安全性
  • 使用 AppGateway 進行 TLS 終止
  • 使用 Azure 金鑰保存庫 來儲存 TLS 憑證
  • 重新加密後端流量時,請確定後端伺服器證書同時包含跟證書和中繼證書頒發機構單位 (CA)
  • 針對後端集區資源使用適當的 DNS 伺服器
  • 符合 應用程式閘道 的所有 NSG 限制
  • 避免在 應用程式閘道 子網上使用 UDR
  • 請注意啟用 WAF 時 應用程式閘道 容量變更

建議

探索下表的建議,以優化安全性 應用程式閘道 組態。

建議 優點
設定 TLS 原則以增強安全性 設定 TLS 原則 以取得額外的安全性。 請確定您一律使用可用的最新 TLS 原則版本。 這會強制執行 TLS 1.2 和更強的加密。
使用 AppGateway 進行 TLS 終止 使用 應用程式閘道 進行 TLS 終止有其優點:

- 效能會改善,因為要求前往不同的後端必須重新驗證至每個後端。
- 較佳的後端伺服器使用率,因為它們不需要執行 TLS 處理
- 藉由存取要求內容來智慧型手機由。
- 較容易管理憑證,因為憑證只需要安裝在 應用程式閘道 上。
使用 Azure 金鑰保存庫 來儲存 TLS 憑證 應用程式閘道 可以與 金鑰保存庫 整合。 這可提供更強大的安全性、更容易區分角色和責任、對受控憑證的支援,以及更簡單的憑證更新和輪替程式。
重新加密後端流量時,請確定後端伺服器證書同時包含跟證書和中繼證書頒發機構單位 (CA) 後端伺服器的 TLS 憑證必須由已知的 CA 簽發。 如果憑證不是由受信任的 CA 所簽發,則 應用程式閘道 會檢查憑證是否由受信任的 CA 所簽發,依此檢查,直到找到受信任的 CA 憑證為止。 只會建立安全連線。 否則,應用程式閘道 會將後端標示為狀況不良。
針對後端集區資源使用適當的 DNS 伺服器 當後端集區包含可解析的 FQDN 時,DNS 解析是以私人 DNS 區域或自定義 DNS 伺服器為基礎(如果在 VNet 上設定),或是使用預設的 Azure 提供的 DNS。
符合 應用程式閘道 的所有 NSG 限制 應用程式閘道 子網支援 NSG,但有一些限制。 例如,禁止某些通訊埠範圍。 請確定您了解這些限制的影響。 如需詳細資訊,請參閱 網路安全組
避免在應用程式閘道子網上使用UDR 在 應用程式閘道 子網上使用使用者定義的路由(UDR)可能會導致一些問題。 後端 的健康情況狀態可能未知。 應用程式閘道 記錄和計量可能不會產生。 建議您不要在 應用程式閘道 子網上使用 UDR,以便檢視後端健康情況、記錄和計量。 如果您的組織需要在 應用程式閘道 子網中使用 UDR,請確定您檢閱支援的案例。 如需詳細資訊,請參閱支援的使用者定義路由
請注意啟用 WAF 時 應用程式閘道 容量變更 啟用WAF時,每個要求都必須由 應用程式閘道 緩衝,直到它完全送達為止,檢查要求是否符合其核心規則集中的任何規則違規,然後將封包轉送至後端實例。 當有大型檔案上傳時(大小為 30 MB 以上),可能會導致顯著的延遲。 由於 應用程式閘道 容量需求與 WAF 不同,因此不建議在 應用程式閘道 上啟用 WAF,而不需進行適當的測試和驗證。

如需詳細資訊,請參閱 安全性要素的原則。

Azure Advisor 可協助您確保並改善業務關鍵應用程式的持續性。 檢閱 Azure Advisor 建議

原則定義

  • 應針對 應用程式閘道 啟用 Web 應用程式防火牆 (WAF)。 在公開的 Web 應用程式前方部署 Azure Web 應用程式防火牆 (WAF),以另外檢查傳入的流量。 Web 應用程式防火牆 (WAF) 可集中保護 Web 應用程式,使其免於遭受常見惡意探索和弱點的攻擊,例如 SQL 插入式攻擊、跨網站指令碼攻擊、本機和遠端檔案執行。 您也可以透過自訂規則,來依國家/地區、IP 位址範圍和其他 http(s) 參數限制對 Web 應用程式的存取。
  • Web 應用程式防火牆 (WAF) 應該使用指定的模式進行 應用程式閘道。 在應用程式閘道的所有 Web 應用程式防火牆原則上授權使用「偵測」或「預防」模式。
  • 應啟用 Azure DDoS 保護。 所有虛擬網路只要其子網路屬於使用公用 IP 的應用程式閘道,就應啟用 DDoS 保護。

所有與 Azure 網路相關的內建原則定義都會列在內建原則 - 網路中。

成本最佳化

成本最佳化是關於考慮如何減少不必要的費用,並提升營運效率。 建議您檢閱 成本優化設計原則

設計檢查清單

  • 熟悉 應用程式閘道 定價
  • 檢閱使用量過低的資源
  • 停止未使用中的 應用程式閘道 實例
  • 具有相應縮小和向外延展原則
  • 檢閱不同參數的取用計量

建議

探索下表的建議,以優化成本優化 應用程式閘道 組態。

建議 優點
熟悉 應用程式閘道 定價 如需 應用程式閘道 定價的相關信息,請參閱瞭解 Azure 應用程式閘道 和 Web 應用程式防火牆 的價格。 您也可以利用 定價計算機

請確定選項大小適當,以符合容量需求,並提供預期的效能,而不會浪費資源。
檢閱使用量過低的資源 使用空後端集區識別和刪除 應用程式閘道 實例,以避免不必要的成本。
不使用時停止 應用程式閘道 實例 當 應用程式閘道 處於已停止狀態時,不會向您收取費用。 持續執行 應用程式閘道 實例可能會產生多餘的成本。 當您不需要時,評估使用模式並停止實例。 例如,開發/測試環境中的上班時間之後使用量應該會很低。

如需如何停止和啟動實例的相關信息,請參閱這些文章。
- Stop-AzApplicationGateway
- Start-AzApplicationGateway
具有相應縮小和向外延展原則 向外延展原則可確保有足夠的實例來處理連入流量和尖峰。 此外,也有相應縮小原則,可確保需求下降時,實例數目會減少。 請考慮選擇實例大小。 大小可能會大幅影響成本。 估計 應用程式閘道 實例計數中有一些考慮。

如需詳細資訊,請參閱什麼是 Azure 應用程式閘道 v2?
檢閱不同參數的取用計量 系統會根據 Azure 所追蹤計量的計量實例來計費 應用程式閘道。 評估各種計量和容量單位,並判斷成本驅動因素。 如需詳細資訊,請參閱 Microsoft成本管理和計費

下列計量是 應用程式閘道 的關鍵。 此資訊可用來驗證布建的實例計數是否符合傳入流量量。

- 預估計費容量單位
- 固定計費容量單位
- 目前容量單位

如需詳細資訊,請參閱 應用程式閘道 計量

請確定您考慮頻寬成本。

如需更多建議,請參閱 成本優化要素的原則。

Azure Advisor 可協助您確保並改善業務關鍵應用程式的持續性。 檢閱 Azure Advisor 建議

卓越營運

監視和診斷對於確保 應用程式閘道和閘道後方 Web 應用程式或後端的運作卓越至關重要。 您不僅可以測量效能統計數據,還可以使用計量快速疑難解答和補救問題。 建議您檢閱 營運卓越設計原則

設計檢查清單

  • 監視容量計量
  • 在 應用程式閘道 與 Web 應用程式防火牆 上啟用診斷 (WAF)
  • 使用 Azure 監視器網路深入解析
  • 比對逾時設定與後端應用程式
  • 使用 Azure Advisor 監視 金鑰保存庫 設定問題
  • 設定及監視 SNAT 埠限制
  • 請考慮設計中的 SNAT 埠限制

建議

探索下表的建議,以優化您的 應用程式閘道 設定,以達到卓越營運。

建議 優點
監視容量計量 使用這些計量作為已布建 應用程式閘道 容量使用率的指標。 我們強烈建議在容量上設定警示。 如需詳細資訊,請參閱 應用程式閘道 高流量支援
使用計量進行疑難排解 還有其他計量可以指出 應用程式閘道 或後端的問題。 建議您評估下列警示:

- 狀況不良的主機計數
- 回應狀態 (維度 4xx 和 5xx)
- 後端回應狀態 (維度 4xx 和 5xx)
- 後端最後一個字節回應時間
- 應用程式閘道 總時間

如需詳細資訊,請參閱 應用程式閘道的計量。
在 應用程式閘道 與 Web 應用程式防火牆 上啟用診斷 (WAF) 診斷記錄可讓您檢視防火牆記錄、效能記錄和存取記錄。 使用這些記錄來管理和疑難解答 應用程式閘道 實例的問題。 如需詳細資訊,請參閱應用程式閘道的後端健康情況和診斷記錄
使用 Azure 監視器網路深入解析 Azure 監視器網路深入解析提供網路資源健康情況和計量的完整檢視,包括 應用程式閘道。 如需 應用程式閘道 的其他詳細數據和支援功能,請參閱 Azure 監視器網路深入解析
比對逾時設定與後端應用程式 請確定您已設定 IdleTimeout 設定,以符合後端應用程式的接聽程式和流量特性。 默認值設定為 4 分鐘,最多可以設定為 30。 如需詳細資訊,請參閱 Load Balancer TCP 重設和閒置逾時時間

如需工作負載考慮,請參閱 監視應用程式健康情況以取得可靠性
使用 Azure Advisor 監視 金鑰保存庫 設定問題 應用程式閘道 每隔 4 小時檢查連結 金鑰保存庫 中更新的憑證版本。 如果因為任何不正確的 金鑰保存庫 設定而無法存取,則會記錄該錯誤並推送對應的 Advisor 建議。 您必須設定 Advisor 警示,以保持更新並立即修正這類問題,以避免發生任何控制或數據平面相關問題。 如需詳細資訊,請參閱 調查和解決密鑰保存庫錯誤。 若要設定此特定案例的警示,請使用建議類型作為解決您 應用程式閘道 的 Azure 金鑰保存庫 問題。
請考慮設計中的 SNAT 埠限制 SNAT 埠限制對於 應用程式閘道 上的後端連線很重要。 有個別因素會影響 應用程式閘道 達到 SNAT 埠限制的方式。 例如,如果後端是公用IP位址,則需要自己的SNAT埠。 為了避免 SNAT 埠限制,您可以增加每個 應用程式閘道 的實例數目、相應放大後端以擁有更多 IP 位址,或將您的後端移至相同的虛擬網路,並使用後端的私人 IP 位址。

如果達到 SNAT 埠限制,應用程式閘道 上的每秒要求數 (RPS) 將會受到影響。 例如,如果 應用程式閘道 達到 SNAT 埠限制,則它將無法開啟與後端的新連線,而且要求將會失敗。

如需更多建議,請參閱 卓越營運支柱的原則。

Azure Advisor 可協助您確保並改善業務關鍵應用程式的持續性。 檢閱 Azure Advisor 建議

效能效益

效能效率可讓您的工作負載進行調整,以有效率的方式符合使用者對其放置的需求。 建議您檢閱 效能效率原則

設計檢查清單

  • 估計實例計數 應用程式閘道
  • 定義實例計數上限
  • 定義最小實例計數
  • 定義子網大小 應用程式閘道
  • 利用 應用程式閘道 V2 功能來自動調整和效能優點

建議

探索下表的建議,以優化您的 應用程式閘道 組態以提升效能效率。

建議 優點
估計實例計數 應用程式閘道 應用程式閘道 v2 會根據許多層面相應放大,例如 CPU、網路輸送量、目前的連線等等。 若要判斷近似實例計數,請考慮下列計量:

目前的計算單位 - 指出 CPU 使用率。 1 應用程式閘道 實例大約是10個計算單位。
輸送量 — 應用程式閘道 實例可以提供 ~500 Mbps 的輸送量。 此數據取決於承載的類型。

計算實例計數時,請考慮此方程式。
近似實例計數

在估計實例計數之後,請將該值與實例計數上限進行比較。 這表示您接近可用容量上限。
定義最小實例計數 對於 應用程式閘道 v2 SKU,自動調整需要一些時間(大約六到七分鐘),然後額外的實例集才能提供流量。 在此期間,如果流量有短暫的尖峰,則預期會有暫時性延遲或流量遺失。

我們建議您將最小實例計數設定為最佳層級。 在您估計平均實例計數並判斷 應用程式閘道 自動調整趨勢之後,請根據您的應用程式模式定義最小實例計數。 如需詳細資訊,請參閱 應用程式閘道 高流量支援

檢查過去一個月的目前計算單位。 此計量代表閘道的CPU使用率。 若要定義最小實例計數,請將尖峰使用量除以 10。 例如,如果您的過去一個月的平均目前計算單位為50,請將最小實例計數設定為5。
定義實例計數上限 建議 125 作為自動調整實例計數上限。 請確定具有 應用程式閘道 的子網有足夠的可用IP位址,以支持實例的相應增加集。

將實例計數上限設定為 125 不會造成任何成本影響,因為您只需針對已取用的容量計費。
定義子網大小 應用程式閘道 應用程式閘道 虛擬網路內需要專用子網。 子網可以有多個已部署 應用程式閘道 資源的實例。 您也可以在該子網、v1 或 v2 SKU 中部署其他 應用程式閘道 資源。

以下是定義子網大小的一些考慮:

- 如果已設定私人前端IP,應用程式閘道會針對每個實例使用一個私人IP位址,並使用另一個私人IP位址。
- Azure 會保留每個子網中的五個 IP 位址以供內部使用。
- 應用程式閘道 (標準或 WAF SKU) 最多可支援 32 個實例。 採用 32 個實例 IP 位址 + 1 個私人前端 IP + 5 Azure 保留,建議使用最小子網大小 /26。 由於Standard_v2或WAF_v2 SKU 最多可支援 125 個實例,因此建議使用相同的計算,建議使用 /24 的子網大小。
- 如果您想要在相同的子網中部署其他 應用程式閘道 資源,請考慮標準與標準 v2 的最大實例計數所需的額外IP位址。
利用功能來自動調整和效能優點 v2 SKU 提供自動調整,以確保您的應用程式閘道可以隨著流量增加而擴大。 相較於 v1 SKU,v2 具有可增強工作負載效能的功能。 例如,更好的 TLS 卸除效能、更快速的部署和更新時間、區域備援等等。 如需自動調整功能的詳細資訊,請參閱調整 應用程式閘道 v2 和 WAF v2

如果您執行 v1 SKU 應用程式閘道,請考慮移轉至應用程式閘道 v2 SKU。 如需詳細資訊,請參閱將 Azure 應用程式閘道和 Web 應用程式防火牆從 v1 移轉至 v2 (部分機器翻譯)。

Azure Advisor 可協助您確保並改善業務關鍵應用程式的持續性。 檢閱 Azure Advisor 建議

Azure Advisor 建議

Azure Advisor 是個人化的雲端顧問,可協助您遵循最佳做法來將 Azure 部署最佳化。 以下是一些建議,可協助您改善 應用程式閘道的可靠性、安全性、成本效益、效能和營運卓越性。

可靠性

其他資源

Azure 架構中心指引

下一步