次の方法で共有

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

  • [アーティクル]

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

この記事では、Azure Machine Learning オンライン エンドポイントのデプロイとスコアリングに関する一般的な問題のトラブルシューティングと解決方法について説明します。

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

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

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

前提条件

要求トレース

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

  • x-request-id はサーバー トレース用に予約されています。 Azure Machine Learning では、このヘッダーが有効な GUID であることを確認するためにオーバーライドされます。 失敗した要求のサポート チケットを作成する場合は、失敗した要求 ID を添付すると調査が迅速になります。 または、リージョン名とエンドポイント名を指定します。

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

ローカルでのデプロイ

ローカル デプロイとは、ローカル Docker 環境にモデルをデプロイすることを意味します。 ローカル デプロイでは、ローカル エンドポイントの作成、更新、削除がサポートされ、エンドポイントからログを呼び出して取得できます。 ローカル デプロイは、クラウドにデプロイする前にテストやデバッグを行う場合に便利です。

ヒント

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

Azure CLI または Python SDK を使用してローカルにデプロイできます。 Azure Machine Learning スタジオでは、ローカル デプロイまたはローカル エンドポイントはサポートされていません。

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

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

次の手順は、ローカル デプロイ中に行われます。

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

詳細については、「ローカル エンドポイントを使用してローカルにデプロイおよびデバッグする」を参照してください。

ヒント

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

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

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

次の種類のコンテナーからログを取得できます。

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

Kubernetes オンライン エンドポイントの場合、管理者は、モデルをデプロイするクラスターに直接アクセスし、Kubernetes のログを確認できます。 次に例を示します。

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

Note

Python ログを使用する場合は、メッセージがログに発行されるように、適切なログ レベル (INFO など) を使用してください。

コンテナーからのログ出力を確認する

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

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

既定では、ログは推論サーバーからプルされます。 –-container storage-initializer を渡すことで、ストレージ初期化子コンテナーからログを取得できます。

az configure を使用してこれらのパラメーターをまだ設定していない場合は、コマンドに --resource-group と --workspace-name を追加します。 これらのパラメーターを設定する方法を表示する場合、または現在値を設定している場合は、次のコマンドを実行します。

az ml online-deployment get-logs -h

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

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

デプロイ操作の状態では、次の一般的なデプロイ エラーが報告される場合があります。

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]'")。

次のセクションでは、イメージ ビルド エラーの一般的なシナリオについて説明します。

Azure Container Registry の認可エラー

エラー メッセージに "container registry authorization failure" と表示されている場合、コンテナー レジストリに現在の資格情報でアクセスできません。 このエラーは、ワークスペース リソースのキーの非同期化によって発生する可能性があり、自動的に同期されるまでに時間がかかります。 ただし、az ml workspace sync-keys を使用してキー同期を手動で呼び出すことで、認可エラーを解決できる場合があります。

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

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

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

イメージ ビルドのタイムアウト

イメージ ビルドのタイムアウトは、多くの場合、イメージが大きくなりすぎて、デプロイの作成期間内にビルドを完了できないことが原因です。 エラーで指定されている場所でイメージ ビルド ログを確認します。 ログは、イメージ ビルドがタイムアウトした時点で遮断されます。

これを解決するには、デプロイの作成時にのみイメージをプルするように、イメージを個別にビルドしてください。 ImageBuild のタイムアウトがある場合は、既定のプローブ設定も確認してください。

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

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

モデルをクラウドにデプロイする前に、ローカルにデプロイして、モデルをテストおよびデバッグしてみてください。

ERROR: OutOfQuota

Azure サービスを使用すると、次のリソースのクォータが不足する可能性があります。

Kubernetes オンライン エンドポイントの場合のみ、Kbernetes リソースもクォータ不足になる可能性があります。

CPU クォータ

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

削除できる未使用のデプロイがあるかどうかを確認したり、クォータの引き上げ要求を送信することができます。

クラスターのクォータ

OutOfQuota エラーは、十分な Azure Machine Learning コンピューティング クラスター クォータがない場合に発生します。 このクォータは、Azure クラウドに CPU または GPU ノードをデプロイするために同時に使用できるサブスクリプションあたりのクラスターの合計数を定義します。

