オンライン エンドポイントのデプロイとスコアリングのトラブルシューティング

  • [アーティクル]

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

Azure Machine Learning オンライン エンドポイントのデプロイとスコアリングでの一般的な問題を解決する方法について説明します。

このドキュメントは、推奨されるトラブルシューティング方法別に構成されています。

  1. クラウドにデプロイする前に、ローカル デプロイを使用してモデルをローカルでテストおよびデバッグする。
  2. 問題のデバッグにコンテナー ログを役立てる。
  3. 発生する可能性がある一般的なデプロイ エラーとその修正方法について理解する。

「HTTP 状態コード」セクションでは、REST 要求でエンドポイントをスコアリングする際に呼び出しと予測のエラーを HTTP 状態コードにマップする方法について説明します。

前提条件

ローカルでのデプロイ

ローカル デプロイとは、ローカルの Docker 環境にモデルをデプロイすることです。 ローカル デプロイは、クラウドにデプロイする前にテストやデバッグを行う場合に便利です。

ヒント

また、Azure Machine Learning 推論 HTTP サーバー Python パッケージを使用して、スコアリング スクリプトをローカルでデバッグすることもできます。 推論サーバーを使用したデバッグは、ローカル エンドポイントにデプロイする前にスコアリング スクリプトをデバッグするのに役立ちます。これにより、デプロイ コンテナーの構成の影響を受けることなくデバッグできます。

ローカル デプロイでは、ローカル エンドポイントの作成、更新、および削除がサポートされています。 また、エンドポイントを呼び出してログを取得することもできます。

ローカル デプロイを使用するには、適切な CLI コマンドに --local を追加します。

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

ローカル デプロイの一環として、次のステップが実行されます。

  • Docker では、新しいコンテナー イメージをビルドするか、ローカルの Docker キャッシュから既存のイメージをプルします。 仕様ファイルの環境部分に一致する既存のイメージがある場合は、それが使用されます。
  • Docker では、モデルやコード ファイルなど、マウントされているローカルの成果物を使用して、新しいコンテナーを起動します。

詳細については、「機械学習モデルのデプロイとスコアリングでのローカルでのデプロイ」を参照してください。

ヒント

お使いのエンドポイントをローカルでテストおよびデバッグするには、Visual Studio Code を使用します。 詳細については、Visual Studio Code でオンライン エンドポイントをローカルでデバッグする方法に関する記事を参照してください。

Conda のインストール

一般に、MLflow デプロイに関する問題は、conda.yaml ファイルに指定されたユーザー環境のインストールに関する問題に起因しています。

Conda のインストールに関する問題をデバッグするには、次のステップを試してください。

  1. Conda のインストールのログを確認します。 コンテナーがクラッシュしたか、起動に時間がかかりすぎる場合は、Conda 環境の更新が正しく解決できなかった可能性があります。

  2. conda env create -n userenv -f <CONDA_ENV_FILENAME> コマンドを使用して mlflow conda ファイルをローカルにインストールします。

  3. ローカルでエラーが発生した場合は、再デプロイする前に、Conda 環境を解決し、機能環境を作成してみてください。

  4. ローカルで解決されてもコンテナーがクラッシュする場合は、デプロイに使用される SKU サイズが小さすぎる可能性があります。

    1. Conda パッケージのインストールは実行時に行われるため、SKU サイズが小さすぎて conda.yaml 環境ファイルで詳しく説明されているすべてのパッケージに対応できない場合、コンテナーがクラッシュする可能性があります。
    2. Standard_F4s_v2 VM は開始 SKU サイズとして適していますが、Conda ファイルで指定されている依存関係によっては、より大きなサイズが必要になる場合があります。
    3. Kubernetes オンライン エンドポイントの場合、Kubernetes クラスターには少なくとも 4 つの vCPU コアと 8 GB のメモリが必要です。

コンテナー ログを取得する

モデルがデプロイされている VM に直接アクセスすることはできません。 ただし、VM で実行されている一部のコンテナーからログを取得することはできます。 取得する情報の量は、デプロイのプロビジョニング状態によって異なります。 指定したコンテナーが稼働している場合は、コンソール出力が表示されます。稼働していない場合は、後でやり直すよう求めるメッセージが表示されます。

ログを取得できるコンテナーには、次の 2 種類があります。

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

コンテナーからのログ出力を表示するには、次の CLI コマンドを使用します。

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

または

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

az configure を介して --resource-group と --workspace-name をまだ設定していない場合は、上記のコマンドにこれらのパラメーターを追加します。

これらのパラメーターを設定する方法について確認する場合、また値を既に設定している場合は、次を実行します。

az ml online-deployment get-logs -h

既定では、ログが推論サーバーからプルされます。

Note

Python ログを使用する場合は、メッセージがログに発行される、適切なログ レベルの順序を使用してください。 たとえば、INFO を使用します。

–-container storage-initializer を渡すことで、ストレージ初期化子コンテナーからログを取得することもできます。

コマンドに --help や --debug を追加して、詳細を表示します。

Kubernetes オンライン エンドポイントの場合、管理者はモデルをデプロイしているクラスターに直接アクセスできるため、Kubernetes のログを検査する際により柔軟に対応できるようになりました。 例:

kubectl -n <compute-namespace> logs <container-name>

要求トレース

次の 2 つのトレース ヘッダーがサポートされています。

  • x-request-id はサーバー トレース用に予約されています。 このヘッダーをオーバーライドして、有効な GUID を確保します。

    Note

    失敗した要求のサポート チケットを作成する場合は、失敗した要求 ID を添付すると調査が迅速になります。

  • x-ms-client-request-id はクライアント トレース シナリオで使用できます。 このヘッダーは、英数字、ハイフン、アンダースコアのみを受け入れるようにサニタイズされ、最大 40 文字に切り詰められます。

一般的なデプロイのエラー

デプロイ操作の状態の一部としてレポートされる一般的なデプロイ エラーのリストを次に示します。

Kubernetes のオンライン デプロイを作成または更新している場合は、Kubernetes デプロイに固有の一般的なエラーを参照できます。

エラー: ImageBuildFailure

このエラーは、環境 (Docker イメージ) がビルドされているときに返されます。 ビルド ログでエラーの詳細を確認できます。 ビルド ログは、Azure Machine Learning ワークスペースの既定のストレージにあります。 正確な場所は、エラーの一部として返される場合があります。 たとえば、"the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'" のようにします。

一般的なイメージ ビルド失敗のシナリオを含めたリストを次に示します。

ImageBuild タイムアウトの場合は、既定のプローブ設定も確認することをお勧めします。

コンテナー レジストリの認可エラー

