スケーリングポリシー：ターゲット追跡とステップスケーリング

負荷が一定であれば固定の希望容量でも対応できますが、実際のトラフィックは変動します。スケーリングポリシーを使うと、Auto Scaling Groupはメトリクスに応じて希望容量を自動調整できます。AWSには、動的なポリシーとして主にターゲット追跡、ステップスケーリング、シンプルスケーリングの3種類があります。SAA-C03試験では、ターゲット追跡とステップスケーリングを理解することが特に重要です。

ターゲット追跡スケーリングは、サーモスタットのように機能します。メトリクスと目標値を指定すると、AWSがそのメトリクスを目標値に保つために追加または削除するインスタンス数を自動的に計算します。たとえば、平均CPU使用率50%を目標に設定し、使用率が80%まで上昇した場合、ASGはCPU使用率を50%に戻すために十分な数のインスタンスを追加します。スケールアウトとスケールインの両方をAWSが管理します。

ターゲット追跡では、標準で複数の定義済みメトリクスを利用できます。ASGAverageCPUUtilization、ASGAverageNetworkIn、ASGAverageNetworkOut、そしてALB固有のALBRequestCountPerTargetです。アプリケーション固有のKPI（キューの深さ、アクティブな接続数、カスタムビジネスメトリクス）には、カスタムCloudWatchメトリクスを指定できます。カスタムメトリクスを使うと、スケーリングの判断基準をより細かく制御できます。

スケールアウトの発生後、ASGはクールダウン期間（デフォルトは300秒）の間、次のスケールアウトの評価を待ちます。これにより、新しく起動したインスタンスがトラフィックの処理を開始し、メトリクスが安定する時間を確保できます。同様に、スケールインのクールダウンによって、容量を追加した直後にインスタンスが早まって終了されるのを防ぎます。ターゲット追跡では、新しいインスタンスが完全に初期化される前にメトリクスへ影響を与えないよう、AWSはウォームアップ期間の使用も推奨しています。

ステップスケーリングは、CloudWatchアラームに応じて、メトリクスがしきい値をどの程度超えたかに基づき、特定の数のインスタンスを追加または削除します。複数のステップ調整を定義し、各ステップでメトリクスの範囲と容量の変更量を指定します。たとえば、CPUが60～70%ならインスタンスを1台追加し、70～90%なら3台追加し、90%を超えたら5台追加します。これにより、負荷レベルの変化に応じて段階的かつ比例的に対応できます。

ステップスケーリングには、事前にCloudWatchアラームを作成しておく必要があります。アラームはメトリクスを監視し、しきい値を超えるとALARM状態に遷移します。スケーリングポリシーは、アラームのしきい値に対するメトリクス値に応じて、参照されたステップ調整を使用します。調整タイプには、ChangeInCapacity（N台追加）、ExactCapacity（N台に設定）、PercentChangeInCapacity（N%単位で増減）を指定できます。

各ステップ調整にはMetricIntervalLowerBoundがあり、必要に応じてMetricIntervalUpperBoundも設定します。範囲はアラームのしきい値を基準とします。アラームのしきい値がCPU 60%の場合、LowerBound=0, UpperBound=10はCPUが60～70%のときに実行され、LowerBound=10, UpperBound=nullはCPUが70%を超えたときに実行されます。この段階的な方式により、大きなトラフィック急増に対して、複数回のアラームサイクルを待たずに大幅な容量追加を即座に行えます。

シンプルスケーリングは、ステップスケーリングより前に使われていた方式です。ステップスケーリングと同様にCloudWatchアラームが必要ですが、トリガーされると固定数のインスタンスを追加または削除し、その後、クールダウン期間全体が終了するまで次の評価を待ちます。そのため、負荷が急速に変化する状況では反応が遅くなります。条件の悪化に対して完全なクールダウンを待たずに継続して実行でき、負荷に比例して対応できるため、ステップスケーリングが推奨されます。

長時間実行されるバッチジョブを実行しているインスタンスなど、スケールイン時に特定のインスタンスが終了されないようにしたい場合があります。コンソールまたはCLIから、個々のインスタンスにインスタンスのスケールイン保護を有効にできます。ASGが終了候補を選択するとき、保護されたインスタンスはスキップされます。ジョブが完了したら保護を解除してください。すべてのインスタンスが保護されていると、ASGがスケールインできなくなる可能性があります。

1つのASGに複数のスケーリングポリシーを関連付けることができます。ターゲット追跡ポリシーとステップスケーリングポリシーが両方存在する場合、ASGはより大きいスケールアウトを推奨するポリシーを使用します（より慎重な判断）。スケールインでは、削除するインスタンス数が少ないポリシーが優先されます。これにより、過剰プロビジョニングとプロビジョニング不足の間でシステムが頻繁に変動するのを防ぎます。一般的な構成では、定常状態にはターゲット追跡ポリシーを使用し、緊急の負荷急増への保護にはステップスケーリングポリシーを使用します。

多くのWebアプリケーションでは、まずCPUまたはターゲットごとのリクエスト数に対するターゲット追跡から始めます。設定が最小限で済み、計算はAWSが管理するためです。負荷の強さに応じて段階的かつ比例的に対応する必要がある場合は、ステップスケーリングを使用します。スケールアウトには時間がかかるため、ベースラインのトラフィックをスケールアウトに頼らず処理できるよう、必ず最小容量を十分に高く設定してください。GroupDesiredCapacityとGroupInServiceInstancesのCloudWatchメトリクスを監視し、ポリシーが期待どおり機能していることを確認します。

このレッスンで学んだAWS Solutions Architect（SAA-C03）の概念について理解度を確認します。

このレッスンでは、次のことを学びました。ターゲット追跡スケーリングは、メトリクスを目標値（CPU 50%など）に保つため、スケールアウト/スケールインの処理を自動的に計算して適用します。ステップスケーリングは、メトリクスがより高いしきい値を超えると、CloudWatchアラームに基づくステップ調整を使って、比例して大きな対応を実行します。1つのASGでポリシーを組み合わせることも安全です。ASGは、スケールアウトでは最も慎重な推奨を、スケールインでは最も控えめな推奨を使用します。次は、既知のトラフィックパターンに対応するスケジュールスケーリングと予測スケーリングについて学びます。