ElastiCache for Redis クラスターの Auto Scaling - Amazon ElastiCache for Redis
前提条件ElastiCache for Redis の Auto Scaling を用いた容量の自動管理ElastiCache for Redis の Auto Scaling に必要な IAM アクセス許可 サービスリンクロールAuto Scaling のベストプラクティス

ElastiCache for Redis クラスターの Auto Scaling

前提条件

ElastiCache for Redis の Auto Scaling は、以下に制限されています。

  • Redis エンジンバージョン 6.0 以降を実行する Redis (クラスターモードが有効) クラスター

  • インスタンスタイプファミリー - R5、R6g、M5、M6g

  • インスタンスサイズ - Large、XLarge、2XLarge

  • ElastiCache for Redis の Auto Scaling は、グローバルデータストア、Outposts、または Local Zones で実行しているクラスターではサポートされません。

  • ElastiCache for Redis の AWS Auto Scaling は、中国 (北京)、中国 (寧夏)、AWS GovCloud (米国西部) および AWS GovCloud (米国東部) のリージョンでは利用できません。

ElastiCache for Redis の Auto Scaling を用いた容量の自動管理

ElastiCache for Redis オートスケーリングは、ElastiCache for Redis サービスで必要なシャードまたはレプリカを自動的に増減する機能です。ElastiCache for Redis は、アプリケーションの Auto Scaling サービスを活用してこの機能を提供します。詳細については、Application Auto Scaling を参照してください。Automatic Scaling を使用するには、割り当てた CloudWatch メトリクスとターゲット値を使用するスケーリングポリシーを定義して適用します。ElastiCache for Redis 自動スケーリングでは、ポリシーを使用し、実際のワークロードに応じてインスタンス数を増減します。

AWS Management Console を使用し、事前定義されたメトリクスに基づいてスケーリングポリシーを適用できます。predefined metric は列挙型で定義されるため、それをコード内に名前で指定するか、AWS Management Console で使用できます。カスタムのメトリクスは、AWS Management Console を使用した選択には使用できません。代わりに、AWS CLI または Application Auto Scaling API を使用し、事前定義されたメトリクスまたはカスタムメトリクスに基づいてスケーリングポリシーを適用することもできます。

ElastiCache for Redis は、次のディメンションのスケーリングをサポートしています。

  • [シャード] — 手動オンラインリシャーディングと同様に、クラスター内のシャードを自動的に追加/削除します。この場合、ElastiCache for Redis の Auto Scaling はユーザーに代わってスケーリングをトリガーします。

  • [レプリカ] – 手動によるレプリカの増加/減少オペレーションと同様に、クラスター内のレプリカを自動的に追加/削除します。ElastiCache for Redis の Auto Scaling は、クラスター内のすべてのシャードにわたって均一にレプリカを追加/削除します。

Redis for ElastiCache は、以下のタイプの自動スケーリングポリシーをサポートします。

次のステップは、前の図に示された ElastiCache for Redis の Auto Scaling のプロセスをまとめたものです。

  1. ElastiCache for Redis レプリケーショングループ用の ElastiCache for Redis の Auto Scaling ポリシーを作成します。

  2. ElastiCache for Redis の Auto Scaling は、ユーザーに代わって CloudWatch アラームのペアを作成します。各ペアはメトリクスの上限と下限を示します。CloudWatch アラームは、クラスターの実際の使用率が一定期間ターゲット使用率を逸脱したときにトリガーされます。コンソールでアラームを表示できます。

  3. 設定したメトリクスの値が特定の期間にターゲット使用率を超える (または下回る) と、CloudWatch は、ElastiCache for Redis の Auto Scaling を呼び出してスケーリングポリシーを評価するアラームをトリガーします。

  4. ElastiCache for Redis の Auto Scaling は、クラスター容量を調整するための変更リクエストを発行します。

  5. Redis for ElastiCache は Modify リクエストを処理してクラスターのシャード/レプリカの容量を動的に増減し、ターゲット使用率に近づけます。