エラー メッセージに "container registry authorization failure" と記載されている場合、コンテナー レジストリに現在の資格情報でアクセスできないことを意味します。 このエラーは、ワークスペース リソースのキーの非同期化によって発生する可能性があり、自動的に同期されるまでに時間がかかります。 しかし、認可の失敗を解決する可能性があるキーの同期を手動で呼び出すことができます。

仮想ネットワークの背後にあるコンテナー レジストリも、正しく設定されていない場合にこのエラーが発生する可能性があります。 仮想ネットワークが正しく設定されていることを確認する必要があります。

VNet を使用したプライベート ワークスペースでイメージ ビルド コンピューティングが設定されていない

このエラー メッセージに "failed to communicate with the workspace's container registry" と表示され、仮想ネットワークを使っていて、ワークスペースの Azure Container Registry が非公開であり、プライベート エンドポイントを使って構成されている場合、仮想ネットワークでイメージをビルドできるように Azure Container Registry を有効にする必要があります。

一般的なイメージ ビルドの失敗

前に示したとおり、ビルド ログでエラーの詳細を確認できます。 ビルド ログで明確なエラーが見つからず、最後の行が Installing pip dependencies: ...working... である場合、依存関係がエラーの原因として考えられます。 conda ファイルでバージョンの依存関係を固定すると、この問題が解決する可能性があります。

また、モデルをクラウドにデプロイする前に、ローカルにデプロイして、ローカルでテストおよびデバッグすることもお勧めします。

ERROR: OutOfQuota

Azure サービスを使用するときにクォータが不足している可能性がある一般的なリソースのリストを次に示します。

さらに、Kubernetes オンライン エンドポイントのみでクォータが不足する可能性のある一般的なリソースのリストを次に示します。

CPU クォータ

モデルをデプロイする前に、十分なコンピューティング クォータを用意する必要があります。 このクォータでは、サブスクリプションごと、ワークスペースごと、SKU ごと、リージョンごとに使用可能な仮想コアの量を定義します。 SKU の種類に基づいて、デプロイするたびに使用可能なクォータが減算され、削除するたびに加算されます。

考えられる軽減策は、使用されていない削除可能なデプロイが含まれていないかを検査することです。 または、クォータの引き上げ要求を送信できます。

クラスターのクォータ

この問題は、十分な Azure Machine Learning コンピューティング クラスター クォータがない場合に発生します。 このクォータにより、Azure Cloud に CPU または GPU ノードをデプロイするための、サブスクリプションごとの一度に使用できるクラスターの合計数が定義されます。

考えられる軽減策は、使用されていない削除可能なデプロイが含まれていないかを検査することです。 または、クォータの引き上げ要求を送信できます。 このクォータの増加要求では、クォータの種類は Machine Learning Service: Cluster Quota を選択するようにしてください。

ディスク クォータ

この問題は、モデルのサイズが使用可能なディスク領域を超え、モデルをダウンロードできない場合に発生します。 より大きなディスク領域がある SKU を試すか、イメージとモデルのサイズを小さくしてください。

メモリ クォータ

この問題は、モデルのメモリ使用量が使用可能なメモリよりも大きい場合に発生します。 より大きなディスク領域がある SKU を試してください。

ロールの割り当てクォータ

マネージド オンライン エンドポイントを作成しているとき、マネージド ID がワークスペース リソースにアクセスするためのロール割り当てが必要です。 ロールの割り当て制限に達した場合は、このサブスクリプションで使用されていないいくつかのロール割り当てを削除してみてください。 Azure portal ですべてのロールの割り当てを確認するには、[アクセス制御] メニューへ進みます。

エンドポイント クォータ

このサブスクリプションで使用されていないエンドポイントをいくつか削除してみてください。 すべてのエンドポイントがアクティブに使用されている場合は、エンドポイント クォータの引き上げを要求してみてください。 エンドポイントの制限について詳しくは、Azure Machine Learning オンライン エンドポイントとバッチ エンドポイントでのエンドポイント クォータに関する記事を参照してください。

Kubernetes クォータ

この問題が発生するのは、このデプロイに対してノードをスケジュールできないために、要求された CPU またはメモリを提供できない場合です。 たとえば、ノードが切断されているか、使用できなくなっている可能性があります。

このエラー メッセージは、通常、クラスター内のリソースが不足していることを示しています (例: OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods...)。これは、クラスター内にポッドが多すぎて、要求に基づいて新しいモデルをデプロイするのに十分なリソースがないことを意味します。

この問題に対処するために、次の軽減策を実施することができます。

  • Kubernetes クラスターを維持する IT 担当者の場合は、ノードを追加するか、クラスター内の未使用のポッドをクリアして、一部のリソースを解放することができます。
  • モデルをデプロイする機械学習エンジニアの場合は、デプロイのリソース要求を減らすことができます。
    • リソース セクションからデプロイ構成のリソース要求を直接定義している場合は、リソース要求を減らすことができます。
    • instance type を使用してモデル デプロイのリソースを定義している場合は、IT 担当者に連絡してインスタンスの種類のリソース構成を調整できます。詳細については、Kubernetes インスタンスの種類を管理する方法に関する記事を参照してください。

リージョン全体の VM 容量

リージョンに Azure Machine Learning の容量がないため、サービスは指定された VM サイズをプロビジョニングできませんでした。 後で再試行するか、別のリージョンにデプロイしてみてください。

その他のクォータ

デプロイの一部として提供される score.py を実行するために、Azure では score.py に必要なすべてのリソースを含むコンテナーを作成し、そのコンテナーでスコアリング スクリプトを実行します。

コンテナーを起動できなかった場合、これはスコアリングを実行できなかったことを意味します。 コンテナーには、instance_type でサポートできるよりも多くのリソースが必要である可能性があります。 その場合は、オンライン デプロイの instance_type を更新することを検討してください。

エラーの正確な原因を取得するには、次を実行します。

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

ERROR: BadArgument

マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントを使用しているときにこのエラーが発生する可能性がある理由のリストを次に示します。

Kubernetes オンライン エンドポイントを使用しているときのみこのエラーが発生する可能性がある理由のリストを以下に示します。

サブスクリプションが存在しない

既存の Azure サブスクリプションを入力する必要があります。 このエラーは、参照された Azure サブスクリプションが見つからない場合に発生します。 このエラーは、サブスクリプション ID の入力ミスが原因である可能性があります。 サブスクリプション ID が正しく入力されていること、および現在アクティブであることを再確認してください。

Azure サブスクリプションの詳細については、「前提条件」セクションを参照してください。

認証エラー

