v1 を使用して Azure Kubernetes Service クラスターにモデルをデプロイする

Azure Machine Learning を使って Azure Kubernetes Service (AKS) 上の Web サービスとしてモデルをデプロイする方法について説明します。 AKS は大規模な運用デプロイに適しています。 次の機能のいずれか 1 つでも必要な場合は、AKS を使います。

• 高速の応答時間
• デプロイされたサービスの自動スケーリング
• ログ記録
• モデルのデータ収集
• 認証
• TLS 終端
• GPU や Field Programmable Gate Array (FPGA) などのハードウェア アクセラレータ オプション

AKS にデプロイするときは、"ワークスペースに接続されている" AKS クラスターにデプロイします。 ワークスペースへの AKS クラスターの接続については、Azure Kubernetes Service クラスターの作成とアタッチに関する記事をご覧ください。

前提条件

• Azure Machine Learning ワークスペース。 詳しくは、Azure Machine Learning ワークスペースの作成に関するページをご覧ください。

• ワークスペースに登録されている機械学習モデル。 登録されたモデルがない場合は、「機械学習モデルを Azure にデプロイする」をご覧ください。

• Azure Machine Learning service 向けの Azure CLI 拡張機能 (v1)、Azure Machine Learning Python SDK、または Azure Machine Learning Visual Studio Code 拡張機能。

  重要

  この記事の Azure CLI コマンドの一部では、Azure Machine Learning 用に azure-cli-ml、つまり v1 の拡張機能を使用しています。 v1 拡張機能のサポートは、2025 年 9 月 30 日に終了します。 その日付まで、v1 拡張機能をインストールして使用できます。

  2025 年 9 月 30 日より前に、ml (v2) 拡張機能に移行することをお勧めします。 v2 拡張機能について詳しくは、Azure Machine Learning CLI 拡張機能と Python SDK v2 に関する記事をご覧ください。

• この記事の Python コード スニペットは、次の変数が設定されていることを前提としています。

  • ws: お使いのワークスペースに設定されます。
  • model: 登録済みのモデルに設定されます。
  • inference_config: モデルの推論構成に設定されます。

  これらの変数の設定について詳しくは、モデルをデプロイする方法と場所に関する記事をご覧ください。

• この記事の CLI のスニペットでは、inferenceconfig.json ドキュメントが既に作成されていることを前提としています。 このドキュメントの作成について詳しくは、「機械学習モデルを Azure にデプロイする」をご覧ください。

• ワークスペースに接続されている AKS クラスター。 詳しくは、Azure Kubernetes Service クラスターの作成とアタッチに関する記事をご覧ください。

  • GPU ノードまたは FPGA ノード (または特定の製品) にモデルをデプロイしたい場合は、特定の製品でクラスターを作成する必要があります。 既存のクラスターにセカンダリ ノード プールを作成し、そのセカンダリ ノード プールにモデルをデプロイすることはサポートされていません。

デプロイ プロセスを理解する

"デプロイ" という用語は、Kubernetes と Azure Machine Learning の両方で使われます。 これら 2 つのコンテキストでは、"デプロイ"の意味が異なります。 Kubernetes では、デプロイは具体的なエンティティであり、宣言型の YAML ファイルで指定されます。 Kubernetes のデプロイには、定義されたライフサイクルと、Pods や ReplicaSets などの他の Kubernetes エンティティへの具体的な関係があります。 Kubernetes については、「Kubernetes とは」のドキュメントとビデオを参照してください。

Azure Machine Learning でのデプロイは、プロジェクト リソースを使用できるようにすることとクリーンアップすることという、より一般的な意味で使われます。 Azure Machine Learning でデプロイの部分と考えられる手順は、次のとおりです。

