Azure Well-Architected Framework 檢閱 - 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 原則版本 (AppGwSslPolicy20170401S \(部分機器翻譯\))。 這會強制執行 TLS 1.2 和更強的加密。
使用 AppGateway 進行 TLS 終止 使用應用程式閘道進行 TLS 終止的優點如下：

- 效能會改善，因為要求移至不同的後端必須重新驗證每個後端。
- 較佳的後端伺服器使用率，因為它們不需要執行 TLS 處理
- 透過存取要求內容來智慧型路由。
- 更容易管理憑證，因為憑證只需要安裝在應用程式閘道上。
使用 Azure 金鑰保存庫來儲存 TLS 憑證 應用程式閘道與金鑰保存庫整合。 這提供更強大的安全性、更輕鬆地區隔角色和責任、受控憑證的支援，以及更容易的憑證更新和輪替程式。
重新加密後端流量時，請確定後端伺服器憑證同時包含根憑證和中繼憑證授權單位單位 (CA) 後端伺服器的 TLS 憑證必須由已知的 CA 發出。 如果憑證不是由受信任的 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 建議。

原則定義

與 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 設定，以符合後端應用程式的接聽程式和流量特性。 預設值設定為四分鐘，且最多可以設定為 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，自動調整需要一些時間 (大約 6 到 7 分鐘) ，才能讓額外的實例集準備好提供流量。 在這段時間內，如果流量有短暫的尖峰，則預期會有暫時性延遲或流量遺失。

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

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

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

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

- 應用程式閘道每個實例使用一個私人 IP 位址，並在設定私人前端 IP 時使用另一個私人 IP 位址。
- Azure 在每個子網中保留五個 IP 位址以供內部使用。
- 應用程式閘道 (Standard 或 WAF SKU) 最多可以支援 32 個實例。 採用 32 個實例 IP 位址 + 1 個私人前端 IP + 5 Azure 保留，建議使用最小子網大小 /26。 由於Standard_v2或WAF_v2 SKU 最多可支援 125 個實例，因此使用相同的計算，建議使用 /24 的子網大小。
- 如果您想要在相同的子網中部署其他應用程式閘道資源，請考慮其最大實例計數所需的額外 IP 位址，包括 Standard 和 Standard v2。
利用自動調整和效能優點的功能 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 架構中心指引

下一步