ディスク クォータ

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

メモリ クォータ

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

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

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

エンドポイント クォータ

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

Kubernetes クォータ

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

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

この問題に対処するために、次の軽減策を試してみてください。

  • Kubernetes クラスターを維持する IT 担当者は、ノードを追加するか、クラスター内の未使用のポッドをクリアして、一部のリソースを解放することができます。

  • モデルをデプロイする機械学習エンジニアは、デプロイのリソース要求を減らすことができます。

    • リソース セクションからデプロイ構成のリソース要求を直接定義している場合は、リソース要求を減らしてみてください。
    • instance_type を使用してモデル デプロイのリソースを定義している場合は、IT オペレーターに問い合わせてインスタンスの種類のリソース構成を調整してください。 詳細については、「インスタンスの種類の作成と管理」を参照してください。

リージョン全体の VM 容量

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

その他のクォータ

デプロイの一部として指定した score.py ファイルを実行するために、Azure は、score.py が必要とするすべてのリソースを含むコンテナーを作成します。 その後、Azure Machine Learning は、そのコンテナーでスコアリング スクリプトを実行します。 コンテナーを開始できない場合、スコアリングを行うことはできません。 コンテナーは、instance_type がサポートできるよりも多くのリソースを要求している可能性があります。 オンライン デプロイの instance_type を更新することを検討してください。

エラーの正確な理由を取得するには、次のアクションを実行します。

次のコマンドを実行します。

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

ERROR: BadArgument

マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントを使用する場合に、次の理由により、このエラーが発生する可能性があります。

次の理由により、Kubernetes オンライン エンドポイントを使用する場合にのみ、このエラーが発生する可能性があります。

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

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

認証エラー

デプロイの作成時にコンピューティング リソースをプロビジョニングすると、Azure はワークスペース コンテナー レジストリからユーザー コンテナー イメージをプルし、ユーザー モデルとコード成果物をワークスペース ストレージ アカウントからユーザー コンテナーにマウントします。 Azure はマネージド ID を使用してストレージ アカウントとコンテナー レジストリにアクセスします。

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

システム割り当て ID と関連付けられたエンドポイントを作成する場合は、Azure のロールベースのアクセス制御 (RBAC) のアクセス許可が自動的に付与されるので、それ以上のアクセス許可は必要ありません。 詳細については、「コンテナー レジストリの認証エラー」を参照してください。

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

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

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

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

コンテナー イメージがワークスペース コンテナー レジストリで使用できることを確認します。 たとえば、イメージが 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 の場合は、次のコマンドを使用して BLOB が存在するかどうかを確認できます。

az storage blob exists --account-name <storage-account-name> --container-name <container-name> --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 モデル形式はサポートされていません

マネージド オンライン エンドポイントに対して従来のネットワーク分離方法を使用している場合は、MLflow モデル形式でプライベート ネットワーク機能を使用することはできません。 コードなしのデプロイ アプローチで MLflow モデルをデプロイする必要がある場合は、ワークスペースのマネージド 仮想ネットワークを使用してみてください。

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

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

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

デプロイされたサービスへ受信推論要求をルーティングするフロントエンド azureml-fe コンポーネントは、k8s-extension のインストール中にインストールされ、必要に応じて自動的にスケーリングされます。 このコンポーネントには、クラスター上に少なくとも 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 を試してみてください。初期化にかかる時間が短縮されます。

  • 依存関係が不足しているなど、コンテナーの環境設定にエラーがある。

    TypeError: register() takes 3 positional arguments but 4 were given エラーが発生した場合は、flask v2 と azureml-inference-server-http の間の依存関係を確認してください。 詳細については、「HTTP サーバーの問題のトラブルシューティング」を参照してください。

ERROR: ResourceNotFound

マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントを使用する場合に、次の理由により、このエラーが発生する可能性があります。

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

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

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

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

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

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

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

診断について詳しくは、「ワークスペース診断の使用方法」を参照してください。

ERROR: WorkspaceManagedNetworkNotReady

