リモートでのモデル デプロイのトラブルシューティング

Azure Machine Learning を使用して Azure Container Instances (ACI) と Azure Kubernetes Service (AKS) にモデルをデプロイするときに発生する可能性がある一般的なエラーのトラブルシューティングと解決、または回避方法について説明します。

前提条件

• Azure サブスクリプション。 無料版または有料版の Azure Machine Learning をお試しください。
• Azure Machine Learning SDK。
• Azure CLI。
• Azure Machine Learning 用 CLI 拡張機能 v1。

機械学習モデルの Docker デプロイの手順

Azure Machine Learning で非ローカル コンピューティングにモデルをデプロイすると、次のことが行われます。

1. InferenceConfig の Environments オブジェクトに指定した Dockerfile が、ソース ディレクトリの内容と共にクラウドに送信されます
2. 以前にビルドされたイメージがコンテナー レジストリで利用できない場合は、新しい Docker イメージがクラウド内でビルドされ、ワークスペースの既定のコンテナー レジストリに格納されます。
3. コンテナー レジストリの Docker イメージが、コンピューティング先にダウンロードされます。
4. ワークスペースの既定の BLOB ストアがコンピューティング先にマウントされ、登録済みのモデルにアクセスできるようになります
5. エントリ スクリプトの init() 関数を実行して、Web サーバーが初期化されます
6. デプロイされたモデルが要求を受け取ると、run() 関数によってその要求が処理されます

ローカル デプロイを使用する場合の主な違いは、コンテナー イメージがローカル コンピューターでビルドされることです。そのため、ローカル デプロイ用に Docker をインストールする必要があります。

こうした大まかな手順を理解することは、エラーが発生している場所を把握するのに役立ちます。

デプロイ ログを取得する

エラーをデバッグする最初のステップは、デプロイ ログを取得することです。 最初に、こちらの手順に従って、ワークスペースに接続します。

az ml service get-logs --verbose --workspace-name <my workspace name> --name <service name>

print(ws.webservices)

# Choose the webservice you are interested in

from azureml.core import Webservice

service = Webservice(ws, '<insert name of webservice>')
print(service.get_logs())

ローカル環境でデバッグする

モデルを ACI または AKS にデプロイする際に問題が発生した場合は、ローカル Web サービスとしてデプロイしてください。 ローカル Web サービスを使用すると、問題のトラブルシューティングが簡単になります。 ローカル環境でのデプロイのトラブルシューティングについては、ローカル環境でのトラブルシューティングに関する記事をご覧ください。

Azure Machine Learning 推論 HTTP サーバー

ローカル推論サーバーを使用すると、エントリ スクリプト (score.py) をすばやくデバッグできます。 基になるスコア スクリプトにバグがある場合、サーバーはモデルの初期化や提供に失敗します。 代わりに、例外と、問題が発生した場所がスローされます。 Azure Machine Learning 推論 HTTP サーバーの詳細

1. Pypi フィードから azureml-inference-server-http パッケージをインストールします。

   python -m pip install azureml-inference-server-http
   

2. サーバーを起動し、エントリ スクリプトとして score.py を設定します。

   azmlinfsrv --entry_script score.py
   

3. curl を使用して、スコアリング要求をサーバーに送信します。

   curl -p 127.0.0.1:5001/score
   

コンテナーをスケジュールできない

Azure Kubernetes Service のコンピューティング先にサービスをデプロイするとき、Azure Machine Learning は要求された量のリソースを使ってサービスのスケジュールを試みます。 5 分後に、適切な量のリソースがある利用可能なノードがクラスターにない場合、デプロイは失敗します。 エラー メッセージは Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00 です。 このエラーに対処するには、ノードを追加するか、ノードの SKU を変更するか、またはサービスで必要なリソースを変更します。

通常、このエラー メッセージでは、追加する必要があるリソースが示されます。たとえば、"0/3 nodes are available: 3 Insufficient nvidia.com/gpu" というエラー メッセージが表示された場合、これは、サービスに GPU が必要であり、クラスターの 3 つのノードには利用可能な GPU がないことを意味します。 これに対処するには、ノードを追加するか (GPU SKU を使用している場合)、GPU 対応の SKU に切り替えるか (SKU が GPU 対応でない場合)、GPU を必要としないように環境を変更します。

サービスを起動できない

イメージが正常にビルドされると、システムはデプロイ構成を使ってコンテナーの開始を試みます。 コンテナーの開始プロセスの一環として、スコアリング スクリプトの init() 関数がシステムによって呼び出されます。 init() 関数でキャッチされない例外がある場合、エラー メッセージに CrashLoopBackOff エラーが表示されることがあります。

「Docker ログを確認する」記事の情報を使ってください。

コンテナー azureml-fe-aci 起動が失敗する

Azure Container Instances コンピューティング先にサービスをデプロイするとき、Azure Machine Learning では、推論要求に名前 azureml-fe-aci が与えられるフロントエンド コンテナーの作成が試行されます。 azureml-fe-aci がクラッシュした場合、az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci を実行することでログを閲覧できます。 ログに含まれるエラー メッセージに従って修正できます。

azureml-fe-aci の最も一般的なエラーは、指定された SSL 証明書またはキーが無効になっていることです。