コンピューティング リソースをプロビジョニングした後 (デプロイの作成時)、Azure ではワークスペースの Azure Container Registry (ACR) からユーザー コンテナー イメージをプルしようとします。 ワークスペース ストレージ アカウントからユーザー コンテナーにユーザー モデルとコード アーティファクトをマウントしようとします。

これらのアクションを行うために、Azure はマネージド ID を使ってストレージ アカウントとコンテナー レジストリにアクセスします。

  • システム割り当て ID と関連付けられたエンドポイントを作成した場合は、Azure のロールベースのアクセス制御 (RBAC) のアクセス許可が自動的に付与されるので、それ以上のアクセス許可は必要ありません。

  • ユーザー割り当て ID と関連付けられたエンドポイントを作成した場合は、ユーザーのマネージド ID にはワークスペースのストレージ アカウントにストレージ BLOB データ閲覧者のアクセス許可、ワークスペースの Azure Container Registry (ACR) には AcrPull のアクセス許可が必要です。 ユーザー割り当て ID に適切なアクセス許可があることを確認します。

詳細については、「コンテナー レジストリの認証エラー」を参照してください。

テンプレート関数の指定が無効です

このエラーは、テンプレート関数を正しく指定しなかった場合に発生します。 ポリシーを修正するか、ポリシーの割り当てを削除してブロックを解除してください。 エラー メッセージには、このエラーのデバッグに役立つポリシー割り当て名とポリシー定義、およびテンプレート エラーを回避するためのヒントについて説明する Azure ポリシー定義構造に関する記事が含まれている場合があります。

ユーザー コンテナー イメージをダウンロードできません

ユーザー コンテナーが見つからなかった可能性があります。 コンテナー ログで詳細情報を確認してください。

ワークスペース ACR でコンテナー イメージを使用できることを確認します。

たとえば、イメージが testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest の場合は、az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table を使用してリポジトリを確認します。

ユーザー モデルをダウンロードできません

ユーザー モデルが見つからない可能性があります。 コンテナー ログで詳細情報を確認してください。

モデルを、デプロイと同じワークスペースに登録しているかどうかを確認します。 ワークスペース内のモデルの詳細を表示するには:

az ml model show --name <model-name> --version <version>

警告

モデルの情報を取得するには、バージョンまたはラベルを指定する必要があります。

また、BLOB がワークスペース ストレージ アカウント内に存在するかどうかを確認することもできます。

  • たとえば、BLOB が https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl の場合、次のコマンドを使用して、それが存在するかどうかを確認できます。

    az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`

  • BLOB が存在する場合は、次のコマンドを使用して、ストレージ初期化子からログを取得できます。

    az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`

MLFlow model format with private network is unsupported (プライベート ネットワークを使った MLFlow モデル形式はサポートされていません)

このエラーは、マネージド オンライン エンドポイントのレガシのネットワークの分離方法と組み合わせて、コードなしのデプロイ アプローチで MLflow モデルをデプロイしようとすると発生します。 レガシのネットワークの分離方法を使っている場合、このプライベート ネットワーク機能を MLFlow モデル形式と組み合わせて使うことはできません。 コードなしのデプロイ アプローチで MLflow モデルをデプロイする必要がある場合は、ワークスペースのマネージド VNet を使ってみてください。

制限を超えているリソース要求

リソースに対する要求は、制限以下でなければなりません。 制限を設定しない場合は、Azure Machine Learning ワークスペースにコンピューティングをアタッチするときに既定値が設定されます。 制限は、Azure portal または az ml compute show コマンドを使用して確認できます。

azureml-fe の準備ができていない

デプロイされたサービスへ受信推論要求をルーティングするフロントエンド コンポーネント (azureml-fe) は、必要に応じて自動的にスケーリングされます。 これは、k8s 拡張機能のインストール中にインストールされます。

このコンポーネントは、クラスター上で正常で、少なくとも 1 つの正常なレプリカである必要があります。 このエラー メッセージは、kubernetes オンライン エンドポイントとデプロイの作成または更新要求をトリガーするときに、このコンポーネントが使用できない場合に表示されます。

ポッドの状態とログを確認してこの問題を解決してください。また、クラスターにインストールされている k8s 拡張機能の更新を試すこともできます。

ERROR: ResourceNotReady

デプロイの一部として提供される score.py を実行するために、Azure では score.py に必要なすべてのリソースを含むコンテナーを作成し、そのコンテナーでスコアリング スクリプトを実行します。 このシナリオのエラーは、実行中にこのコンテナーがクラッシュしたため、スコアリングを実行できないことを意味します。 このエラーは、次の場合に発生します。

  • score.py にエラーがある。 get-logs を使用すると、一般的な問題を診断できます：
    • score.pyが インポートを試みるパッケージ は、conda 環境には含まれません。
    • 構文エラーです。
    • init() メソッドのエラー。
  • get-logs によってログが生成されていない場合は、通常、コンテナーの起動に失敗したということを意味します。 この問題をデバッグするには、代わりにローカルにデプロイしてみてください。
  • readiness probe または liveness probe が正しく設定されていない。
  • コンテナーの初期化に時間がかかりすぎるため、準備またはliveness probeが失敗しきい値を超えて失敗します。 この場合は、プローブ設定を調整して、コンテナーの初期化により多くの時間をかけられるようにします。 あるいは、サポート対象の VM SKU のうち、より大きな VM SKU を試してみてください。これにより、初期化にかかる時間が短縮されます。
  • 依存関係が不足しているなど、コンテナーの環境設定にエラーがある。
  • TypeError: register() takes 3 positional arguments but 4 were given エラーが発生した場合は、flask v2 と azureml-inference-server-http の間の依存関係を確認してください。 詳細については、推論 HTTP サーバーに関する FAQ を参照してください。

ERROR: ResourceNotFound

マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントを使用しているときにこのエラーのみ発生する可能性がある理由のリストを次に示します。

Resource Manager がリソースを見つけることができない

このエラーは Azure Resource Manager が必要なリソースを見つけられない場合に発生します。 たとえば、ストレージ アカウントが参照されているが、指定されたパスで見つからない場合、このエラーが発生することがあります。 正確なパスまたは名前のスペルによって指定されている可能性のあるリソースを再確認してください。

詳細については、「リソースが見つからないエラーを解決する」を参照してください。

コンテナー レジストリの認証エラー

このエラーは、プライベートまたはアクセスできないコンテナー レジストリに属するイメージがデプロイ用に指定された場合に発生します。 現時点では、Microsoft の API は、プライベート レジストリの資格情報を受け入れることができません。

このエラーを軽減するには、コンテナー レジストリがプライベートでないことを確認するか、次の手順に従います。

  1. プライベート レジストリの acrPull ロールを、オンライン エンドポイントのシステム ID に付与します。
  2. 環境の定義で、プライベート イメージのアドレスと、イメージを変更 (ビルド) しない命令を指定します。

