Azure Machine Learning 推斷路由器和連線需求
Azure Machine Learning 推斷路由器是使用 Kubernetes 叢集進行即時推斷的重要元件。 在本文中,您可了解:
- 什麼是 Azure Machine Learning 推斷路由器
- 自動調整的運作方式
- 如何設定並符合推斷要求效能 (每秒要求數目和延遲)
- AKS 推斷叢集的連線需求
什麼是 Azure Machine Learning 推斷路由器
Azure Machine Learning 推斷路由器是前端元件 (azureml-fe
),其在 Azure Machine Learning 延伸模組部署時間部署於 AKS 或 Arc Kubernetes 叢集上。 它有下列功能:
- 將來自叢集負載平衡器或輸入控制器的傳入推斷要求路由傳送至對應的模型 Pod。
- 平衡所有傳入推斷要求與智慧協調路由的負載。
- 管理模型 Pod 自動調整。
- 容錯和容錯移轉功能,以確保推斷要求一律為重要的商務應用程式提供服務。
下列步驟是前端處理要求的方式:
- 用戶端會將要求傳送至負載平衡器。
- 負載平衡器會傳送至其中一個前端。
- 前端會找出服務的服務路由器 (作為協調器的前端執行個體)。
- 服務路由器會選取後端並將它傳回至前端。
- 前端會將要求轉送至後端。
- 處理要求之後,後端會將回應傳送至前端元件。
- 前端會將回應傳播回用戶端。
- 前端會通知服務路由器,後端已完成處理並可供其他要求使用。
下圖說明此流程:
如上圖所示,預設會在 Azure Machine Learning 延伸模組部署期間建立 3 個 azureml-fe
執行個體,一個執行個體作為協調角色,而其他執行個體則為傳入推斷要求提供服務。 協調執行個體具有模型 Pod 的所有相關資訊,並決定要為傳入要求提供服務的模型 Pod,而服務 azureml-fe
執行個體則負責將要求路由傳送至所選的模型 Pod,並將回應傳播回原始使用者。
自動調整規模
Azure Machine Learning 推斷路由器會處理 Kubernetes 叢集上所有模型部署的自動調整。 因為所有推斷要求都會通過它,所以它具有自動調整已部署模型的必要資料。
重要
請勿為模型部署啟用 Kubernetes 水平 Pod 自動調整程式 (HPA)。 這麼做會導致兩個自動調整元件互相競爭。 Azureml-fe 的設計可自動調整 Azure ML 部署的模型,其中的 HPA 必須從一般計量 (例如 CPU 使用量或自訂計量設定) 猜測或估計模型使用率。
Azureml-fe 無法調整 AKS 叢集中的節點數目,因為這可能會導致非預期的成本增加。 相反地,它會在實體叢集界限內調整模型的複本數目。 如果您需要調整叢集內的節點數目,您可以手動調整叢集或設定 AKS 叢集自動調整程式。
自動調整可由部署 YAML 中的 scale_settings
屬性控制。 下列範例示範如何啟用自動調整:
# deployment yaml
# other properties skipped
scale_setting:
type: target_utilization
min_instances: 3
max_instances: 15
target_utilization_percentage: 70
polling_interval: 10
# other deployment properties continue
相應增加或減少的決策是以 utilization of the current container replicas
為基礎。
utilization_percentage = (The number of replicas that are busy processing a request + The number of requests queued in azureml-fe) / The total number of current replicas
如果此數目超過 target_utilization_percentage
,則會建立更多複本。 如果低於此數目,即會減少複本。 依預設,目標使用率為 70%。
新增複本的決策是積極且快速 (大約 1 秒)。 移除複本的決策是保守 (大約 1 分鐘)。
例如,如果您想要部署模型服務,而且想知道應該針對每秒目標要求 (RPS) 和目標回應時間設定多少執行個體 (Pod/複本)。 您可以使用下列程式碼來計算所需的複本:
from math import ceil
# target requests per second
targetRps = 20
# time to process the request (in seconds)
reqTime = 10
# Maximum requests per container
maxReqPerContainer = 1
# target_utilization. 70% in this example
targetUtilization = .7
concurrentRequests = targetRps * reqTime / targetUtilization
# Number of container replicas
replicas = ceil(concurrentRequests / maxReqPerContainer)
azureml-fe 的效能
azureml-fe
每秒要求數目 (QPS) 可以達到 5 千個,且延遲良好,平均額外負荷不超過 3 毫秒,99% 的百分位數為 15 毫秒。
注意
如果您有高於 10K 的 RPS 需求,請考慮下列選項:
- 提高
azureml-fe
Pod 的資源要求/限制,預設有 2 個 vCPU 和 1.2G 記憶體資源限制。 - 增加
azureml-fe
的執行個體數目。 根據預設,Azure Machine Learning 會為每個叢集建立 3 或 1 個azureml-fe
執行個體。- 此執行個體計數取決於您 Azure Machine Learning 延伸模組的
inferenceRouterHA
組態。 - 無法保存增加的執行個體計數,因為它會在升級延伸模組之後以您設定的值覆寫。
- 此執行個體計數取決於您 Azure Machine Learning 延伸模組的
- 連絡 Microsoft 專家以取得協助。
了解 AKS 推斷叢集的連線需求
AKS 叢集會使用下列兩種網路模型之一來部署:
- Kubenet 網路 - 在部署 AKS 叢集時通常會建立並設定網路資源。
- Azure 容器網路介面 (CNI) 網路 - AKS 叢集會連線至現有的虛擬網路資源和設定。
針對 Kubenet 網路功能,會為 Azure Machine Learning 服務建立並正確設定網路。 針對 CNI 網路功能,您需要了解連線需求,並確保 AKS 推斷的 DNS 解析和輸出連線。 例如,如果您使用防火牆來封鎖網路流量,您可能需要額外的步驟。
下圖顯示 AKS 推斷的連線需求。 黑色箭號代表實際的通訊,而藍色箭號代表網域名稱。 您可能需要將這些主機的項目新增至您的防火牆或自訂 DNS 伺服器。
如需一般 AKS 連線需求,請參閱控制 Azure Kubernetes Service 中叢集節點的輸出流量。
如需在防火牆後方存取 Azure Machine Learning 服務,請參閱設定輸入和輸出網路流量。
整體 DNS 解析需求
現有 VNet 內的 DNS 解析由您控制。 例如,防火牆或自訂 DNS 伺服器。 下列主機必須可連線:
主機名稱 | 使用對象 |
---|---|
<cluster>.hcp.<region>.azmk8s.io |
AKS API 伺服器 |
mcr.microsoft.com |
Microsoft Container Registry (MCR) |
<ACR name>.azurecr.io |
您的 Azure Container Registry (ACR) |
<account>.blob.core.windows.net |
Azure 儲存體帳戶 (Blob 儲存體) |
api.azureml.ms |
Microsoft Entra 驗證 |
ingest-vienna<region>.kusto.windows.net |
用於上傳遙測的 Kusto 端點 |
以時間順序排列的連線需求:從叢集建立到模型部署
部署 azureml-fe 之後,它會隨即嘗試啟動,而這需要:
- 解析 AKS API 伺服器的 DNS
- 查詢 AKS API 伺服器以探索其本身的其他執行個體 (這是多 Pod 服務)
- 連線至其本身的其他執行個體
一旦啟動 azureml-fe,需要下列項目,連線才能正常運作:
- 連線 Azure 儲存體,以下載動態設定
- 解析 Microsoft Entra 驗證伺服器 api.azureml.ms 的 DNS,並在部署的服務使用 Microsoft Entra 驗證時與其通訊。
- 查詢 AKS API 伺服器以探索部署的模型
- 與已部署的模型 Pod 通訊
在模型部署時,成功的模型部署 AKS 節點應該能夠:
- 解析客戶的 ACR DNS
- 從客戶的 ACR 下載映像
- 解析儲存模型所在 Azure Blob 的 DNS
- 從 Azure Blob 下載模型
模型部署且服務啟動之後,azureml-fe 將使用 AKS API 自動探索它,並準備好將要求路由至其中。 它必須能夠與模型 Pod 通訊。
注意
如果已部署的模型需要任何連線 (例如查詢外部資料庫或其他 REST 服務、下載 BLOB 等),則應該同時啟用這些服務的 DNS 解析和輸出通訊。