翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
モニタリングすべきメトリクス
次の CloudWatch メトリクスは、ElastiCache パフォーマンスを把握するのに役立ちます。ほとんどの場合、パフォーマンスの問題が発生する前に修正作業を行うことができるように、これらのメトリクスに CloudWatch アラームを設定することをお勧めします。
モニタリングするメトリクス
CPUUtilization
パーセント値でレポートされるホストレベルのメトリクスです。詳細については、「ホストレベルのメトリクス」を参照してください。
Valkey および Redis OSS
2 個以下の vCPU を持つ小さなノードタイプの場合は、CPUUtilization
メトリクスを使用してワークロードをモニタリングします。
一般的に、利用可能な CPU の 90% にしきい値を設定することをお勧めします。Valkey および Redis OSS はどちらもシングルスレッドであるため、実際のしきい値はノードの総容量の一部として計算すべきです。例えば、2 個のコアを搭載するノードタイプを使用しているとします。この場合、CPUUtilization のしきい値は 90/2、つまり 45% になります。
使用しているキャッシュノードのコア数に基づいて独自のしきい値を決定する必要があります。このしきい値を超えた場合で、主なワークロードが読み込みリクエストから生成されている場合、リードレプリカを追加してキャッシュクラスターをスケールします。主なワークロードが書き込みリクエストからのものである場合、クラスター設定に応じて、以下のことをお勧めします。
-
Valkey または Redis OSS (クラスターモードが無効) クラスター: より大きなキャッシュインスタンスタイプを使用してスケールアップします。
-
Valkey または Redis OSS (クラスターモードが有効) クラスター: より多くのシャードを追加して、より多くのプライマリノード間で書き込みワークロードを分散します。
ヒント
Valkey または Redis OSS ユーザーは、ホストレベルのメトリクス CPUUtilization
を使用する代わりに、Valkey または Redis OSS エンジンコアでの使用量のパーセント値をレポートするメトリクス EngineCPUUtilization
を使用できる場合があります。ノードでこのメトリクスが利用できるかどうか、およびその詳細については、「Valkey と Redis OSS のメトリクス」を参照してください。
4 個以上の vCPU を持つ大きなノードタイプでは、Valkey または Redis OSS エンジンコアでの使用量のパーセント値をレポートする EngineCPUUtilization
メトリクスを使用することをお勧めします。ノードでこのメトリクスが利用できるかどうか、およびその詳細については、「Metrics for Redis OSS」を参照してください。
Memcached
Memcached はマルチスレッドのため、このメトリクスは約 90% です。このしきい値を超えた場合、より大きいキャッシュノードタイプを使用してキャッシュクラスターをスケールするか、さらにキャッシュノードを追加してスケールアウトします。
EngineCPUUtilization
4 個以上の vCPU を持つ大きなノードタイプでは、Redis OSS エンジンコアでの使用量のパーセント値をレポートする EngineCPUUtilization
メトリクスを使用することをお勧めします。ノードでこのメトリクスが利用できるかどうか、およびその詳細については、「Valkey と Redis OSS のメトリクス」を参照してください。
詳細については、CPUs」セクションを参照してください。 Amazon ElastiCache Amazon CloudWatch
SwapUsage (Valkey および Redis OSS)
バイト単位でレポートされるホストレベルのメトリクスです。詳細については、「ホストレベルのメトリクス」を参照してください。
FreeableMemory
CloudWatch メトリクスが 0 に近い (つまり 100 MB 未満) または SwapUsage
メトリクスが FreeableMemory
メトリクスより大きい場合、ノードがメモリプレッシャーを受けていることを示します。このような場合は、以下のトピックを参照してください。
Evictions
これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。
Memcached を使用していて、選択したしきい値を超えた場合は、より大きいノードタイプを使用してクラスターをスケールするか、さらにノードを追加してスケールアウトします。
CurrConnections
これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。
CurrConnections の値が大きくなった場合、アプリケーションに問題があることを示している可能性があります。アプリケーション動作を調査してこの問題を解決する必要があります。
詳細については、「Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS でのベストプラクティスのモニタリング」の「接続」セクションを参照してください。 Amazon ElastiCache Amazon CloudWatch
メモリ (Valkey および Redis OSS)
メモリは Valkey および Redis OSS の中核的な側面です。クラスターのメモリ使用率を理解することは、データの損失を回避し、データセットの将来の増加に対応するために必要です。ノードのメモリ使用率に関する統計は、INFO
詳細については、「Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS でのベストプラクティスのモニタリング」の「メモリ」セクションを参照してください。 Amazon ElastiCache Amazon CloudWatch
ネットワーク
クラスターのネットワーク帯域幅容量の決定要因の 1 つは、選択したノードの種類です。ノードのネットワーク容量の詳細については、「Amazon ElastiCache 料金表
詳細については、「Amazon Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS のモニタリングのベストプラクティス
レイテンシー
ElastiCache for Valkey インスタンスの応答時間の測定は、必要な詳細度のレベルに応じてさまざまな方法でアプローチできます。ElastiCache for Valkey のサーバー側の全体的な応答時間に影響する主要なステージは、コマンドの前処理、コマンドの実行、およびコマンドの後処理です。
GetTypeCmdsLatency や SetTypeCmdsLatency メトリクスなどの Valkey INFO
レイテンシーメトリクスSuccessfulWriteRequestLatency
と は、ElastiCache for Valkey エンジンがリクエストに応答するのにかかる合計時間SuccessfulReadRequestLatency
を測定します。
注記
Valkey クライアントで CLIENT REPLY を有効にして Valkey パイプラインを使用すると、 SuccessfulWriteRequestLatency
および SuccessfulReadRequestLatency
メトリクスの値が拡張される可能性があります。Valkey Pipelining は、個々のコマンドへの応答を待たずに、複数のコマンドを一度に発行することでパフォーマンスを向上させる手法です。値が拡張されないようにするには、Client REPLY OFF
詳細については、「Amazon CloudWatch を使用した Amazon ElastiCache のモニタリングのベストプラクティス
レプリケーション
レプリケーションされるデータの量は、ReplicationBytes
メトリクスを介して見ることができます。このメトリクスは、レプリケーショングループに対する書き込み負荷を表しますが、レプリケーションの状態に関するインサイトは提供されません。この目的のために、ReplicationLag
メトリクスを使用できます。
詳細については、「Amazon Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS でのベストプラクティスのモニタリング
トラフィック管理 (Valkey および Redis OSS)
ElastiCache for Redis OSS は、Valkey または Redis OSS で処理できる数よりも多くの受信コマンドがノードに送信されると、ノードに対するトラフィックを自動的に管理します。これにより、エンジンの最適な動作と安定性を維持します。
ノードでトラフィックがアクティブに管理されている場合、メトリクス TrafficManagementActive
は 1 のデータポイントを出力します。これは、提供されているワークロードに対してノードが過小評価されている可能性を示します。このメトリクスが長期にわたって 1 を示している場合は、クラスターを評価してスケールアップまたはスケールアウトする必要があるかどうかを判断します。
詳細については、「メトリクス」ページの TrafficManagementActive
メトリクスを参照してください。