軽減策が成功した場合、イメージをビルドする必要がなくなり、最終的なイメージ アドレスが指定したイメージ アドレスになります。 デプロイ時に、オンライン エンドポイントのシステム ID によって、プライベート レジストリからイメージがプルされます。

診断について詳しくは、ワークスペース診断 API の使用方法に関するページを参照してください。

エラー: OperationCanceled

マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントを使用しているときにこのエラーが発生する可能性がある理由のリストを次に示します。

優先度が高い別の操作によって取り消された操作

Azure の操作には、優先度レベルが割り当てられており、高いものから順に実行されます。 このエラーは、操作が優先度の高い別の操作によって上書きされた場合に発生します。

操作を再試行すると、キャンセルせずに操作を実行することが許可される場合があります。

ロックの確認を待機していて取り消された操作

Azure の操作には送信後短い待機期間があり、その間操作はロックを取得し、競合状態に陥らないようにしています。 このエラーは、送信した操作が他の操作と同じ場合に発生します。 現在、他の操作は、続行するためにロックを受け取ったかという確認を待機しています。 これは、最初の要求の直後によく似た要求を送信したことを示している可能性があります。

数秒から最大 1 分間待機した後に操作を再試行すると、取り消しなしで実行できる場合があります。

ERROR: SecretsInjectionError

オンライン デプロイの作成時のシークレットの取得と挿入では、ワークスペース接続およびキー コンテナーからシークレットを取得するために、オンライン エンドポイントに関連付けられた ID を使用します。 このエラーは、次の場合に発生します。

  • シークレットはデプロイ定義によって (環境変数にマップされ) 参照として指定されていても、エンドポイント ID には、ワークスペース接続およびキー コンテナーからシークレットを読み取るための Azure RBAC アクセス許可がありません。 ロールの割り当ての変更が有効になるには時間がかかる場合があることに注意してください。
  • シークレット参照の形式が無効であるか、指定されたシークレットがワークスペース接続やキー コンテナー内に存在しません。

詳細については、「オンライン エンドポイントでのシークレットの挿入 (プレビュー)」および「シークレット挿入を使用したオンライン デプロイからのシークレットへのアクセス (プレビュー)」を参照してください。

ERROR: InternalServerError

Microsoft では信頼性の高い、安定したサービスを提供するために最善を尽くしていますが、計画どおりに進まない場合があります。 このエラーが発生した場合、Microsoft 側で問題が発生しているため、当社で修正する必要があります。 すべての関連情報を記載のうえ、カスタマー サポート チケットを送信していただけましたら、こちらで問題に対処できます。

Kubernetes デプロイに固有の一般的なエラー

ID と認証に関するエラー。

crashloopbackoff に関するエラー。

スコアリング スクリプトに関するエラー。

その他:

エラー: ACRSecretError

Kubernetes オンライン デプロイを作成または更新しているときにこのエラーが発生する場合に考えられる原因のリストを以下に示します。

  • ロールの割り当ては完了していません。 この場合は、数秒待ってから、後でもう一度お試しください。
  • Azure ARC (Azure Arc Kubernetes クラスターの場合) または Azure Machine Learning 拡張機能 (AKS の場合) のインストールや構成が正しく行われていません。 Azure ARC または Azure Machine Learning 拡張機能の構成と状態を確認してみてください。
  • Kubernetes クラスターに不適切なネットワーク構成があります。プロキシやネットワーク ポリシー、証明書を確認してください。
    • プライベート AKS クラスターを使用している場合は、AKS vnet で ACR、ストレージ アカウント、ワークスペースのプライベート エンドポイントを設定する必要があります。
  • Azure Machine Learning の拡張機能のバージョンが v1.1.25 より大きいことを確認します。

エラー: TokenRefreshFailed

このエラーは、Kubernetes クラスター ID が適切に設定されていないため、拡張機能で Azure からプリンシパル資格情報を取得できないため発生します。 Azure Machine Learning 拡張機能を再インストールしてもう一度お試しください。

エラー: GetAADTokenFailed

このエラーは、Kubernetes クラスター要求 AzureAD トークンが失敗したかタイムアウトしたことが原因です。ネットワーク アクセシビリティをチェックしてから、もう一度お試しください。

  • 「必要なネットワーク トラフィックを構成する」に従って送信プロキシをチェックし、クラスターがワークスペースに接続できることを確認します。
  • ワークスペース エンドポイント URL は、クラスターのオンライン エンドポイント CRD にあります。

ワークスペースがパブリック ネットワーク アクセスを無効にしたプライベート ワークスペースの場合、Kubernetes クラスターはプライベート リンクを介してのみ、そのプライベート ワークスペースと通信する必要があります。

  • ワークスペース アクセスでパブリック アクセスが許可されているかどうかを確認します。AKS クラスターは、それ自体がパブリックかプライベートかに関係なく、プライベート ワークスペースにアクセスできないはずです。
  • 詳しくは、「セキュリティで保護された Azure Kubernetes Service 推論環境」をご覧ください

エラー: ACRAuthenticationChallengeFailed

このエラーは、Kubernetes クラスターが認証チャレンジでワークスペースの ACR サービスに到達できないことが原因です。 ネットワーク (特に ACR パブリック ネットワーク アクセス) をチェックしてから、もう一度お試しください。

「GetAADTokenFailed」のトラブルシューティング手順に従って、ネットワークをチェックします。

エラー: ACRTokenExchangeFailed

このエラーは、 Azure AD トークンがまだ承認されていないため、Kubernetes クラスターの ACR トークンの交換に失敗したことが原因で発生します。 ロールの割り当てには時間がかかるため、しばらく待ってからもう一度やり直してください。

このエラーは、その時点で ACR サービスに対する要求が多すぎることが原因の場合もあります。これは一時的なエラーのはずですので、後でもう一度お試しください。

ERROR: KubernetesUnaccessible

Kubernetes モデルのデプロイ中に、次のエラーが発生する場合があります。

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

このエラーを軽減するには、次の方法があります。

  • クラスターの AKS 証明書をローテーションする。 詳細については、「Azure Kubernetes Service (AKS)」を参照してください。
  • 新しい証明書は 5 時間後に更新されるため、5 時間待ってから再デプロイできます。

ERROR: ImagePullLoopBackOff

Kubernetes オンライン デプロイを作成または更新するときにこのエラーが発生する場合は、イメージをコンテナー レジストリからダウンロードできず、イメージのプルが失敗していることが原因と考えられます。

この場合、クラスターがコンテナー レジストリからイメージをプルできる場合は、クラスター ネットワーク ポリシーとワークスペース コンテナー レジストリを確認できます。