ElastiCache for Redis の Auto Scaling の仕組みを理解するため、UsersCluster という名前のテーブルがあると仮定します。UsersCluster の CloudWatch メトリックスをモニタリングすることで、トラフィックがピークのときにクラスターが必要とする最大シャードを決定し、トラフィックが最小ポイントにあるときに最小シャードを決定します。また、UsersCluster クラスターの CPU 使用率のターゲット値を決定します。ElastiCache for Redis の Auto Scaling は、ターゲット追跡アルゴリズムを使用して、UsersCluster のプロビジョンされたシャードが必要に応じて調整され、使用率がターゲット値またはその近くに留まるようにします。

注記

スケーリングにはかなりの時間がかかることがあり、シャードを再調整するために余分なクラスターリソースが必要になります。ElastiCache for Redis の Auto Scaling は、実際のワークロードの増減が数分間維持された場合にのみ、リソース設定を変更します。ElastiCache for Redis の Auto Scaling ターゲット追跡アルゴリズムはターゲット使用率を選択した値の付近に長期に渡って維持しようとします。

ElastiCache for Redis の Auto Scaling に必要な IAM アクセス許可

ElastiCache for Redis の Auto Scaling は、ElastiCache for Redis、CloudWatch、および Application Auto Scaling API を組み合わせることで可能になります。クラスターは ElastiCache for Redis で作成および更新され、アラームは CloudWatch で作成され、スケーリングポリシーは Application Auto Scaling で作成されます。クラスターの作成および更新のためのデフォルトの IAM アクセス許可に加えて、ElastiCache for Redis の Auto Scaling 設定にアクセスする IAM ユーザーは、動的スケーリングをサポートするサービスに対する適切なアクセス許可が必要です。IAM ユーザーには、次のポリシー例に示すアクションを使用するためのアクセス許可が必要です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "application-autoscaling:*",
                "elasticache:DescribeReplicationGroups",
                "elasticache:ModifyReplicationGroupShardConfiguration",
                "elasticache:IncreaseReplicaCount",
                "elasticache:DecreaseReplicaCount",
                "elasticache:DescribeCacheClusters",
                "elasticache:DescribeCacheParameters",
                "cloudwatch:DeleteAlarms",
                "cloudwatch:DescribeAlarmHistory",
                "cloudwatch:DescribeAlarms",
                "cloudwatch:DescribeAlarmsForMetric",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:ListMetrics",
                "cloudwatch:PutMetricAlarm",
                "cloudwatch:DisableAlarmActions",
                "cloudwatch:EnableAlarmActions",
                "iam:CreateServiceLinkedRole",
                "sns:CreateTopic",
                "sns:Subscribe",
                "sns:Get*",
                "sns:List*"
            ],
            "Resource": "arn:aws:iam::123456789012:role/autoscaling-roles-for-cluster"
        }
    ]
}

サービスリンクロール

ElastiCache for Redis の Auto Scaling サービスには、クラスターと CloudWatch のアラームを記述するためのアクセス許可と、ユーザーに代わって ElastiCache for Redis のターゲット容量を変更するためのアクセス許可も必要です。ElastiCache for Redis クラスターの Auto Scaling を有効にすると、サービスにリンクされたロールが AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG という名前で作成されます。このサービスにリンクされたロールは、ElastiCache for Redis の Auto Scaling に対して、ポリシーのアラームの記述、フリートの現容量のモニタリング、およびフリートの容量の変更を行うためのアクセス許可を付与します。サービスにリンクされたロールは、ElastiCache for Redis の Auto Scaling のデフォルトロールです。詳細については、Application Auto Scaling ユーザーガイドの「ElastiCache for Redis の Auto Scaling のサービスにリンクされたロール」を参照してください。

Auto Scaling のベストプラクティス