1. プロジェクト フォルダー内のファイルの圧縮。.amlignore または .gitignore で指定されているものは無視します
2. コンピューティング クラスターのスケールアップ (Kubernetes 関連)
3. Dockerfile のビルドまたは計算ノードへのダウンロード (Kubernetes 関連)
   1. システムにより、次のハッシュが計算されます。
      • 基本イメージ
      • カスタム Docker の手順 (「カスタム Docker ベース イメージを使用してモデルをデプロイする」を参照してください)
      • Conda 定義 YAML (Azure Machine Learning でのソフトウェア環境の作成と使用に関するページを参照してください)
   2. システムはこのハッシュをキーとして使って、ワークスペースの Azure Container Registry (ACR) を検索します
   3. 見つからない場合、グローバル ACR で一致するものを検索します
   4. 見つからない場合、システムは新しいイメージをビルドしてキャッシュし、ワークスペースの ACR にプッシュします
4. 計算ノード上の一時的なストレージへの、圧縮されたプロジェクト ファイルのダウンロード
5. プロジェクト ファイルの解凍
6. 計算ノードでの python <entry script> <arguments> の実行
7. ./outputs に書き込まれたログ、モデル ファイル、その他のファイルの、ワークスペースに関連付けられたストレージ アカウントへの保存
8. 一時的なストレージの削除など、コンピューティングのスケールダウン (Kubernetes 関連)

Azure Machine Learning ルーター

着信した推論要求をデプロイされたサービスにルーティングするフロントエンド コンポーネント (azureml-fe) は、必要に応じて自動的にスケーリングします。 azureml-fe のスケーリングは、AKS クラスターの目的とサイズ (ノードの数) に基づいています。 クラスターの目的とノードは、AKS クラスターを作成またはアタッチするときに構成されます。 クラスターごとに 1 つの azureml-fe サービスがあり、複数のポッドで実行されている可能性があります。

azureml-fe では、使用するコアを増やすスケールアップ (垂直方向) と、使用するポッドを増やすスケールアウト (水平方向) の両方が行われます。 スケールアップするかどうかを決定するときは、受信推論要求のルーティングにかかる時間が使用されます。 この時間がしきい値を超えると、スケールアップが発生します。 受信要求をルーティングする時間がしきい値を超え続けると、スケールアウトが発生します。

スケールダウンとスケールインを行うときは、CPU 使用率が使用されます。 CPU 使用率のしきい値に達した場合、フロントエンドは最初にスケールダウンされます。 CPU 使用率がスケールインのしきい値まで低下した場合は、スケールイン操作が行われます。 スケールアップとスケールアウトは、使用できるクラスター リソースが十分にある場合にのみ発生します。

スケールアップまたはスケールダウンが行われると、azureml-fe ポッドが再起動されて CPU とメモリの変更が適用されます。 再起動は推論の要求に影響しません。

AKS 推論クラスターの接続要件を理解する

Azure Machine Learning によって AKS クラスターが作成またはアタッチされると、AKS クラスターは次の 2 つのネットワーク モデルのいずれかでデプロイされます。

• kubenet ネットワーク: AKS クラスターがデプロイされると、通常、ネットワーク リソースが作成されて構成されます。
• Azure Container Networking Interface (CNI) ネットワーク: AKS クラスターは、既存の仮想ネットワーク リソースと構成に接続されます。

Kubenet ネットワークでは、ネットワークが作成され、Azure Machine Learning service 用に適切に構成されます。 CNI ネットワークでは、ユーザーは接続要件を理解し、AKS 推論のための DNS 解決と送信接続を確認する必要があります。 たとえば、ファイアウォールを使ってネットワーク トラフィックをブロックしている場合があります。

次の図は、AKS 推論の接続要件を示しています。 黒い矢印は実際の通信を表し、青い矢印はドメイン名を表します。 これらのホストのエントリをファイアウォールまたはカスタム DNS サーバーに追加することが必要な場合があります。

AKS の接続の一般的な要件については、「Azure Kubernetes Service (AKS) で Azure Firewall を使用してネットワーク トラフィックを制限する」をご覧ください。

