翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # モニタリングすべきメトリクス 次の CloudWatch メトリクスは、ElastiCache パフォーマンスを把握するのに役立ちます。ほとんどの場合、パフォーマンスの問題が発生する前に修正作業を行うことができるように、これらのメトリクスに CloudWatch アラームを設定することをお勧めします。 **Topics** + [ ## CPUUtilization ](#metrics-cpu-utilization) + [ ## EngineCPUUtilization ](#metrics-engine-cpu-utilization) + [ ## SwapUsage (Valkey および Redis OSS) ](#metrics-swap-usage) + [ ## Evictions ](#metrics-evictions) + [ ## CurrConnections ](#metrics-curr-connections) + [ ## メモリ (Valkey および Redis OSS) ](#metrics-memory) + [ ## Network ](#metrics-network) + [ ## レイテンシー ](#metrics-latency) + [ ## レプリケーション ](#metrics-replication) + [ ## トラフィック管理 (Valkey および Redis OSS) ](#traffic-management) ## CPUUtilization パーセント値でレポートされるホストレベルのメトリクスです。詳細については、「[ホストレベルのメトリクス](CacheMetrics.HostLevel.md)」を参照してください。 **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 のメトリクス](CacheMetrics.Redis.md)」を参照してください。 4 個以上の vCPU を持つ大きなノードタイプでは、Valkey または Redis OSS エンジンコアでの使用量のパーセント値をレポートする `EngineCPUUtilization` メトリクスを使用することをお勧めします。ノードでこのメトリクスが利用できるかどうか、およびその詳細については、「[Metrics for Redis OSS](CacheMetrics.Redis.md)」を参照してください。 **Memcached** Memcached はマルチスレッドのため、このメトリクスは約 90% です。このしきい値を超えた場合、より大きいキャッシュノードタイプを使用してクラスターをスケールするか、さらにキャッシュノードを追加してスケールアウトします。 ## EngineCPUUtilization 4 個以上の vCPU を持つ大きなノードタイプでは、Redis OSS エンジンコアでの使用量のパーセント値をレポートする `EngineCPUUtilization` メトリクスを使用することをお勧めします。ノードでこのメトリクスが利用できるかどうか、およびその詳細については、「[Valkey と Redis OSS のメトリクス](CacheMetrics.Redis.md)」を参照してください。 詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**CPU**」セクションを参照してください。 ## SwapUsage (Valkey および Redis OSS) バイト単位でレポートされるホストレベルのメトリクスです。詳細については、「[ホストレベルのメトリクス](CacheMetrics.HostLevel.md)」を参照してください。 `FreeableMemory` CloudWatch メトリクスが 0 に近い (つまり 100 MB 未満) または `SwapUsage` メトリクスが `FreeableMemory` メトリクスより大きい場合、ノードがメモリプレッシャーを受けていることを示します。このような場合は、以下のトピックを参照してください。 + [Valkey または Redis OSS スナップショットを作成するのに十分なメモリがあることを確認する](BestPractices.BGSAVE.md) + [Valkey および Redis OSS の予約済みメモリを管理する](redis-memory-management.md) ## Evictions これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。 Memcached を使用していて、選択したしきい値を超えた場合は、より大きいノードタイプを使用してクラスターをスケールするか、さらにノードを追加してスケールアウトします。 ## CurrConnections これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。 *CurrConnections* の値が大きくなった場合、アプリケーションに問題があることを示している可能性があります。アプリケーション動作を調査してこの問題を解決する必要があります。 詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**接続**」セクションを参照してください。 ## メモリ (Valkey および Redis OSS) メモリは Valkey および Redis OSS の中核的な側面です。クラスターのメモリ使用率を理解することは、データの損失を回避し、データセットの将来の増加に対応するために必要です。ノードのメモリ使用率に関する統計は、[INFO](https://valkey.io/commands/info) コマンドのメモリセクションで確認できます。 詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**メモリ**」セクションを参照してください。 ## Network クラスターのネットワーク帯域幅容量の決定要因の 1 つは、選択したノードの種類です。ノードのネットワーク容量の詳細については、「[Amazon ElastiCache 料金表](https://aws.amazon.com/elasticache/pricing/)」を参照してください。 詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**ネットワーク**」セクションを参照してください。 ## レイテンシー ElastiCache for Valkey インスタンスの応答時間を測定するには、必要な粒度レベルに応じてさまざまな方法があります。ElastiCache for Valkey のサーバー側の応答時間全体に影響する主なステージは、コマンドの前処理、コマンドの実行、およびコマンドの後処理です。 GetTypeCmdsLatency や SetTypeCmdsLatency メトリクスなど、Valkey [INFO](https://valkey.io/commands/info) コマンドから派生したコマンド固有のレイテンシーメトリクスは、Valkey コマンドのコアコマンドロジックの実行に特に重点を置いています。これらのメトリクスは、コマンドの実行時間やデータ構造ごとの合計レイテンシーを決定するユースケースに役立ちます。 レイテンシーメトリクス `SuccessfulWriteRequestLatency` および `SuccessfulReadRequestLatency` は、ElastiCache for Valkey エンジンがリクエストに応答するのにかかる合計時間を測定します。 **注記** Valkey クライアントで CLIENT REPLY を有効にして Valkey パイプラインを使用すると、`SuccessfulWriteRequestLatency` および `SuccessfulReadRequestLatency` メトリクスの値が異常に大きくなる場合があります。Valkey パイプラインは、個々のコマンドへの応答を待たずに複数のコマンドを一度に実行することでパフォーマンスを向上させる手法です。値が異常に大きくなるのを防ぐために、[CLIENT REPLY OFF](https://valkey.io/commands/client-reply/) の状態でコマンドをパイプラインするように Valkey クライアントを設定することをお勧めします。 詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache のモニタリングのベストプラクティス](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**レイテンシー**」セクションを参照してください。 ## レプリケーション レプリケーションされるデータの量は、`ReplicationBytes` メトリクスを介して見ることができます。このメトリクスは、レプリケーショングループに対する書き込み負荷を表しますが、レプリケーションの状態に関するインサイトは提供されません。この目的のために、`ReplicationLag` メトリクスを使用できます。 詳細については、「[Amazon CloudWatch を使用した Amazon ElastiCache for Redis OSS によるベストプラクティスのモニタリング](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)」の「**レプリケーション**」セクションを参照してください。 ## トラフィック管理 (Valkey および Redis OSS) ElastiCache for Redis OSS は、Valkey または Redis OSS が処理できる数よりも多くのコマンドがノードに送信された場合に、ノードに対するトラフィックを自動的に管理します。これにより、エンジンの最適な動作と安定性を維持します。 ノードでトラフィックがアクティブに管理されている場合、メトリクス `TrafficManagementActive` は 1 のデータポイントを出力します。これは、提供されているワークロードに対してノードが過小評価されている可能性を示します。このメトリクスが長期にわたって 1 を示している場合は、クラスターを評価してスケールアップまたはスケールアウトする必要があるかどうかを判断します。 詳細については、「[メトリクス](CacheMetrics.Redis.md)」ページの `TrafficManagementActive` メトリクスを参照してください。