クラスターモードが有効になっている Amazon ElastiCache for Valkey または Amazon ElastiCache for Redis のセルフマネージドクラスターにおいて、シャード間のメモリ使用量が不均一になっています。
簡単な説明
デフォルトでは、クラスターモードが有効になっている Valkey および Redis OSS クラスターは、クラスター内のシャード間でキャッシュキーの容量を均等に分散しようとします。詳細については、「Amazon ElastiCache for Redis でクラスターモードを使用する方法」を参照してください。
次の要因でメモリ使用量のバランスが崩れ、一部のシャードが他のシャードよりも多くのデータを保存するようになる可能性があります。
- 不均一なキー分散
- 容量が大きすぎるキー
- 「ホット」キーまたはシャード
- 不均一なハッシュタグの使用
- クライアント出力バッファの増加
解決策
注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。
不均一なキー分散
ハッシュスロットをシャード全体に均等に分散していない場合、一部のシャードが他のシャードよりも多くのキーを処理する可能性があります。この問題を解決するには、クラスター全体でスロットのバランスを再調整します。
注: [スロットのバランス再調整] オプションでは、使用可能なシャード間で 16384 個のハッシュスロットを均等に分配しようとします。このオプションでは、メモリ使用量や各シャードのデータ量に基づいたバランス再調整は行いません。
一部のキー容量が大きすぎる場合
一部のキーが他のキーよりも大幅に大容量である場合、これらのキーをホストするシャードのメモリ使用量が多くなる可能性があります。大容量キーを小容量キーと値のペアに分割すると、この問題を解決できます。または、不要な大容量キーを削除して空き容量を増やしてください。
データセットにビッグキーがないかスキャンするには、valkey-cli --bigkeys コマンドまたは valkey-cli --memkeys コマンドを使用します。詳細については、Valkey のウェブサイトで「ビッグキーのスキャン」を参照してください。
効率的なキー命名方法、データ構造、圧縮手法により、キーのメモリ使用量を最適化することをおすすめします。
ホットキーまたはシャード
あるキーへのアクセス頻度が他のキーよりも高い場合、負荷が不均等に分散され、サービス側ホストのメモリ使用率に負荷がかかります。アクセス頻度が高いキーは、ホットキーまたはホットシャードと呼ばれます。
ホットキーを見つけるには、valkey-cli --hotkeys コマンドを実行してキーのアクセスパターンを確認し、キーを特定します。場合によっては、単独のホットキャッシュキーが要因で、キャッシュノードに負荷がかかるホットスポットが発生することがあります。ホットスポットは、ノードの CPU、メモリ、およびネットワークリソースに影響する可能性があります。
**注:**hotkeys コマンドは、maxmemory-policy が *lfu に設定されている場合にのみ機能します。
この問題を解決するには、次の手順を実行します。
- クラスターを垂直方向にスケーリングし、付与するリソースを増やします。
- 読み取りトラフィックをリードレプリカに分散します。詳細については、Valkey のウェブサイトで「READONLY」を参照してください。
- クライアントアプリケーションを変更し、キーへの書き込み量を削減します。、
不均一なハッシュタグの使用
クラスターモードが有効な環境では、ハッシュタグを使用して Valkey クラスターにマルチキー操作を実装する必要があります。ハッシュタグを多く使用すると、一部のハッシュスロットには他のハッシュスロットよりも多くのキーが保存され、シャード間でメモリのバランスが崩れます。
この問題を解決するには、キー容量とハッシュタグの使用状況を確認し、データをより多くのハッシュスロットに分散します。詳細については、Valkey のウェブサイトで「クラスター仕様」の「ハッシュタグ」セクションを参照してください。
クライアント出力バッファの増加
クライアントのコマンドにより、Valkey がクライアントに送信できる速度よりも速く出力を生成すると、クライアントの出力バッファが大きくなり、メモリ使用量が増加します。詳細については、Valkey のウェブサイトで「出力バッファの制限」を参照してください。
バッファに関する問題の原因を特定するには、問題が発生したノードに接続し、CLIENT LIST コマンドを実行してバッファ領域を使用するクライアントを特定します。詳細については、Valkey のウェブサイトで「CLIENT LIST」を参照してください。
クライアントの出力バッファが増加する原因を特定するには、出力内の次の主要パラメータを確認します。
- obl: 出力バッファ長
- omem: 出力バッファのメモリ使用量
- tot-mem: クライアントが使用する合計メモリ
さらに、Amazon CloudWatch でメトリクス DatabaseMemoryUsageCountedForEvictPercentage および DatabaseMemoryUsagePercentage を確認します。2 つのメトリク間でメモリ使用量の差が大きい場合、メモリ使用量はクライアントの出力バッファに起因しています。
注: DatabaseMemoryUsagePercentage メトリクスには、接続のオーバーヘッドとクライアント出力バッファのメモリ使用量も含まれます。
ベストプラクティス
メモリの不均衡の問題を削減するには、次のベストプラクティスを実施します。
TTL 設定を構成する
キーに適切な保持期間 (TTL) 値を設定します。適切な TTL 値を設定すると、Valkey ノードは TTL を使い果たしたキーを自動的に削除し、メモリ使用量を最適化します。詳細については、Valkey のウェブサイトで「TTL」を参照してください。
メモリメトリクスを確認する
シャード全体で、次の主要なメモリメトリクスを定期的に確認することで、不均衡を早期に特定し、積極的な対策を講じることをおすすめします。
- DatabaseMemoryUsagePercentage: ノードでの全体的なメモリ使用率を追跡します。
- DatabaseMemoryUsageCountedForEvictPercentage: バッファとオーバーヘッドの使用率増加を検出するには、DatabaseMemoryUsagePercentage と比較します。
- BytesUsedForCache: キャッシュされたデータが使用する実際のメモリを監視します。
- CurrItems: 各シャードに保存されている項目数を追跡します。
- SwapUsage: ホストで使用されているスワップの量を追跡します。
注: ElastiCache では、ある程度の SwapUsage は一般的に発生します。通常の使用では遅延の問題は発生しません。SwapUsage が 300 MB を超える場合は、メモリに負荷がかかっていないか確認してください。詳細については、「必要な予約メモリ量を教えてください」を参照してください。
ノードをアップグレードする
大容量キーや頻繁なアクセスパターンに対処するには、ElastiCache クラスターを一時的にスケールアップし、CPU とメモリのリソースを増やします。
関連情報
独自設計した Amazon ElastiCache for Redis クラスターのメモリ使用量を確認し、メモリ使用量の増加に対処するためのベストプラクティスを実装する方法を教えてください
キー分散モデル (Valkey のウェブサイト)
Amazon ElastiCache アップデート - Redis クラスターでのオンラインサイズ変更
ElastiCache インスタンスでスワップアクティビティが増加している場合の解決方法を教えてください