ファイアウォールの内側にある Azure Machine Learning サービスへのアクセスについては、「ネットワークの着信トラフィックおよび送信トラフィックを構成する」をご覧ください。

全体的な DNS 解決の要件

既存の仮想ネットワーク内の DNS 解決は、ユーザーが管理します。 たとえば、ファイアウォールやカスタム DNS サーバーなどです。 次のホストに到達できる必要があります。

時系列での接続要件

AKS の作成またはアタッチのプロセスでは、Azure Machine Learning ルーター (azureml-fe) が AKS クラスターにデプロイされます。 Azure Machine Learning ルーターをデプロイするには、AKS ノードで次のことができる必要があります。

• AKS API サーバーの DNS を解決する
• Azure Machine Learning ルーターの Docker イメージをダウンロードするために、MCR の DNS を解決する
• MCR からイメージをダウンロードする (この場合、送信接続が必要です)

azureml-fe はデプロイされるとすぐに開始しようとしますが、そのためにはユーザーが次のことを行う必要があります。

• AKS API サーバーの DNS を解決する
• AKS API サーバーにそれ自体の他のインスタンスを検出するためにクエリを実行する (マルチポッド サービス)
• それ自体の他のインスタンスに接続する

azureml-fe が開始されると、正常に機能するために次の接続が必要になります。

• 動的構成をダウンロードするために Azure Storage に接続する
• デプロイされたサービスで Microsoft Entra 認証が使われている場合は、Microsoft Entra 認証サーバー api.azureml.ms の DNS を解決して、それと通信する。
• AKS API サーバーでクエリを実行して、デプロイされたモデルを検出する
• デプロイされたモデルのポッドと通信する

モデルのデプロイ時に、モデルのデプロイが成功するには、AKS ノードで次のことができる必要があります。

• お客様の ACR の DNS を解決する
• お客様の ACR からイメージをダウンロードする
• モデルが格納されている Azure BLOB の DNS を解決する
• Azure の BLOB からモデルをダウンロードする

モデルがデプロイされてサービスが開始した後、azureml-fe は AKS API を使ってそれを自動的に検出し、要求をそれにルーティングできるようになります。 モデルのポッドと通信できる必要があります。

AKS にデプロイする

AKS にモデルをデプロイするには、必要なコンピューティング リソースが記述されているデプロイ構成を作成します。 たとえば、コアの数やメモリなどです。 また、モデルと Web サービスのホストに必要な環境が記述されている推論構成も必要です。 推論構成の作成について詳しくは、モデルをデプロイする方法と場所に関する記事をご覧ください。

from azureml.core.webservice import AksWebservice, Webservice
from azureml.core.model import Model
from azureml.core.compute import AksCompute

aks_target = AksCompute(ws,"myaks")
# If deploying to a cluster configured for dev/test, ensure that it was created with enough
# cores and memory to handle this deployment configuration. Note that memory is also used by
# things such as dependencies and AML components.
deployment_config = AksWebservice.deploy_configuration(cpu_cores = 1, memory_gb = 1)
service = Model.deploy(ws, "myservice", [model], inference_config, deployment_config, aks_target)
service.wait_for_deployment(show_output = True)
print(service.state)
print(service.get_logs())

az ml model deploy --ct myaks -m mymodel:1 -n myservice --ic inferenceconfig.json --dc deploymentconfig.json

{
    "computeType": "aks",
    "autoScaler":
    {
        "autoscaleEnabled": true,
        "minReplicas": 1,
        "maxReplicas": 3,
        "refreshPeriodInSeconds": 1,
        "targetUtilization": 70
    },
    "dataCollection":
    {
        "storageEnabled": true
    },
    "authEnabled": true,
    "containerResourceRequirements":
    {
        "cpu": 0.5,
        "memoryInGB": 1.0
    }
}

自動スケーリング

適用対象:Azure Machine Learning SDK v1 for Python