エラー: DeploymentCrashLoopBackOff

Kubernetes オンライン デプロイを作成または更新するときにこのエラーが発生する場合は、初期化時にユーザー コンテナーがクラッシュしたことが原因と考えられます。 このエラーの原因は以下の 2 つが考えられます。

  • ユーザー スクリプト score.py に構文エラーまたはインポート エラーがあるため、初期化時に例外が発生します。
  • デプロイ ポッドに必要なメモリが上限を上回っています。

このエラーを軽減するには、まずデプロイ ログ内で、ユーザー スクリプト中の例外を検査します。 エラーが解決しない場合は、リソース/インスタンス タイプのメモリの上限を上げてみてください。

エラー: KubernetesCrashLoopBackOff

Kubernetes オンライン エンドポイントまたはオンライン デプロイを作成または更新しているときにこのエラーが発生する場合に考えられる原因のリストを以下に示します。

  • 1 つ以上のポッドが CrashLoopBackoff 状態でスタックしています。デプロイ ログが存在するかどうか、およびログにエラー メッセージがあるかどうかを確認できます。
  • score.py にエラーがあり、スコア コードを初期化するとコンテナーがクラッシュしました。エラー: ResourceNotReady のパートに従ってください。
  • スコアリング プロセスでメモリがもっと必要であり、デプロイ構成の上限が不足しています。メモリの上限をもっと大きくしてデプロイを更新できます。

エラー: NamespaceNotFound

Kubernetes オンライン エンドポイントを作成または更新しているときにこのエラーが発生する場合は、Kubernetes コンピューティングが使用した名前空間がクラスターで使用できないことが原因と考えられます。

ワークスペース ポータルで Kubernetes コンピューティングを確認し、Kubernetes クラスター内の名前空間を確認できます。 名前空間が使用できない場合は、レガシ コンピューティングをデタッチし、再アタッチして新しいコンピューティングを作成し、クラスターに既に存在する名前空間を指定できます。

エラー: UserScriptInitFailed

Kubernetes オンライン デプロイを作成または更新するときにこのエラーが発生する場合は、アップロードした score.py ファイルの init 関数で例外が発生したことが原因と考えられます。

デプロイ ログを検査して、例外メッセージの詳細を確認し、例外を修正できます。

エラー: UserScriptImportError

Kubernetes オンライン デプロイを作成または更新するときにこのエラーが発生する場合は、score.py ファイルをアップロードした際に使用できないパッケージがインポートされたことが原因と考えられます。

デプロイ ログを検査して、例外メッセージの詳細を確認し、例外を修正できます。

エラー: UserScriptFunctionNotFound

Kubernetes オンライン デプロイを作成または更新するときにこのエラーが発生する場合は、アップロードした score.py ファイルに init() または run() という名前の関数がないことが原因と考えられます。 コードを検査し、関数を追加できます。

ERROR: EndpointNotFound

Kubernetes オンラインデプロイを作成または更新するときにこのエラーが発生する場合は、システムがクラスター内のデプロイのエンドポイント リソースを見つけることができないことが原因と考えられます。 既存のエンドポイントにデプロイを作成するか、クラスターで最初にこのエンドポイントを作成する必要があります。

ERROR: EndpointAlreadyExists

Kubernetes オンライン エンドポイントを作成するときにこのエラーが発生する場合は、作成中のエンドポイントがクラスターに既に存在することが原因と考えられます。

エンドポイント名はワークスペースごと、およびクラスターごとに一意である必要があるため、この場合は別の名前でエンドポイントを作成する必要があります。

ERROR: ScoringFeUnhealthy

Kubernetes オンライン エンドポイントまたはデプロイを作成または更新するときにこのエラーが発生する場合は、クラスターで実行されているシステム サービスである Azureml-fe が見つからないか、異常が発生していることが原因と考えられます。

この問題のトラブルシューティングを行うには、クラスターに Azure Machine Learning 拡張機能を再インストールするか、更新します。

ERROR: ValidateScoringFailed

Kubernetes オンライン デプロイを作成または更新するときにこのエラーが発生する場合は、モデルのデプロイを処理するときにスコアリング要求 URL の検証に失敗したことが原因と考えられます。

この場合は、最初にエンドポイント URL を検査してから、デプロイの再デプロイを試みることができます。

ERROR: InvalidDeploymentSpec

Kubernetes オンライン デプロイを作成または更新するときにこのエラーが発生する場合は、デプロイ仕様が無効であることが原因と考えられます。

この場合は、エラー メッセージを確認します。

  • instance count が有効であることを確認します。
  • 自動スケーリングを有効にしている場合は、minimum instance count と maximum instance count が両方とも有効であることを確認します。

ERROR: PodUnschedulable

Kubernetes オンライン エンドポイントまたはオンライン デプロイを作成または更新しているときにこのエラーが発生する場合に考えられる原因のリストを以下に示します。

  • クラスター内のリソースが不足しているため、ポッドをノードにスケジュールできません。
  • ノード アフィニティまたはセレクターに一致するノードがありません。

このエラーを軽減するには、次のステップに従ってください。

  • 使用した instance type の node selector 定義とクラスター ノードの node label 構成を確認します。
  • AKS クラスターの instance type とノード SKU サイズ、または Arc-Kubernetes クラスターのノード リソースを確認します。
    • クラスターのリソースが不足している場合は、このインスタンスの種類に対するリソース要件を減らすか、必要なリソースが少ない別のインスタンスの種類を使用できます。
  • クラスターにデプロイの要件を満たすリソースがもうない場合は、リソースを解放するために一部のデプロイを削除します。

エラー: PodOutOfMemory

オンライン デプロイを作成または更新するときにこのエラーが発生する場合は、デプロイに対して指定しているメモリの上限が低すぎることが原因と考えられます。 このエラーを軽減するには、メモリの上限の設定値を大きくするか、もっと大きなインスタンス タイプを使用することができます。

エラー: InferencingClientCallFailed

Kubernetes オンライン エンドポイントを作成または更新しているときにこのエラーが発生する場合は、Kubernetes クラスターの k8s-extension が接続できないことが原因と考えられます。

この場合は、コンピューティングをデタッチしてから再アタッチできます。

注意

再アタッチしてエラーをトラブルシューティングするには、必ず前にデタッチしたコンピューティングと厳密に同じ構成 (同じコンピューティング名や名前空間など) を使用して再アタッチしてください。使用しないと、他のエラーが発生する場合があります。

それでも解決しない場合は、クラスターにアクセスできる管理者に、kubectl get po -n azureml を使用してリレー サーバー ポッドが実行されているかどうか検査してもらってください。

