翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Auto Scaling Valkey クラスターと Redis OSSクラスター
前提条件
ElastiCache Auto Scaling は以下に限定されます。
-
Valkey 7.2 以降、または Redis OSS エンジンバージョン 6.0 以降を実行している Valkey または Redis OSS (クラスターモードが有効) クラスター
-
Valkey 7.2 以降、または Redis OSS エンジンバージョン 7.0.7 以降を実行しているデータ階層化 (クラスターモードが有効) クラスター
-
インスタンスサイズ - ラージ、XLarge、2XLarge
-
インスタンスタイプファミリー – R7g、R6g、R6gd、R5、M7g、M6g、M5、C7gn
-
の Auto Scaling ElastiCache は、グローバルデータストア、Outposts、またはローカルゾーンで実行されているクラスターではサポートされていません。
Valkey または Redis による ElastiCache Auto Scaling によるキャパシティの自動管理 OSS
ElastiCache Valkey または Redis を使用した自動スケーリングOSSは、 ElastiCache サービス内の必要なシャードまたはレプリカを自動的に増減する機能です。 は、Application Auto Scaling サービス ElastiCache を活用してこの機能を提供します。詳細については、Application Auto Scaling を参照してください。自動スケーリングを使用するには、割り当てた CloudWatch メトリクスとターゲット値を使用するスケーリングポリシーを定義して適用します。 ElastiCache 自動スケーリングは、ポリシーを使用して、実際のワークロードに応じてインスタンスの数を増減します。
を使用して、事前定義されたメトリクスに基づいてスケーリングポリシー AWS Management Console を適用できます。predefined metric
は列挙型で定義されるため、それをコード内に名前で指定するか、 AWS Management Consoleで使用できます。カスタムのメトリクスは、 AWS Management Consoleを使用した選択には使用できません。または、 AWS CLI または Application Auto Scaling API を使用して、事前定義されたメトリクスまたはカスタムメトリクスに基づいてスケーリングポリシーを適用することもできます。
ElastiCache Valkey または Redis では、次のディメンションのスケーリングOSSがサポートされています。
-
[シャード] — 手動オンラインリシャーディングと同様に、クラスター内のシャードを自動的に追加/削除します。この場合、 ElastiCache自動スケーリングはユーザーに代わってスケーリングをトリガーします。
-
[レプリカ] – 手動によるレプリカの増加/減少オペレーションと同様に、クラスター内のレプリカを自動的に追加/削除します。 ElastiCache Valkey または Redis OSS 自動スケーリングを使用すると、クラスター内のすべてのシャードでレプリカが均等に追加/削除されます。
ElastiCache Valkey または Redis では、次のタイプの自動スケーリングポリシーOSSがサポートされています。
-
ターゲット追跡スケーリングポリシー – 特定のメトリクスのターゲット値に基づいて、サービスが実行するシャード/レプリカの数を増減させます。これはサーモスタットが家の温度を維持する方法に似ています。温度を選択すれば、後はサーモスタットがすべてを実行します。
-
Valkey または Redis OSS 自動スケーリング ElastiCache によるアプリケーションのスケジュールされたスケーリング – サービスが実行しているシャード/レプリカの数を、日時に基づいて増減します。
次の手順では、前の図に示すように、 ElastiCache と Valkey または Redis OSS 自動スケーリングプロセスの概要を示します。
-
レプリケーショングループの ElastiCache 自動スケーリングポリシーを作成します。
-
ElastiCache Valkey または Redis による自動スケーリングは、ユーザーに代わって CloudWatch アラームのペアOSSを作成します。各ペアはメトリクスの上限と下限を示します。これらの CloudWatch アラームは、クラスターの実際の使用率がターゲット使用率から一定期間逸脱したときにトリガーされます。コンソールでアラームを表示できます。
-
設定されたメトリクス値が特定の期間にわたってターゲット使用率を超える (またはターゲットを下回る) 場合、 は自動スケーリングを呼び出してスケーリングポリシーを評価するアラーム CloudWatch をトリガーします。
-
ElastiCache Valkey または Redis OSS 自動スケーリングを使用すると、クラスター容量を調整するための変更リクエストが発行されます。
-
ElastiCache Valkey または Redis では、ターゲット使用率に近づくようにクラスターのシャード/レプリカ容量を動的に増加 (または減少) して、変更リクエストOSSを処理します。
Valkey または Redis OSS Auto Scaling ElastiCache の仕組みを理解するには、 という名前のクラスターがあるとしますUsersCluster
。の CloudWatch メトリクスをモニタリングすることでUsersCluster
、トラフィックがピーク時にクラスターが必要とする最大シャードと、トラフィックが最低ポイントにあるときに最小シャードを決定します。また、UsersCluster
クラスターのCPU使用率のターゲット値も決定します。 ElastiCache 自動スケーリングでは、ターゲット追跡アルゴリズムを使用して、 のプロビジョニングされたシャードUsersCluster
が必要に応じて調整され、使用率がターゲット値に近づくようにします。
注記
スケーリングにはかなりの時間がかかる場合があり、シャードが再調整するには追加のクラスターリソースが必要になります。Valkey または Redis OSS Auto Scaling ElastiCache では、実際のワークロードが数分間維持されて (または抑制されて) いる場合にのみリソース設定を変更します。自動スケーリングターゲット追跡アルゴリズムは、ターゲット使用率を長期的に選択した値以下に維持することを目指します。
IAM Auto Scaling に必要なアクセス許可
ElastiCache Valkey または Redis OSS Auto Scaling は ElastiCache、、 CloudWatch、および Application Auto Scaling の組み合わせによって可能になりますAPIs。クラスターは ElastiCache (Redis OSS) で作成および更新され、アラームは で作成され CloudWatch、スケーリングポリシーは Application Auto Scaling で作成されます。クラスターを作成および更新するための標準IAMアクセス許可に加えて、 ElastiCache 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 Valkey または Redis OSS 自動スケーリングサービスの には、クラスターと CloudWatch アラームを記述するアクセス許可と、ユーザーに代わって ElastiCache ターゲットキャパシティを変更するアクセス許可も必要です。クラスターの Auto Scaling を有効にすると、 という名前のサービスにリンクされたロールが作成されますAWSServiceRoleForApplicationAutoScaling_ElastiCacheRG
。このサービスにリンクされたロールは、ポリシーのアラームを記述し、フリートの現在の容量をモニタリングし、フリートの容量を変更する ElastiCache 自動スケーリングアクセス許可を付与します。サービスにリンクされたロールは、 ElastiCache 自動スケーリングのデフォルトロールです。詳細については、Application Auto Scaling ユーザーガイドの ElastiCache (Redis OSS) 自動スケーリングのサービスにリンクされたロールを参照してください。
Auto Scaling のベストプラクティス
Auto Scaling に登録する前に、以下のことをお勧めします。
-
追跡メトリクスを 1 つだけ使用する – クラスターに CPU または データ集約型ワークロードがあるかどうかを特定し、対応する事前定義されたメトリクスを使用してスケーリングポリシーを定義します。
-
エンジン CPU:
ElastiCachePrimaryEngineCPUUtilization
(シャードディメンション) またはElastiCacheReplicaEngineCPUUtilization
(レプリカディメンション) -
データベースの使用状況:
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage
このスケーリングポリシーは、クラスターで maxmemory-policy が noeviction に設定されている場合に最適です。
クラスターのディメンションごとに複数のポリシーを避けることをお勧めします。Valkey または Redis OSS Auto スケーリング ElastiCache を使用すると、ターゲット追跡ポリシーがスケールアウトできる状態であればスケーラブルターゲットがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分が有効になっている) がスケールインできる状態である場合にのみスケールインされます。複数のポリシーによって、スケーラブルなターゲットが同時にスケールアウトまたはスケールインするように指示される場合、Auto Scaling は、スケールインとスケールアウトの両方で最大の容量を提供するポリシーに基づいてスケールします。
-
-
ターゲット追跡のカスタマイズされたメトリクス — Target Tracking 用にカスタマイズされたメトリクスを使用する場合は注意が必要です。Auto Scaling は、ポリシー用に選択されたメトリクスの変更に比例してスケールアウトするのに最適です。スケーリングアクションに比例して変更されないメトリクスがポリシーの作成に使用されると、可用性やコストに影響する可能性のあるスケールアウトまたはスケールインアクションが継続する可能性があります。
データ階層化クラスター (r6gd ファミリーのインスタンスタイプ) では、スケーリングにメモリベースのメトリクスを使用しないでください。
-
スケジュールに基づくスケーリング — ワークロードが確定的 (特定の時点で高/低に達する) であることが判明した場合は、スケジュールされたスケーリングを使用し、必要に応じてターゲット容量を設定することをお勧めします。ターゲット追跡は、非決定的なワークロードや、必要なターゲットメトリクスでクラスターを操作する場合に最適です。これにより、より多くのリソースが必要な場合はスケールアウトし、必要な場合はスケールインします。
-
スケールインを無効化する — ターゲット追跡での Auto Scaling は、ワークロードが徐々に増減するクラスターに最適です。メトリクスのスパイク/ディップが連続するスケールアウト/イン振動を引き起こす可能性があるためです。このような振動を避けるために、スケールインを無効にして開始し、後でいつでも必要に応じて手動でスケールインすることができます。
-
アプリケーションをテスト — 可用性の問題を回避するために、スケーリングポリシーを作成しながら、クラスターに必要な最小/最大シャード/レプリカの絶対値を決定するために、最小/最大ワークロードを推定してアプリケーションをテストすることをお勧めします。Auto Scaling は Max にスケールアウトし、ターゲットに設定された最小しきい値にスケールインできます。
-
ターゲット値の定義 – 4 週間にわたるクラスター使用率に対応する CloudWatch メトリクスを分析して、ターゲット値のしきい値を決定できます。選択する値が不明な場合は、サポートされる最小定義メトリクス値から開始することをお勧めします。
-
AutoScaling on Target Tracking は、シャード/レプリカディメンション間でワークロードを均一に分散するクラスターに最適です。不均一な分布を持つと、次のことが可能になります。
-
いくつかのホットシャード/レプリカでワークロードの急増/減少が原因で、必要のない場合のスケーリング。
-
ホットシャード/レプリカがあるにもかかわらず、全体的な平均ターゲットに近いために必要なときにスケーリングされません。
-
注記
クラスターをスケールアウトすると、 ElastiCache は既存のノード (ランダムに選択) の 1 つにロードされた関数を新しいノード (複数可) に自動的にレプリケートします。クラスターに Valkey または Redis OSS7.0 以降があり、アプリケーションが Functions
に登録したら AutoScaling、次の点に注意してください。
-
Auto Scaling でサポートされる設定には制限があるため、Auto Scaling に登録されているレプリケーショングループの設定を変更しないことをお勧めします。次に例を示します。
-
インスタンスタイプをサポートされていないタイプに手動で変更します。
-
レプリケーショングループをグローバルデータストアに関連付けます。
-
ReservedMemoryPercent
パラメータの変更。 -
ポリシーの作成時に設定された Min/Max 容量を超えるシャード/レプリカを手動で増減します。
-