本文說明如何使用 Azure Data Factory 提供任務關鍵性進階分析解決方案。 此架構是基準架構和企業強化架構的延伸模組。 本文提供以任務關鍵性作業方式管理工作負載所需之建議變更的特定指引。
此架構與 Azure 最佳做法和指引的 雲端採用架構 一致，以及任務關鍵性工作負載的建議。
建立任務關鍵架構
在基準架構中，Contoso 會操作獎章湖屋，以支持財務部門的第一個數據工作負載。 Contoso 強化並擴充此系統，以支持企業的分析數據需求。 此策略提供數據科學功能和自助功能。
在企業強化架構中，Contoso 已實作一個獎牌湖屋架構，可支援其企業分析數據需求，並使用網域模型來啟用商務使用者。 隨著 Contoso 繼續其全球擴張，財務部門已使用 Azure 機器學習 來建立交易詐騙模型。 此模型現在需要進一步精簡，才能作為任務關鍵性營運服務運作。
重要需求
使用 Data Factory 提供任務關鍵性進階分析解決方案有幾個重要需求：
機器學習模型必須設計為任務關鍵性操作服務，且可全域提供給各種交易操作系統使用。
機器學習模型結果和效能計量必須可用於重新定型和稽核。
機器學習模型稽核線索必須保留 10 年。
機器學習模型目前以美國、歐洲和南美洲為目標，並計劃在未來擴展到亞洲。 解決方案必須遵守數據合規性需求，例如適用於歐洲國家或區域的一般數據保護規定。
機器學習模型預計將在尖峰上班時間支援任何指定區域中最多 1,000 名並行使用者。 若要將成本降到最低，機器學習處理必須在不使用時相應減少。
主要的設計決策
需求並不能證明重新設計平臺以符合任務關鍵規格的成本和複雜度。 機器學習模型應該改為容器化，然後部署到任務關鍵性解決方案。 此方法藉由隔離模型服務並遵守任務關鍵性指引，將成本和複雜性降到最低。 此設計需要在平台上開發模型，然後容器化以進行部署。
容器化模型之後，即可透過 API 在美國、歐洲和南美 Azure 區域中使用 縮放單位架構 來提供。 只有 具有可用性區域的配對區域 位於範圍內，可支持備援需求。
由於單一 API 服務的簡單性，我們建議您使用 Web 應用程式作為容器 功能來裝載應用程式。 這項功能提供簡單明瞭。 您也可以使用 Azure Kubernetes Service （AKS），以提供更多控制權，但會增加複雜性。
模型是透過 MLOps 架構來部署。 Data Factory 用來將數據移入和移出任務關鍵性實作。
若要進行容器化，您需要：
提供模型結果的 API 前端。
若要將稽核和效能計量卸除至記憶體帳戶，接著可以使用排程的作業，透過 Data Factory 將稽核和效能計量移回主要平臺。
部署和復原部署管線，可讓每個區域部署與正確的目前模型版本同步處理。
服務 健康情況模型 ，以測量和管理工作負載的整體健康情況。
稽核線索一開始可以儲存在Log Analytics工作區中，以進行即時分析和操作支援。 在使用 sentinel Microsoft 30 天或 90 天后，稽核線索可以自動傳送至 Azure 數據總管以進行長期保留。 這種方法允許在Log Analytics工作區內進行最多兩年的互動式查詢，以及以高達12年的成本保持較舊、不常使用的數據的能力。 使用適用於數據記憶體的 Azure 數據總管來啟用執行跨平台查詢，並將 Azure 數據總管和Microsoft Sentinel 的數據可視化。 此方法提供符合成本效益的解決方案，以符合長期記憶體需求，同時維持支持選擇性。 如果沒有保留過多資料的需求，您應該考慮將其刪除。
架構
工作流程
下列工作流程對應至上圖：
機器學習模型是在數據平台上開發。 此設計變更需要下列架構更新：
Azure Container Registry 可讓您在支援機器學習模型部署的私人登錄中建置、儲存和管理 Docker 容器映射和成品。
容器的 Web 應用程式功能可讓持續整合和持續部署活動，以 API 服務的形式傳遞機器學習模型輸出所需的活動。
Data Factory 可讓您移轉模型執行所需的任何數據，並啟用從任務關鍵實作擷取模型輸出和效能計量。
Data Lake 銅層（或 原始層）目錄結構會使用 封存層 來儲存模型輸出和效能計量，以符合數據保留需求。
Azure DevOps 會協調模型程式代碼基底的部署，以及為所有支援服務建立和淘汰區域部署。
機器學習模型會部署為自己定義訂用帳戶內的專用任務關鍵性工作負載。 此方法可確保模型可避免平臺可能強加的任何 元件限制或服務限制 。
一組共用資源橫跨整個解決方案，因此定義為全域：
Container Registry 可讓您跨區域部署散發目前的機器學習模型版本。
Azure Front Door 提供負載平衡服務，以分散跨區域部署的流量。
監視功能會使用 Log Analytics 和 Azure Data Lake Storage。
區域 部署戳記 是一組解決方案元件，您可以部署到任何目標區域。 此方法提供規模、服務復原和區域特定服務。
根據機器學習模型的性質，可能會有需要機器學習模型遵守主權法規的區域數據合規性需求。 此設計支援這些需求。
每個區域部署都隨附自己的監視和儲存堆疊，可提供與解決方案其餘部分的隔離。
解決方案 的縮放單位 具有下列元件：
容器的 Web 應用程式功能會裝載機器學習模型，並提供其輸出。 身為此解決方案的核心服務元件，您應該將容器 Web 應用程式的規模限制視為主要條件約束。 如果這些限制不支持解決方案需求，請考慮改用 AKS。
Azure 金鑰保存庫 會針對透過 Azure Private Link 保護的區域範圍秘密、憑證和密鑰強制執行適當的控制。
Data Lake Storage 提供透過 Private Link 保護的數據記憶體。
Azure DNS 提供名稱解析，可啟用服務復原，並簡化解決方案之間的負載平衡。
為了協助解決方案的支援和疑難解答，也包含下列元件：
Azure Bastion 提供跳躍主機的安全連線，而不需要公用IP位址。
Azure 虛擬機器 可作為解決方案的跳躍主機，以提升安全性狀態。
自我裝載的組建代理程式 提供規模和效能，以支援解決方案部署。
網路設計
您應該使用新一代防火牆，例如 Azure 防火牆 來保護內部部署基礎結構與 Azure 虛擬網路之間的網路連線。
您可以在內部部署環境或 Azure 中的虛擬機 （VM） 上部署自我裝載整合運行時間 （SHIR）。 請考慮在 Azure 中部署 VM 作為共用支援資源登陸區域的一部分，以簡化治理和安全性。 您可以使用 SHIR 安全地連線到內部部署數據源，並在 Data Factory 中執行資料整合工作。
機器學習輔助數據標籤不支援預設記憶體帳戶，因為它們在虛擬網路後方受到保護。 首先建立機器學習輔助數據標記的記憶體帳戶。 然後套用標籤，並在虛擬網路後方加以保護。
私人端點會 提供從虛擬網路到 Azure 服務的私人 IP 位址。 此程式可有效地將服務帶入您的虛擬網路。 這項功能可讓服務只能從虛擬網路或連線的網路存取，以確保更安全且私人的連線。 私人端點使用 Private Link，可保護平臺即服務 （PaaS） 解決方案的連線。 如果您的工作負載使用任何不支援私人端點的資源，您可能可以使用 服務端點。 建議您盡可能對任務關鍵性工作負載使用私人端點。
如需詳細資訊，請參閱 網路和連線能力。
重要
判斷您的使用案例是否正常運作，例如此案例，或它是否與數據平台相關。 如果您的使用案例包含數據平臺，例如數據科學或分析，它可能不符合任務關鍵性資格。 任務關鍵性工作負載需要大量資源，而且只有在資源投資合理時，才應該定義為這類。
替代項目
您可以使用 AKS 來裝載容器。 針對此使用案例，AKS 所需的管理負擔使其成為較不理想的選項。
您可以使用 Azure Container Apps ，而不是用於容器功能的 Web 應用程式。 容器應用程式目前不支援私人端點，但服務可以整合到現有或新的虛擬網路中。
您可以使用 Azure 流量管理員 做為負載平衡替代方案。 此案例偏好使用 Azure Front Door，因為額外的可用功能和更 快速的故障轉移效能。
如果模型需要讀取和寫入功能做為其數據處理的一部分，請考慮使用 Azure Cosmos DB。
考量
這些考量能實作 Azure Well-Architected Framework 的要素，其為一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 架構良好的架構。
可靠性
可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性的設計檢閱檢查清單。
相較於基準架構，此架構：
安全性
安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱 安全性的設計檢閱檢查清單。
相較於基準架構，此架構：
遵循任務關鍵 性安全性 設計考慮中的指引。
實作 任務關鍵性參考架構的安全性指引 。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。
任務關鍵性設計很 昂貴，因此實作控件很重要。 某些控制項包括：
將元件 SKU 選取專案對齊解決方案 縮放單位界限 ，以防止過度布建。
可用且實用的作業費用節省優點，例如 適用於穩定工作負載的 Azure 保留 、 動態工作負載的節省方案 ，以及 Log Analytics 承諾層。
透過 成本管理Microsoft的成本和預算警示。
卓越營運
卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱 卓越營運的設計檢閱檢查清單。
相較於基準架構，此架構：
遵循任務關鍵 性營運卓越 設計考慮的指引。
分隔全域和區域監視資源，以防止可檢視性中的單一點失敗。
實作 來自任務關鍵參考架構的部署和測試指引 和 操作程式 。
效能效益
效能效率可讓您的工作負載進行調整，以有效率的方式符合使用者對其放置的需求。 如需詳細資訊，請參閱 效能效率的設計檢閱檢查清單。
相較於基準架構，此架構：
遵循任務關鍵 性效能效率 設計考慮中的指引。
完成任務關鍵性工作負載的架構良好評定，以提供解決方案的整備基準。 定期重新流覽此評估，作為主動測量和管理週期的一部分。
反模式
購物清單方法： 商務項目關係人通常會看到功能與服務等級的購物清單，而不需要成本或複雜度的內容。 請務必確保任何解決方案都以已驗證的需求為基礎，且解決方案設計受到財務模型化支援，並提供選項。 這種方法可讓項目關係人在必要時做出明智的決策並樞紐。
不具挑戰性的需求： 任務關鍵性設計對於實作和維護來說可能相當昂貴且複雜。 應詢問業務項目關係人的需求，以確保“任務關鍵性”確實是必要的。
部署並忘記： 模型會部署，而不需要持續監視、更新或支持機制。 部署模型之後，它不需要進行中維護，而且會保持隔離運作。 這種忽視可能會導致效能降低、模型精確度漂移，以及新興數據模式的弱點。 最後，忽視會破壞模型在服務其預定目的時的可靠性與有效性。
下一步
- 架構完善的架構任務關鍵性指引
- 雲端採用架構 (機器翻譯)