モニタリングすべきメトリクス - Amazon ElastiCache

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

モニタリングすべきメトリクス

以下の CloudWatch メトリクスは、 ElastiCache パフォーマンスに関する優れたインサイトを提供します。ほとんどの場合、パフォーマンスの問題が発生する前に修正措置を講じることができるように、これらのメトリクスの CloudWatch アラームを設定することをお勧めします。

CPUUtilization

パーセント値でレポートされるホストレベルのメトリクスです。詳細については、「ホストレベルのメトリクス」を参照してください。

バルキーと Redis OSS

2 vCPUs 以下の小さいノードタイプでは、 CPUUtilization メトリクスを使用してワークロードをモニタリングします。

一般的に、しきい値は使用可能な の 90% に設定することをお勧めしますCPU。Valkey と Redis OSSはどちらもシングルスレッドであるため、実際のしきい値はノードの合計容量に対する割合として計算する必要があります。例えば、2 個のコアを搭載するノードタイプを使用しているとします。この場合、 のしきい値は 90/2、つまり 45% CPUUtilizationになります。

使用しているキャッシュノードのコア数に基づいて独自のしきい値を決定する必要があります。このしきい値を超えた場合で、主なワークロードが読み込みリクエストから生成されている場合、リードレプリカを追加してキャッシュクラスターをスケールします。主なワークロードが書き込みリクエストからのものである場合、クラスター設定に応じて、以下のことをお勧めします。

  • Valkey または Redis OSS (クラスターモードが無効) クラスター: より大きなキャッシュインスタンスタイプを使用してスケールアップします。

  • Valkey または Redis OSS (クラスターモードが有効) クラスター: シャードを追加して、書き込みワークロードをより多くのプライマリノードに分散します。

ヒント

ホストレベルのメトリクス を使用する代わりにCPUUtilization、Valkey および Redis OSSユーザーはメトリクス を使用できる場合があります。メトリクス はEngineCPUUtilization、Valkey または Redis OSS エンジンコアの使用率をレポートします。このメトリクスがノードで使用できるかどうかを確認するには、「Valkey と Redis のメトリクスOSS」を参照してください。

ノードタイプが 4 vCPUs 個以上の場合は、 EngineCPUUtilizationメトリクスを使用して、Valkey または Redis OSS エンジンコアの使用率をレポートできます。コードでこのメトリクスが利用できるかどうか、およびその詳細については、「Redis のメトリクスOSS」を参照してください。

Memcached

Memcached はマルチスレッドのため、このメトリクスは約 90% です。このしきい値を超えた場合、より大きいキャッシュノードタイプを使用してキャッシュクラスターをスケールするか、さらにキャッシュノードを追加してスケールアウトします。

EngineCPUUtilization

ノードタイプが 4 vCPUs 個以上の場合は、 EngineCPUUtilizationメトリクスを使用して、Redis OSS エンジンコアの使用率をレポートできます。このメトリクスがノードで使用できるかどうかを確認するには、「Valkey と Redis のメトリクスOSS」を参照してください。

詳細については、「Amazon OSSを使用した Amazon ElastiCache for Redis でのベストプラクティスのモニタリング CloudWatchCPUs」のセクションを参照してください。

SwapUsage (バルキーと Redis OSS)

バイト単位でレポートされるホストレベルのメトリクスです。詳細については、「ホストレベルのメトリクス」を参照してください。

FreeableMemory CloudWatch メトリクスが 0 に近い (つまり、100MB 未満) か、SwapUsageメトリクスが FreeableMemory メトリクスより大きい場合は、ノードがメモリ負荷を受けていることを示します。このような場合は、以下のトピックを参照してください。

Evictions

これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。

Memcached を使用していて、選択したしきい値を超えた場合は、より大きいノードタイプを使用してクラスターをスケールするか、さらにノードを追加してスケールアウトします。

CurrConnections

これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。

の数が増えると、アプリケーションに問題があるCurrConnections可能性があります。この問題に対処するには、アプリケーションの動作を調査する必要があります。

