翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # トラブルシューティング 以下のよくある質問は、Amazon SageMaker 非同期推論エンドポイントの問題をトラブルシューティングするのに役立ちます。 ## Q: 自動スケーリングを有効にしました。任意の時点でエンドポイントの背後にあるインスタンス数を調べるにはどうすればよいですか? 以下の方法を使用して、エンドポイントの背後にあるインスタンス数を確認できます。 + SageMaker AI [DescribeEndpoint](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeEndpoint.html) API を使用すると、任意の時点におけるエンドポイントの背後にあるインスタンスの数を記述できます。 + インスタンス数は、Amazon CloudWatch メトリクスを表示することで取得できます。`CPUUtilization` や `MemoryUtilization` などの[エンドポイントインスタンスのメトリクス](https://docs.aws.amazon.com/sagemaker/latest/dg/monitoring-cloudwatch.html#cloudwatch-metrics-jobs)を表示し、1 分間のサンプル数統計を確認します。この数は、アクティブなインスタンスの数と同じである必要があります。次のスクリーンショットは、CloudWatch コンソールでグラフ化された `CPUUtilization` メトリクスを示しています。**統計**は `Sample count` に設定され、**期間**は `1 minute` に設定され、結果の数は 5 です。 ![エンドポイントのアクティブなインスタンス数のグラフが表示された CloudWatch コンソール。](http://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/images/cloudwatch-sample-count.png) ## Q: SageMaker AI コンテナに共通する調整可能な環境変数にはどのようなものがありますか? 以下のテーブルは、SageMaker AI コンテナの一般的な調整可能な環境変数をフレームワークタイプ別にまとめたものです。 **TensorFlow** | 環境変数 | 説明 | | --- | --- | | `SAGEMAKER_TFS_INSTANCE_COUNT` | TensorFlow ベースのモデルの場合、`tensorflow_model_server` バイナリはメモリへのモデルの読み込み、モデルグラフに対する入力の実行、出力の取得を行う操作要素です。通常、このバイナリのインスタンスは 1 つ起動され、エンドポイント内のモデルを処理します。このバイナリは内部でマルチスレッド化されており、推論リクエストに応答するために複数のスレッドを生成します。インスタンスによっては、CPU がある程度 (使用率が 30% 以上) 使用されていても、メモリが十分に活用されていない場合 (使用率が 10% 未満) は、このパラメータを増やすと役立つ場合があります。利用可能な `tensorflow_model_servers` の数を増やすと、一般的にエンドポイントのスループットが向上します。 | | `SAGEMAKER_TFS_FRACTIONAL_GPU_MEM_MARGIN` | このパラメータは、CUDA/cuDNN やその他の GPU ライブラリを初期化するために利用可能な GPU メモリの割合を制御します。`0.2` は利用可能な GPU メモリの 20% が CUDA/cuDNN と他の GPU ライブラリを初期化するために予約され、利用可能な GPU メモリの 80% が TF プロセス全体に均等に割り当てられることを意味します。`allow_growth` オプションが有効になっていない限り、GPU メモリは事前に割り当てられます。 | | `SAGEMAKER_TFS_INTER_OP_PARALLELISM` | これは `inter_op_parallelism_threads` 変数と結びついています。この変数は、独立したノンブロッキング操作で使用されるスレッドの数を決定します。`0` は、システムが適切な数を選択することを意味します。 | | `SAGEMAKER_TFS_INTRA_OP_PARALLELISM` | これは `intra_op_parallelism_threads` 変数と結びついています。これにより、行列の乗算や高速化のための削減などの特定の操作に使用できるスレッド数が決まります。`0` の値は、システムが適切な数を選択することを意味します。 | | `SAGEMAKER_GUNICORN_WORKERS` | これは Gunicorn がリクエストを処理するために生成するように要求されるワーカープロセスの数を制御します。この値を他のパラメータと組み合わせて使用すると、推論スループットを最大化するセットが導出されます。これに加えて、`SAGEMAKER_GUNICORN_WORKER_CLASS` は生成されるワーカーのタイプ (通常は `async` または `gevent`) を決定します。 | | `SAGEMAKER_GUNICORN_WORKER_CLASS` | これは Gunicorn がリクエストを処理するために生成するように要求されるワーカープロセスの数を制御します。この値を他のパラメータと組み合わせて使用すると、推論スループットを最大化するセットが導出されます。これに加えて、`SAGEMAKER_GUNICORN_WORKER_CLASS` は生成されるワーカーのタイプ (通常は `async` または `gevent`) を決定します。 | | `OMP_NUM_THREADS` | Python は、プロセス内でのマルチスレッドの実装に OpenMP を内部的に使用しています。通常、CPU コアの数と同じ数のスレッドが生成されます。しかし、Intel の HypeThreading などの同時マルチスレッディング (SMT) の上に実装すると、特定のプロセスが実際の CPU コア数の 2 倍のスレッドを生成して、特定のコアをオーバーサブスクライブする可能性があります。場合によっては、Python バイナリは、使用可能なプロセッサコアの最大 4 倍のスレッドを生成することがあります。そのため、ワーカースレッドを使用して使用可能なコアをオーバーサブスクライブしている場合、このパラメータの理想的な設定は `1`、または SMT がオンになっている CPU の CPU コア数の半分です。 | | `TF_DISABLE_MKL`
`TF_DISABLE_POOL_ALLOCATOR` | `TF_DISABLE_MKL` と `TF_DISABLE_POOL_ALLOCATOR` が `1` に設定されている場合、MKL をオフにすると推論が速くなる場合があります。 | **PyTorch** | 環境変数 | 説明 | | --- | --- | | `SAGEMAKER_TS_MAX_BATCH_DELAY` | これは TorchServe が受信するまで待機する最大バッチ遅延時間です。 | | `SAGEMAKER_TS_BATCH_SIZE` | タイマーが切れる前に `batch_size` で指定された数のリクエストを受信しなかった場合、TorchServe は受信したリクエストをモデルハンドラに送ります。 | | `SAGEMAKER_TS_MIN_WORKERS` | TorchServe がスケールダウンできるワーカーの最小数。 | | `SAGEMAKER_TS_MAX_WORKERS` | TorchServe がスケールアップできるワーカーの最大数。 | | `SAGEMAKER_TS_RESPONSE_TIMEOUT` | 応答がない場合に推論がタイムアウトになるまでの遅延時間。 | | `SAGEMAKER_TS_MAX_REQUEST_SIZE` | TorchServe の最大ペイロードサイズ。 | | `SAGEMAKER_TS_MAX_RESPONSE_SIZE` | TorchServe の最大レスポンスサイズ。 | **マルチモデルサーバー (MMS)** | 環境変数 | 説明 | | --- | --- | | `job_queue_size` | このパラメータは、推論リクエストのペイロードの種類が大きく、ペイロードのサイズが大きいため、このキューが管理されている JVM のヒープメモリ消費量が増える可能性がある場合の調整に役立ちます。JVM のヒープメモリ要件を低く抑え、Python ワーカーが実際のモデル処理により多くのメモリを割り当てられるようにすることが理想的です。JVM は、HTTP リクエストを受信してキューに入れ、Python ベースのワーカーにディスパッチして推論するためだけのものです。`job_queue_size` を増やすと、JVM のヒープメモリ消費量が増え、最終的には Python ワーカーが使用していたはずのメモリがホストから奪われる可能性があります。そのため、このパラメータを調整する際にも注意が必要です。 | | `default_workers_per_model` | このパラメータはバックエンドモデルサービス用であり、Python が各モデルの生成スレッドを処理するベースとなるモデルサービス全体の重要なコンポーネントであるため、調整することが有益である場合があります。このコンポーネントが遅い (または適切に調整されていない) 場合、フロントエンドの調整には効果がない可能性があります。 | ## Q: コンテナが非同期推論をサポートしていることを確認する方法を教えてください。 非同期推論には、リアルタイム推論や Batch 変換と同じコンテナを使用できます。コンテナのタイムアウトとペイロードサイズの制限が、より大きなペイロードと長いタイムアウトを処理するように設定されていることを確認する必要があります。 ## Q: 非同期推論にはどのような制限がありますか? 非同期推論を調整するこはできますか? 非同期推論については、以下の制限を参照してください。 + ペイロードサイズの制限: 1 GB + タイムアウト制限: リクエストには最大 60 分かかります。 + キューメッセージの TimeToLive (TTL): 6 時間 + Amazon SQS 内に保存できるメッセージの数: 無制限。ただし、標準キューの伝送中メッセージには 120,000 件、FIFO キューには 20,000 件という制限があります。 ## Q: 非同期推論の自動スケーリングにはどのようなメトリクスを定義するのが最適ですか? 複数のスケーリングポリシーを設定できますか? 一般に、非同期推論では、呼び出しまたはインスタンスに基づいてスケールアウトできます。呼び出しメトリクスについては、キュー内のまだ処理されていないアイテムの数を定義するメトリクスである `ApproximateBacklogSize` を確認することをお勧めします。このメトリクスまたは `InvocationsPerInstance` メトリクスを利用して、どの TPS が制限されているかを把握できます。インスタンスレベルでは、インスタンスタイプとその CPU/GPU 使用率を確認して、いつスケールアウトするかを定義します。1 つのインスタンスの容量が 60～70% を超えている場合は、ハードウェアが飽和状態になっていることを示す良い兆候です。 複数のスケーリングポリシーを設定することはお勧めしません。これらのポリシーは、ハードウェアレベルで競合して混乱を招き、スケールアウト時に遅延を引き起こす可能性があります。 ## Q: 非同期エンドポイントがインスタンスを `Unhealthy` として終了させ、自動スケーリングからの更新リクエストが失敗するのはなぜですか? コンテナが ping リクエストと呼び出しリクエストを同時に処理できるかどうかを確認してください。SageMaker AI の呼び出しリクエストには約 3 分かかります。この間、通常、タイムアウトが原因で複数の ping リクエストが失敗し、SageMaker AI はコンテナを `Unhealthy` として検出します。 ## Q: `MaxConcurrentInvocationsPerInstance` は、ningx/gunicorn/flask の設定を持つ BYOC モデルコンテナで機能しますか? はい。`MaxConcurrentInvocationsPerInstance` は非同期エンドポイントの機能です。これはカスタムコンテナの実装には依存しません。`MaxConcurrentInvocationsPerInstance` は呼び出しリクエストがカスタマーコンテナに送信される速度を制御します。この値を `1` として設定すると、カスタマーコンテナに何人のワーカーがいるかに関わらず、一度に 1 つのリクエストのみがコンテナに送信されます。 ## Q: 非同期エンドポイントでモデルサーバーエラー (500) をデバッグする方法を教えてください。 このエラーは、カスタマーコンテナがエラーを返したことを意味します。SageMaker AI はカスタマーコンテナの動作を制御しません。SageMaker AI は `ModelContainer` からの応答を返すだけで、再試行は行いません。必要に応じて、失敗時に呼び出しを再試行するように構成できます。コンテナロギングをオンにし、コンテナログを確認して、モデルの 500 エラーの根本原因を見つけることをお勧めします。障害発生時点で、対応する `CPUUtilization` と `MemoryUtilization` メトリクスも確認してください。また、失敗を調査するための非同期エラー通知の一部として、Amazon SNS のモデル応答に [S3FailurePath](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AsyncInferenceOutputConfig.html#sagemaker-Type-AsyncInferenceOutputConfig-S3FailurePath) を設定することもできます。 ## Q: `MaxConcurrentInvocationsPerInstance=1` が有効になったかどうかはどうすればわかりますか? 確認できるメトリクスはありますか? `InvocationsProcesssed` メトリクスを確認できます。単一同時実行に基づいて 1 分間に処理されると予想される呼び出しの数と一致するはずです。 ## Q: 呼び出しリクエストの成功と失敗を追跡するにはどうすればよいですか? ベストプラクティスにはどのようなものがありますか？ ベストプラクティスは Amazon SNS を有効にすることです。Amazon SNS は、メッセージング指向のアプリケーション向け通知サービスです。HTTP、Amazon SQS、E メールなどのトランスポートプロトコルの選択肢から、複数のサブスクライバーがタイムクリティカルなメッセージの「プッシュ」通知を要求および受信します。`CreateEndpointConfig` を使用してエンドポイントを作成し、Amazon SNS トピックを指定すると、非同期推論により通知が投稿されます。 Amazon SNS を使って非同期エンドポイントからの予測結果をチェックするには、まずトピックを作成してそのトピックをサブスクライブし、トピックのサブスクリプションを確認してから、そのトピックの Amazon リソースネーム (ARN) を把握しておく必要があります。Amazon SNS トピックの Amazon ARN を作成、サブスクライブ、発見する方法の詳細については、「*Amazon SNS 開発者ガイド*」の「[Amazon SNS を設定する](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html)」を参照してください。Amazon SNS を非同期推論で使用する方法の詳細については、「[Check prediction results](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-check-predictions.html)」を参照してください。 ## Q: スケーリングポリシーを定義して、新しいリクエストを受信したときにインスタンスをゼロからスケールアップすることはできますか? はい。非同期推論には、リクエストがない場合にインスタンス数を 0 までスケールダウンするメカニズムがあります。この期間中にエンドポイントのインスタンスがゼロインスタンスにスケールダウンされた場合、キュー内のリクエスト数がスケーリングポリシーで指定された目標を超えるまで、エンドポイントは再びスケールアップされません。その結果、キュー内のリクエストの待ち時間が長くなる可能性があります。このような場合、指定したキューターゲット未満の新しいリクエストに対してゼロインスタンスからスケールアップしたい場合は、`HasBacklogWithoutCapacity` という追加のスケーリングポリシーを使用できます。このスケーリングポリシーの定義方法については、「[非同期エンドポイントをオートスケールする](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-autoscale.html#async-inference-autoscale-scale-up)」を参照してください。 ## Q: インスタンスタイプが非同期推論でサポートされていないというエラーが表示されます。非同期推論ではどのようなインスタンスタイプがサポートされていますか? 非同期推論でサポートされるインスタンスのリージョン別の一覧については、「[SageMaker の料金](https://aws.amazon.com/sagemaker/pricing/)」を参照してください。先に進む前に、必要なインスタンスがリージョンで利用可能かどうかを確認してください。