ターゲット追跡スケーリングポリシー
ターゲット追跡スケーリングポリシーで、メトリクスを選択してターゲット値を設定します。Valkey または Redis OSS 対応 ElastiCache の自動スケーリングは、スケーリングポリシーをトリガーする CloudWatch アラームを作成および管理し、メトリクスとターゲット値に基づいてスケーリング調整値を計算します。スケーリングポリシーは、指定されたターゲット値、またはそれに近い値にメトリクスを維持するため、必要に応じてシャードを追加または削除します。ターゲットの追跡スケーリングポリシーは、メトリクスをターゲット値近くに維持することに加えて、負荷パターンの変動によるメトリクスの変動に合わせて調整し、フリートの容量の急速な変動を最小化します。
たとえば、設定されたターゲット値を持つ事前定義された平均 ElastiCachePrimaryEngineCPUUtilization メトリクスを使用するスケーリングポリシーを考慮してください。このようなポリシーは、指定されたターゲット値、またはそれに近い値に CPU 使用率を維持できます。
事前定義メトリクス
定義済みメトリクスとは、特定の CloudWatch メトリクスの特定の名前、ディメンション、統計 (average) を参照する構造です。Auto Scaling ポリシーでは、クラスターの次の事前定義されたメトリクスのいずれかを定義します。
| 事前定義済みメトリクス名 | CloudWatch メトリクス名 | CloudWatch メトリクスディメンション | 不適格なインスタンスタイプ |
|---|---|---|---|
ElastiCachePrimaryEngineCPUUtilization |
|
ReplicationGroupId、ロール = プライマリ |
なし |
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage |
|
Valkey または Redis OSS レプリケーショングループメトリクス |
なし |
ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage |
|
Valkey または Redis OSS レプリケーショングループメトリクス |
R6gd |
これらのインスタンスタイプはメモリと SSD の両方にデータを保存するため、データ階層型インスタンスタイプでは ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage を使用できません。データ階層インスタンスの想定される使用例は、メモリを 100% 使用し、必要に応じて SSD をいっぱいにすることです。
シャードの Auto Scaling 基準
事前定義されたメトリクスが Target 設定以上であることを検出した場合、シャードの容量が自動的に増加します。Valkey または Redis OSS 対応 ElastiCache は、ターゲットからの変動率と現在のシャードの 20% の 2 つの数字のうち、大きい方の数に等しい数だけクラスターシャードをスケールアウトします。スケールインの場合、全体的なメトリクス値が定義されたターゲットの 75% を下回らない限り、ElastiCache は自動スケールインしません。
スケールアウトの例では、50個のシャードを持っている場合
-
ターゲットが 30% 超えた場合、Valkey または Redis OSS 対応 ElastiCache は 30% スケールアウトして、クラスターあたり 65 個のシャードになります。
-
ターゲットが 10% 超えた場合、Valkey または Redis OSS 対応 ElastiCache はデフォルトで最小 20% スケールアウトして、クラスターあたり 60 個のシャードになります。
スケールインの例では、ターゲット値として 60% を選択した場合、Valkey または Redis OSS 対応 ElastiCache は、メトリクスが 45% 以下 (ターゲットの 60% を 25% 下回る) になるまで自動スケールインしません。
Auto Scaling に関する考慮事項
次の考慮事項に注意が必要です。
-
ターゲットの追跡スケーリングポリシーでは、指定されたメトリクスがターゲット値を超えている場合、スケールアウトする必要があると見なされます。指定されたメトリクスがターゲット値を下回っている場合、ターゲットの追跡スケーリングポリシーを使用してスケールアウトすることはできません。Valkey または Redis OSS 対応 ElastiCache は、クラスター内の既存のシャードのターゲットの最小偏差の 20% 分だけシャードをスケールアウトします。
-
指定されたメトリクスに十分なデータがない場合、ターゲットの追跡スケーリングポリシーによってスケールされません。不十分なデータの使用率は低いと解釈されないため、スケールインされません。
-
ターゲット値と実際のメトリクスデータポイント間にギャップが発生する場合があります。これは、Valkey または Redis OSS 対応 ElastiCache の自動スケーリングが追加または削除する容量を決定するときに、その数を切り上げまたは切り捨てて常に控えめに動作するためです。これにより、不十分な容量を追加したり、必要以上に容量を削除することを防ぎます。
-
アプリケーションの可用性を高めるために、サービスのスケールアウトはメトリクスに比例して可能な限り高速に行われますが、スケールインはより抑制されています。
-
それぞれが異なるメトリクスを使用していれば、Valkey または Redis OSS 対応 ElastiCache クラスターに対して複数のターゲット追跡スケーリングポリシーを設定できます。ElastiCache (Redis OSS) の自動スケーリングの目的は常に可用性を優先することであるため、その動作は、ターゲット追跡ポリシーがスケールアウトまたはスケールインの準備ができているかどうかに応じて異なります。ターゲット追跡ポリシーのいずれかでスケールアウトする準備ができると、サービスがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分が有効) でスケールインする準備ができている場合にのみスケールインされます。
-
ターゲットの追跡スケーリングポリシーのために Valkey または Redis OSS 対応 ElastiCache の自動スケーリングが管理する CloudWatch アラームを編集または削除しないでください。ElastiCache の自動スケーリングでは、スケーリングポリシーを削除するときに、アラームが自動的に削除されます。
-
ElastiCache の自動スケーリングにより、クラスターシャードを手動で変更できなくなることはありません。これらの手動調整は、スケーリングポリシーにアタッチされている CloudWatch アラームに影響しませんが、これらの CloudWatch アラームをトリガーする可能性のあるメトリクスに影響する可能性があります。
-
Auto Scaling によって管理されるこれらの CloudWatch アラームは、クラスター内のすべてのシャードでの AVG メトリクスで定義されます。したがって、ホットシャードを持つと、次のいずれかのシナリオが発生する可能性があります。
-
CloudWatch アラームをトリガーするいくつかのホットシャードへの負荷が原因で、必要のない場合にスケーリングする
-
アラームが違反しないように影響を及ぼすすべてのシャードで集約された AVG が原因で、必要な場合にスケーリングしない。
-
-
クラスターごとのノードに対する Valkey または Redis OSS 対応 ElastiCache のデフォルト制限は引き続き適用されます。したがって、Auto Scaling を選択するときに、最大ノード数がデフォルトの制限を超えると予測される場合は、[AWS サービス制限] で制限の増加をリクエストし、制限タイプ [インスタンスタイプごとのクラスターあたりのノード] を選択します。
-
スケールアウト時に必要な、VPC で十分な ENI（Elastic Network Interfaces）が使用可能であることを確認します。詳細については、「Elastic Network Interface」を参照してください。
-
EC2 の容量が十分にない場合、ElastiCache の自動スケーリングは、容量が利用可能になるまで、スケールせず、遅延します。
-
スケールイン中の ElastiCache (Redis OSS) の自動スケーリングは、シリアル化後のアイテムサイズが 256 MB を超えるスロットを持つシャードを削除しません。
-
スケールイン中に、結果として得られるシャード設定で利用可能なメモリが不足している場合、シャードは削除されません。
