

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

# 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 グループをスケールアウトすることはできません。