リアルタイムの推論のためのオンライン エンドポイントとデプロイ

適用対象:Azure CLI ml extension v2 (現行)Python SDK azure-ai-ml v2 (現行)

Azure Machine Learning では、"オンライン エンドポイント" にデプロイされたモデルを使って、データに対してリアルタイムの推論を実行できます。 推論とは、機械学習モデルに新しい入力データを適用して出力を生成するプロセスです。 通常、これらの出力は "予測" と呼ばれますが、推論を使うと、分類やクラスタリングなどの他の機械学習タスク用の出力を生成できます。

オンライン エンドポイント

オンライン エンドポイントを使うと、HTTP プロトコルの下で予測を返すことができるモデルが Web サーバーにデプロイされます。 オンライン エンドポイントを使用して、同期型低遅延要求のリアルタイム推論用のモデルを運用化します。 次の場合に使用することをお勧めします。

  • 低遅延の要件がある
  • モデルが比較的短時間で要求に応答できる
  • モデルの入力が要求の HTTP ペイロードに適合している
  • 要求の数に関してスケールアップする必要がある

エンドポイントを定義するには、以下を指定する必要があります。

  • エンドポイント名: この名前は、Azure リージョン内で一意である必要があります。 名前付けルールの詳細については、エンドポイントの制限に関する記事を参照してください。
  • 認証モード: エンドポイントに対して、キーベースの認証モードと Azure Machine Learning トークンベースの認証モードのいずれかを選ぶことができます。 キーには有効期限がありませんが、トークンには有効期限があります。 認証の詳細については、オンライン エンドポイントの認証に関する記事を参照してください。

Azure Machine Learning は、ターンキー方式での ML モデルのデプロイにマネージド オンライン エンドポイントを使うことができるため便利です。 これは、Azure Machine Learning でオンライン エンドポイントを使うための "お勧め" の方法です。 マネージド オンライン エンドポイントは、スケーラブルでフル マネージドの方法で Azure の強力な CPU および GPU マシンと動作します。 また、これらのエンドポイントを使うと、モデルの提供、スケーリング、セキュリティ保護、監視が行われ、基になるインフラストラクチャの設定と管理のオーバーヘッドがなくなります。 マネージド オンライン エンドポイントにデプロイする方法については、オンライン エンドポイントを使った ML モデルのデプロイに関する記事を参照してください。

ACI または AKS(v1) 経由のマネージド オンライン エンドポイントを選ぶ理由

マネージド オンライン エンドポイントを使うのは、Azure Machine Learning でオンライン エンドポイントを使うための "お勧め" の方法です。 次の表は、Azure Machine Learning SDK/CLI v1 ソリューション (ACI と AKS(v1)) と比較した、マネージド オンライン エンドポイントの主な属性を示しています。

属性 マネージド オンライン エンドポイント (v2) ACI または AKS(v1)
ネットワークのセキュリティと分離 クイックトグルを使った受信/送信制御が簡単 仮想ネットワークがサポートされていないか、複雑な手動構成が必要
管理されたサービス - フル マネージドのコンピューティングのプロビジョニングとスケーリング
- データ流出防止のためのネットワーク構成
- ホスト OS のアップグレード、インプレース更新の制御されたロールアウト
- スケーリングは v1 限定
- ネットワーク構成またはアップグレードはユーザーによる管理が必要
エンドポイントとデプロイの概念 エンドポイントとデプロイの区別があるため、モデルの安全なロールアウトなど、複雑なシナリオに対応可能 エンドポイントの概念なし
診断および監視 - Docker と Visual Studio Code でローカル エンドポイントのデバッグが可能
- デプロイ間で比較するための、グラフやクエリを使った高度なメトリックとログ分析
- コストの内訳はデプロイ レベルまで可能
ローカル デバッグが複雑
スケーラビリティ 無制限でエラスティックな自動スケーリング - ACI が非スケーラブル
- AKS (v1) はクラスター内スケールのみをサポート。スケーラビリティ構成が必要
エンタープライズ対応 プライベート リンク、カスタマー マネージド キー、Microsoft Entra ID、クォータ管理、課金の統合、SLA サポートされていません
高度な ML 機能 - モデル データ収集
- モデルの監視
- チャンピオン チャレンジャー モデル、安全なロールアウト、トラフィック ミラーリング
- 責任ある AI の拡張性
サポートされていません