get_model_path() 関数が失敗する

スコアリング スクリプトの init() 関数では、コンテナー内のモデル ファイルまたはモデル ファイルのフォルダーを見つけるために、Model.get_model_path() 関数が呼び出されることがよくあります。 モデル ファイルまたはフォルダーが見つからない場合、この関数は失敗します。 このエラーをデバッグする最も簡単な方法は、Container シェルで以下の Python コードを実行することです。

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

from azureml.core.model import Model
import logging
logging.basicConfig(level=logging.DEBUG)
print(Model.get_model_path(model_name='my-best-model'))

この例では、スコアリング スクリプトによってモデル ファイルまたはフォルダーの存在が予期されるコンテナー内のローカル パス (/var/azureml-app の相対パス) が出力されます。 その後、ファイルまたはフォルダーが想定される場所であるかどうかを確認できます。

ログ レベルを DEBUG に設定すると、追加情報がログに記録される可能性があり、エラーの特定に役立つ場合があります。

run(input_data) 関数が失敗する

サービスは正常にデプロイされたのに、スコアリング エンドポイントにデータを送るとクラッシュする場合は、代わりに詳細なエラー メッセージが返されるように、run(input_data) 関数にエラー キャッチ ステートメントを追加できます。 次に例を示します。

def run(input_data):
    try:
        data = json.loads(input_data)['data']
        data = np.array(data)
        result = model.predict(data)
        return json.dumps({"result": result.tolist()})
    except Exception as e:
        result = str(e)
        # return error message back to the client
        return json.dumps({"error": result})

注意: run(input_data) の呼び出しからエラー メッセージを返すことは、デバッグのためにのみ行う必要があります。 セキュリティ上の理由から、運用環境ではこの方法でエラー メッセージを返さないでください。

HTTP 状態コード 502

502 状態コードは、サービスが例外をスローしたか、score.py ファイルの run() メソッドでクラッシュしたことを示します。 この記事の情報を使用して、ファイルをデバッグします。

HTTP 状態コード 503

Azure Kubernetes Service のデプロイでは、自動スケールがサポートされているため、レプリカを加えて、追加の負荷に対応することができます。 自動スケーラーは、段階的な負荷の変化に対処するように設計されています。 1 秒間に受信する要求の量が急増した場合、クライアントは HTTP 状態コード 503 を受け取る可能性があります。 自動スケーラーはすばやく反応しますが、AKS が追加のコンテナーを作成するにはかなりの時間がかかります。

スケールアップとスケールダウンの決定は、現在のコンテナー レプリカの使用率に基づきます。 ビジー状態 (要求を処理中) のレプリカの数を現在のレプリカの総数で割った値が、現在の使用率です。 この値が autoscale_target_utilization を超えると、さらにレプリカが作成されます。 これが下回ると、レプリカが減少します。 レプリカの追加は早期にすばやく行われます (約 1 秒)。 レプリカの削除は慎重に行われます (約 1 分)。 既定では、自動スケールの目標使用率は 70% に設定されています。これは、1 秒あたりに受信する要求の量 (RPS) が最大 30% 増加した場合まで対処できることを意味します。

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

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

  重要

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

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

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

  レプリカの最小数を増やすには、autoscale_min_replicas をより大きな値に設定します。 必要なレプリカの数は、次のコードを使って計算できます。値は、実際のプロジェクトに固有の値に置き換えてください。

  from math import ceil
  # target requests per second
  targetRps = 20
  # time to process the request (in seconds)
  reqTime = 10
  # Maximum requests per container
  maxReqPerContainer = 1
  # target_utilization. 70% in this example
  targetUtilization = .7
  
  concurrentRequests = targetRps * reqTime / targetUtilization
  
  # Number of container replicas
  replicas = ceil(concurrentRequests / maxReqPerContainer)
  

  注意

  新しい最小レプリカが処理できるよりも大きい要求スパイクを受信した場合は、再び 503 を受け取る可能性があります。 たとえば、サービスへのトラフィックが増えたら、レプリカの最小数を増やすことが必要な場合があります。

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

HTTP 状態コード 504

504 状態コードは、要求がタイムアウトしたことを示します。既定のタイムアウトは 1 分です。

タイムアウトを長くするか、score.py を変更して不要な呼び出しを削除し、サービスの高速化を試みることができます。 これらのアクションで問題が解決しない場合は、この記事の情報を使用して score.py ファイルをデバッグします。 コードが応答しない状態または無限ループである可能性があります。

その他のエラー メッセージ

以下のエラーには次のように対処します。

高度なデバッグ

モデル デプロイに含まれる Python コードの対話的なデバッグが必要になる場合があります。 たとえば、エントリ スクリプトが失敗し、ログを追加しても理由を特定できない場合があります。 Visual Studio Code と debugpy を使用すると、Docker コンテナー内で実行されているコードにアタッチできます。

詳細については、VS Code での対話型デバッグのガイドを参照してください。

モデル デプロイ ユーザー フォーラム

次のステップ

デプロイの詳細については、以下を参照してください。

• デプロイする方法とその場所
• ローカル環境で実験の実行とデバッグを行う方法