自動スケールの問題

自動スケールで問題が発生した場合は、「Azure 自動スケーリングのトラブルシューティング」を参照してください。

Kubernetes オンライン エンドポイントの場合は、Kubernetes クラスター上のすべてのモデル デプロイで自動スケーリングを処理するフロントエンド コンポーネントである Azure Machine Learning 推論ルーターがあります。詳細については、「Kubernetes 推論ルーティングの自動スケーリング」を参照してください

一般的なモデル消費のエラー

エンドポイント invoke 操作の状態に起因する一般的なモデル消費エラーのリストを次に示します。

帯域幅の制限の問題

マネージド オンライン エンドポイントには、エンドポイントごとに帯域幅の制限があります。 制限の構成は、「オンライン エンドポイントの制限」で確認できます。 帯域幅の使用量が制限を超えると、要求が遅延します。 帯域幅の遅延を監視するには:

  • メトリック「ネットワーク バイト数」を使って、現在の帯域幅の使用状況を把握します。 詳細については、「マネージド オンライン エンドポイントを監視する」を参照してください。
  • 帯域幅の制限が適用されると、次の 2 つの応答トレーラーが返されます。
    • ms-azureml-bandwidth-request-delay-ms: 要求ストリームの転送にかかった延期期間 (ミリ秒単位)。
    • ms-azureml-bandwidth-response-delay-ms: 応答ストリームの転送にかかった延期期間 (ミリ秒単位)。

HTTP 状態コード

REST 要求でオンライン エンドポイントにアクセスしたときに返される状態コードは、HTTP の状態コードの標準に準拠しています。 エンドポイントの呼び出しと予測エラーが HTTP 状態コードにマップされる方法の詳細を以下に示します。

マネージド オンライン エンドポイントの一般的なエラー コード

REST 要求でマネージド オンライン エンドポイントを消費するときの一般的なエラー コードを含む表を次に示します。

状態コード 理由の文字列 このコードが返される理由
200 OK 待ち時間の範囲内で、モデルが正常に実行されました。
401 権限がありません スコアリングなどの要求されたアクションを実行するためのアクセス許可がないか、トークンの有効期限が切れているか、形式が正しくありません。 詳細については、エンドポイント認証の概念およびエンドポイントの認証方法に関するページを参照してください。
404 見つかりません エンドポイントに、正の重みを持つ有効なデプロイがありません。
408 要求タイムアウト モデルの実行にかかる時間が、モデル デプロイ構成の request_settings の request_timeout_ms で指定したタイムアウトよりも長くなっています。
424 モデル エラー モデル コンテナーから 200 以外の応答が返された場合、Azure は 424 を返します。 エンドポイントの Azure Monitor Metric Explorer の Requests Per Minute メトリックの下にある Model Status Code ディメンジョンを確認します。 または、ms-azureml-model-error-statuscode と ms-azureml-model-error-reason の応答ヘッダーで詳細を確認します。 424 にlivenessまたはreadiness probeが失敗した場合は、コンテナーのライブ性または準備状態をプローブする時間を長くできるように プローブ設定 を調整することを検討してください。
429 保留中の要求が多すぎます モデルで現在、処理できる数よりも多くの要求を受信しています。 Azure Machine Learning では、スムーズな操作を保証するために、任意の時点で最大 2 * max_concurrent_requests_per_instance * instance_count requests の並列処理を許可するシステムが実装されています。 この最大値を超えるその他の要求は拒否されます。 request_settings と scale_settings のセクションでモデル デプロイの構成を確認し、これらの設定を確認して調整できます。 さらに、RequestSettings の YAML 定義で説明されているように、環境変数 WORKER_COUNT が正しく渡されるようにすることが重要です。

自動スケーリングを使用していてこのエラーが発生する場合、お使いのモデルが、システムがスケールアップできるよりも速く要求を受信していることを意味します。 このような状況では、システムに調整が必要な時間を与えるために、エクスポネンシャル バックオフを使用して要求を再送信することを検討してください。 また、インスタンス数を計算するコードを使用してインスタンスの数を増やすこともできます。 これらの手順を、自動スケーリングの設定と組み合わせることで、要求の流入を処理するためにモデルを確実に準備することができます。
429 レート制限 1 秒あたりの要求数が、マネージド オンライン エンドポイントの制限に達しました。
500 内部サーバー エラー Azure Machine Learning でプロビジョニングされたインフラストラクチャが失敗しています。

kubernetes オンライン エンドポイントの一般的なエラー コード

REST 要求で Kubernetes オンライン エンドポイントを消費するときの一般的なエラー コードを含む表を次に示します。

状態コード 理由の文字列 このコードが返される理由
409 競合のエラー 操作が既に進行中の場合、同じオンライン エンドポイントでの新しい操作は、409 競合エラーで応答します。 たとえば、オンライン エンドポイントの作成または更新操作の進行中に、新しい削除操作がトリガーされた場合、エラーがスローされます。
502 score.py ファイルの run() メソッドで例外がスローされたか、クラッシュしました score.py でエラーが発生した場合、たとえば、インポートされたパッケージが conda 環境に存在しない、構文エラー、または init() メソッドにエラーが発生した場合などです。 こちらに従ってファイルをデバッグできます。
503 1 秒間に大量の要求を受信する 自動スケールは、段階的な負荷の変化に対処するように設計されています。 1 秒あたりに受信する要求の量が急増した場合、クライアントは HTTP 状態コード 503 を受信する可能性があります。 オートスケーラーは迅速に反応しますが、AKS で追加のコンテナーを作成するにはかなりの時間がかかります。 こちらに従って 503 状態コードを防いでください。
504 要求がタイムアウトした 504 状態コードは、要求がタイムアウトしたことを示します。既定のタイムアウト設定は 5 秒です。 タイムアウトを増やすか、score.py を変更して不要な呼び出しを削除することでエンドポイントの高速化を試みることができます。 これらの操作で問題が解決しない場合は、こちらに従って score.py ファイルをデバッグできます。 コードが応答なし状態または無限ループになっている可能性があります。
500 内部サーバー エラー Azure Machine Learning でプロビジョニングされたインフラストラクチャが失敗しています。

503 状態コードを防ぐ方法

Kubernetes オンライン デプロイでは自動スケーリングがサポートされています。これにより、追加の負荷をサポートするためにレプリカを追加できます。詳細については、Azure Machine Learning 推論ルーターに関するページを参照してください。 スケールアップ/スケールダウンの決定は、コンテナーの現在のレプリカの使用率に基づきます。

状態コード 503 を防ぐには、次の 2 つのことが役立ちます。

ヒント

