

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon EC2 Auto Scaling のターゲットトラッキングスケーリングポリシー
<a name="as-scaling-target-tracking"></a>

ターゲット追跡スケーリングポリシーは、ターゲットメトリクス値に基づいて Auto Scaling グループのキャパシティを自動的にスケールします。個々のアプリケーションの一意の使用パターンに自動的に適応されます。これにより、手動で操作しなくても、アプリケーションは高いコスト効率で最適なパフォーマンスと EC2 インスタンスの高い使用率を維持できます。

ターゲット追跡を使用することで、アプリケーションの理想的な平均使用率またはスループットレベルを表すメトリクスとターゲット値を選択します。Amazon EC2 Auto Scaling は、メトリクスがターゲットから逸脱したときにスケーリングイベントを呼び出す CloudWatch アラームを作成および管理します。例として、これはサーモスタットがターゲット温度を維持する仕組みと似ています。

例えば、現在 2 つのインスタンスで実行されているアプリケーションがあり、アプリケーションの負荷が変化しても Auto Scaling グループの CPU 使用率を約 50% に維持する必要があるとします。これにより、過剰な数のアイドルリソースを維持することなくトラフィックのスパイクを処理するための追加のキャパシティが得られます。

このニーズを満たすには、50% の平均 CPU 使用率をターゲットとする、ターゲット追跡スケーリングポリシーを作成します。次に、CPU が 50% を超えると、Auto Scaling グループがスケールアウトして (キャパシティを増やして) 負荷の増加に対応します。CPU が 50% を下回るとスケールインして (キャパシティを減らして) 使用率が低い期間のコストを最適化します。