このエラーは、ワークスペースのマネージド仮想ネットワークを有効にするオンライン デプロイを作成しようとしても、マネージド仮想ネットワークがまだプロビジョニングされていない場合に発生します。 オンライン デプロイを作成する前に、ワークスペースのマネージド仮想ネットワークをプロビジョニングしてください。

ワークスペースのマネージド仮想ネットワークを手動でプロビジョニングするには、「マネージド VNET を手動でプロビジョニングする」の手順に従います。 その後、オンライン デプロイの作成を開始できます。 詳細については、「マネージド オンライン エンドポイントでのネットワークの分離」と「ネットワーク分離を使用してマネージド オンライン エンドポイントをセキュリティで保護する」を参照してください。

エラー: OperationCanceled

マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイントを使用する場合に、次の理由により、このエラーが発生する可能性があります。

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

Azure の操作には、優先度レベルが割り当てられており、高いものから順に実行されます。 このエラーは、行っている操作が優先度の高い別の操作によって上書きされた場合に発生します。 操作を再試行すると、キャンセルせずに操作を実行できる場合があります。

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

Azure の操作には送信後短い待機期間があり、その間操作はロックを取得し、競合状態が発生しないようにしています。 このエラーは、送信した操作が他の操作と同じ場合に発生します。 その間、他の操作はロックを受け取ったかという確認を待ってから、続行されます。

最初の要求の後に同様の要求を送信した可能性があります。 最大 1 分待ってから操作を再試行すると、キャンセルせずに実行できる場合があります。

ERROR: SecretsInjectionError

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

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

  • シークレット参照の形式が無効であるか、指定されたシークレットがワークスペース接続やキー コンテナー内に存在しません。

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

ERROR: InternalServerError

このエラーは、Azure Machine Learning サービスに修正が必要な問題があることを意味します。 問題に対処するために必要なすべての情報を記載のうえ、カスタム サポート チケットを送信してください。

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

ID と認証のエラー:

Crashloopbackoff エラー:

スクリプト エラーのスコアリング:

その他のエラー:

エラー: ACRSecretError

Kubernetes オンライン デプロイを作成または更新する場合、次のいずれかの理由でこのエラーが発生する可能性があります。

  • ロールの割り当てが完了していません。 数秒待ってから、もう一度やり直してください。

  • Azure Arc 対応 Kubernetes クラスターまたは AKS Azure Machine Learning 拡張機能のインストールや構成が正しく行われていません。 Azure Arc 対応 Kubernetes または Azure Machine Learning 拡張機能の構成と状態を確認してください。

  • Kubernetes クラスターのネットワーク構成が不適切です。 プロキシ、ネットワーク ポリシー、または証明書を確認してください。

  • プライベート AKS クラスターに適切なエンドポイントがありません。 Container Registry、ストレージ アカウント、および AKS 仮想ネットワーク内のワークスペースにプライベート エンドポイントを設定していることを確認してください。

  • Azure Machine Learning 拡張機能のバージョンが v1.1.25 以下です。 拡張機能のバージョンが v1.1.25 以上であることを確認してください。

エラー: TokenRefreshFailed

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

エラー: GetAADTokenFailed

このエラーは、Kubernetes クラスター要求 Microsoft Entra ID トークンが失敗またはタイムアウトしたために発生します。ネットワーク アクセスを確認してから、もう一度やり直してください。

  • 「Kubernetes コンピューティングを使用する」の手順に従って送信プロキシを確認し、クラスターがワークスペースに接続できることを確認します。 ワークスペース エンドポイントの URL は、クラスター内のオンライン エンドポイントのカスタム リソース定義 (CRD) にあります。

  • ワークスペースでパブリック アクセスが許可されているかどうかを確認します。 AKS クラスター自体がパブリックかプライベートかに関係なく、プライベート ワークスペースで公衆ネットワーク アクセスが無効になっている場合、Kubernetes クラスターはプライベート リンクを介してのみそのワークスペースと通信できます。 詳細については、「セキュリティで保護された AKS 推論環境」を参照してください。

エラー: ACRAuthenticationChallengeFailed

このエラーは、Kubernetes クラスターが認証チャレンジを実行するためにワークスペース Container Registry サービスに到達できないために発生します。 ネットワーク (特に Container Registry 公衆ネットワーク アクセス) を確認してから、もう一度やり直してください。 「GetAADTokenFailed」のトラブルシューティング手順に従って、ネットワークをチェックします。