これらの 2 つの方法は、個別に使用することも、組み合わせて使用することもできます。

  • 自動スケールによって新しいレプリカが作成される使用率レベルを変更します。 使用率の目標を調整するには、autoscale_target_utilization をより小さい値に設定します。

    重要

    この変更によって、レプリカの作成時間は短縮されません。 その代わり、より低い使用率しきい値で作成されます。 サービスの使用率が 70% になるまで待機するのでなく値を 30% に変更すると、使用率が 30% になった段階でレプリカが作成されます。

    現在の最大数のレプリカが Kubernetes オンライン エンドポイントによって既に使用されていて、状態コード 503 が引き続き発生する場合は、autoscale_max_replicas の値を大きくして、レプリカの最大個数を増やします。

  • レプリカの最小個数を変更します。 レプリカの最小個数を増やすと、着信トラフィックの急増に対処するためのプールが大きくなります。

    インスタンスの数を増やすには、次のコードのようにして必要なレプリカの数を計算できます。

    from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

    注意

    受信する要求の量が、新しい最小レプリカ数で対処できるレベルを超えて急増した場合、再び 503 が発生する可能性があります。 たとえば、ご利用のエンドポイントへのトラフィックが増えた場合、レプリカの最小個数を増やすことが必要な場合があります。

インスタンスの数を計算する方法

インスタンスの数を増やすために、次のコードを使用して必要なレプリカの数を計算できます。

from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

CORS ポリシーによってブロックされる

オンライン エンドポイント (v2) は現在、クロスオリジン リソース共有 (CORS) をネイティブでサポートしていません。 Web アプリが CORS プレフライト要求を適切に処理せずにエンドポイントを呼び出そうとすると、次のエラー メッセージが表示されます。

Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.

CORS プレフライト要求を処理するための中間レイヤーとして、Azure Functions、Azure Application Gateway、または任意のサービスを使用することをお勧めします。

ネットワークの分離に関する一般的な問題

V1LegacyMode == true メッセージでオンライン エンドポイントの作成が失敗する

Azure Machine Learning ワークスペースを v1_legacy_mode で構成して、v2 API を無効にすることができます。 マネージド オンライン エンドポイントは v2 API プラットフォームの機能であり、ワークスペースで v1_legacy_mode が有効になっている場合は機能しません。

重要

v1_legacy_mode を無効にする前に、ネットワーク セキュリティ チームに確認してください。 ネットワーク セキュリティ チームが意図的に有効にしている可能性があります。

v1_legacy_mode を無効にする方法については、v2 を使用したネットワークの分離に関する記事を参照してください。

キーベースの認証を使用したオンライン エンドポイントの作成が失敗する

次のコマンドを使って、ワークスペース用の Azure Key Vault のネットワーク規則の一覧を取得します。 <keyvault-name> は、実際のキー コンテナーの名前に置き換えます。

az keyvault network-rule list -n <keyvault-name>

このコマンドの応答は、次の JSON ドキュメントのようになります。

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

bypass の値が AzureServices ではない場合は、「Azure Key Vault のネットワーク設定を構成する」のガイダンスを使って、それを AzureServices に設定します。

イメージのダウンロード エラーでオンライン デプロイが失敗する

Note

この問題は、マネージド オンライン エンドポイントに従来のネットワークの分離方法を使用する場合に当てはまります。この方法では、Azure Machine Learning によって、エンドポイントに各デプロイ用のマネージド仮想ネットワークが作成されます。

  1. egress-public-network-access フラグがデプロイに対して無効になっているかどうかを調べます。 このフラグが有効で、コンテナー レジストリの可視性がプライベートである場合、この失敗が予想されます。

  2. プライベート エンドポイント接続の状態を調べるには、次のコマンドを使います。 <registry-name> は、実際のワークスペースの Azure Container Registry の名前に置き換えます。

    az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{Name:name, status:privateLinkServiceConnectionState.status}"

    応答ドキュメントで、status フィールドが Approved に設定されていることを確認します。 承認されていない場合は、次のコマンドを使って承認します。 <private-endpoint-name> は、前のコマンドから返された名前に置き換えます。

    az network private-endpoint-connection approve -n <private-endpoint-name>

スコアリング エンドポイントを解決できない

  1. スコアリング要求を発行しているクライアントが、Azure Machine Learning ワークスペースにアクセスできる仮想ネットワークであることを確認します。

  2. エンドポイントのホスト名に対して nslookup コマンドを使って、IP アドレスの情報を取得します。

    nslookup endpointname.westcentralus.inference.ml.azure.com

    応答にアドレスが含まれています。 このアドレスが、仮想ネットワークによって提供される範囲内のものである必要があります

    注意

    Kubernetes オンライン エンドポイントの場合、エンドポイントのホスト名は、Kubernetes クラスターで指定されている CName (ドメイン名) である必要があります。 HTTP エンドポイントの場合、IP アドレスは、Studio UI で直接取得できるエンドポイント URI に含まれます。 エンドポイントの IP アドレスを取得する他の方法については、Secure Kubernetes オンライン エンドポイントに関するページを参照してください。

  3. ホスト名が nslookup コマンドによって解決されない場合:

    マネージド オンライン エンドポイントの場合、

    1. 仮想ネットワークのプライベート DNS ゾーンに A レコードが存在するかどうかを確認します。

      レコードを調べるには、次のコマンドを使います。

      az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name

      結果に、*.<GUID>.inference.<region> のようなエントリが含まれている必要があります。

    2. 推論値が返されない場合は、ワークスペースのプライベート エンドポイントを削除して作り直します。 詳しくは、プライベート エンドポイントを構成する方法に関するページをご覧ください。

    3. プライベート エンドポイントを備えたワークスペースがカスタム DNS を使用してセットアップされている (「カスタム DNS サーバーでワークスペースを使用する方法」) 場合、解決がカスタム DNS から正しく機能するかどうかを確認するには、次のコマンドを使用します。

      dig endpointname.westcentralus.inference.ml.azure.com

    Kubernetes オンライン エンドポイントの場合、

    1. Kubernetes クラスターの DNS 構成を確認します。

    2. さらに、azureml-fe が期待どおりに動作するかどうかを、次のコマンドを使用して確認します。

      kubectl exec -it deploy/azureml-fe -- /bin/bash
(Run in azureml-fe pod)

curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

      HTTP の場合、以下を使用します。

      curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

    curl HTTPs が失敗 (タイムアウトなど) しても HTTP が機能する場合は、証明書が有効であることを確認してください。

    これが A レコードに解決されない場合は、解決が Azure DNS (168.63.129.16) から機能するかどうかを確認します。

    dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com

    これが成功した場合は、カスタム DNS 上のプライベート リンクに対する条件付きフォワーダーのトラブルシューティングを行うことができます。

