ElastiCache クラスターのメモリ使用率が高いか、または増加しているのはなぜですか?

解決方法

クラスターとそのノード全体のメモリ使用量を判断するには、こちらの Redis メトリクスを確認します。これらのメトリクスは、Amazon CloudWatch でクラスター内のノードごとに公開されます。

• BytesUsedForCache: データセット、バッファなどに Redis で割り当てられた総バイト数。このメトリクスは、Redis ノードの INFO コマンド出力から得られます。このメトリクスを使用して、クラスターのメモリ使用率を判断します。
• FreeableMemory: このホストレベルのメトリクスは、ホストで使用可能な空きメモリの量を示します。キャッシュデータまたはオーバーヘッドによってメモリ使用量が増加すると、FreeableMemory の減少が見られます。FreeableMemory の減少は、ホストの空きメモリが少ないことを示唆しています。FreeableMemory が低すぎると、スワップが発生することがあります。
• DataBaseMemoryUsagePercentage: このメトリクスは、Redis INFO コマンド出力から得られます。これは、クラスターノードによって使用されているメモリの割合です。このメトリクスがしきい値の 100% に達すると、Redis は Redis maxmemory エビクションポリシーを開始します。

デフォルトでは、ElastiCache for Redis は max-memory の 25% をデータ以外の用途 (フェイルオーバーやバックアップなど) に予約していることに注意してください。データ以外の用途に十分な予約メモリを指定しないと、スワップの可能性が高くなります。詳細については、「Managing reserved memory」(予約済みメモリの管理) を参照してください。

突然のメモリ使用量増加の原因

• 最近追加されたキー: 新しいキーと値のペアを追加すると、メモリ使用量が増加します。既存のキーに要素を追加すると、メモリ使用量も増加します。SetTypeCmds メトリクスを調べて、ノードにデータ変更が最近加えられたかどうかを確認します。このメトリクスは、書き込みタイプコマンドの総数をログに記録するもので、Redis commandstats 統計から得られます。
• バッファ使用量の増加: クライアントはネットワーク経由で Redis に接続されています。クライアントがキャッシュから十分な速さで読み込まない場合、Redis は応答データをクライアント出力バッファと呼ばれるメモリ空間に保持します。クライアントは、このバッファ空間から読み込みを続けることができます。これは、サブスクライブしているクライアントが十分な速さで読み込まない場合の Pub/Sub クライアントにも当てはまります。
  ネットワーク帯域幅にボトルネックがある場合、またはクラスターに継続的に高い負荷がかかっている場合は、バッファ使用量が累積し続ける可能性があります。この蓄積がメモリの枯渇やパフォーマンス低下の原因となります。デフォルトでは、ElastiCache for Redis は出力バッファの増大を制限せず、クライアントごとに独自のバッファがあります。バッファ使用量を確認するには、client-list コマンドを使用します。
• 多数の新規接続: 新規接続の数が多いと、メモリ使用量が増加する可能性があります。新規接続では必ず、メモリを消費するファイル記述子が作成されます。新規接続の数が多いと総メモリ消費量が高くなり、データエビクションまたは OOM エラーにつながる可能性があります。承認された新規接続の総数については、NewConnections メトリクスを確認してください。
• スワップ使用量が多い: 空きメモリがある場合にキャッシュノードで多少のスワップ使用量が見られるのは正常です。ただし、スワップ使用量が多すぎると、パフォーマンスの問題が発生する可能性があります。通常、スワップの多さはメモリ不足で動作しているノードで起こり始め、その結果として空きメモリが減少します。SwapUsage メトリクスを使用して、ホストのスワップを監視します。
• メモリのフラグメンテーションが多い: メモリのフラグメンテーションが多いということは、オペレーティングシステム内のメモリ管理が非効率であることを示しています。キーを削除しても Redis はメモリを解放しない可能性があります。MemoryFragmentationRatio メトリクスを使用して、フラグメント化率を監視します。フラグメンテーションの問題が発生した場合は、アクティブメモリ最適化用の activedefrag パラメータをオンにします。
• ビッグキー: データサイズが大きい、または要素数が多いキーをビッグキーと呼びます。CurrItems メトリクスが低いままでも、ビッグキーの結果としてメモリ使用率が高くなる場合があります。データセット内のビッグキーを検出するには、redis-cli --bigkeys コマンドを使用します。

高いメモリ使用量を制御するベストプラクティス

• キーに TTL を使用する: キーに TTL を指定して有効期限を設定できます。これにより、メモリ不足になる前に期限切れのキーが削除されます。結果として、不要なキーで Redis が乱雑になるのを防ぐことができます。エビクションの数が少なければ心配いりませんが、エビクションの数が多いということは、ノードがメモリ不足で動作していることを意味します。
• エビクションポリシーを使用する: キャッシュメモリが不足し始めると、Redis は maxmemory-policy に基づいてキーを削除してスペースを解放します。デフォルトの maxmemory-policy ポリシーは volatile_lru に設定されています。ワークロードのニーズに固有のエビクションポリシーを選択するのがベストプラクティスです。
• 予約済みメモリの割り当て: フェイルオーバーまたはバックアップ時の問題を回避するには、reserved_memory_percentage で 25% 以上をデータ以外の用途に設定することをお勧めします。フェイルオーバーまたはバックアップの実行に十分な予約済みメモリがない場合、スワップとパフォーマンスの問題が発生します。
• 接続プールを使用する: 接続プールは、Redis クライアントが試みる多数の新規接続を制御するのに役立ちます。多数の新規接続を処理するための AWS ベストプラクティスガイドラインを確認してください。
• 出力バッファサイズ制限を調整する: 出力バッファ制限を調整して、バッファ空間の使用量を制御できます。ElastiCache for Redis パラメータグループは、クライアント出力バッファ使用量が無制限に増加するのを防ぐために、client-output-buffer-limit-* で始まるいくつものパラメータを提供します。すべてのワークロードは一意であるため、これらのパラメータには推奨される制限がないことに注意してください。適切な値を選択できるように、ワークロードをベンチマークするのがベストプラクティスです。
• ハッシュマッピングの使用を検討する: Redis では、Redis DB の合計メモリフットプリントは線形です。少ないフィールドでハッシュマッピングされた単一のキーよりも、わずかな個々のキーの方が多くのメモリを必要とします。ハッシュマッピングは、多数のキーを持つデータ構造に役立ちます。ハッシュマッピングに加えて、ハッシュテーブルと比較してメモリフットプリントを削減する ziplist エンコーディングを利用できます。ハッシュマッピングを使用すると、Redis エンジンの使用量が急増する可能性があることに注意してください。これは複雑なコマンドであり、セットオペレーションよりも多くの CPU を必要とするためです。
• クラスターをスケーリングする: 必要な対策を講じてもメモリが不足することがあります。これが発生し、かつ使用量が予想されるワークロードによるものである場合は、適切なスケーリングを行い、メモリのボトルネックを緩和することを検討してください。
• メモリ使用量のアラームを設定します。 CloudWatch アラームを使用すると、メモリ使用量が事前設定されたしきい値を超えた場合にアラームが開始されます。BytesUsedForCache または DatabaseMemoryUsagePercentage メトリクスを使用して、モニタリングとスケーリングの目的で CloudWatch コンソールからアラームを作成します。

---

関連情報

Redis のメトリクス

Redis 4.0.10 パラメータの変更

ElastiCache for Redis クラスターノードの「OOM command not allowed」(OOM コマンドは許可されていません) というエラーメッセージを解決する方法を教えてください。

キーエビクション

Redis のメモリ最適化