Azure Machine Learning モデルのデプロイの自動スケーリングを処理するコンポーネントは、azureml-fe というスマート要求ルーターです。 すべての推論要求がそれを通過するため、そこにはデプロイされたモデルを自動的にスケーリングするために必要なデータがあります。

自動スケーリングは、AKS Web サービスの autoscale_target_utilization、autoscale_min_replicas、autoscale_max_replicas を設定して制御できます。 自動スケーリングを有効にする方法の例を次に示します。

aks_config = AksWebservice.deploy_configuration(autoscale_enabled=True, 
                                                autoscale_target_utilization=30,
                                                autoscale_min_replicas=1,
                                                autoscale_max_replicas=4)

スケールアップまたはスケールダウンの決定は、現在のコンテナー レプリカの使用率に基づきます。 ビジー状態 (要求を処理中) のレプリカの数を現在のレプリカの総数で除算した数が、現在の使用率です。 この数が autoscale_target_utilization を超えると、さらにレプリカが作成されます。 これが下回ると、レプリカが減少します。 既定では、ターゲット使用率は 70% です。

レプリカの追加は、集中的かつ迅速に決定されます (約 1 秒)。 レプリカの削除は慎重に決定されます (約 1 分)。

必要なレプリカの数は、次のコードを使用して計算できます。

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)

autoscale_target_utilization、autoscale_max_replicas、autoscale_min_replicas の設定について詳しくは、AksWebservice モジュールのリファレンスをご覧ください。

Web サービス認証

Azure Kubernetes Service にデプロイする場合、キーベース の認証は既定で有効になります。 "トークンベース" の認証を有効にすることもできます。 トークンベースの認証では、クライアントが Microsoft Entra アカウントを使って認証トークンを要求する必要があります。これは、デプロイされたサービスへの要求を行うために使われます。

認証を "無効" にするには、デプロイ構成の作成時に auth_enabled=False パラメーターを設定します。 次の例では、SDK を使用して認証を無効にします。

deployment_config = AksWebservice.deploy_configuration(cpu_cores=1, memory_gb=1, auth_enabled=False)

クライアント アプリケーションからの認証については、「Web サービスとしてデプロイされた Azure Machine Learning モデルを使用する」をご覧ください。

キーによる認証

キー認証が有効になっている場合は、get_keys メソッドを使って、プライマリとセカンダリの認証キーを取得できます。

primary, secondary = service.get_keys()
print(primary)

トークンによる認証

トークン認証を有効にするには、デプロイの作成時や更新時に token_auth_enabled=True パラメーターを設定します。 次の例では、SDK を使用してトークン認証を有効にします。

deployment_config = AksWebservice.deploy_configuration(cpu_cores=1, memory_gb=1, token_auth_enabled=True)

トークン認証が有効になっている場合は、 get_token メソッドを使用して JWT とそのトークンの有効期限を取得できます。

token, refresh_by = service.get_token()
print(token)

脆弱性のスキャン

Microsoft Defender for Cloud では、統合されたセキュリティ管理と高度な脅威に対する保護がハイブリッド クラウド ワークロード全体に提供されます。 ユーザーは、Microsoft Defender for Cloud にリソースのスキャンを許可し、その推奨事項に従う必要があります。 詳しくは、Microsoft Defender for Containers でのコンテナーのセキュリティに関する記事をご覧ください。

関連コンテンツ

• Kubernetes 認可に Azure ロールベースのアクセス制御を使用する
• 仮想ネットワークを使用して Azure Machine Learning 推論環境をセキュリティで保護する
• カスタム コンテナーを使用してモデルをオンライン エンドポイントにデプロイする
• リモートでのモデル デプロイのトラブルシューティング
• デプロイされた Web サービスを更新する
• TLS を使用して Azure Machine Learning による Web サービスをセキュリティで保護する
• Web サービスとしてデプロイされた Azure Machine Learning モデルを使用する
• ML Web サービス エンドポイントからのデータを監視および収集する
• 実稼働環境のモデルからデータを収集する