オンライン デプロイをスコアリングできない

  1. デプロイが正常にデプロイされたかどうかを確認するには、次のコマンドを使います。

    az ml online-deployment show -e <endpointname> -n <deploymentname> --query '{name:name,state:provisioning_state}'

    デプロイが正常に完了した場合、state の値は Succeeded になります。

  2. デプロイが成功した場合は、次のコマンドを使って、トラフィックがデプロイに割り当てられていることを確認します。 <endpointname> は、お使いのエンドポイントの名前に置き換えます。

    az ml online-endpoint show -n <endpointname>  --query traffic

    ヒント

    このデプロイをターゲットにするために要求で azureml-model-deployment ヘッダーを使っている場合、このステップは必要ありません。

    このコマンドからの応答では、デプロイに割り当てられているトラフィックの割合の一覧が示されるはずです。

  3. トラフィックの割り当て (またはデプロイ ヘッダー) が正しく設定されている場合は、次のコマンドを使ってエンドポイントのログを取得します。 <endpointname> はエンドポイントの名前に、<deploymentname> はデプロイに置き換えます。

    az ml online-deployment get-logs  -e <endpointname> -n <deploymentname>

    ログを調べて、デプロイに要求を送信したときに、スコアリング コードの実行で問題が発生しているかどうかを確認します。

推論サーバーのトラブルシューティング

このセクションでは、Azure Machine Learning 推論 HTTP サーバーの基本的なトラブルシューティングのヒントについて説明します。

基本的な手順

トラブルシューティングの基本的なステップは次のとおりです。

  1. Python 環境のバージョン情報を収集します。
  2. 環境ファイル内で指定されている Python パッケージ azureml-inference-server-http のバージョンが、起動ログに表示される AzureML 推論 HTTP サーバーのバージョンと一致していることを確認します。 PIP の依存関係リゾルバーにより、予期しないバージョンのパッケージがインストールされる場合があります。
  3. ご利用の環境で Flask (やその依存関係) を指定している場合は、それらを削除します。 依存関係には Flask、Jinja2、itsdangerous、Werkzeug、MarkupSafe、click が含まれます。 Flask はサーバー パッケージ内の依存関係としてリストされ、サーバーにインストールするよう推奨されています。 こうすると、サーバーで新しいバージョンの Flask がサポートされると自動的に取得できます。

サーバーのバージョン

サーバー パッケージ azureml-inference-server-http が PyPI に公開されています。 PyPI ページで、変更ログとすべての旧バージョンを確認できます。 以前のバージョンを使用している場合は、最新バージョンに更新します。

  • 0.4.x: 20220601 以下のトレーニング イメージおよぴ azureml-defaults>=1.34,<=1.43 にバンドルされているバージョン。 0.4.13 が最新の安定バージョンです。 バージョン 0.4.11 より前のサーバーを使用すると、名前 Markup を jinja2 からインポートできないなどの Flask の依存関係の問題が示される場合があります。 可能であれば、0.4.13 または 0.8.x (最新バージョン) にアップグレードすることをお勧めします。
  • 0.6.x: 推論イメージ 20220516 以下にプレインストールされているバージョン。 最新の安定バージョンは 0.6.1 です。
  • 0.7.x: Flask 2 をサポートする最初のバージョン。 最新の安定バージョンは 0.7.7 です。
  • 0.8.x: ログ形式が変更され、Python 3.6 のサポートがドロップされました。

パッケージの依存関係

サーバー azureml-inference-server-http に最も関連のあるパッケージは、次のパッケージです。

  • flask
  • opencensus-ext-azure
  • inference-schema

Python 環境で azureml-defaults を指定した場合、azureml-inference-server-http パッケージが依存しており、自動的にインストールされます。

ヒント

Python SDK v1 を使用していて、Python 環境で azureml-defaults を明示的に指定しない場合、SDK によりパッケージが追加される場合があります。 しかし、SDK のバージョンに固定されます。 たとえば、SDK のバージョンが1.38.0 の場合、この環境の PIP 要件に azureml-defaults==1.38.0 が追加されます。

よく寄せられる質問

1. サーバーの起動時に次のエラーが発生しました:


TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

Python 環境に Flask 2 がインストールされているが、Flask 2 をサポートしていないバージョンの azureml-inference-server-http が実行されています。 Flask 2 のサポートも azureml-inference-server-http>=0.7.0 に追加されています。これは azureml-defaults>=1.44 にも追加されています。

  • AzureML Docker イメージでこのパッケージを使用していない場合、azureml-inference-server-http または azureml-defaults の最新バージョンを使用します。

  • AzureML Docker イメージでこのパッケージを使用している場合は、2022 年 7 月以降にビルドされたイメージを使用していることを確認してください。イメージのバージョンは、コンテナー ログで確認できます。 次のようなログが見つかるはずです。

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materializaton Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    イメージのビルド日は、上の例では 20220708 または 2022 年 7 月 8 日と、"Materialization Build" の後に表示されます。 このイメージは Flask 2 と互換性があります。 このようなバナーがコンテナー ログに表示されない場合、イメージは古く、更新する必要があります。 CUDA イメージを使用していて、新しいイメージが見つからない場合は、AzureML-Containers でイメージが非推奨になっていないかを検査してください。 その場合は、代わりのものを見つけることができるはずです。

  • サーバーとオンライン エンドポイントを併用している場合は、Azure Machine Learning スタジオのオンライン エンドポイント ページの [デプロイ ログ] の下にログを見つけることができます。 SDK v1 を使用してデプロイし、デプロイ構成でイメージを明示的に指定しない場合、既定ではローカル SDK ツールセットに一致するバージョンの openmpi4.1.0-ubuntu20.04 が使用されます。これは、イメージの最新バージョンではない可能性があります。 たとえば、SDK 1.43 では既定で openmpi4.1.0-ubuntu20.04:20220616 が使用され、これには互換性がありません。 デプロイに最新の SDK を使用していることを確認します。

  • 何らかの理由でイメージを更新できない場合は、azureml-defaults==1.43 または azureml-inference-server-http~=0.4.13 をピン留めして、Flask 1.0.x を備えた古いバージョンのサーバーをインストールすることで、問題を一時的に回避できます。

2. 起動時にモジュール opencensus、jinja2、MarkupSafe、または click で、次のようなメッセージを含む ImportError または ModuleNotFoundError が発生しました。

ImportError: cannot import name 'Markup' from 'jinja2'

以前のバージョン (<= 0.4.10) のサーバーでは、Flask の依存関係が互換性のあるバージョンにピン留めされませんでした。 この問題は、最新バージョンのサーバーで修正されています。

次のステップ