上記以外では、モデルのデプロイやエンドポイントの提供に Kubernetes を利用しており、インフラストラクチャ要件の管理に慣れている場合は、"Kubernetes オンライン エンドポイント" を使うことができます。 これらのエンドポイントでは、CPU や GPU を使って、完全に構成および管理された Kubernetes クラスターでどこでもモデルのデプロイやオンライン エンドポイントの提供を行うことができます。

AKS(v2) 経由のマネージド オンライン エンドポイントを選ぶ理由

マネージド オンライン エンドポイントを使うと、デプロイ プロセスを効率化し、Kubernetes オンライン エンドポイントに対して次の利点を得ることができます。

  • マネージド インフラストラクチャ

    • コンピューティングを自動的にプロビジョニングし、モデルをホストします (VM の種類とスケールの設定のみ指定する必要があります)
    • 基になるホスト OS イメージを自動的に更新しパッチを適用する
    • システム障害が発生した場合にノードの自動回復を行います
  • 監視とログ

    Screenshot showing Azure Monitor graph of endpoint latency.

  • コストを表示する

    Screenshot cost chart of an endpoint and deployment.

    Note

    マネージド オンライン エンドポイントは、Azure Machine Learning コンピューティングに基づいています。 マネージド オンライン エンドポイントを使用する場合は、コンピューティングとネットワークの料金を支払います。 追加料金は発生しません。 価格の詳細については、Azure の料金計算ツールに関するページを参照してください。

    Azure Machine Learning 仮想ネットワークを使ってマネージド オンライン エンドポイントからの送信トラフィックをセキュリティで保護する場合は、マネージド仮想ネットワークで使われている Azure プライベート リンクと FQDN 送信規則について課金されます。 詳細については、マネージド仮想ネットワークの価格に関する記事を参照してください。

マネージド オンライン エンドポイントと Kubernetes オンライン エンドポイント

次の表は、マネージド オンライン エンドポイントトと Kubernetes オンライン エンドポイントの主な違いを示しています。

マネージド オンライン エンドポイント Kubernetes オンライン エンドポイント (AKS(v2))
推奨されるユーザー マネージド モデル デプロイおよび拡張された MLOps エクスペリエンスを必要とするユーザー Kubernetes を使用し、インフラストラクチャの要件を自己管理できるユーザー
ノード プロビジョニング マネージド コンピューティングのプロビジョニング、更新、削除 ユーザーの責任での対応
ノード メンテナンス マネージド ホスト OS イメージの更新、およびセキュリティ強化 ユーザーの責任での対応
クラスターのサイズ設定 (スケーリング) マネージド 手動および自動スケーリング、追加のノード プロビジョニングをサポート 手動と自動スケーリング、固定クラスター境界内のレプリカ数のスケーリングをサポート
コンピューティングの種類 サービスによって管理 カスタマー マネージド Kubernetes クラスター (Kubernetes)
管理対象 ID サポートされています サポートされています
仮想ネットワーク (VNET) マネージド ネットワーク分離を介してサポート ユーザーの責任での対応
追加設定なしの監視およびログ Azure Monitor と Log Analytics を利用 (エンドポイントとデプロイの主要なメトリックとログ テーブルを含む) ユーザーの責任での対応
Application Insights のログ (レガシ) サポートされています サポートされています
コストを表示する エンドポイントまたはデプロイ レベルに関する詳細 クラスター レベル
適用されるコスト デプロイに割り当てられた VM クラスターに割り当てられた VM
ミラー化されたトラフィック サポートされています サポートされていない
コードなしのデプロイ サポートされている (MLflowTriton の各モデル) サポートされている (MLflowTriton の各モデル)

オンライン デプロイ

デプロイは、実際の推論を行うモデルをホストするのに必要な一連のリソースとコンピューティングです。 1 つのエンドポイントに、異なる構成を持つ複数のデプロイを含めることができます。 このセットアップを使うと、デプロイに提示されている "実装の詳細" から、エンドポイントによって提示されている "インターフェイスを切り離す" ことができます。 オンライン エンドポイントには、エンドポイント内の特定のデプロイに要求を転送できるルーティング メカニズムがあります。