**Topics**
+ [複数のターゲット追跡スケーリングポリシー](#target-tracking-multiple-policies)
+ [メトリクスを選択する](#target-tracking-choose-metrics)
+ [ターゲット値の定義](#target-tracking-define-target-value)
+ [インスタンスウォームアップ時間を定義する](#as-target-tracking-scaling-warmup)
+ [考慮事項](#target-tracking-considerations)
+ [ターゲット追跡スケーリングポリシーを作成する](policy_creating.md)
+ [高解像度のメトリクスを使用してターゲット追跡ポリシーを作成し、迅速に対応する](policy-creating-high-resolution-metrics.md)
+ [Metric Math を使用してターゲット追跡スケーリングポリシーを作成する](ec2-auto-scaling-target-tracking-metric-math.md)

## 複数のターゲット追跡スケーリングポリシー
<a name="target-tracking-multiple-policies"></a>

スケーリングパフォーマンスを最適化するために複数のターゲット追跡スケーリングポリシーを同時に使用できますが、それぞれが異なるメトリクスを使用する必要があります。例えば、使用率とスループットは互いに影響し合う可能性があります。これは、これらのメトリクスのいずれかが変更されるたびに、通常、他のメトリクスも影響を受けることを意味します。このため、複数のメトリクスを使用することで、Auto Scaling グループの負荷に関する追加情報が提供されます。これにより、Amazon EC2 Auto Scaling は、グループに追加するキャパシティの量を決定する際に、より多くの情報に基づいた意思決定ができます。

Amazon EC2 Auto Scaling の目的は、常に可用性を優先することです。ターゲット追跡ポリシーのいずれかでスケールアウトが必要な場合、Auto Scaling グループがスケールアウトされます。すべてのターゲット追跡ポリシー (スケールイン部分が有効な状態) でスケールインできる場合にのみスケールインされます。

## メトリクスを選択する
<a name="target-tracking-choose-metrics"></a>

事前定義されたメトリクスまたはカスタムメトリクスのいずれかを使用して、ターゲット追跡スケーリングポリシーを作成できます。事前定義されたメトリクスを使用すると、スケーリングに最もよく使用されるメトリクスにより簡単にアクセスできます。カスタムメトリクスを使用すると、数秒ほどでより細かい間隔で発行される[高解像度メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Resolution_definition)など、他の利用可能な CloudWatch メトリクスをスケールできます。独自の高解像度メトリクスまたは他の AWS サービスが発行するメトリクスを発行できます。

高解像度メトリクスを使用してターゲット追跡ポリシーを作成する方法の詳細については、「[高解像度のメトリクスを使用してターゲット追跡ポリシーを作成し、迅速に対応する](policy-creating-high-resolution-metrics.md)」を参照してください。

ターゲット追跡では、以下の事前定義されたメトリクスがサポートされます。
+ `ASGAverageCPUUtilization` - Auto Scaling グループの平均 CPU 使用率。
+ `ASGAverageNetworkIn` - すべてのネットワークインターフェイスで Auto Scaling グループが受信した平均バイト数。
+ `ASGAverageNetworkOut` - すべてのネットワークインターフェイスで Auto Scaling グループが送信した平均バイト数。
+ `ALBRequestCountPerTarget` — Auto Scaling グループのターゲットあたりの Application Load Balancer リクエストの平均。

**重要**  
ターゲットごとの CPU 使用率、ネットワーク I/O、Application Load Balancer リクエスト数のメトリクスに関するその他の有益な情報は、「*Amazon EC2 ユーザーガイド*」の「[インスタンスに対して利用可能な CloudWatch メトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)」および「*Application Load Balancer ユーザーガイド*」の「[CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)」に記載されています。

カスタムメトリクスを指定することで、他の利用可能な CloudWatch メトリクスまたは CloudWatch の独自のメトリクスを選択できます。を使用してターゲット追跡スケーリングポリシーのカスタマイズされたメトリクス仕様を指定する例については AWS CLI、「」を参照してください[のスケーリングポリシーの例 AWS CLI](examples-scaling-policies.md)。

メトリクスを選択するときは、以下の点に注意してください。
+ 使用状況の変化に応じてより迅速にスケールできるように、1 分以下の間隔で利用可能なメトリクスのみを使用することをお勧めします。短い間隔で発行されるメトリクスにより、ターゲット追跡ポリシーは Auto Scaling グループの使用率の変化をより迅速に検出して対応できます。
+ CPU 使用率など、Amazon EC2 によって発行される事前定義されたメトリクスを選択する場合は、詳細モニタリングを有効にすることをお勧めします。デフォルトでは、Amazon EC2 メトリクスはすべて 5 分間隔で発行されますが、詳細モニタリングを有効にすると 1 分未満に設定できます。詳細モニタリングを有効にする方法については、「[Auto Scaling インスタンスのモニタリングを設定する](enable-as-instance-metrics.md)」を参照してください。
+ カスタムメトリクスにはターゲット追跡に使用できないものもあります。メトリクスは、有効な使用率メトリクスで、インスタンスの使用頻度を示す必要があります。メトリクス値は Auto Scaling グループのインスタンス数に比例して増減する必要があります。それにより、メトリクスデータを使用して比例的にインスタンス数をスケールアウトまたはスケールインできます。例えば、`CPUUtilization` Auto Scaling グループの負荷がインスタンス間で分散されている場合、Auto Scaling グループの CPU 使用率 (メトリクスディメンション `AutoScalingGroupName` を持つ Amazon EC2 メトリクス ) は有効です。
+ 以下のメトリクスはターゲットの追跡では機能しません。
  + Auto Scaling グループの前にあるロードバランサーが受信したリクエスト数 (つまり、Elastic Load Balancing メトリクス`RequestCount`)。ロードバランサーによって受信されたリクエストの数は、Auto Scaling グループの使用率に基づいて変化しません。
  + ロードバランサーのリクエストのレイテンシー (Elastic Load Balancing メトリクス`Latency`)。リクエストのレイテンシーは、使用率の増加により増える場合がありますが、必ずしも比例して変化するわけではありません。
  + CloudWatch Amazon SQS キューメトリクス`ApproximateNumberOfMessagesVisible`。キュー内のメッセージ数は、キューからのメッセージを処理する Auto Scaling グループのサイズに比例して変わらない可能性があるためです。ただし、Auto Scaling グループの EC2 インスタンスごとにキュー内のメッセージの数を測定するカスタムメトリクスは機能します。詳しくは、「[Amazon SQS に基づくスケーリングポリシー](as-using-sqs-queue.md)」を参照してください。
+ `ALBRequestCountPerTarget` メトリクスを使用するには、`ResourceLabel` パラメータを指定して、メトリクスに関連付けられているロードバランサーターゲットグループを識別する必要があります。を使用してターゲット追跡スケーリングポリシーの `ResourceLabel`パラメータを指定する例については AWS CLI、「」を参照してください[のスケーリングポリシーの例 AWS CLI](examples-scaling-policies.md)。
+ メトリクスが CloudWatch に実数 0 の値を出力する場合 (`ALBRequestCountPerTarget` など)、Auto Scaling グループは、長期間アプリケーションへのトラフィックがない場合に 0 にスケールインできます。Auto Scaling グループにリクエストがルーティングされないときに Auto Scaling グループを 0 にスケールインするには、グループの最小キャパシティを 0 に設定する必要があります。
+ スケーリングポリシーで使用する新しいメトリクスを公開する代わりに、メトリクス数式を使用して既存のメトリクスを組み合わせることができます。詳細については、「[Metric Math を使用してターゲット追跡スケーリングポリシーを作成する](ec2-auto-scaling-target-tracking-metric-math.md)」を参照してください。

## ターゲット値の定義
<a name="target-tracking-define-target-value"></a>

ターゲット追跡スケーリングポリシーを作成するときは、ターゲット値を指定する必要があります。ターゲット値は、Auto Scaling グループの最適な平均使用率またはスループットを表します。優れたコスト効率でリソースを使用するには、予期しないトラフィックの増加に対して適切なバッファを使用し、ターゲット値をできる限り高く設定します。アプリケーションが通常のトラフィックフローに対して最適にスケールアウトされる場合、実際のメトリクス値は、ターゲット値以下である必要があります。

スケーリングポリシーが Application Load Balancer のターゲットごとのリクエスト数、ネットワーク I/O、またはその他のカウントメトリクスなどのスループットに基づいている場合、ターゲット値は単一のインスタンスからの最適な 1 分間の平均スループットを表します。

## インスタンスウォームアップ時間を定義する
<a name="as-target-tracking-scaling-warmup"></a>

オプションで、新しく起動されたインスタンスのウォームアップ時間を秒単位で指定できます。指定されたウォームアップ時間が終了するまで、インスタンスは Auto Scaling グループの集約された EC2 インスタンスメトリクスにカウントされません。

インスタンスのウォームアップ期間中、スケーリングポリシーは、ウォームアップしていないインスタンスからのメトリクス値がポリシーのターゲット使用率を超える場合にのみスケールアウトします。

グループが再度スケールアウトする場合、まだウォームアップ中のインスタンスは、次のスケールアウトアクティビティの希望キャパシティーの一部として計上されます。その目的は、スケールアウトを継続的に (ただし過剰になることなく) 行うことです。

スケールアウトアクティビティの進行中は、インスタンスがウォームアップを終了するまで、スケーリングポリシーによって開始されるすべてのスケールインアクティビティがブロックされます。インスタンスのウォームアップが完了し、スケールインイベントが発生した場合、現在終了処理中のインスタンスは、新しい希望するキャパシティを計算する際にグループの現在のキャパシティにカウントされます。したがって、Auto Scaling グループから必要以上の数のインスタンスが削除されることがなくなります。

**デフォルトの値**  
値が設定されていない場合、スケーリングポリシーは、グループに定義されている[デフォルトのインスタンスウォームアップ](ec2-auto-scaling-default-instance-warmup.md)の値であるデフォルト値を使用します。インスタンスのデフォルトウォームアップが null の場合、[デフォルトクールダウン](ec2-auto-scaling-scaling-cooldowns.md#set-default-cooldown)の値にフォールバックします。ウォームアップ時間が変更されたときにすべてのスケーリングポリシーを簡単に更新できるように、デフォルトのインスタンスウォームアップを使用することをお勧めします。

## 考慮事項
<a name="target-tracking-considerations"></a>

ターゲット追跡スケーリングポリシーを使用する場合は、次の考慮事項が適用されます。
+ ターゲット追跡スケーリングポリシーで使用されている CloudWatch アラームを作成、編集、または削除しないでください。Amazon EC2 Auto Scaling は、ターゲット追跡スケーリングポリシーに関連付けられている CloudWatch アラームを作成および管理し、必要に応じて編集、置換、または削除して、アプリケーションのスケーリングエクスペリエンスとその変化する利用パターンをカスタマイズできます。
+ ターゲット追跡スケーリングポリシーは、トラフィック減少時に徐々にスケールインすることにより、トラフィックレベルが変動する期間中の可用性を優先します。より詳細な制御が必要な場合は、ステップスケーリングポリシーが適している可能性があります。ターゲット追跡ポリシーのスケールイン部分を一時的に無効にすることもできます。これにより、デプロイを成功させるための最小限のインスタンス数を維持できます。
+ メトリクスにデータポイントがない場合、CloudWatch アラームの状態は `INSUFFICIENT_DATA` に変化します。この状態になると、Amazon EC2 Auto Scaling は、新しいデータポイントが見つかるまでグループをスケールできなくなります。
+ メトリクスが設計上まばらに報告される場合は、メトリクス数式が役立つことがあります。例えば、最新の値を使用するには、`FILL(m1,REPEAT)` という関数を使用します (`m1` がメトリクスです)。
+ ターゲット値と実際のメトリクスデータポイント間にギャップが発生する場合があります。これは、追加または削除するインスタンス数を決定するときに、その数を切り上げまたは切り捨てて常に控えめに動作するためです。これにより、不十分な数のインスタンスを追加したり、インスタンスを過剰に削除したりすることがなくなります。ただし、インスタンス数が少ない、より小さな Auto Scaling グループでは、グループの使用率はターゲット値からかなり離れているように見える場合があります。

  例えば、CPU 使用率に 50 パーセントのターゲット値を設定し、Auto Scaling グループがそのターゲットを超過したとします。1.5 インスタンスを追加することで CPU 使用率が 50 パーセント近くに減少すると判断される場合があります。1.5 インスタンスを追加することはできないので、これを切り上げて、2 インスタンスを追加します。これにより、CPU 使用率は 50 パーセント未満の値に下がる可能性がありますが、アプリケーションをサポートする十分なリソースが確保されます。同様に、0.5 インスタンスを削除すると CPU 使用率が 50% を超えると判断した場合、スケールインが振動を引き起こさないと考えられるほどメトリクスが十分に低くなるまでスケールインしないことを選択します。

  より多くのインスタンスのある大規模な Auto Scaling グループの場合、使用率はより多くのインスタンス間で分散されます。その場合、インスタンスの追加または削除により、ターゲット値と実際のメトリクスデータポイントとの差が小さくなります。
+ ターゲットの追跡スケーリングポリシーでは、指定されたメトリクスがターゲット値を超えている場合、Auto Scaling グループをスケールアウトする必要があるとみなされます。指定されたメトリクスがターゲット値を下回っている場合、ターゲット追跡スケーリングポリシーを使用して Auto Scaling グループをスケールアウトすることはできません。

# ターゲット追跡スケーリングポリシーを作成する
<a name="policy_creating"></a>

Auto Scaling グループのターゲット追跡スケーリングポリシーを作成するには、次のいずれかの方法を使用します。

開始する前に、(Amazon EC2 メトリクスのデフォルトが 5 分間隔であることを踏まえて) 希望するメトリクスが 1 分間隔で利用可能であることを確認してください。

------
#### [ Console ]

**新しい Auto Scaling グループにターゲット追跡スケーリングポリシーを作成するには**

1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。

1. **[Auto Scaling グループの作成]** を選択します。

1. ステップ 1、2、および 3 で、必要に応じてオプションを選択し、「**ステップ 4: グループサイズとスケーリングポリシーを設定する**」に進みます。

1. **[スケーリング]** で、**[最小の希望する容量]** と **[最大の希望する容量]** を更新してスケールする範囲を指定します。これら 2 つの設定により、Auto Scaling グループは動的にスケーリングできます。詳細については、「[Auto Scaling グループのスケーリング制限を設定する](asg-capacity-limits.md)」を参照してください。

1. **[自動スケーリング]** で、**[ターゲット追跡スケーリングポリシー]** を選択します。

1. ポリシーを定義するには、以下の作業を行います。

   1. ポリシーの名前を指定します。

   1. [**Metric type (メトリクスタイプ)**] でメトリクスを選択します。

      [**Application Load Balancer request count per target (ターゲットあたりのApplication Load Balancer リクエスト数)**] を選択し、[**Target group (ターゲットグループ)**] のターゲットグループを選択します。

   1. メトリクスの [**Target value**] を指定します。

   1. (オプション) **[インスタンスのウォームアップ]** で、必要に応じてインスタンスのウォームアップ値を更新します。

   1. (オプション) [**Disable scale in to create only a scale-out policy (スケールインを無効にしてスケールアウトポリシーのみを作成する)**] を選択します。これにより、必要に応じて異なるタイプの別のスケールインポリシーを作成できます。

1. Auto Scaling グループの作成に進みます。スケーリングポリシーは、Auto Scaling グループの作成後に作成されます。

**既存の Auto Scaling グループにターゲット追跡スケーリングポリシーを作成するには**

1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。

1. Auto Scaling グループの横にあるチェックボックスを選択します。

   ページの下部にスプリットペインが開きます。

1. スケーリング制限が適切に設定されていることを検証します。例えば、グループの希望するキャパシティが既に最大に達している場合は、スケールアウトするために新しい最大を指定する必要があります。詳細については、「[Auto Scaling グループのスケーリング制限を設定する](asg-capacity-limits.md)」を参照してください。

1. **[Automatic scaling]** (オートスケーリング) タブの **[Dynamic scaling policies]** (動的スケーリングポリシー) で、**[Create dynamic scaling]** (動的スケーリングポリシーの作成) を選択します。

1. ポリシーを定義するには、以下の作業を行います。

   1. **[ポリシータイプ]** で、**[ターゲット追跡スケーリング]** のデフォルト設定を維持します。

   1. ポリシーの名前を指定します。

   1. [**Metric type (メトリクスタイプ)**] でメトリクスを選択します。選択できるメトリクスタイプは 1 つだけです。複数のメトリクスを使用するには、複数のポリシーを作成します。

      [**Application Load Balancer request count per target (ターゲットあたりのApplication Load Balancer リクエスト数)**] を選択し、[**Target group (ターゲットグループ)**] のターゲットグループを選択します。

   1. メトリクスの [**Target value**] を指定します。

   1. (オプション) **[インスタンスのウォームアップ]** で、必要に応じてインスタンスのウォームアップ値を更新します。

   1. (オプション) [**Disable scale in to create only a scale-out policy (スケールインを無効にしてスケールアウトポリシーのみを作成する)**] を選択します。これにより、必要に応じて異なるタイプの別のスケールインポリシーを作成できます。

1. **[作成]** を選択します。

------
#### [ AWS CLI ]

ターゲット追跡スケーリングポリシーを作成するには、次の例を使用して開始できます。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。

**注記**  
その他の例については、「[のスケーリングポリシーの例 AWS CLI](examples-scaling-policies.md)」を参照してください。

**ターゲット追跡スケーリングポリシーを作成するには (AWS CLI)**

1. 以下の `cat` コマンドを使用して、スケーリングポリシーのターゲット値と事前に定義されたメトリクスの仕様を、ホームディレクトリにある `config.json` という名前の JSON ファイルに保存します。平均 CPU 使用率を 50% に維持するターゲット追跡設定の例を次に示します。

   ```
   $ cat ~/config.json
   {
     "TargetValue": 50.0,
     "PredefinedMetricSpecification": 
       {
         "PredefinedMetricType": "ASGAverageCPUUtilization"
       }
   }
   ```

   詳細については、*Amazon EC2 Auto Scaling API リファレンス*の「[PredefinedMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredefinedMetricSpecification.html)」を参照してください。

1. [ut-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) コマンドを使用して、前のステップで作成した `config.json` と共に、スケーリングポリシーを作成します。

   ```
   aws autoscaling put-scaling-policy --policy-name cpu50-target-tracking-scaling-policy \
     --auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
     --target-tracking-configuration file://config.json
   ```

   成功した場合、このコマンドはユーザーに代わって作成された 2 つの CloudWatch アラームの ARN と名前を返します。

   ```
   {
       "PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/cpu50-target-tracking-scaling-policy",
       "Alarms": [
           {
               "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
               "AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
           },
           {
               "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
               "AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
           }
       ]
   }
   ```

------

# 高解像度のメトリクスを使用してターゲット追跡ポリシーを作成し、迅速に対応する
<a name="policy-creating-high-resolution-metrics"></a>

ターゲット追跡は、1 分未満間隔で発行される秒レベルのデータポイントを持つ高解像度の CloudWatch メトリクスをサポートします。クライアントサービス API、ライブストリーミングサービス、e コマースウェブサイト、オンデマンドデータ処理など、需要パターンが変動しやすいアプリケーションに対して高解像度の CloudWatch メトリクスを通じて使用率をモニタリングするようにターゲット追跡ポリシーを設定します。キャパシティと需要のマッチングの精度を高めるために、ターゲット追跡では、このきめ細かなモニタリングを使用し、EC2 インスタンスの需要と使用率の変化をより迅速に検出して対応します。

高解像度でメトリクスを発行する方法の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)」を参照してください。高解像度で CPU 使用率などの EC2 メトリクスにアクセスして発行するには、[CloudWatch エージェント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)を使用することをお勧めします。

## AWS リージョン
<a name="policy-creating-high-resolution-metrics-regions"></a>

高解像度メトリクスを使用したターゲット追跡は、 AWS リージョン を除くすべての で使用できます AWS GovCloud (US) Regions。

## 高解像度のメトリクスを使用したターゲット追跡ポリシーの仕組み
<a name="policy-high-resolution-metrics-how-works"></a>

追跡するメトリクスとメトリクスで維持するターゲット値を定義して、ターゲット追跡ポリシーを作成します。高解像度のメトリクスでスケールするには、メトリクスの名前を指定し、ターゲット追跡でこのメトリクスを監視するメトリクス期間を 60 秒未満の値に設定します。現在、サポートされている最小の間隔は 10 秒です。これより短い間隔でメトリクスを発行できます。

**注記**  
60 を超えるメトリクス期間はサポートされていません。

単一の CloudWatch メトリクスにターゲット追跡を設定したり、複数の CloudWatch メトリクスをクエリし、数式を使用して、メトリクスに基づく新しい単一の時系列を作成できます。どちらのオプションでもメトリクス期間を定義できます。

## 例
<a name="high-resolution-metrics-examples"></a>

**例 1**  
次の例では、高解像度の CloudWatch メトリクスに基づいてターゲット追跡ポリシーを作成します。メトリクスは、10 秒の解像度で発行されます。期間を定義することで、ターゲット追跡を有効にして、このメトリクスを 10 秒の粒度でモニタリングできます。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。

```
$ cat ~/config.json
{
  "TargetValue": 100.0,
  "CustomizedMetricSpecification": {
      "MetricName": "MyHighResolutionMetric",
      "Namespace": "MyNamespace",
      "Dimensions": [
        {
          "Name": "MyOptionalDimensionName",
          "Value": "MyOptionalMetricDimensionValue"
        }
      ],
      "Statistic": "Average",
      "Unit": "None"
      "Period": "10                  
  }
}
```

**例 2**  
メトリクス数式を使用して、複数のメトリクスを単一の時系列に結合してスケールできます。メトリクス演算は、既存のメトリクスをインスタンスあたりの平均に変換するために特に役立ちます。ターゲット追跡では、メトリクスが Auto Scaling グループのキャパシティに反比例することを前提としているため、メトリクスの変換は不可欠です。したがって、キャパシティが増加すると、メトリクスはほぼ同じ割合で減少します。

例えば、アプリケーションで処理される保留中のジョブを表すメトリクスがあるとします。メトリクス演算を使用すると、保留中のジョブを Auto Scaling グループの実行キャパシティで割ることができます。Auto Scaling はキャパシティメトリクスを 1 分単位で発行するため、このメトリクスには 1 分未満の間隔の値はありません。このため、高解像度を使用してスケールする場合、キャパシティと保留中のジョブメトリクスの期間が一致しなくなる可能性があります。この不一致を回避するには、FILL 式を使用して、欠落している値を前の 1 分間のタイムスタンプに記録されたキャパシティの数で埋めることをお勧めします。

次の例では、メトリクス演算を使用して、保留中のジョブメトリクスをキャパシティで割ります。期間については、両方のメトリクスを 10 秒で設定します。メトリクスは 1 分間隔で発行されるため、キャパシティメトリクスに FILL 操作を使用しています。

メトリクス演算を使用して複数のメトリクスを変更するには

```
{
    "CustomizedMetricSpecification": {
        "Metrics": [
            {
                "Label": "Pending jobs to be processed",
                "Id": "m1",
                "MetricStat": {
                    "Metric": {
                        "MetricName": "MyPendingJobsMetric",
                        "Namespace": "Custom",
                    },
                    "Stat": "Sum"
                    "Period": 10
                },
                "ReturnData": false
            },
            {
                "Label": "Get the running instance capacity (matching the period to that of the m1)",
                "Id": "m2",
                "MetricStat": {
                    "Metric": {
                        "MetricName": "GroupInServiceInstances",
                        "Namespace": "AWS/AutoScaling",
                        "Dimensions": [
                            {
                                "Name": "AutoScalingGroupName",
                                "Value": "my-asg"
                            }
                        ]
                    },
                    "Stat": "Average"
                    "Period": 10
                },
                "ReturnData": false
            },
            {
                "Label": "Calculate the pending job per capacity (note the use of the FILL expression)",
                "Id": "e1",
                "Expression": "m1 / FILL(m2,REPEAT)",
                "ReturnData": true
            }
        ]
    },
    "TargetValue": 100
}
```

## 考慮事項
<a name="high-resolution-considerations"></a>

ターゲット追跡と高解像度のメトリクスを使用する場合は、次の点を考慮してください。
+ 望ましくない自動スケーリング結果につながる可能性のあるデータポイントの欠落がないようにするには、CloudWatch メトリクスを指定した期間と同じかそれ以上の解像度で発行する必要があります。
+ ターゲット値を、Auto Scaling グループにおいて維持するインスタンスごとの 1 分あたりのメトリクス値として定義します。メトリクスの期間に基づいて値が増大するメトリクスを使用する場合は、適切なターゲット値を設定することが重要です。例えば、SUM 統計を使用するリクエスト数や保留中のジョブなどのカウントベースのメトリクスは、選択した期間に応じて異なるメトリクス値になります。それでも、1 分あたりの平均に対してターゲットを設定していることを前提にする必要があります。
+ Amazon EC2 Auto Scaling の使用には追加料金はかかりませんが、Amazon EC2 インスタンス、CloudWatch メトリクス、CloudWatch アラームなどのリソースに対しては料金を支払う必要があります。前の例で作成した高解像度アラームの料金は、標準の CloudWatch アラームの料金とは異なります。CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
+ ターゲット追跡では、メトリクスが EC2 インスタンスのインスタンスごとの平均使用率を表す必要があります。これを実現するには、ターゲット追跡ポリシー設定の一部として[メトリクス演算オペレーション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)を使用できます。Auto Scaling グループの実行キャパシティでメトリクスを割ります。単一の時系列の作成に使用するメトリクスごとに、同じメトリクス期間が定義されていることを確認します。これらのメトリクスが異なる間隔で発行される場合は、間隔が大きいメトリクスで FILL 操作を使用して、欠落しているデータポイントを埋めます。

# Metric Math を使用してターゲット追跡スケーリングポリシーを作成する
<a name="ec2-auto-scaling-target-tracking-metric-math"></a>

メトリクス数学の使用により、複数の CloudWatch メトリクスをクエリし、数表現を使用して、メトリクスに基づく新しい時系列を作成できます。作成された時系列を CloudWatch コンソール内で視覚化でき、ダッシュボードに追加できます。メトリクス演算の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch メトリクスでの数式の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)」を参照してください。

Metric Math の数式には、次の考慮事項が適用されます。
+ 利用可能な CloudWatch メトリクスをクエリできます。各メトリクスは、メトリクス名、名前空間、0 以上のディメンションの一意の組み合わせです。
+ 任意の算術演算子 (\$1 - \$1 / ^)、統計関数 (AVG や SUM など)、または CloudWatch がサポートするその他の関数を使用できます。
+ 数式の関係式では、メトリクスと他の数式の結果の両方を使用できます。
+ メトリクスの指定で使用される数式はすべて、最終的に単一の時系列を返す必要があります。
+ CloudWatch コンソールまたは CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API を使用して、Metric Math の数式が有効であることを確認できます。

## 例: インスタンスごとの Amazon SQS キューバックログ
<a name="metric-math-sqs-queue-backlog"></a>

インスタンスごとの Amazon SQS キューバックログを計算するには、キューからの取得に使用できるメッセージの概数を取得し、その数を Auto Scaling グループの実行キャパシティーで除算します。つまり、`InService` 状態のインスタンスの数になります。詳細については、「[Amazon SQS に基づくスケーリングポリシー](as-using-sqs-queue.md)」を参照してください。

この数式のロジックは次のとおりです。

 `sum of (number of messages in the queue)/(number of InService instances)`

この場合、CloudWatch メトリクス情報は次のようになります。


| ID | CloudWatch メトリクス | 統計 | 間隔 | 
| --- | --- | --- | --- | 
| m1 | ApproximateNumberOfMessagesVisible | 合計 | 1 分 | 
| m2 | GroupInServiceInstances | 平均 | 1 分 | 

メトリクス数学 ID と表現は次のとおりです。


| ID | 表現 | 
| --- | --- | 
| e1 | (m1)/(m2) | 

このメトリクスのアーキテクチャを以下に図で示します。

![\[キューを使用する Amazon EC2 Auto Scaling アーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/sqs-as-custom-metric-diagram.png)


**この Metric Math を使用してターゲット追跡スケーリングポリシーを作成するには (AWS CLI)**

1. Metric Math の数式を、カスタマイズされたメトリクス仕様の一部として、`config.json` という名前の JSON ファイルに保存します。

   次の例を参考にして開始してください。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。

   ```
   {
       "CustomizedMetricSpecification": {
           "Metrics": [
               {
                   "Label": "Get the queue size (the number of messages waiting to be processed)",
                   "Id": "m1",
                   "MetricStat": {
                       "Metric": {
                           "MetricName": "ApproximateNumberOfMessagesVisible",
                           "Namespace": "AWS/SQS",
                           "Dimensions": [
                               {
                                   "Name": "QueueName",
                                   "Value": "my-queue"
                               }
                           ]
                       },
                       "Stat": "Sum"
                   },
                   "ReturnData": false
               },
               {
                   "Label": "Get the group size (the number of InService instances)",
                   "Id": "m2",
                   "MetricStat": {
                       "Metric": {
                           "MetricName": "GroupInServiceInstances",
                           "Namespace": "AWS/AutoScaling",
                           "Dimensions": [
                               {
                                   "Name": "AutoScalingGroupName",
                                   "Value": "my-asg"
                               }
                           ]
                       },
                       "Stat": "Average"
                   },
                   "ReturnData": false
               },
               {
                   "Label": "Calculate the backlog per instance",
                   "Id": "e1",
                   "Expression": "m1 / m2",
                   "ReturnData": true
               }
           ]
       },
       "TargetValue": 100
   }
   ```

   詳細については、「*Amazon EC2 Auto Scaling API Reference*」の「[TargetTrackingConfiguration](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TargetTrackingConfiguration.html)」を参照してください。
**注記**  
以下は、CloudWatch メトリクスのメトリクス名、名前空間、ディメンション、および統計を見つけるために役立つ追加のリソースです。  
 AWS のサービスで使用可能なメトリクスの詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch メトリクスを発行するAWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)」を参照してください。
CloudWatch メトリクスの正確なメトリクス名、名前空間、ディメンション (該当する場合) を AWS CLIで取得するには、「[list-metrics](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/list-metrics.html)」を参照してください。

1. このポリシーを作成するには、以下の例にあるように、JSON ファイルを入力として使用して [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行します。

   ```
   aws autoscaling put-scaling-policy --policy-name sqs-backlog-target-tracking-scaling-policy \
     --auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
     --target-tracking-configuration file://config.json
   ```

   成功した場合、このコマンドは、ユーザーに代わって作成したポリシーの Amazon リソースネーム (ARN) および 2 つの CloudWatch アラームの ARN を返します。

   ```
   {
       "PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/sqs-backlog-target-tracking-scaling-policy",
       "Alarms": [
           {
               "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
               "AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
           },
           {
               "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
               "AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
           }
       ]
   }
   ```
**注記**  
このコマンドがエラーをスローする場合は、 を AWS CLI ローカルで最新バージョンに更新していることを確認してください。