翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# インスタンスプールを使用して複数のインスタンスタイプにデプロイする
モデルを SageMaker AI エンドポイントにデプロイする場合、通常、本番稼働用バリアントに単一のインスタンスタイプを指定します。そのインスタンスタイプがターゲットアベイラビリティーゾーンで使用できない場合、デプロイは容量不足エラー (ICE) で失敗し、別のインスタンスタイプで手動で再試行する必要があります。
インスタンスプールでは、本番稼働用バリアントに最大 5 つのインスタンスタイプの順序付きリストを指定できます。SageMaker AI は、優先度の高いタイプ (優先度 1) から開始してインスタンスのプロビジョニングを試み、容量が利用できない場合、優先度の低いタイプに自動的にフォールバックします。これにより、手動で再試行する必要がなくなり、エンドポイントの可用性が向上します。
インスタンスプールは、リアルタイム推論エンドポイントと非同期推論エンドポイントの両方をサポートします。単一モデルエンドポイントと推論コンポーネントで使用できます。
次の手順では、インスタンスプールのプロビジョニングの仕組みについて説明します。
1. SageMaker AI は、最も優先度の高いプール (優先度 1) からインスタンスをプロビジョニングしようとします。
1. 現在のインスタンスタイプで容量不足エラー (ICE) が発生した場合、SageMaker AI は優先度順に次のプールに自動的にフォールバックします。
1. これは、必要な数のインスタンスがプロビジョニングされるか、すべてのプールが使い果たされるか、プロビジョニングタイムアウトの合計 (`VariantInstanceProvisionTimeoutInSeconds`) に達するまで続きます。
**Topics**
+ [インスタンスプールを使用してエンドポイントを設定する](#heterogeneous-endpoint-setup)
+ [インスタンスプールのモニタリング](#heterogeneous-endpoint-observability)
+ [インスタンスプールによる自動スケーリング](#heterogeneous-endpoint-autoscaling)
## インスタンスプールを使用してエンドポイントを設定する
インスタンスプールを使用するには、本番稼働用バリアントの `InstanceType`パラメータを `InstancePools`リストに置き換えます。各エントリは、インスタンスタイプと優先度 (1 ～ 5、1 が最上位) を指定します。オプションで `VariantInstanceProvisionTimeoutInSeconds` (300～3600 秒) を設定して、オペレーションが失敗する前に SageMaker AI がすべてのプールにインスタンスをプロビジョニングしようとした合計時間を制御できます。
### 単一モデルによるリアルタイムエンドポイント
次の例では、2 つのインスタンスプールを持つエンドポイント設定を作成します。`ml.g6.2xlarge` インスタンスが使用できない場合、SageMaker AI は にフォールバックします`ml.g6e.2xlarge`。
```
import boto3
sagemaker_client = boto3.client("sagemaker")
endpoint_config_name = "my-heterog-endpoint-config"
sagemaker_client.create_endpoint_config(
EndpointConfigName=endpoint_config_name,
ProductionVariants=[
{
"VariantName": "AllTraffic",
"ModelName": "my-model",
"InitialInstanceCount": 2,
"InstancePools": [
{
"InstanceType": "ml.g6.2xlarge",
"Priority": 1,
},
{
"InstanceType": "ml.g6e.2xlarge",
"Priority": 2,
},
],
"VariantInstanceProvisionTimeoutInSeconds": 600,
}
],
)
sagemaker_client.create_endpoint(
EndpointName="my-heterog-endpoint",
EndpointConfigName=endpoint_config_name,
)
```
各プールで `ModelNameOverride`パラメータを使用して、そのインスタンスタイプに最適化された別のモデルを指定することもできます。たとえば、GPU 用にコンパイルされたモデルを 1 つのインスタンスタイプにデプロイし、コンパイルされていないバージョンを別のインスタンスタイプにデプロイできます。
### 推論コンポーネントを使用したリアルタイムエンドポイント
インスタンスプールで推論コンポーネントを使用する場合、仕様を定義するための 2 つのオプションがあります。
+ **Single `Specification`** — エンドポイントのインスタンスプール内のすべてのインスタンスタイプで同じモデルとリソース設定を使用します。これは、モデルが同じリソース要件を持つプロビジョニングされたインスタンスタイプのいずれかで実行できる場合に機能します。
+ **Multiple `Specifications`** — `Specifications`パラメータ (複数) を使用して、インスタンスタイプごとに異なるモデルまたはリソース設定を定義します。各仕様には、エンドポイントのインスタンスプールのインスタンスタイプにマッピングする `InstanceType`フィールドが含まれています。
次の例では、per-instance-type仕様を持つ推論コンポーネントを作成します。
```
sagemaker_client.create_inference_component(
InferenceComponentName="my-ic",
EndpointName="my-heterog-endpoint",
VariantName="AllTraffic",
Specifications=[
{
"InstanceType": "ml.g6.2xlarge",
"ModelName": "my-model-g6",
"Container": {
"Image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/my-image:latest",
},
"ComputeResourceRequirements": {
"NumberOfAcceleratorDevicesRequired": {{1}},
"MinMemoryRequiredInMb": {{4096}},
},
},
{
"InstanceType": "ml.g6e.2xlarge",
"ModelName": "my-model-g6e",
"Container": {
"Image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/my-image:latest",
},
"ComputeResourceRequirements": {
"NumberOfAcceleratorDevicesRequired": {{1}},
"MinMemoryRequiredInMb": {{8192}},
},
},
],
RuntimeConfig={
"CopyCount": 2,
},
)
```
## インスタンスプールのモニタリング
`Invocations`、、 など、バリアント内のすべてのインスタンスに集約された既存の CloudWatch メトリクスは`ModelLatency`、インスタンスプールを使用する場合も引き続き同じように`CPUUtilization`動作します。さらに、CloudWatch はこれらのメトリクスを `InstanceType`ディメンションで公開するため、インスタンスタイプごとにパフォーマンスを個別にモニタリングできます。
### インスタンスタイプごとのメトリックス
本番稼働用バリアントがインスタンスプールを使用する場合、CloudWatch ではper-instance-typeモニタリングに次のディメンションの組み合わせを使用できます。
| ディメンションの組み合わせ | ユースケース |
| --- | --- |
| EndpointName, VariantName, InstanceType | バリアント内の特定のインスタンスタイプのエンドポイントレベルおよび呼び出しメトリクス (CPUUtilization、Invocations、 などModelLatency) をフィルタリングします。 |
| InferenceComponentName, InstanceType | 特定のインスタンスタイプの推論コンポーネントメトリクスをフィルタリングします。これを使用して、異なるインスタンスタイプ間で同じ推論コンポーネントがどのように機能するかを比較します。 |
これらのディメンションは、標準の CloudWatch メトリクスと拡張メトリクスの両方で使用できます。使用可能なメトリクスの完全なリストについては、[Amazon CloudWatch における Amazon SageMaker AI メトリクス](monitoring-cloudwatch.md)「」および「」を参照してください[推論エンドポイントの Amazon SageMaker AI 拡張メトリクス](monitoring-cloudwatch-enhanced-metrics.md)。
### フリートディストリビューションを確認する
各プールの現在のインスタンス数を確認するには、 [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeEndpoint.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeEndpoint.html) API を呼び出します。レスポンス`ProductionVariants`の には、各インスタンスタイプの現在の数を含む`InstancePools`リストが含まれます。これは、優先度の低いプールからのフォールバックインスタンスを含む、プロビジョニング後のフリート構成を示します。
推論コンポーネントを使用する場合、[https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeInferenceComponent.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeInferenceComponent.html)レスポンスには、インスタンスタイプごとのコピー数を示すランタイム設定概要の `PlacementStatus` フィールドが含まれます。これを使用して、推論コンポーネントのコピーがフリートのインスタンスタイプ全体にどのように分散されるかを理解します。
## インスタンスプールによる自動スケーリング
インスタンスプールによる自動スケーリングは、標準エンドポイントの自動スケーリングと同じプロセスに従います。スケーラブルターゲットを登録し、スケーリングポリシーを定義して、エンドポイントに適用します。一般的な自動スケーリングの設定については、「」を参照してください[Amazon SageMaker AI モデルの自動スケーリング](endpoint-auto-scaling.md)。
主な違いは、スケーリングイベントがトリガーされたときに SageMaker AI がインスタンスをプロビジョニングおよび解放する方法です。
スケールアウト (インスタンスの追加)
SageMaker AI は、最も優先度の高いプール (最も優先度の低い値) で始まるインスタンスをプロビジョニングします。現在のインスタンスタイプで容量不足エラーが発生した場合、SageMaker AI は優先度順に次のプールに自動的にフォールバックします。SageMaker AI `VariantInstanceProvisionTimeoutInSeconds`は、インスタンスがプロビジョニングされるか、合計に達するまで、プール間で再試行を続けます。
スケールイン (インスタンスの削除)
SageMaker AI は、最も優先度の低いプール (最も優先度の高い値) で始まるインスタンスをリリースします。優先され優先度の高いインスタンスタイプは可能な限り実行され、フォールバックインスタンスが最初にリリースされます。
### 事前定義されたスケーリングメトリクスを使用する
などの事前定義されたスケーリングメトリクスは、`SageMakerVariantInvocationsPerInstance`引き続きインスタンスプールで機能します。これらのメトリクスはバリアント内のすべてのインスタンスタイプに集約されるため、スケーリング動作は標準エンドポイントと同じです。これは、プール内のすべてのインスタンスタイプに同様の容量がある場合に最も簡単なアプローチです。
ターゲット追跡とステップスケーリングポリシーの設定については、「」を参照してください[Amazon SageMaker AI モデルの自動スケーリング](endpoint-auto-scaling.md)。
### 混合フリートに加重カスタムメトリクスを使用する
インスタンスプールに異なるコンピューティング容量を持つインスタンスタイプが含まれている場合、CloudWatch メトリクス数式を使用して加重スケーリングシグナルを作成できます。これにより、各インスタンスタイプの負荷が全体的なスケーリング決定にどの程度寄与するかを制御できます。
次の例では、2 つのインスタンスタイプ`ConcurrentRequestsPerModel`にわたって の加重平均を使用するターゲット追跡ポリシーを作成します。重みは、スケーリングポリシーが各タイプの負荷に対してどの程度敏感かを決定します。
```
import boto3
aas_client = boto3.client("application-autoscaling")
# Register the scalable target
aas_client.register_scalable_target(
ServiceNamespace="sagemaker",
ResourceId="endpoint/my-heterog-endpoint/variant/AllTraffic",
ScalableDimension="sagemaker:variant:DesiredInstanceCount",
MinCapacity=1,
MaxCapacity=10,
)
# Define target tracking policy with weighted metric math
aas_client.put_scaling_policy(
PolicyName="weighted-concurrent-requests",
ServiceNamespace="sagemaker",
ResourceId="endpoint/my-heterog-endpoint/variant/AllTraffic",
ScalableDimension="sagemaker:variant:DesiredInstanceCount",
PolicyType="TargetTrackingScaling",
TargetTrackingScalingPolicyConfiguration={
"TargetValue": {{10.0}},
"CustomizedMetricSpecification": {
"Metrics": [
{
"Id": "cr_g6",
"Label": "ConcurrentRequests-g6-2xlarge",
"MetricStat": {
"Metric": {
"Namespace": "AWS/SageMaker",
"MetricName": "ConcurrentRequestsPerModel",
"Dimensions": [
{"Name": "EndpointName", "Value": "my-heterog-endpoint"},
{"Name": "VariantName", "Value": "AllTraffic"},
{"Name": "InstanceType", "Value": "ml.g6.2xlarge"},
],
},
"Stat": "Average",
},
"ReturnData": False,
},
{
"Id": "cr_g6e",
"Label": "ConcurrentRequests-g6e-2xlarge",
"MetricStat": {
"Metric": {
"Namespace": "AWS/SageMaker",
"MetricName": "ConcurrentRequestsPerModel",
"Dimensions": [
{"Name": "EndpointName", "Value": "my-heterog-endpoint"},
{"Name": "VariantName", "Value": "AllTraffic"},
{"Name": "InstanceType", "Value": "ml.g6e.2xlarge"},
],
},
"Stat": "Average",
},
"ReturnData": False,
},
{
"Id": "weighted_avg",
"Label": "WeightedConcurrentRequests",
"Expression": "{{0.5}} * cr_g6 + {{0.5}} * cr_g6e",
"ReturnData": True,
},
],
},
},
)
```
この例では、 `cr_g6`と `cr_g6e` はper-instance-type`ConcurrentRequestsPerModel`メトリクスを取得します。`weighted_avg` 式は、それらを等しい重み (0.5 / 0.5) で結合します。重みを調整して、各インスタンスタイプのロードに対するポリシーの応答方法を変更します。
**重みがスケーリング動作に与える影響:** インスタンスタイプの重みが大きいほど、スケーリングポリシーはそのタイプの負荷に対して*より敏感*になります。低加重型の信号は減衰されるため、スケーリングイベントをトリガーする前により高い使用率で実行できます。
| 重み戦略 | 優先度の高いタイプの許容値 | 優先度の低いタイプの許容値 | 次の用途に適しています |
| --- | --- | --- | --- |
| 優先度が高い場合の重みが高い (0.7 / 0.3) | 低 (保護) | 高 (よりホットに実行) | 高コストまたは大容量のインスタンスを過負荷から保護する |
| 等しい (0.5/0.5) | バランスが取れている | バランスが取れている | ほとんどのワークロードのデフォルトのレコメンデーション |
| 優先度が低い場合の重みが高い (0.3/0.7) | 高 (よりホットに実行) | 低 (保護) | 小さなフォールバックインスタンスが飽和するのを防ぐ |
自動スケーリングを使用したカスタムメトリクスの詳細については、「」を参照してください[カスタムメトリクスを定義する (CloudWatch メトリクス: CPUUtilization)](endpoint-auto-scaling-add-code-define.md#endpoint-auto-scaling-add-code-custom)。