次の図は、"blue" と "green" の 2 つのデプロイを持つオンライン エンドポイントを示しています。 Blue デプロイでは、CPU SKU を持つ VM が使用され、モデルのバージョン 1 が実行されます。 green デプロイでは、GPU SKU を持つ VM が使用され、モデルのバージョン 2 が実行されます。 エンドポイントは着信トラフィックの 90% を blue デプロイにルーティングするように構成されていますが、残りの 10% は green デプロイが受け取ります。

Diagram showing an endpoint splitting traffic to two deployments.

次の表は、デプロイの主な属性について説明しています。

属性 内容
名前 デプロイの名前。
エンドポイント名 デプロイを作成するエンドポイントの名前。
モデル デプロイに使用するモデル。 この値は、ワークスペース内の既存のバージョン管理されたモデルへの参照またはインライン モデルの仕様のいずれかです。
コード パス モデルのスコアリングに使用されるすべての Python ソース コードが格納されている、ローカル開発環境上のディレクトリへのパス。 入れ子になったディレクトリとパッケージを使用できます。
スコアリング スクリプト ソース コード ディレクトリ内のスコアリング ファイルへの相対パス。 この Python コードには、init() 関数と run() 関数が含まれている必要があります。 init() 関数は、モデルの作成または更新後に呼び出されます (たとえば、モデルをメモリにキャッシュするために使用できます)。 run() 関数は、実際のスコアリングおよび予測を実行するために、エンドポイントが呼び出されるたびに呼び出されます。
環境 モデルとコードをホスティングする環境。 この値は、ワークスペース内の既存のバージョン管理された環境への参照、またはインライン環境仕様のいずれかになります。 注: Microsoft は、既知のセキュリティ脆弱性に対して、定期的にベース イメージにパッチを適用しています。 パッチが適用されているイメージを使うには、エンドポイントを再デプロイする必要があります。 独自のイメージを指定する場合は、その更新も行う必要があります。 詳細については、「イメージの修正」を参照してください。
インスタンスの種類 デプロイに使用する VM サイズ。 サポートされているサイズの一覧については、マネージド オンライン エンドポイント SKU の一覧に関するページを参照してください。
インスタンス数 デプロイに使用するインスタンスの数。 想定されるワークロードに基づく値を指定します。 高可用性を実現するために、この値を少なくとも 3 に設定することをお勧めします。 アップグレードを実行するために 20% 余分に予約されています。 詳細については、「デプロイのための仮想マシン クォータの割り当て」を参照してください。

CLI、SDK、スタジオ、ARM テンプレートを使ってオンライン エンドポイントをデプロイする方法については、オンライン エンドポイントを使った ML モデルのデプロイに関する記事を参照してください。

プログラマーと非プログラマーのデプロイ

Azure Machine Learning は、"コードなしのデプロイ"、"ローコード デプロイ"、"Bring Your Own Certificate (BYOC) デプロイ" のオプションを提供しており、プログラマーと非プログラマーのいずれに対しても同様に、オンライン エンドポイントへのモデル デプロイをサポートしています。

  • コードなしのデプロイでは、一般的なフレームワーク (scikit-learn、TensorFlow、PyTorch、ONNX など) に対する推論を、MLflow や Triton を使って追加設定なしで行うことができます。
  • ローコード デプロイでは、デプロイに対して、ML モデルと併せて最小限のコードを指定できます。
  • BYOC デプロイでは、任意のコンテナーを仮想的に使って、オンライン エンドポイントを実行できます。 自動スケーリング、GitOps、デバッグ、安全なロールアウトなど、Azure Machine Learning プラットフォームのあらゆる機能を使って、MLOps パイプラインを管理できます。

次の表は、オンライン デプロイのオプションに関する主な側面を示しています。

