診断レポートは、パフォーマンスメトリクス、リクエストのディストリビューション、スロークエリデータを分析することで、ApsaraDB for Redis インスタンスの健全性を評価します。これを使用して、ビジネスに影響が及ぶ前に異常を特定し、対処してください。
前提条件
作業を開始する前に、以下の条件を満たしていることを確認してください。
インスタンスで診断を実行します。詳細については、「インスタンスで診断を実行する」をご参照ください。
レポートの構成
診断レポートは、以下の 4 つのセクションで構成されています。
基本的なインスタンス情報：インスタンス ID、インスタンスタイプ、エンジンバージョン、インスタンスがデプロイされているゾーン
サマリー：インスタンスの健全性スコアおよび減点項目の内訳
パフォーマンスレベル：主要なパフォーマンスメトリックの現在の状態
スロークエリ数が最も多い上位 10 ノード：スロークエリ数に基づく上位 10 のデータノードと、それらのクエリに関する詳細情報
基本的なインスタンス情報
このセクションには、インスタンス ID、インスタンスタイプ、エンジンバージョン、インスタンスがデプロイされているリージョンが表示されます。
サマリー
このセクションには、インスタンスの全体的な健全性スコアが表示されます。最大スコアは 100 です。100 を下回るスコアの場合、減点の原因となった診断項目とその理由が記載されます。
パフォーマンスレベル
このセクションには、主要なパフォーマンスメトリックの現在の状態が表示されます。ハザード 状態のメトリックには特に注意してください。しきい値を超える状態が続くと、スループットが低下し、レイテンシが増加する可能性があります。
クラスタアーキテクチャまたは読み書き分離アーキテクチャで動作しているインスタンスの場合、データノード間でメトリックが均等に分散されているかを確認してください。各メトリックの 上位 5 ノード のカーブチャートを確認し、最も負荷が高いノードを特定します。アーキテクチャの詳細については、「クラスタマスターレプリカインスタンス」および「読み書き分離インスタンス」をご参照ください。
次の表では、各パフォーマンスメトリック、そのしきい値、しきい値超過時のビジネスへの影響、およびトラブルシューティング方法について説明します。
| メトリック | しきい値 | 適用対象 | 影響 | 考えられる原因と次のステップ |
|---|---|---|---|---|
| CPU 使用率 | 60% | すべてのアーキテクチャ | CPU 使用率が高くなると、スループットが低下し、応答時間が長くなります。クライアントが応答しなくなる可能性があります。 | 原因：複雑度の高いコマンド、ホットキー、または接続の頻繁な生成。詳細については、「インスタンスの CPU 使用率が高くなる問題のトラブルシューティング」をご参照ください。 |
| メモリ使用量 | 80% | すべてのアーキテクチャ | メモリ使用量が継続的に高くなると、応答時間が長くなり、秒間クエリ数 (QPS) が不安定になり、キーエビクションが頻繁にトリガーされます。 | 原因：メモリ枯渇または多数のラージキー。詳細については、「インスタンスのメモリ使用量が高くなる問題のトラブルシューティング」をご参照ください。 |
| データノードの接続数使用量 | 80% | 直接接続モードでのクラスタインスタンスのみ。プロキシノード経由でクライアントが接続している場合は、代わりにプロキシノードレベルで接続数をモニターしてください。「直接接続モードを有効化する」および「パフォーマンスモニタリングデータを表示する」をご参照ください。 | 接続数が上限に達すると、新しい接続リクエストがタイムアウトまたは失敗します。 | 原因：トラフィックスパイクまたは解放されていないアイドル接続。詳細については、「インスタンスセッション」をご参照ください。 |
| インバウンドトラフィック | 80% | すべてのアーキテクチャ | トラフィックがインスタンスタイプによって提供される帯域幅を超えると、クライアントのパフォーマンスが低下します。 | 原因：ワークロードの急増またはラージキーの頻繁な読み取り/書き込み。詳細については、「インスタンスのトラフィック使用量が高くなる問題のトラブルシューティング」をご参照ください。 |
| アウトバウンドトラフィック | 80% | すべてのアーキテクチャ | インバウンドトラフィックと同じ影響があります。 | インバウンドトラフィックと同じ原因およびトラブルシューティング手順が適用されます。 |
リクエストディストリビューションの偏り
クラスタアーキテクチャ または 読み書き分離アーキテクチャ で動作しているインスタンスの場合、レポートではデータノード間でリクエストが均等に分散されているかもチェックされます。特定のメトリックでリクエストの偏りが検出された場合は、どのノードに不均等な負荷がかかっているかを特定してください。
レポートは、以下の両方の条件を満たす場合に、リクエストの偏りをフラグ付けします。
すべてのデータノードにおけるピーク値が、以下の最小しきい値を超えていること。
CPU 使用率：10%
メモリ使用量：20%
インバウンドおよびアウトバウンドトラフィック：5 Mbit/s
接続使用量: 5%
バランススコアが 1.3 を超えていること。バランススコアは次のように計算されます：
max{すべてのデータノードの平均パフォーマンス値} / すべてのデータノードのパフォーマンス値の中央値。たとえば、あるインスタンスに CPU 使用率の平均がそれぞれ 10%、30%、50%、60% の 4 つのデータノードがある場合、中央値は 40% となり、バランススコアは 60% / 40% = 1.5 です。1.5 > 1.3 であるため、このレポートでは CPU 使用率に偏りがあると判断されます。
| 考えられる原因 | トラブルシューティング方法 |
|---|---|
| データノードに過剰なラージキーが存在している。 | オフラインキーアナリシス機能 または トップキースtatistics 機能 を使用して、該当キーを特定し、再分散してください。 |
| データノードにホットキーが存在している。 | トップキースtatistics 機能 を使用して、ホットキーを特定してください。 |
| ハッシュタグの構成が不適切である。同じハッシュタグを持つキーは常に同じデータノードに配置されます。多くのキーが同じハッシュタグを共有している場合、そのノードが過負荷になります。 | キーをノード間で均等に分散できるよう、ハッシュタグの構成を見直して調整してください。 |
スロークエリ数が最も多い上位 10 ノード
このセクションには、スロークエリ数に基づく上位 10 のデータノードと、それらのクエリに関する詳細情報が表示されます。レポートは、以下の 2 つのソースからスローログデータを取得しています。
システム監査ログ：4 日間保持されるスローログ
データノードログ：各データノードに直接保存される最新の 1,024 件のログエントリ。redis-cli を使用してインスタンスに接続し、
SLOWLOG GETコマンドを実行することで取得できます。
スロークエリデータを使用して、パフォーマンスの問題を引き起こしているコマンドを特定してください。
| 原因 | 解決策 |
|---|---|
O(N) の時間計算量または CPU コストが高いコマンド（例：KEYS * | FLUSHALL、KEYS、HGETALL などの高リスクコマンドを評価し、無効化してください。「高リスクコマンドを無効化する」をご参照ください。 |
| ラージキーがデータノードから頻繁に読み取られたり、書き込まれたりしている。 | オフラインキーアナリシス機能 を使用してラージキーを分析し、ビジネス要件に基づいて分割してください。 |