リアルタイム推論のためのオンライン エンドポイントのデプロイ
適用対象:
Azure CLI ml extension v2 (現行)Python SDK azure-ai-ml v2 (現行)
この記事では、Azure Machine Learning でのリアルタイム推論のためのオンライン エンドポイントについて説明します。 推論とは、機械学習モデルに新しい入力データを適用して出力を生成するプロセスです。 Azure Machine Learning では、"オンライン エンドポイント" にデプロイされたモデルを使って、データに対してリアルタイムの推論を実行できます。 通常、これらの出力は "予測" と呼ばれますが、推論を使うと、分類やクラスタリングなどの他の機械学習タスク用の出力を生成できます。
オンライン エンドポイント
オンライン エンドポイントを使うと、HTTP プロトコルの下で予測を返すことができるモデルが Web サーバーにデプロイされます。 オンライン エンドポイントは、同期された低遅延要求のリアルタイム推論用のモデルを運用化することができ、次の場合に最適です。
- 低遅延の要件がある。
- モデルが比較的短時間で要求に応答できる。
- モデルの入力が要求の HTTP ペイロードに適合する。
- 要求の数をスケールアップする必要がある。
エンドポイントを定義するには、以下を指定する必要があります。
- エンドポイント名。 この名前は Azure リージョン内で一意である必要があります。 その他の名前付け要件については、「Azure Machine Learning オンライン エンドポイントとバッチ エンドポイント」を参照してください。
- 認証モード。 エンドポイントに対して、キーベースの認証モード、Azure Machine Learning トークンベースの認証モード、または Microsoft Entra トークンベースの認証の中から選ぶことができます。 認証の詳細については、オンライン エンドポイントのクライアントを認証するに関する記事を参照してください。
マネージド オンライン エンドポイント
マネージド オンライン エンドポイントを使用すると、便利なターンキー方式で機械学習モデルがデプロイされます。これは、Azure Machine Learning オンライン エンドポイントを使用するための推奨される方法です。 マネージド オンライン エンドポイントは、スケーラブルでフル マネージドの方法で Azure の強力な CPU および GPU マシンと動作します。
基になるインフラストラクチャの設定と管理のオーバーヘッドをなくすために、モデルの提供、スケーリング、セキュリティ保護、監視もこれらのエンドポイントで行われます。 マネージド オンライン エンドポイントを定義する方法については、「エンドポイントを定義する」を参照してください。
マネージド オンライン エンドポイントと Azure Container Instances または Azure Kubernetes Service (AKS) v1
マネージド オンライン エンドポイントは、Azure Machine Learning でオンライン エンドポイントを使うためのお勧めの方法です。 次の表は、Azure Container Instances および Azure Kubernetes Service (AKS) v1 ソリューションと比較した、マネージド オンライン エンドポイントの主な属性を示しています。
| 属性 | マネージド オンライン エンドポイント (v2) | Container Instances または AKS (v1) |
|---|---|---|
| ネットワークのセキュリティと分離 | クイックトグルを使った受信/送信制御が簡単 | 仮想ネットワークがサポートされていないか、複雑な手動構成が必要 |
| 管理されたサービス | • フル マネージドのコンピューティングのプロビジョニングとスケーリング • データ流出防止のためのネットワーク構成 • ホスト OS のアップグレード、インプレース更新の制御されたロールアウト |
• スケーリングが制限される • ユーザーがネットワーク構成またはアップグレードを管理する必要がある |
| エンドポイントとデプロイの概念 | エンドポイントとデプロイの区別があるため、モデルの安全なロールアウトなど、複雑なシナリオに対応可能 | エンドポイントの概念なし |
| 診断および監視 | • Docker と Visual Studio Code でローカル エンドポイントのデバッグが可能 • デプロイ間で比較するための、グラフやクエリを使った高度なメトリックとログ分析 • コストの内訳はデプロイ レベルまで可能 |
ローカル デバッグが複雑 |
| スケーラビリティ | 無制限でエラスティックな自動スケーリング | • Container Instances はスケーラブルでない • AKS v1 はクラスター内スケーリングのみをサポートし、スケーラビリティ構成が必要 |
| エンタープライズ対応 | プライベート リンク、カスタマー マネージド キー、Microsoft Entra ID、クォータ管理、課金の統合、サービス レベル アグリーメント (SLA) | サポートされていません |
| 高度な ML 機能 | • モデル データ収集 • モデルの監視 • チャンピオン チャレンジャー モデル、安全なロールアウト、トラフィック ミラーリング • 責任ある AI の拡張性 |
サポートされていません |
マネージド オンライン エンドポイントと Kubernetes オンライン エンドポイント
モデルのデプロイやエンドポイントの提供に Kubernetes を利用しており、インフラストラクチャ要件の管理に慣れている場合は、"Kubernetes オンライン エンドポイント" を使うことができます。 これらのエンドポイントでは、CPU や GPU を使って、完全に構成されたマネージド Kubernetes クラスターでどこでもモデルのデプロイやオンライン エンドポイントの提供を行うことができます。
マネージド オンライン エンドポイントを使うと、デプロイ プロセスを効率化し、Kubernetes オンライン エンドポイントに対して次の利点を得ることができます。
自動インフラストラクチャ管理
- コンピューティングをプロビジョニングし、モデルをホストします。 仮想マシン (VM) の種類とスケール設定を指定するだけです。
- 基になるホスト OS イメージを更新し、パッチを適用します。
- システム障害が発生した場合にノードの回復を実行します。
監視とログ
- Azure Monitor とのネイティブ統合を使用して、モデルの可用性、パフォーマンス、SLA を監視できます。
- ログと、Log Analytics とのネイティブ統合を使用した、デプロイのデバッグの容易さ。
コスト分析ビューでは、エンドポイントとデプロイのレベルでコストを監視できます。
注意
マネージド オンライン エンドポイントは、Azure Machine Learning コンピューティングに基づいています。 マネージド オンライン エンドポイントを使用する場合は、コンピューティングとネットワークの料金を支払います。 追加料金は発生しません。 価格の詳細については、Azure の料金計算ツールに関するページを参照してください。
Azure Machine Learning 仮想ネットワークを使ってマネージド オンライン エンドポイントからの送信トラフィックをセキュリティで保護する場合は、マネージド仮想ネットワークで使う Azure プライベート リンクと完全修飾ドメイン名 (FQDN) アウトバウンド規則について課金されます。 詳細については、マネージド仮想ネットワークの価格に関する記事を参照してください。
次の表は、マネージド オンライン エンドポイントトと Kubernetes オンライン エンドポイントの主な違いを示しています。
| マネージド オンライン エンドポイント | Kubernetes オンライン エンドポイント (AKS v2) | |
|---|---|---|
| 推奨されるユーザー | マネージド モデル デプロイおよび拡張された MLOps エクスペリエンスを必要とするユーザー | Kubernetes を使用し、インフラストラクチャの要件を自己管理できるユーザー |
| ノード プロビジョニング | マネージド コンピューティングのプロビジョニング、更新、削除 | ユーザーの責任での対応 |
| ノード メンテナンス | マネージド ホスト OS イメージの更新とセキュリティ強化 | ユーザーの責任での対応 |
| クラスターのサイズ設定 (スケーリング) | マネージドの手動および自動スケーリング、追加のノード プロビジョニングをサポート | 手動と自動スケーリング、固定クラスター境界内のレプリカ数のスケーリングをサポート |
| コンピューティングの種類 | サービスによって管理 | カスタマー マネージド Kubernetes クラスター |
| マネージド ID | サポートされています | サポートされています |
| 仮想ネットワーク | マネージド ネットワーク分離を介してサポート | ユーザーの責任での対応 |
| 追加設定なしの監視およびログ | Azure Monitor と Log Analytics を利用 (エンドポイントとデプロイの主要なメトリックとログ テーブルを含む) | ユーザーの責任での対応 |
| Application Insights のログ (レガシ) | サポートされています | サポートされています |
| コスト ビュー | エンドポイントまたはデプロイ レベルに関する詳細 | クラスター レベル |
| コスト適用対象 | デプロイに割り当てられた仮想マシン (VM) | クラスターに割り当てられた VM |
| ミラー化されたトラフィック | サポートされています | サポートされていない |
| コードなしのデプロイ | MLflow と Triton の各モデルをサポート | MLflow と Triton の各モデルをサポート |
オンライン デプロイ
"デプロイ" は、推論を行うモデルをホストするのに必要な一連のリソースとコンピューティングです。 1 つのエンドポイントに、異なる構成を持つ複数のデプロイを含めることができます。 このセットアップを使うと、デプロイに提示されている "実装の詳細" から、エンドポイントによって提示されている "インターフェイスを切り離す" ことができます。 オンライン エンドポイントには、エンドポイント内の特定のデプロイに要求を転送できるルーティング メカニズムがあります。
次の図は、"blue" と "green" の 2 つのデプロイを持つオンライン エンドポイントを示しています。 Blue デプロイでは、CPU SKU を持つ VM が使用され、モデルのバージョン 1 が実行されます。 green デプロイでは、GPU SKU を持つ VM が使用され、モデルのバージョン 2 が実行されます。 エンドポイントは着信トラフィックの 90% を blue デプロイにルーティングするように構成されていますが、残りの 10% は green デプロイが受け取ります。
モデルをデプロイするには、次が必要です。
モデル ファイル (または、ワークスペースに既に登録されているモデルの名前とバージョン)。
特定の入力要求でモデルを実行するスコアリング スクリプト コード。
スコアリング スクリプトは、デプロイされた Web サービスに送信されたデータを受け取り、それをモデルに渡します。 その後、スクリプトはモデルを実行して、その応答をクライアントに返します。 スコアリング スクリプトはモデルに固有のものであり、モデルが入力として期待し、出力として返すデータを理解する必要があります。
モデルを実行するための環境。 この環境には、Conda 依存関係がある Docker イメージか、または Dockerfile のいずれかを使用できます。
インスタンスの種類とスケーリング キャパシティを指定するための設定。
Azure CLI、Python SDK、Azure Machine Learning スタジオ、または ARM テンプレートを使用してオンライン エンドポイントをデプロイする方法については、オンライン エンドポイントを使用した機械学習モデルのデプロイに関するページを参照してください。
デプロイの主な属性
次の表は、デプロイの主な属性について説明しています。
| 属性 | 内容 |
|---|---|
| 名前 | デプロイの名前。 |
| エンドポイント名 | デプロイを作成するエンドポイントの名前。 |
| モデル | デプロイに使用するモデル。 この値は、ワークスペース内の既存のバージョン管理されたモデルへの参照またはインライン モデルの仕様のいずれかです。 モデルへのパスを追跡および指定する方法について詳しくは、「オンライン エンドポイントで使用するためにデプロイするモデルを指定する」をご覧ください。 |
| コード パス | モデルのスコアリングに使用されるすべての Python ソース コードが格納されている、ローカル開発環境上のディレクトリへのパス。 入れ子になったディレクトリとパッケージを使用できます。 |
| スコアリング スクリプト | ソース コード ディレクトリ内のスコアリング ファイルへの相対パス。 この Python コードには、init() 関数と run() 関数が含まれている必要があります。 init() 関数は、モデルが作成または更新された後に呼び出され、たとえばモデルをメモリにキャッシュします。 run() 関数は、実際のスコアリングおよび予測を実行するために、エンドポイントが呼び出されるたびに呼び出されます。 |
| 環境 | モデルとコードをホスティングする環境。 この値は、ワークスペース内の既存のバージョン管理された環境への参照、またはインライン環境仕様のいずれかになります。 |
| インスタンスの種類 | デプロイに使用する VM サイズ。 サポートされているサイズの一覧については、マネージド オンライン エンドポイント SKU の一覧に関するページを参照してください。 |
| インスタンス数 | デプロイに使用するインスタンスの数。 想定されるワークロードに基づく値を指定します。 高可用性を実現するために、この値を少なくとも 3 に設定します。 システムは、アップグレードを実行するために 20% 余分に予約されています。 詳細については、「デプロイのための VM クォータの割り当て」を参照してください。 |
オンライン デプロイに関する注意
デプロイは、環境に定義されているモデルとコンテナー イメージをいつでも参照できます。たとえば、デプロイ インスタンスにセキュリティ修正プログラムやその他の復旧操作を実施するときなどです。 Azure Container Registry で登録済みのモデルまたはコンテナー イメージをデプロイに使用し、後からそのモデルまたはコンテナー イメージを削除した場合、再イメージ化が行われると、これらの資産に依存するデプロイが失敗する可能性があります。 モデルまたはコンテナー イメージを削除した場合は必ず、依存するデプロイを代替モデルまたはコンテナー イメージで再作成または更新してください。
環境で参照されるコンテナー レジストリは、エンドポイント ID に Microsoft Entra 認証と Azure ロールベースのアクセス制御 (RBAC) を介してアクセスする権限がある場合にのみ、プライベートにすることができます。 同じ理由から、Container Registry 以外のプライベート Docker レジストリはサポートされていません。
Microsoft は、既知のセキュリティ脆弱性に対して、定期的にベース イメージにパッチを適用しています。 パッチが適用されたイメージを使うには、エンドポイントを再デプロイする必要があります。 独自のイメージを指定する場合は、その更新も行う必要があります。 詳細については、「イメージの修正」を参照してください。
デプロイのための VM クォータの割り当て
マネージド オンライン エンドポイントの場合、Azure Machine Learning では、一部の VM SKU でアップグレードを実行するためにコンピューティング リソースの 20% が予約されます。 デプロイ内のそれらの VM SKU に対して特定の数のインスタンスを要求する場合は、使用可能な ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU のクォータを確保して、エラーが発生しないようにする必要があります。 たとえば、デプロイで Standard_DS3_v2 VM (4 コアを搭載) の 10 個のインスタンスを要求する場合は、使用可能な 48 コア (12 instances * 4 cores) のクォータが必要です。 この追加のクォータは、OS のアップグレードや VM の復旧などのシステムによって開始される操作用に予約されており、そのような操作が実行されない限りコストは発生しません。
追加のクォータ予約から除外される特定の VM SKU があります。 完全な一覧を表示するには、マネージド オンライン エンドポイント SKU の一覧を参照してください。 使用状況を確認してクォータの増加を要求するには、「Azure portal で使用状況とクォータを表示する」を参照してください。 マネージド オンライン エンドポイントの実行コストを表示するには、「マネージド オンライン エンドポイントのコストを表示する」を参照してください。
共有クォータ プール
Azure Machine Learning には共有クォータ プールが用意されており、さまざまなリージョンのユーザーが、可用性に応じて、そのクォータにアクセスして限られた時間だけテストを実行できます。 スタジオを使ってモデル カタログから Llama-2、Phi、Nemotron、Mistral、Dolly、Deci-DeciLM モデルをマネージド オンライン エンドポイントにデプロイした場合、Azure Machine Learning では、テストを実行できるように、少しの間、その共有クォータ プールにアクセスできます。 共有クォータ プールについて詳しくは、「Azure Machine Learning の共有クォータ」をご覧ください。
共有クォータを使用してモデル カタログから Llama-2、Phi、Nemotron、Mistral、Dolly、Deci-DeciLM の各モデルをデプロイするには、Enterprise Agreement サブスクリプションを持っている必要があります。 オンライン エンドポイントのデプロイに共有クォータを使用する方法の詳細については、「スタジオを使用して基礎モデルをデプロイする方法」を参照してください。
Azure Machine Learning のリソースのクォータと制限の詳細については、「Azure Machine Learning を使用するリソースのクォータと制限の管理と引き上げ」を参照してください。
プログラマーと非プログラマーに対応したデプロイ
Azure Machine Learning は、"コードなしのデプロイ"、"ローコード デプロイ"、"Bring Your Own Container (BYOC) デプロイ" のオプションを提供しており、プログラマーと非プログラマーのいずれに対しても、オンライン エンドポイントへのモデル デプロイをサポートしています。
- コードなしのデプロイでは、一般的なフレームワーク (scikit-learn、TensorFlow、PyTorch、Open Neural Network Exchange (ONNX) など) に対する推論を、MLflow や Triton を使って追加設定なしで行うことができます。
- ローコード デプロイでは、デプロイに対して、機械学習モデルと併せて最小限のコードを指定できます。
- BYOC デプロイでは、事実上あらゆるコンテナーを使ってオンライン エンドポイントを実行できます。 自動スケーリング、GitOps、デバッグ、安全なロールアウトなど、Azure Machine Learning プラットフォームのあらゆる機能を使って、MLOps パイプラインを管理できます。
次の表は、オンライン デプロイのオプションの主な側面を示しています。
| コードなし | ローコード | BYOC | |
|---|---|---|---|
| まとめ | scikit-learn、TensorFlow、PyTorch、ONNX などの一般的なフレームワークに対して MLflow や Triton を使って追加設定なしで行うことができる推論を使います。 詳細については、「MLflow モデルのオンライン エンドポイントへのデプロイ」を参照してください。 | 一般的なフレームワークには、安全で公開済みのキュレーションされたイメージを使います。脆弱性に対処するために、2 週間ごとに更新プログラムが実行されます。 ユーザーは、スコアリング スクリプトや Python の依存関係を指定します。 詳細については、「Azure Machine Learning のキュレーションされた環境」を参照してください。 | カスタム イメージに対する Azure Machine Learning のサポートを使って、完全なスタックを指定します。 詳細については、「カスタム コンテナーを使用してモデルをオンライン エンドポイントにデプロイする」を参照してください。 |
| カスタム基本イメージ | なし。 キュレーションされた環境では、デプロイを容易にするためのベース イメージが提供されます。 | キュレーションされたイメージを使用することも、カスタマイズしたイメージを使用することもできます。 | docker.io、Container Registry、Microsoft アーティファクト レジストリなどのアクセス可能なコンテナー イメージの場所、またはコンテナーの Container Registry でビルドまたはプッシュできる Dockerfile のいずれかを使用します。 |
| カスタムの依存関係 | なし。 キュレーションされた環境では、デプロイを容易にするための依存関係が提供されます。 | モデルが実行されている Azure Machine Learning 環境を使います (Conda 依存関係を含む Docker イメージ、または dockerfile)。 | カスタム依存関係はコンテナー イメージに含まれています。 |
| カスタム コード | なし。 簡単にデプロイできるように、スコアリング スクリプトが自動生成されます。 | 独自のスコアリング スクリプトをお使いください。 | スコアリング スクリプトはコンテナー イメージに含まれています。 |
Note
AutoML 実行では、スコアリング スクリプトと依存関係がユーザーに代わって自動的に作成されます。 コードなしのデプロイでは、他のコードを作成しなくても、任意の AutoML モデルをデプロイできます。 ローコード デプロイでは、自動生成されたスクリプトをビジネス ニーズに合わせて変更できます。 AutoML モデルを使用してデプロイする方法については、「AutoML モデルをオンライン エンドポイントにデプロイする方法」を参照してください。
オンライン エンドポイントのデバッグ
可能であれば、Azure にデプロイする前にローカルでエンドポイントをテスト実行してコードと構成を検証し、デバッグします。 Azure CLI と Python SDK ではローカルのエンドポイントとデプロイがサポートされていますが、Azure Machine Learning スタジオと ARM テンプレートではローカルのエンドポイントまたはデプロイはサポートされていません。
Azure Machine Learning には、オンライン エンドポイントをローカルで、およびコンテナー ログを使ってデバッグするために、次の方法が用意されています。
- Azure Machine Learning 推論 HTTP サーバーを使用したローカル デバッグ
- ローカル エンドポイントを使用したローカル デバッグ
- ローカル エンドポイントと Visual Studio Code を使用したローカル デバッグ
- コンテナー ログを使用したデバッグ
Azure Machine Learning 推論 HTTP サーバーを使用したローカル デバッグ
Azure Machine Learning 推論 HTTP サーバーを使うと、スコアリング スクリプトをローカルでデバッグできます。 この HTTP サーバーは、スコアリング関数を HTTP エンドポイントとして公開し、Flask サーバー コードと依存関係を単一のパッケージにラップしている Python パッケージです。
Azure Machine Learning では、モデルをデプロイするために使用する推論用の事前構築済み Docker イメージに HTTP サーバーが含まれています。 このパッケージだけを使って、運用環境用にローカルにモデルをデプロイすることができ、ローカル開発環境でエントリ スコアリング スクリプトを簡単に検証することもできます。 スコアリング スクリプトに問題がある場合、サーバーからエラーとそのエラーが発生した場所が返されます。 Visual Studio Code を使って、Azure Machine Learning 推論 HTTP サーバーでデバッグすることもできます。
ヒント
Azure Machine Learning 推論 HTTP サーバー Python パッケージを使用して、Docker エンジンなしでスコアリング スクリプトをローカルでデバッグできます。 推論サーバーを使用したデバッグは、ローカル エンドポイントにデプロイする前にスコアリング スクリプトをデバッグするのに役立ちます。これにより、デプロイ コンテナーの構成の影響を受けることなくデバッグできます。
HTTP サーバーを使ったデバッグの詳細については、「Azure Machine Learning 推論 HTTP サーバーを使用してスコアリング スクリプトをデバッグする」を参照してください。
ローカル エンドポイントを使用したローカル デバッグ
ローカル デバッグの場合は、ローカル Docker 環境にデプロイされたモデルが必要です。 このローカル デプロイは、クラウドにデプロイする前のテストやデバッグに使うことができます。
ローカルにデプロイするには、Docker エンジンをインストールして実行している必要があります。 そうすると、Azure Machine Learning によって、オンライン イメージを模倣するローカル Docker イメージが作成されます。 Azure Machine Learning は、自動的にローカルでデプロイを構築して実行し、迅速な反復処理用にイメージをキャッシュします。
ヒント
コンピューターの起動時に Docker エンジンが起動しない場合は、Docker エンジンのトラブルシューティングを行うことができます。 Docker Desktop などのクライアント側ツールを使用し、コンテナーで起こることをデバッグできます。
ローカル デバッグには、通常、次の手順が含まれます。
- 最初に、ローカル デプロイが成功したことを確認します。
- 次に、推論のためにローカル エンドポイントを呼び出します。
- 最後に、
invoke操作の出力ログを確認します。
ローカル エンドポイントには、次の制限があります。
トラフィック ルール、認証、プローブ設定はサポートされていません。
エンドポイントごとにサポートされるデプロイは 1 つのみです。
ローカル モデル ファイル、およびローカルの conda ファイルのみの環境をサポートします。
ローカル デバッグの詳細については、「ローカル エンドポイントを使ってデプロイしローカルでデバッグする」を参照してください。
ローカル エンドポイントと 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 で実行されている次のコンテナーからログを取得できます。
- 推論サーバー コンソール ログには、スコアリング スクリプト score.py コードからの出力またはログ関数の出力が含まれます。
- ストレージ初期化子ログには、コードとモデル データがコンテナーに正常にダウンロードされたかどうかに関する情報が含まれます。 推論サーバー コンテナーの実行が開始される前に、コンテナーが実行されます。
コンテナー ログを使ったデバッグの詳細については、「コンテナー ログを取得する」を参照してください。
オンライン デプロイへのトラフィック ルーティングとミラーリング
1 つのオンライン エンドポイントに複数のデプロイを含めることができます。 エンドポイントで受信トラフィック要求を受け取ると、ネイティブのブルー/グリーン デプロイ戦略の場合と同様に、トラフィックの割合を各デプロイにルーティングできます。 エンドポイントでは、あるデプロイから別のデプロイへのトラフィックをミラーリングまたはコピーすることもできます。これは、トラフィック ミラーリングまたはシャドウイングともいいます。
blue/green デプロイのトラフィック ルーティング
ブルー/グリーン デプロイは、新しいグリーン デプロイを完全にロールアウトする前に、小さなサブセットのユーザーまたは要求にロールアウトできるデプロイ戦略です。 エンドポイントでは、負荷分散を実装して、特定の割合のトラフィックを各デプロイに割り当てることができます。すべてのデプロイに対して、合計最大 100% が割り当てられます。
ヒント
要求では、azureml-model-deployment の HTTP ヘッダーを含めることによって、構成されたトラフィックの負荷分散をバイパスできます。 ヘッダーの値を、要求のルーティング先のデプロイの名前に設定します。
次の図は、blue デプロイと green デプロイの間のトラフィックの割り当てに対する Azure Machine Learning スタジオでの設定を示しています。
上記のトラフィック割り当てでは、次の図に示すように、トラフィックの 10% がグリーン デプロイに、トラフィックの 90% がブルー デプロイにルーティングされます。
オンライン デプロイへのトラフィック ミラーリング
エンドポイントでは、あるデプロイから別のデプロイへのトラフィックをミラーリングまたはコピーすることもできます。 トラフィック ミラーリング (シャドウ テストともいいます) は、顧客が既存のデプロイから受け取る結果に影響を与えることなく、実稼働トラフィックで新しいデプロイをテストする場合に使用できます。
たとえば、トラフィックの 100% がブルーにルーティングされ、10% がグリーン デプロイにミラーリングされるブルー/グリーン デプロイを実装できます。 グリーン デプロイにミラーリングされたトラフィックの結果はクライアントに返されませんが、メトリックとログが記録されます。
トラフィック ミラーリングを使用する方法の詳細については、「リアルタイム推論のために新しいデプロイの安全なロールアウトを実行する」を参照してください。
その他のオンライン エンドポイント機能
以降のセクションでは、Azure Machine Learning オンライン エンドポイントのその他の機能について説明します。
認証と暗号化
- 認証: キーと Azure Machine Learning トークン
- マネージド ID: ユーザー割り当ておよびシステム割り当て
- エンドポイント呼び出し用の既定の Secure Socket Layer (SSL)
自動スケール
自動スケールでは、アプリケーションの負荷を処理するために適切な量のリソースが自動的に実行されます。 マネージド エンドポイントは、Azure Monitor 自動スケーリング機能との統合によって、自動スケールをサポートします。 CPU 使用率 >70% などのメトリックベースのスケーリング、ピーク営業時間ルールなどのスケジュールベースのスケーリング、またはその両方を構成できます。
詳細については、「Azure Machine Learning でのオンライン エンドポイントの自動スケーリング」を参照してください。
マネージド ネットワーク分離
機械学習モデルをマネージド オンライン エンドポイントにデプロイするときに、プライベート エンドポイントを使ってオンライン エンドポイントとの通信をセキュリティ保護できます。 受信スコアリング要求と送信通信のセキュリティを個別に構成できます。
受信通信では Azure Machine Learning ワークスペースのプライベート エンドポイントが使用され、送信通信ではワークスペースのマネージド仮想ネットワーク用に作成されたプライベート エンドポイントが使用されます。 詳細については、マネージド オンライン エンドポイントによるネットワーク分離に関するページを参照してください。
オンライン エンドポイントとデプロイの監視
Azure Machine Learning エンドポイントは、 Azure Monitor と統合されます。 Azure Monitor 統合により、グラフでのメトリックの表示、アラートの構成、ログ テーブルのクエリを行うことができ、Application Insights を使ってユーザー コンテナーからイベントを分析することができます。 詳しくは、「オンライン エンドポイントを監視する」をご覧ください。
オンライン デプロイでのシークレットの挿入 (プレビュー)
オンライン デプロイのシークレット挿入は、シークレット ストアから API キーなどのシークレットを取得し、デプロイ内で実行されるユーザー コンテナーにそれを挿入することです。 BYOC デプロイでスコアリング スクリプトまたは推論スタックを実行する推論サーバーに対して、セキュリティで保護されたシークレットの使用を実現するには、環境変数を使用してシークレットにアクセスできます。
マネージド ID を使用してシークレットを自分で挿入するか、シークレット挿入機能を使用することができます。 シークレットの挿入について詳しくは、「オンライン エンドポイントでのシークレット挿入 (プレビュー)」を参照してください。