コードなし ローコード BYOC
まとめ scikit-learn、TensorFlow、PyTorch、ONNX などの一般的なフレームワークに対して MLflow や Triton を使って追加設定なしで行うことができる推論を使います。 詳細については、「MLflow モデルのオンライン エンドポイントへのデプロイ」を参照してください。 一般的なフレームワークには、安全で公開済みのキュレーションされたイメージを使います。脆弱性に対処するために、2 週間ごとに更新プログラムが実行されます。 ユーザーは、スコアリング スクリプトや Python の依存関係を指定します。 詳細については、「Azure Machine Learning のキュレーションされた環境」を参照してください。 カスタム イメージに対する Azure Machine Learning のサポートを使って、完全なスタックを指定します。 詳細については、「カスタム コンテナーを使用してモデルをオンライン エンドポイントにデプロイする」を参照してください。
カスタム基本イメージ 対応していません。キュレーションされた環境では、デプロイを簡単に行うことができます。 対応している場合と対応していない場合があります。キュレーションされたイメージも、カスタマイズしたイメージも使うことができます。 対応しています。コンテナーの ACR でビルドまたはプッシュできる、アクセス可能なコンテナー イメージの場所 (docker.io、Azure Container Registry (ACR)、Microsoft Container Registry (MCR) など) または Dockerfile を使います。
カスタムの依存関係 対応していません。キュレーションされた環境では、デプロイを簡単に行うことができます。 対応しています。モデルが実行されている Azure Machine Learning 環境を使います (Conda 依存関係を持つ Docker イメージ、または dockerfile)。 対応しています。これは、コンテナー イメージに含まれます。
カスタム コード 対応していません。簡単にデプロイできるように、スコアリング スクリプトが自動生成されます。 対応しています。スコアリング スクリプトをお使いください。 対応しています。これは、コンテナー イメージに含まれます。

Note

AutoML を実行すると、ユーザーに対してスコアリング スクリプトと依存関係が自動的に作成されるため、追加のコードを作成しなくても任意の AutoML モデルをデプロイできます (コードなしのデプロイの場合)。または、自動生成されたスクリプトをビジネス ニーズに合わせて変更することができます (ローコード デプロイの場合)。AutoML モデルを使ってデプロイする方法については、オンライン エンドポイントを使った AutoML モデルのデプロイに関する記事を参照してください。

オンライン エンドポイントのデバッグ

Azure Machine Learning には、オンライン エンドポイントをローカルでデバッグする方法や、コンテナー ログを使ってデバッグする方法など、さまざまな方法が用意されています。

Azure Machine Learning 推論 HTTP サーバーを使ったローカル デバッグ

Azure Machine Learning 推論 HTTP サーバーを使うと、スコアリング スクリプトをローカルでデバッグできます。 この HTTP サーバーは、スコアリング関数を HTTP エンドポイントとして公開し、Flask サーバー コードと依存関係を単一のパッケージにラップしている Python パッケージです。 これは、Azure Machine Learning でモデルをデプロイする際に使用する推論用の事前構築済み Docker イメージに含まれています。 このパッケージのみを使用すると、運用環境用にローカルにモデルをデプロイできます。また、ローカル開発環境でスコアリング (エントリ) スクリプトを簡単に検証することもできます。 スコアリング スクリプトに問題がある場合、サーバーからエラーとそのエラーが発生した場所が返されます。 Visual Studio Code を使って、Azure Machine Learning 推論 HTTP サーバーでデバッグすることもできます。

HTTP サーバーを使ったデバッグの詳細については、「Azure Machine Learning 推論 HTTP サーバーを使用したスコアリング スクリプトのデバッグ (プレビュー)」を参照してください。

ローカル デバッグ

ローカル デバッグの場合は、ローカル デプロイが必要です。つまり、ローカル Docker 環境にデプロイされているモデルです。 このローカル デプロイは、クラウドにデプロイする前のテストやデバッグに使うことができます。 ローカルにデプロイするには、Docker エンジンをインストールして実行する必要があります。 その後、Azure Machine Learning で、Azure Machine Learning イメージを模倣したローカル Docker イメージが作成されます。 Azure Machine Learning では、ユーザーに代わって、ローカルでデプロイを構築して実行し、迅速な反復処理用にイメージをキャッシュします。

通常、ローカル デバッグの手順は次のとおりです。

  • ローカル デプロイが成功したかどうかの確認
  • 推論に向けたローカル エンドポイントの呼び出し
  • 呼び出し操作の出力のログの確認

