Azure 架構良好的架構檢閱 - Azure 應用程式閘道 v2
本文提供 Azure 應用程式閘道 v2 系列 SKU 的架構最佳做法。 本指南以架構卓越五大要素為基礎:
我們假設您有 Azure 應用程式閘道 的工作知識,且熟悉 v2 SKU 功能。 如需詳細資訊,請參閱 Azure 應用程式閘道 功能。
必要條件
- 了解架構完善的架構支柱有助於產生高品質、穩定且有效率的雲端架構。 建議您使用 Azure 架構良好的架構檢閱 評估來檢閱您的工作負載。
- 使用參考架構,根據本文所提供的指引來檢閱考慮。 建議您從使用 應用程式閘道 和 API 管理 和 IaaS 保護 API:具有關係資料庫的 Web 應用程式開始。
可靠性
在雲端中,我們知道失敗在所難免。 此目標不是試著完全避免失敗,而是將單一故障元件的影響降至最低。 使用下列資訊將失敗的實例降到最低。
設計檢查清單
當您為 應用程式閘道 做設計選擇時,請檢閱可靠性設計原則。
- 在可用區域感知組態中部署實例。
- 在虛擬網路內搭配 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 架構中心指引
- 在微服務中使用 API 閘道
- 虛擬網路的防火牆和應用程式閘道
- 使用應用程式閘道和 API 管理來保護 API
- IaaS:具有關聯式資料庫的 Web 應用程式
- 安全管理的 Web 應用程式
- 具有 Azure 防火牆 和 應用程式閘道 之 Web 應用程式的零信任網路
下一步
- 部署 應用程式閘道 以查看其運作方式:快速入門:使用 Azure 應用程式閘道 引導 Web 流量 - Azure 入口網站