エラー: ACRTokenExchangeFailed

このエラーは、Microsoft Entra ID トークンがまだ承認されておらず、Kubernetes クラスター交換の Container Registry トークンが失敗するために発生します。 ロールの割り当てには時間がかかるため、少し待ってからやり直してください。

このエラーは、Container Registry サービスに対する同時要求が多すぎることが原因である可能性もあります。 このエラーは一時的なもので、後でもう一度試すことができます。

ERROR: KubernetesUnaccessible

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

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

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

ERROR: ImagePullLoopBackOff

Kubernetes オンライン デプロイを作成または更新する場合に、コンテナー レジストリからイメージをダウンロードできず、イメージのプル エラーが発生するため、このエラーが発生する可能性があります。 クラスター ネットワーク ポリシーとワークスペース コンテナー レジストリを確認して、クラスターがコンテナー レジストリからイメージをプルできるかどうかを確認します。

エラー: DeploymentCrashLoopBackOff

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

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

このエラーを軽減するには、まずデプロイ ログ内で、ユーザー スクリプトに例外がないか確認します。 エラーが解決しない場合は、リソース/インスタンスの種類のメモリ制限を拡張してみてください。

エラー: KubernetesCrashLoopBackOff

Kubernetes オンライン エンドポイントまたはデプロイを作成または更新する場合に、次のいずれかの理由で、このエラーが発生する可能性があります。

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

エラー: NamespaceNotFound

Kubernetes オンライン エンドポイントを作成または更新する場合に、Kubernetes コンピューティングで使用されている名前空間がクラスターで使用できないため、このエラーが発生する可能性があります。 ワークスペース ポータルで Kubernetes コンピューティングを確認し、Kubernetes クラスター内の名前空間を確認します。 名前空間が使用できない場合は、レガシ コンピューティングをデタッチし、再アタッチして新しいコンピューティングを作成し、クラスターに既に存在する名前空間を指定します。

エラー: UserScriptInitFailed

アップロードした score.py ファイルの init 関数で例外が発生したため、Kubernetes オンライン デプロイを作成または更新する場合に、このエラーが発生する可能性があります。 デプロイ ログで例外メッセージの詳細を確認し、例外を修正します。

エラー: 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 オンライン エンドポイントまたはデプロイを作成または更新する場合に、次のいずれかの理由で、このエラーが発生する可能性があります。

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

このエラーを軽減するには、次の手順に従います。

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

エラー: PodOutOfMemory

オンライン デプロイを作成または更新する場合に、デプロイに対して指定したメモリ制限が不十分であるため、このエラーが発生する可能性があります。 このエラーを軽減するために、メモリ制限の設定値を大きくするか、もっと大きなインスタンスの種類を使用することができます。

エラー: InferencingClientCallFailed

Kubernetes オンライン エンドポイントまたはデプロイを作成または更新する場合に、Kubernetes クラスターの k8s 拡張機能が接続できないため、このエラーが発生する可能性があります。 この場合は、コンピューティングをデタッチしてから再アタッチします。

再アタッチによるエラーのトラブルシューティングを行うには、他のエラーを回避するために、デタッチされたコンピューティングと同じ構成 (コンピューティング名や名前空間など) を使用して再アタッチしてください。 それでも解決しない場合は、クラスターにアクセスできる管理者に、kubectl get po -n azureml を使用して中継サーバー ポッドが実行されているかどうか検査してもらってください。

モデルの使用に関する問題

エンドポイント invoke 操作状態に起因する一般的なモデル使用エラーには、帯域幅制限の問題、CORS ポリシー、さまざまな HTTP 状態コードが含まれます。

帯域幅の制限の問題

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

帯域幅の遅延を監視するには、[ネットワーク バイト] メトリックを使用して現在の帯域幅の使用状況を把握します。 詳細については、「マネージド オンライン エンドポイントを監視する」を参照してください。