Auto Scaling に登録する前に、以下のことをお勧めします。

  1. 追跡メトリクスを 1 つだけ使用 — クラスターに CPU 負荷の高いワークロードまたはメモリ負荷の高いワークロードがあるかどうかを識別し、対応する定義済みメトリックを使用してスケーリングポリシーを定義します。クラスターの 1 つのディメンションでポリシーが複数にならないようお勧めします。ElastiCache for Redis の Auto Scaling では、ターゲット追跡ポリシーのいずれかでスケールアウトする準備ができると、スケーラブルなターゲットがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分が有効) でスケールインする準備ができている場合のみスケールインされます。複数のポリシーによって、スケーラブルなターゲットが同時にスケールアウトまたはスケールインするように指示される場合、Auto Scaling は、スケールインとスケールアウトの両方で最大の容量を提供するポリシーに基づいてスケールします。

  2. 1 つのディメンションのみを使用 — クラスターに書き込みまたは読み込みの大量のワークロードがあるかどうかを識別し、対応するディメンション (シャード/レプリカ) を使用してスケーリングポリシーを定義します。同じクラスターの複数のディメンションにポリシーを設定すると、スケーリングアクションに影響する可能性があります。例えば、シャードとレプリカの両方に対してエンジン CPU にスケーリングポリシーを作成し、レプリカと共に新しいシャードを追加するシャードディメンションでスケールアウトアクションがトリガーされた場合、新しいレプリカのこの増加は、レプリカのスケールインをトリガーするレプリカディメンションのスケーリングポリシーに影響を及ぼし、逆も同様です。Avg メトリクスは、事前定義メトリックのクラスタノード間で使用されます。

  3. ターゲット追跡のカスタマイズされたメトリクス — Target Tracking 用にカスタマイズされたメトリクスを使用する場合は注意が必要です。Auto Scaling は、ポリシー用に選択されたメトリクスの変更に比例してスケールアウトするのに最適です。スケーリングアクションに比例して変更されないメトリクスがポリシーの作成に使用されると、可用性やコストに影響する可能性のあるスケールアウトまたはスケールインアクションが継続する可能性があります。

  4. スケジュールに基づくスケーリング — ワークロードが確定的 (特定の時点で高/低に達する) であることが判明した場合は、スケジュールされたスケーリングを使用し、必要に応じてターゲット容量を設定することをお勧めします。ターゲット追跡は、非決定的なワークロードや、必要なターゲットメトリクスでクラスターを操作する場合に最適です。これにより、より多くのリソースが必要な場合はスケールアウトし、必要な場合はスケールインします。

  5. スケールインを無効化する — ターゲット追跡での Auto Scaling は、ワークロードが徐々に増減するクラスターに最適です。メトリクスのスパイク/ディップが連続するスケールアウト/イン振動を引き起こす可能性があるためです。このような振動を避けるために、スケールインを無効にして開始し、後でいつでも必要に応じて手動でスケールインすることができます。

  6. アプリケーションをテスト — 可用性の問題を回避するために、スケーリングポリシーを作成しながら、クラスターに必要な最小/最大シャード/レプリカの絶対値を決定するために、最小/最大ワークロードを推定してアプリケーションをテストすることをお勧めします。Auto Scaling は Max にスケールアウトし、ターゲットに設定された最小しきい値にスケールインできます。

  7. ターゲット値の定義 — 4 週間のクラスター使用率の対応する CloudWatch メトリクスを分析し、目標値のしきい値を決定できます。選択する値が不明な場合は、サポートされる最小定義メトリクス値から開始することをお勧めします。

  8. ターゲット追跡での AutoScaling は、シャード/レプリカのディメンション間でワークロードが均一に分散されるクラスターに最適です。不均一な分布を持つと、次のことが可能になります。

    • いくつかのホットシャード/レプリカでワークロードの急増/減少が原因で、必要のない場合のスケーリング。

    • ホットシャード/レプリカがあるにもかかわらず、全体的な平均ターゲットに近いために必要なときにスケーリングされません。

注記

クラスターをスケールアウトすると、ElastiCache は (ランダムに選択された) 既存のノードのいずれかにロードされた関数を新しいノードに自動的にレプリケートします。クラスターに Redis 7.0 以上があり、アプリケーションで Redis 関数を使用している場合は、スケールアウトする前に、クラスターがシャードにより異なる関数定義にならないように、すべての関数をすべてのシャードに読み込むことをお勧めします。

AutoScaling に登録したら、以下の点に注意してください。

  • Auto Scaling でサポートされる設定には制限があるため、Auto Scaling に登録されているレプリケーショングループの設定を変更しないことをお勧めします。次に例を示します。

    • インスタンスタイプをサポートされていないタイプに手動で変更します。

    • レプリケーショングループをグローバルデータストアに関連付けます。

    • ReservedMemoryPercent パラメータの変更。

    • ポリシーの作成時に設定された Min/Max 容量を超えるシャード/レプリカを手動で増減します。