ローカル デバッグの詳細については、「ローカル エンドポイントを使用してデプロイとデバッグをローカルで行う」を参照してください。

Visual Studio Code を使ったローカル デバッグ (プレビュー)

重要

現在、この機能はパブリック プレビュー段階にあります。 このプレビュー バージョンはサービス レベル アグリーメントなしで提供されており、運用環境のワークロードに使用することは推奨されません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。

詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。

ローカル デバッグと同様に、まず Docker エンジンをインストールして実行してから、ローカル Docker 環境にモデルをデプロイする必要があります。 ローカル デプロイを実行すると、Azure Machine Learning のローカル エンドポイントでは、Docker と Visual Studio Code の開発コンテナーを使ったローカルのデバッグ環境の構築と構成が行われます。 開発コンテナーでは、Docker コンテナー内から、対話型デバッグなど、Visual Studio Code の機能を利用できます。

VS Code でのオンライン エンドポイントの対話型デバッグの詳細については、「Visual Studio Code を使用してオンライン エンドポイントをローカルでデバッグする」を参照してください。

コンテナー ログを使ったデバッグ

デプロイでは、モデルがデプロイされている VM に直接アクセスすることはできません。 ただし、VM で実行されている一部のコンテナーからログを取得することはできます。 ログを取得できるコンテナーには、次の 2 種類があります。

  • 推論サーバー: ログには、(推論サーバーからの) コンソール ログが含まれます。これには、スコアリング スクリプト (score.py コード) からの出力/ログ記録関数の出力が含まれます。
  • ストレージ初期化子: ログには、コードとモデル データがコンテナーに正常にダウンロードされたかどうかに関する情報が含まれます。 推論サーバー コンテナーの実行が開始される前に、コンテナーが実行されます。

コンテナー ログを使ったデバッグの詳細については、「コンテナー ログを取得する」を参照してください。

オンライン デプロイへのトラフィック ルーティングとミラーリング

1 つのオンライン エンドポイントに複数のデプロイを含めることができることを思い出してください。 エンドポイントで受信トラフィック (または要求) を受け取ると、ネイティブの blue/green デプロイ戦略で使われているように、トラフィックの割合を各デプロイにルーティングできます。 また、あるデプロイから別のデプロイへのトラフィックをミラーリング (またはコピー) することもできます。これは、トラフィック ミラーリングまたはシャドウイングともいいます。

blue/green デプロイのトラフィック ルーティング

blue/green デプロイは、新しいデプロイ (green デプロイ) を完全にロールアウトする前に、小さなサブセットのユーザーまたは要求にロールアウトできるデプロイ戦略です。 エンドポイントでは、負荷分散を実装して、特定の割合のトラフィックを各デプロイに割り当てることができます。すべてのデプロイに対して、合計最大 100% が割り当てられます。

ヒント

要求では、azureml-model-deployment の HTTP ヘッダーを含めることによって、構成されたトラフィックの負荷分散をバイパスできます。 ヘッダーの値を、要求のルーティング先のデプロイの名前に設定します。

次の図は、blue デプロイと green デプロイの間のトラフィックの割り当てに対する Azure Machine Learning スタジオでの設定を示しています。

Screenshot showing slider interface to set traffic allocation between deployments.

このトラフィック割り当てでは、次の図に示すように、トラフィックがルーティングされます。トラフィックの 10% が green デプロイに、トラフィックの 90% が blue デプロイに送信されます。

Diagram showing an endpoint splitting traffic to two deployments.

オンライン デプロイへのトラフィック ミラーリング

エンドポイントでは、あるデプロイから別のデプロイへのトラフィックをミラーリング (またはコピー) することもできます。 トラフィック ミラーリング (シャドウ テストともいいます) は、顧客が既存のデプロイから受け取る結果に影響を与えることなく、実稼働トラフィックで新しいデプロイをテストする場合に便利です。 たとえば、blue/green デプロイを実装しており、トラフィックの 100% が blue デプロイにルーティングされ、10% が green デプロイに "ミラーリング" されている場合、green デプロイにミラーリングされたトラフィックの結果はクライアントに返されませんが、メトリックとログが記録されます。

Diagram showing an endpoint mirroring traffic to a deployment.