帯域幅の制限が適用されている場合は、次の 2 つの応答トレーラーが返されます。

  • ms-azureml-bandwidth-request-delay-ms は、要求ストリームの転送にかかった延期期間 (ミリ秒単位) です。
  • ms-azureml-bandwidth-response-delay-ms は、応答ストリームの転送にかかった延期期間 (ミリ秒単位) です。

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、または別のサービスを使用できます。

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 probe または readiness probe の失敗が伴う場合は、コンテナーのライブ性または準備状態をプローブする時間を長くできるように ProbeSettings を調整することを検討してください。
429 保留中の要求が多すぎます モデルで現在、処理できる数よりも多くの要求を受信しています。 円滑な操作を保証するために、Azure Machine Learning では、任意の時点で最大 2 * max_concurrent_requests_per_instance * instance_count requests の並列処理を許可しています。 この最大値を超える要求は拒否されます。

request_settings セクションと scale_settings セクションでモデルのデプロイ構成を確認し、これらの設定を確認して調整できます。 また、RequestSettings で説明されているように、環境変数 WORKER_COUNT が正しく渡されていることを確認します。

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

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

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

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

503 状態コードを防ぐ方法

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

2 つのアクションは、503 状態コード エラーを防ぐのに役立ちます。新しいレプリカを作成するために使用率レベルを変更するか、レプリカの最小数を変更します。 これらの方法は、個別に、または組み合わせて使用できます。

  • autoscale_target_utilization を小さい値に設定して、自動スケーリングによって新しいレプリカが作成される使用率ターゲットを変更します。 この変更により、レプリカの作成時間が短縮されるのではなく、使用率のしきい値が低くなります。 たとえば、値を 30% に変更すると、サービスの使用率が 70% になるまで待機するのでなく、使用率が 30% になった段階でレプリカが作成されます。

  • レプリカの最小数を変更して、受信の増加を処理できる大きなプールを提供します。

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

インスタンスの数を増やすために、次のように必要なレプリカの数を計算できます。

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)

Note

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

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

ネットワークの分離に関する問題

このセクションでは、ネットワークの分離に関する一般的な問題について説明します。

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

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

v1_legacy_mode を無効にするには、「v2 によるネットワークの分離」を参照してください。

重要

v1_legacy_mode を無効にする前に、ネットワーク セキュリティ チームに確認してください。理由があって有効にしている可能性があるためです。

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

次のコマンドを使用して、ワークスペース用の 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 フラグがデプロイに対して disabled となっているかどうかを確認します。 このフラグが有効で、コンテナー レジストリの可視性がプライベートである場合、この失敗が予想されます。

  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

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

    Note

    • Kubernetes オンライン エンドポイントの場合、エンドポイントのホスト名は、Kubernetes クラスターで指定されている CName (ドメイン名) である必要があります。
    • エンドポイントが HTTP の場合、IP アドレスはエンドポイント URI に含まれ、スタジオ UI から取得できます。
    • エンドポイントの IP アドレスを取得する他の方法については、「セキュリティで保護された 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 からの解決が正しく動作することを確認します。

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"

  3. curl HTTP が失敗するかタイムアウトしても HTTP が機能する場合は、証明書が有効かどうかを確認します。

  4. 上記のプロセスで A レコードへの解決に失敗した場合は、解決が Azure DNS (168.63.129.16) から機能するかどうかを確認します。

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

  5. 上記のコマンドが成功した場合は、カスタム 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>

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

推論サーバーの問題

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

インストールしたパッケージを確認する

インストールされているパッケージに関する問題に対処するには、次の手順に従います。

  1. Python 環境にインストールされているパッケージとバージョンに関する情報を収集します。

  2. 環境ファイル内で指定されている azureml-inference-server-http Python パッケージのバージョンが、スタートアップ ログに表示される Azure Machine Learning 推論 HTTP サーバーのバージョンと一致していることを確認します。

    場合によっては、pip 依存関係リゾルバーによって予期しないパッケージ バージョンがインストールされます。 インストールされているパッケージとバージョンを修正するには、pip を実行する必要がある場合があります。

  3. ご利用の環境で Flask またはその依存関係を指定している場合は、それらの項目を削除します。

    • 依存パッケージには、flask、jinja2、itsdangerous、werkzeug、markupsafe、click が含まれます。
    • flask は、サーバー パッケージの依存関係として一覧表示されます。 最適な方法は、推論サーバーが flask パッケージをインストールできるようにすることです。
    • 推論サーバーが新しいバージョンの Flask をサポートするように構成されている場合、サーバーは、パッケージの更新プログラムが利用可能になるとこれを自動的に受け取ります。

