翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
モニタリングすべきメトリクス
以下の CloudWatch メトリクスは、 ElastiCache パフォーマンスに関する優れたインサイトを提供します。ほとんどの場合、パフォーマンスの問題が発生する前に是正措置を講じることができるように、これらのメトリクスの CloudWatch アラームを設定することをお勧めします。
モニタリングするメトリクス
CPUUtilization
パーセント値でレポートされるホストレベルのメトリクスです。詳細については、「ホストレベルのメトリクス」を参照してください。
Valkey と 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 個以上の大きなノードタイプでは、Valkey または Redis OSS エンジンコアの使用率をレポートするEngineCPUUtilizationメトリクスを使用できます。このメトリクスがノードで使用可能かどうかを確認し、詳細については、「Redis のメトリクスOSS」を参照してください。
Memcached
Memcached はマルチスレッドのため、このメトリクスは約 90% です。このしきい値を超えた場合は、より大きなキャッシュノードタイプを使用してキャッシュクラスターをスケールアップするか、キャッシュノードをさらに追加してスケールアウトします。
EngineCPUUtilization
4 vCPUs つ以上のより大きなノードタイプでは、Redis OSS エンジンコアの使用率をレポートするEngineCPUUtilizationメトリクスを使用できます。このメトリクスがノードで使用可能かどうかを確認し、詳細については、「Valkey と Redis のメトリクスOSS」を参照してください。
詳細については、「Amazon を使用した Amazon ElastiCache (Redis OSS) でのベストプラクティスのモニタリング CloudWatch
SwapUsage （バルキーと Redis OSS）
バイト単位でレポートされるホストレベルのメトリクスです。詳細については、「ホストレベルのメトリクス」を参照してください。
FreeableMemory CloudWatch メトリクスが 0 に近い (1100MB) か、SwapUsageメトリクスがFreeableMemoryメトリクスより大きい場合は、ノードがメモリ圧力を受けていることを示します。このような場合は、以下のトピックを参照してください。
Evictions
これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。
Memcached を使用していて、選択したしきい値を超える場合は、より大きなノードタイプを使用してクラスターをスケールアップするか、ノードを追加してスケールアウトします。
CurrConnections
これは、キャッシュエンジンのメトリクスです。アプリケーションニーズに基づいてこのメトリクスの独自のアラームしきい値を決定することをお勧めします。
の数が増えると、アプリケーションに問題があるCurrConnections可能性があります。この問題に対処するには、アプリケーションの動作を調べる必要があります。
詳細については、「Amazon を使用した Amazon (Redis ) でのベストプラクティスのモニタリング」の「Connections」セクションを参照してください。 ElastiCache OSS CloudWatch
メモリ (Valkey と Redis OSS）
メモリは Valkey と Redis の中核的な側面ですOSS。クラスターのメモリ使用率を理解することは、データの損失を回避し、データセットの将来の増加に対応するために必要です。ノードのメモリ使用率に関する統計は、 INFO
詳細については、「Amazon を使用した Amazon (Redis ) でのベストプラクティスのモニタリング」の「メモリ」セクションを参照してください。 ElastiCache OSS CloudWatch
ネットワーク
クラスターのネットワーク帯域幅容量の決定要因の 1 つは、選択したノードの種類です。ノードのネットワーク容量の詳細については、「Amazon の ElastiCache 料金
詳細については、「Amazon を使用した Amazon ElastiCache (Redis OSS) でのベストプラクティスのモニタリング CloudWatch
レイテンシー
コマンドのレイテンシーは、データ構造ごとに集約されたレイテンシーを提供する一連の CloudWatch メトリクスを使用して測定できます。これらのレイテンシーメトリクスは、Valkey INFOcommandstats統計を使用して計算されます。
詳細については、「Amazon を使用した Amazon ElastiCache でのベストプラクティスのモニタリング CloudWatch
レプリケーション
レプリケーションされるデータの量は、ReplicationBytes メトリクスを介して見ることができます。このメトリクスは、レプリケーショングループに対する書き込み負荷を表しますが、レプリケーションの状態に関するインサイトは提供されません。この目的のために、ReplicationLag メトリクスを使用できます。
詳細については、「Amazon を使用した Amazon ElastiCache (Redis OSS) でのベストプラクティスのモニタリング CloudWatch
トラフィック管理 (バルキーと Redis OSS）
ElastiCache (Redis OSS) は、Valkey または Redis で処理できる数よりも多くの受信コマンドがノードに送信されると、ノードに対するトラフィックを自動的に管理しますOSS。これにより、エンジンの最適な動作と安定性を維持します。
ノードでトラフィックがアクティブに管理されている場合、メトリクス TrafficManagementActive は 1 のデータポイントを出力します。これは、提供されているワークロードに対してノードが過小評価されている可能性を示します。このメトリクスが長期にわたって 1 を示している場合は、クラスターを評価してスケールアップまたはスケールアウトする必要があるかどうかを判断します。
詳細については、「メトリクス」ページの TrafficManagementActive メトリクスを参照してください。