トラフィック ミラーリングを使う方法については、オンライン エンドポイントの安全なロールアウトに関する記事を参照してください。

Azure Machine Learning でのオンライン エンドポイントのその他の機能

認証と暗号化

  • 認証: キーと Azure Machine Learning トークン
  • マネージド ID: ユーザー割り当ておよびシステム割り当て
  • エンドポイント呼び出しのための既定の SSL

自動スケール

自動スケールでは、アプリケーションの負荷を処理するために適切な量のリソースが自動的に実行されます。 マネージド エンドポイントは、Azure Monitor 自動スケーリング機能との統合によって、自動スケールをサポートします。 メトリックベースのスケーリング (たとえば、CPU 使用率 >70%)、スケジュールに基づくスケーリング (たとえば、営業時間のピーク時のルールのスケーリング)、またはその組み合わせを構成できます。

Screenshot showing that autoscale flexibly provides between min and max instances, depending on rules.

自動スケーリングを構成する方法については、オンライン エンドポイントの自動スケーリング方法に関する記事を参照してください。

マネージド ネットワーク分離

ML モデルをマネージド オンライン エンドポイントにデプロイする場合は、プライベート エンドポイントを使ってオンライン エンドポイントとの通信をセキュリティで保護することができます。

ワークスペースやその他のサービスでの受信スコアリング要求と送信通信のセキュリティを個別に構成できます。 受信通信では、Azure Machine Learning ワークスペースのプライベート エンドポイントが使用されます。 送信通信では、ワークスペースのマネージド仮想ネットワーク用に作成されたプライベート エンドポイントが使用されます。

詳細については、マネージド オンライン エンドポイントによるネットワーク分離に関するページを参照してください。

オンライン エンドポイントとデプロイの監視

Azure Machine Learning エンドポイントの監視は、Azure Monitor との統合を行うと可能になります。 この統合を行うと、グラフでのメトリックの表示、アラートの構成、ログ テーブルからのクエリの実行を行うことができると同時に、Application Insights を使ってユーザー コンテナーからイベントを分析することができます。

  • メトリック: Azure Monitor を使って、要求の待機時間など、さまざまなエンドポイント メトリックを追跡して、デプロイまたは状態レベルにドリルダウンします。 また、CPU や GPU の使用率など、デプロイ レベルのメトリックを追跡し、インスタンス レベルにドリルダウンすることもできます。 Azure Monitor では、グラフ内のこれらのメトリックを追跡し、ダッシュボードとアラートを設定して、さらに分析を行うことができます。

  • ログ: Kusto クエリ構文を使ってログに対してクエリを実行できる Log Analytics ワークスペースにメトリックを送信します。 ストレージ アカウントや Event Hubs にメトリックを送信して、さらに処理を行うこともできます。 また、オンライン エンドポイント関連のイベント、トラフィック、コンテナー ログに専用のログ テーブルを使うことができます。 Kusto クエリを使うと、複数のテーブルが結合された複雑な分析を行うことができます。

  • Application Insights: キュレーションされた環境には Application Insights との統合が含まれています。これは、オンライン デプロイを作成するときに有効または無効にすることができます。 組み込みのメトリックとログは Application insights に送信され、ライブ メトリック、トランザクション検索、エラー、パフォーマンスなどの組み込み機能を使って、さらに分析を行うことができます。

監視の詳細については、「オンライン エンドポイントを監視する」を参照してください。

オンライン デプロイでのシークレットの挿入 (プレビュー)

オンライン デプロイのコンテキストでのシークレットの挿入は、シークレット ストアからシークレット (API キーなど) を取得し、オンライン デプロイ内で実行されているユーザー コンテナーにそれを挿入するプロセスです。 シークレットは、最終的には環境変数を介してアクセスできるようになります。これにより、スコアリング スクリプトを実行する推論サーバー、または BYOC (Bring Your Own Container) デプロイ アプローチを使ってユーザーが導入する推論スタックで、安全な方法で使用できます。

シークレットを挿入する方法は 2 つあります。 マネージド ID を使用してシークレットを自分で挿入するか、シークレット挿入機能を使用することができます。 シークレットを挿入する方法の詳細については、「オンライン エンドポイントでのシークレットの挿入 (プレビュー)」を参照してください。

次のステップ