Azure 流量管理員的 Well-Architected 框架觀點
Azure 流量管理員是全域負載平衡器，可將流量分散到多個 Azure 區域、區域內的區域，或這些區域內的數據中心。 它會使用網域名稱系統（DNS）通訊協定來建立用戶端與工作負載端點之間的通訊路徑。 建立連線之後，用戶端可以直接連線到端點，而不需要流量管理員的協助。
本文假設您身為一位架構師，已檢閱 Azure 中的 負載平衡選項，並為您的工作負載選擇 Azure 流量管理員，將其部署在多個區域的主動-主動或主動-被動模型中。 本文中的指引提供架構建議，這些建議會對應至 Well-Architected Framework 支柱的原則。
重要
如何使用本指南
每個區段都有一個 設計檢查清單，其中會呈現需要關注的設計區域，以及針對技術範圍調整的設計策略。
此外，也包含可協助具體化這些策略的技術功能建議。 建議並不代表流量管理員及其相依性可用之所有設定的完整清單。 而是，他們列出了對應至設計觀點的主要建議。 使用建議來建置概念證明，或將現有的環境優化。
示範主要建議的基礎架構：多區域負載平衡與流量管理員、Azure 防火牆和應用程式網關。
技術範圍
此檢閱著重於下列 Azure 資源的相關決策：
- 流量管理員
注意
對於裝載 HTTP 應用程式的工作負載，Azure Front Door 是自然選擇，因為它的功能，例如內容傳遞網路、傳輸層安全性 （TLS） 終止，以及整合式防火牆。
相較於 Azure Front Door，流量管理員更容易設定、設定和維護。 流量管理員沒有您可以直接控制的端點。 與處理用戶端要求的 Front Door 不同，流量管理員只會將用戶端連線到工作負載的端點。
但是，這種簡單性伴隨著可帶來架構複雜度之取捨。 例如，您可能需要實作額外的安全性措施，以封鎖 Open Worldwide Application Security Project （OWASP） 攻擊類型。 Azure Front Door 或 Azure 應用程式閘道中的 Web 應用程式防火牆 （WAF） 提供這項功能。 或者，您可以新增快取，以加速內容傳遞，但會增加複雜性，因為您必須管理數據存放區。
如需詳細資訊，請參閱 Well-Architected Azure Front Door 架構觀點。
可靠性
可靠性支柱的目的是藉由 建置足夠的復原能力，以及從失敗中快速復原的能力，來提供持續的功能。
可靠性設計原則 提供適用於個別元件、系統流程和整個系統的高階設計策略。
設計檢查清單
根據可靠性 的設計檢閱檢查清單，啟動您的設計策略。 判斷其與您的商務需求相關性，同時記住應用程式的本質及其元件的重要性。 擴充策略，以視需要包含更多方法。
考慮潛在的失敗。 流量管理員的設計目的是具備復原能力。 但它仍然可能是您工作負載的單點故障。 若要降低此風險，請定義一條通往替代服務的次要路徑，當流量管理員無法使用時，該路徑就會啟動。 若要避免路由問題，請勿同時使用流量管理員和替代服務。
充分瞭解服務等級協定（SLA）涵蓋範圍。 當您評估 流量管理員 SLA時，請瞭解與已發佈百分位數相關的涵蓋範圍。 例如，您的 DNS 查閱可能會失敗多次。 這些失敗不會被視為停機，直到發生連續 DNS 查閱失敗的完整分鐘為止。
在您的工作負載架構中納入備援。 如果您的服務是透過公用IP位址公開，請使用流量管理員在 Azure 區域、內部部署和其他雲端之間實作備援。 例如，您可能有一個內部部署應用程式，在雲端中具有備份實例。 如果本地部署系統失敗，雲端實例可以啟動，以確保系統的持續運作。
使用可靠的部署架構來支援備援。 身為負載平衡器，流量管理員會根據您設定其路由方法的方式，將流量分散到工作負載端點。 您會在流量管理員設定檔中定義此組態。 設定檔是您部署策略的重要組成部分。 您可以使用適當的配置檔組態來實作主動-主動模型或具有暖備援的主動-被動模型。
每個配置檔都會指定單一流量路由方法。 某些案例需要更複雜的流量路由。 您可以結合流量管理員配置檔來利用多個流量路由方法。
評估 DNS 回應的快取持續時間。 流量管理員中 DNS 查閱的存留時間 （TTL） 設定會決定下游 DNS 解析程式快取 DNS 回應的時間長度。 默認 TTL 可能會導致快取時間超過必要時間，如果端點失敗，可能會導致停機。 減少 TTL 以增加快取更新的頻率。 此方法有助於減輕停機時間，但會增加 DNS 查閱的頻率。
避免將流量傳送到不健康或遭入侵的實例。 查看流量管理員中的內建健康檢查功能。
針對 HTTPS 和 HTTP 應用程式，實作健康情況端點監視模式，以在應用程式中提供自定義頁面。 根據特定檢查，頁面會傳回適當的 HTTPS 狀態代碼。 除了端點的可用性之外，健康檢查應該監視應用程式的所有依賴項。
對於其他應用程式，流量管理員會使用傳輸控制通訊協定 （TCP） 來判斷端點的可用性。
判斷您的停電容忍度。 如果後端變成無法使用，在流量管理員辨識失敗並停止將流量導向至無法使用的端點之前，可能會經過一段時間。 有一段時間無法滿足客戶的需求。 使用此容差來設定探測設定，以決定您希望何時啟動業務連續性作業的速度。
包含端點作為復原測試的一部分。 模擬無法使用的端點，以查看流量管理員如何處理失敗。 假設您的工作負載使用負載平衡器，例如私人虛擬網路中的應用程式閘道。 您可以在 Azure Chaos Studio 中使用網路安全組 （NSG） 規則來模擬端點的失敗。 您可以封鎖對應用程式閘道所在子網的存取。
建議
| 建議 | 效益 |
|---|---|
| 在流量管理員配置檔中 部署多個端點，並加以啟用。 如果端點未啟用，則不會進行健康檢查，也不會包含在流量路由輪替中。 將這些端點放在不同的區域中。 | 備援實例有助於確保一個端點失敗時的可用性。 |
|
評估各種流量路由方法。 設定一或組合方法，以配合您的部署策略。 流量管理員會將所選的方法套用至每個 DNS 查詢，並使用 方法來判斷 DNS 回應中傳回的端點。 - 加權方法 根據設定的權數係數分配流量。 此方法支援主動-主動模型。 - 優先順序型方法 設定主要區域以接收流量，並將其傳送至次要區域做為備份。 此方法支持主動-被動模型。 - 地理方法 根據 DNS 查詢的地理來源路由傳送流量。 若要涵蓋所有區域，請使用 All （World） 屬性來設定至少一個端點。 |
優化的路由方法有助於確保您能有效率地將流量分散到端點。 您可以支持主動-主動或主動-被動部署模型目標。 有效率的路由方法可協助確保次要區域可以處理流量或做為備份。 地理路由可協助根據使用者的位置，將用戶導向至最近的端點。 這有助於確保流量有效率地受到管理，而不會遺失。 |
| 將 DNS TTL 間隔 持續時間設定為低值，最好小於 60 秒。 若要優化效能，請調整健康探測的時間設定和 DNS 記錄的 TTL。 | 縮短 TTL 持續時間有助於更頻繁地更新下游 DNS 解析器快取並更快地故障轉移。 它也會將停機時間降到最低，並改善應用程式的整體回應性。 |
| 設定健康探測以 監控端點。 - 請勿啟用 AlwaysServe，這會停用端點監視，並將要求傳送至端點，而不論其健康狀態為何。 - 設定 probing interval 值。 請考慮偵測失敗的速度與端點要求數目之間的取捨。 要求數量可能相當龐大，因為 Traffic Manager 是一項全球服務，能同時在全球各個位置進行 ping。 - 設定 probe timeout 值。 請考慮在宣告端點狀況不良之前等候的時間長度。 在失敗次數中包含假陽性。 |
健康情況探查可確保只有狀況良好的實例可處理使用者要求。 它們也有助於判斷失敗是否為非暫時性的，以及故障轉移作業應該多快進行。 |
安全
安全性要素的目的是為工作負載提供 機密性、完整性和可用性 保證。
安全性設計原則 藉由將方法套用至流量管理員的技術設計，為達成這些目標提供高階的設計策略。
設計檢查清單
檢閱安全性基準。 若要增強您的安全性狀態，請檢閱流量管理員 的安全性基準。
防止未經授權的流量路由修改。 將流量管理員配置檔視為重要的工作負載資源，因為它們包含路由流量的組態設定。 只有經授權的身分才能存取這些配置檔。 在控制平面上實作 角色型訪問控制 （RBAC），以限制建立、刪除或修改資源等工作。 只有授權的身分識別才應該具有啟用或停用端點的授權。 未經授權的存取可能會導致組態變更，並可能將流量重新路由傳送至惡意實作。
保護應用程式免於網路邊緣的威脅。 流量管理員不提供內建的安全性功能，例如 WAF。 為了協助保護 HTTP 應用程式，您應該在端點層級實作流量檢查。
典型的架構可能包括流量管理員和多個端點。 針對每個端點，處理 TLS 終止和其他安全性功能的應用程式閘道會提供保護。 如需示範該模式的參考架構，請參閱 使用 Traffic Manager、Azure 防火牆和應用程式網關進行多重區域負載平衡。
強化 DNS 記錄。 流量管理員可能會受到管理 DNS 數據的攻擊，這可將流量重新導向至惡意網站並造成安全性問題。 常見的威脅是子域接管，這種情況發生在 DNS 記錄指向已移除的 Azure 資源。 若要防止子域接管，請使用 Azure DNS 別名記錄，並將 DNS 記錄的生命週期與 Azure 資源結合在一起。
如需詳細資訊，請參閱 防止懸置的 DNS 條目。
建議
| 建議 | 好處 |
|---|---|
|
將應用程式閘道新增至工作負載端點。 若要使用 HTTP 應用程式的防火牆實作安全性檢查，請將應用程式閘道新增至工作負載端點。 |
您可以檢查輸入 HTTP 流量，協助保護應用程式免於遭受常見的攻擊。 |
| 在 Azure DNS 中為工作負載的根域名建立別名記錄，將其指向流量管理員配置檔。 | 別名記錄會緊密結合 DNS 記錄與 Azure 資源的生命週期。 如果工作負載停止運作，此設定有助於防止懸空參照。 如果流量管理員配置檔已刪除，DNS 別名記錄會變成空的記錄集。 它不再參考已刪除的資源。 |
成本優化
成本優化著重於 偵測支出模式、將投資放在重要領域，並將其他 優化，以符合組織的預算，同時符合商務需求。
成本優化設計原則 提供高階設計策略，以達成這些目標，並在與流量管理員及其環境相關的技術設計中在必要時進行取捨。
設計檢查清單
以 設計檢閱檢查清單作為基礎開始您的設計策略，以進行投資成本優化。 微調設計，讓工作負載符合為工作負載配置的預算。 您的設計應該使用正確的 Azure 功能、監視投資，以及尋找經過一段時間優化的機會。
評估功能的成本。 流量檢視儀錶板功能會顯示用戶端從何處連線和相關聯的延遲。 這項資訊有助於優化效能並精簡您的設計，有助於卓越營運和系統效率。 不過，會產生額外費用。 如需詳細資訊，請參閱 流量檢視計費。
另外考慮與健康檢測相關聯的成本。 流量管理員會從各種位置偵測已定義的端點，以檢查其可用性。 您可以選擇慢速 ping 和快速 ping。 快速的 Ping 會更快檢測故障，但會產生較高的成本。 它們也會增加工作負載，因為健康檢查較為頻繁。
評估路由策略的成本。 例如，如果大多數用戶端從高延遲區域存取您的端點，您可以建立更接近這些使用者的另一個端點，並在流量管理員中調整路由方法。 這種做法可減少延遲，讓您可以處理更多容量較少的要求，進而節省成本。
建議
| 建議 | 效益 |
|---|---|
| 使用 定價計算機 來估計流量管理員功能的成本。 | 如有需要，您可以擁有更精確的成本模型，並設定資源周圍的治理。 |
| 在優化工作期間，啟用 流量檢視儀錶板。 | 此功能可協助您進一步瞭解使用模式。 使用此資料進行效能微調，以協助符合您的工作負載目標。 在正確的時間啟用功能，並套用正確的層級以避免資源浪費。 |
| 視您的復原計量而定，選擇 健康情況探查快速或緩慢的 ping。 快速 Ping 會更快偵測失敗，但成本更高。 緩慢的 Ping 速度較慢，但成本較低。 請勿停用 Ping。 |
減少 Ping 頻率以優化成本，並降低工作負載端點的負荷。 |
卓越營運
卓越營運主要著重於 開發實務、可觀察性和發行管理的程式。
營運卓越設計原則 提供高階設計策略，以達成工作負載作業需求的目標。
設計檢查清單
收集和分析作業數據，作為工作負載監視的一部分。 擷取相關的流量管理記錄和度量指標。 使用此數據進行疑難解答、瞭解流量行為，以及微調路由邏輯。
檢視檔案的流量數據。 此數據有助於找出可改善的區域，例如在高延遲地區擴展您的 Azure 覆蓋範圍。 它也會醒目提示不同區域的流量模式，以協助您判斷增加或減少投資的位置。
實作災害復原作業。 您的災害復原實作可以設計為將網路流量從主網站重新導向到備份網站。 您可以使用 Azure DNS 和 Azure 流量管理員 （DNS） 來實作此災害復原方法。 發生災害時，如果主要端點降級，流量管理員會將流量重新導向至狀況良好的次要端點。 根據預設，流量管理員會將優先順序設定為主要端點，但也可以設定額外的故障轉移端點或負載平衡器來分散流量負載。 如需詳細資訊，請參閱 設定災害復原和中斷偵測。
避免自動故障恢復作業。 當您進行容錯回復時，請勿使用自動容錯回復，這會在主要端點可用時立即切換回原始端點。 請改為停用原始端點，並使用次要端點，直到您想要切換為止。 這種方法提供時間以進行穩定。 立即故障回退可能會導致額外的負載和延遲。
如需詳細資訊，請參閱 多重區域負載平衡參考架構。
測試組態設定。 設定錯誤可能會影響工作負載的所有層面，特別是可靠性。 在各種位置使用多個客戶端測試組態。 如需詳細資訊，請參閱 驗證流量管理員設定。
建議
| 建議 | 好處 |
|---|---|
|
為流量管理設定檔啟用診斷記錄。 使用 工具 重播日誌並分析健康檢查數據。 |
診斷記錄提供流量管理器設定檔行為的深入解析。 例如，您可以針對端點識別個別探查逾時的原因。 |
| 啟用 流量檢視儀錶板。 了解您的客戶從哪裡連接及相關的延遲。 | 這項資訊有助於優化效能和成本，因為您可以精簡設計。 |
| 利用 熱度圖 REST API，其提供用戶端位置和延遲的相關數據。 | 這種方法提供彈性，例如設定特定時段。 您可以將資料新增至自訂工具或儀錶板。 您也可以使用此 API 與外部工具整合。 |
| 停用與營運相關活動的端點。 例如，您可以在故障轉移之後停用容錯回復，以進行維護或測試。 | 停用負載平衡器的端點對於執行操作任務非常有利，因為您無法中斷即時流量。 在維護期間，如果您停用端點，實例就不會收到流量。 此方法可防止自動容錯回復。 |
效能效率
效能效率與 維護用戶體驗有關，即使藉由管理容量來增加負載 也一定。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。
效能效率設計原則 提供針對預期使用量達成這些容量目標的高階設計策略。
設計檢查清單
請根據效能效率 指標的設計審查清單，開始您的設計策略。 定義以流量管理員關鍵效能指標為基礎的基準。
測量設定的效能影響。 流量管理員不會干擾用戶端與端點之間的直接連線。 主要效能影響是初始 DNS 查閱。 TTL 設定會影響此查閱發生的頻率。 較低的 TTL 表示更頻繁的 DNS 解析，這可能會影響效能。 如果您將 TTL 設定為零，每個要求都需要 DNS 查閱，這會在存取端點之前新增一個小延遲。
由於流量管理員在 DNS 層級運作，因此不支援會話親和性。 流量管理員可能會將用戶導向至每個呼叫的不同端點。 如果您需要會話親和性，您必須將狀態保存到個別的資料存放區。
如需詳細資訊，請參閱流量管理員 的效能考慮。
調整流量路由行為以將效能優化。 單一配置檔可以有多個端點，但一次只能套用一個路由方法。
針對更複雜的案例，請考慮建立一個層級架構來結合不同的路由方法。 例如，您可以設定區域的優先順序，然後在區域內使用以效能為基礎的路由。
建議
| 建議 | 好處 |
|---|---|
| 當您在不同地理位置有端點時，請使用 效能路由方法。 | 此方法會優先將流量傳送至具有最低延遲的端點。 此方法可協助確保使用者的快速服務。 |
| 使用特製化工具來優化效能。 測量 DNS 查詢的效能。 若要分析流量的效能，請使用 流量檢視儀錶板 或 熱度圖 REST API。 | DNS 延遲測量工具會執行完整的 DNS 查閱，並提供效能數據。 您可以使用此資料來設定 TTL 持續時間並優化效能。 |
| 結合流量方法與 巢狀配置檔，以根據您的工作負載需求達到最佳效能。 | 優化的路由方法可協助確保流量導向至回應最快速且最接近的端點。 這種方法有助於改善應用程式效能和用戶體驗。 |
| 使用實際的使用者度量功能 來檢視 Azure 區域的網路等待時間度量。 這項功能不需額外費用。 | 您可以進行數據導向路由決策，以將查詢導向至提供最低延遲的 Azure 區域。 |
| 將 DNS TTL 間隔 設定為較高的值。 | 用戶端可以快取較長時間的結果，以減少每次解析 DNS 的需求。 |
Azure 原則
Azure 提供一組與流量管理員及其相依性相關的大量內建原則。 您可以透過 Azure 原則稽核上述一些建議。 例如，您可以檢查是否：
- 已啟用資源記錄來追蹤活動。
- 流量管理員配置檔的記錄會傳送至 Azure 事件中樞。
如需全面治理，請檢閱 azure 網路服務 的Azure 原則內建定義。
Azure Advisor 建議
Azure Advisor 是個人化雲端顧問，可協助您遵循最佳做法來優化 Azure 部署。 以下是一些建議，可協助您改善 Web 應用程式實例的可靠性、安全性、成本效益、效能和營運卓越性。
權衡
如果您使用柱子檢查清單中的方法，您可能需要進行設計取捨。 以下是一些優點和缺點範例。
可靠性和效能效率
DNS 查詢的 TTL 設定。 預設的 TTL 設定可能會導致較長的快取時間。 如果端點失敗，快取的長時間可能會導致停機，因為應用程式會在 TTL 時間內持續嘗試連接至失敗的端點。
減少TTL以協助減輕此問題。 較低的 TTL 會有更頻繁的更新和更快速的故障轉移，但它也增加了 DNS 查詢的頻率。 這種方法可能會影響效能，並增加 DNS 伺服器上的負載。
可靠性和成本優化
- 健康探測。 流量管理員會使用健康探測，從各種位置探測端點的可用性。 您可以選擇慢速 Ping 或快速 Ping。 發送快速Ping訊號可以更快偵測失敗，但會增加成本。 慢速 ping 偵測失敗所需的時間較長，但成本較低。 將失敗偵測和復原的速度與相關聯的成本進行平衡。
下一步
請考慮下列資源，示範本文中的建議。
使用下列參考架構作為如何將本文指引套用至工作負載的範例：
使用下列產品檔來改善您的實作專業知識：