サーバーのバージョンを確認する

サーバー パッケージ azureml-inference-server-http は PyPI に公開されています。 PyPI ページには、変更ログと以前のすべてのバージョンが一覧表示されます。

以前のバージョンのパッケージを使用している場合は、構成を最新バージョンに更新します。 次の表は、安定したバージョン、よくある問題、推奨される調整をまとめたものです。

パッケージのバージョン 説明 問題 解決策
0.4.x 日付が 20220601 以前および azureml-defaults パッケージ バージョン .1.34 から 1.43 のトレーニング イメージにバンドルされています。 最新の安定バージョンは 0.4.13 です。 0.4.11 より前のバージョンのサーバーの場合、"can't import name Markup from 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 の場合、azureml-defaults==1.38.0 エントリがこの環境の pip 要件に追加されます。

サーバーのスタートアップ時に TypeError が発生する

サーバーの起動時に、次の TypeError が発生することがあります。

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 がインストールされているが、azureml-inference-server-http パッケージ バージョンが Flask 2 をサポートしていない場合に発生します。 Flask 2 のサポートは、azureml-inference-server-http パッケージ バージョン 0.7.0 以降、および azureml-defaults パッケージ バージョン 1.44 以降で利用できます。

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

  • Azure Machine Learning Docker イメージで Flask 2 パッケージを使用する場合は、イメージのビルド バージョンが 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, Materialization Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    イメージのビルド日は、Materialization Build 表記の後に表示されます。 前の例では、イメージのバージョンは 20220708 (2022 年 7 月 8 日) です。 この例のイメージは 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 1.43 と互換性がありません。 デプロイに最新の SDK を使用していることを確認します。

イメージを更新できない場合は、環境ファイルに azureml-defaults==1.43 エントリまたは azureml-inference-server-http~=0.4.13 エントリをピン留めすることで、一時的に問題を回避できます。 これらのエントリは、flask 1.0.x を使用して古いバージョンをインストールするようにサーバーに指示します。

サーバーのスタートアップ時に ImportError または ModuleNotFoundError が発生する

サーバーの起動時に、opencensus、jinja2、markupsafe、click など、特定のモジュールで ImportError または ModuleNotFoundError が発生することがあります。 次の例は、エラー メッセージを示しています。

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

インポートとモジュールのエラーは、Flask の依存関係を互換性のあるバージョンにピン留めしない 0.4.10 以前のバージョンのサーバーを使用すると発生します。 この問題を回避するには、それ以降のバージョンのサーバーをインストールします。

その他の一般的な問題

その他の一般的なオンライン エンドポイントの問題は、Conda のインストールと自動スケーリングに関連しています。

Conda のインストールに関する問題

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

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

  1. Conda のインストール ログを確認します。 コンテナーがクラッシュした場合、または起動に時間がかかりすぎる場合は、Conda 環境の更新が正しく解決できなかった可能性があります。
  2. conda env create -n userenv -f <CONDA_ENV_FILENAME> コマンドを使用して mlflow conda ファイルをローカルにインストールします。
  3. ローカルでエラーが発生した場合は、再デプロイする前に、Conda 環境を解決し、機能環境を作成してみてください。
  4. ローカルで解決されてもコンテナーがクラッシュする場合は、デプロイに使用される SKU サイズが小さすぎる可能性があります。
    • Conda パッケージのインストールは実行時に行われるため、SKU サイズが小さすぎて conda.yml 環境ファイルのすべてのパッケージに対応できない場合、コンテナーがクラッシュする可能性があります。
    • Standard_F4s_v2 VM は SKU の開始サイズとして適していますが、Conda ファイルで指定されている依存関係によっては、より大きな VM が必要になる場合があります。
    • Kubernetes オンライン エンドポイントの場合、Kubernetes クラスターには、少なくとも 4 つの vCPU コアと 8 GB のメモリが必要です。

自動スケールの問題

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

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

関連するコンテンツ