詳細については、「Amazon を使用した Amazon for Redis でのベストプラクティスのモニタリング」の「接続」セクションを参照してください。 ElastiCache OSS CloudWatch

メモリ (Valkey および Redis OSS)

メモリは、Valkey と Redis の中核的な側面ですOSS。クラスターのメモリ使用率を理解することは、データの損失を回避し、データセットの将来の増加に対応するために必要です。ノードのメモリ使用率に関する統計は、 INFO コマンドのメモリセクションで確認できます。

詳細については、「Amazon を使用した Amazon for Redis でのベストプラクティスのモニタリング」の「メモリ」セクションを参照してください。 ElastiCache OSS CloudWatch

ネットワーク

クラスターのネットワーク帯域幅容量の決定要因の 1 つは、選択したノードの種類です。ノードのネットワーク容量の詳細については、「Amazon の ElastiCache 料金」を参照してください。

詳細については、「Amazon OSSを使用した Amazon ElastiCache for Redis でのベストプラクティスのモニタリング CloudWatch」の「ネットワーク」セクションを参照してください。

レイテンシー

ElastiCache for Valkey インスタンスの応答時間の測定は、必要な粒度のレベルに応じてさまざまな方法でアプローチできます。Valkey ElastiCache の のサーバー側の全体的な応答時間に影響する主要なステージは、コマンドの前処理、コマンドの実行、およびコマンドの後処理です。

GetTypeCmdsLatency や などの Valkey INFO コマンドから派生したコマンド固有のレイテンシー SetTypeCmdsLatency メトリクスは、特に Valkey コマンドのコアコマンドロジックの実行に焦点を当てています。これらのメトリクスは、ユースケースが、データ構造ごとのコマンド実行時間または集約レイテンシーを決定する場合に役立ちます。

レイテンシーメトリクスSuccessfulWriteRequestLatencyと は、 ElastiCache for Valkey エンジンがリクエストに応答するのにかかる合計時間SuccessfulReadRequestLatencyを測定します。

注記

Valkey クライアントで CLIENTREPLYを有効にして Valkey Pipelining を使用すると、 SuccessfulWriteRequestLatencyおよび SuccessfulReadRequestLatencyメトリクスの値が拡張される可能性があります。バルキーパイプライン化は、個々のコマンドへの応答を待たずに、複数のコマンドを一度に発行することでパフォーマンスを向上させる手法です。値が増えないようにするには、 でコマンドをパイプラインするように Valkey CLIENT REPLY OFFクライアントを設定することをお勧めします。

詳細については、「Amazon を使用した Amazon ElastiCache でのベストプラクティスのモニタリング CloudWatch」の「レイテンシー」セクションを参照してください。

レプリケーション

レプリケーションされるデータの量は、ReplicationBytes メトリクスを介して見ることができます。このメトリクスは、レプリケーショングループに対する書き込み負荷を表しますが、レプリケーションの状態に関するインサイトは提供されません。この目的のために、ReplicationLag メトリクスを使用できます。

詳細については、「Amazon OSSを使用した Amazon ElastiCache for Redis でのベストプラクティスのモニタリング CloudWatch」の「レプリケーション」セクションを参照してください。

トラフィック管理 (Valkey および Redis OSS)

ElastiCache for Redis は、Valkey または Redis で処理できる数よりも多くの受信コマンドがノードに送信されると、ノードに対するトラフィックOSSを自動的に管理しますOSS。これにより、エンジンの最適な動作と安定性を維持します。

ノードでトラフィックがアクティブに管理されている場合、メトリクス TrafficManagementActive は 1 のデータポイントを出力します。これは、提供されているワークロードに対してノードが過小評価されている可能性を示します。このメトリクスが長期にわたって 1 を示している場合は、クラスターを評価してスケールアップまたはスケールアウトする必要があるかどうかを判断します。

詳細については、「メトリクス」ページの TrafficManagementActive メトリクスを参照してください。