インスタンス診断の実行方法と、パフォーマンスメトリクス、リクエスト分散の偏り、スロークエリなどの診断レポートの解釈方法について説明します。
インスタンスの診断の実行
Tair (Redis OSS-compatible) は、Database Autonomy Service (DAS) の診断レポート機能を統合しています。この機能を使用すると、診断レポートを作成して、指定した期間内のインスタンスの状態を評価できます。診断レポートは、パフォーマンスレベル、リクエスト分散の偏り、スロークエリログなどのメトリックを収集し、インスタンスの例外を特定するのに役立ちます。
操作手順
コンソールにログインし、[インスタンス] ページに移動します。上部のナビゲーションバーで、管理するインスタンスが存在するリージョンを選択します。次に、対象のインスタンスを見つけて、インスタンス ID をクリックします。
- 左側のナビゲーションウィンドウで、 を選択します。
- [レポートの作成] をクリックします。
- 表示されたダイアログボックスで、診断レポートを作成する時間範囲を指定し、[OK] をクリックします。説明 時間範囲は 1 日を超えることはできません。診断の時間範囲を短くすると、より詳細な統計が診断レポートに収集されます。
- [診断レポート] ページを更新して、診断タスクの進行状況を確認します。診断レポートが作成されたら、[操作] 列の [レポートの表示] をクリックします。説明 診断レポートの解釈方法の詳細については、「インスタンス診断レポートの理解」をご参照ください。
インスタンス診断レポートの理解
診断レポートは、パフォーマンスメトリクス、リクエスト分散、スロークエリデータを分析することで、ApsaraDB for Redis インスタンスのヘルス状態を評価します。これを使用して異常を特定し、ビジネスに影響が及ぶ前に対処します。
レポートのセクション
診断レポートには 4 つのセクションがあります:
-
インスタンスの基本情報:インスタンス ID、インスタンスタイプ、エンジンバージョン、インスタンスがデプロイされているゾーン
-
概要:インスタンスのヘルススコアと減点の詳細
-
パフォーマンスレベル:主要なパフォーマンスメトリクスの現在の状態
-
スロークエリが最も多い上位 10 ノード:スロークエリ数で上位 10 のデータノードと、それらのクエリに関する詳細
インスタンスの基本情報
インスタンス ID、インスタンスタイプ、エンジンバージョン、インスタンスがデプロイされているリージョンを表示します。
診断期間は 2021 年 3 月 1 日 11:10:23 から 2021 年 3 月 1 日 14:10:23 までです。インスタンスの基本情報には、次のフィールドが含まれます:
-
インスタンス ID:インスタンス ID とインスタンス名 (例のサフィックス:「-Diagnostic Report Test」)
-
仕様:2 GB Cluster Edition (2 ノード)
-
インスタンスタイプ:Redis 5.0
-
ゾーン:中国 (杭州)
概要
インスタンスの全体的なヘルススコアを表示します。最大スコアは 100 です。100 未満のスコアの場合は、減点の原因となった診断項目とその理由が一覧表示されます。
ヘルススコアは 100 点中 70 点です。次の項目が減点の原因となりました:
-
高い CPU 使用率:CPU 使用率が 85.9% に達し、安全なしきい値を超えました。10 点減点。
-
高いメモリ使用量:メモリ使用量が 100.0% に達し、安全なしきい値を超えました。10 点減点。
-
スローログアクセス:サーバーに記録された上位 12 件のスローログエントリ。10 点減点。
パフォーマンスレベル
主要なパフォーマンスメトリクスの現在の状態を表示します。危険状態にあるメトリックには特に注意してください。しきい値を超える状態が続くと、スループットが低下し、レイテンシーが増加する可能性があります。
クラスタアーキテクチャまたは読み書き分離アーキテクチャで実行されているインスタンスの場合、メトリックがデータノード間で不均等に分散されていないか確認してください。各メトリックの [上位 5 ノード] 曲線グラフを確認して、どのノードの負荷が最も高いかを特定します。アーキテクチャの詳細については、「クラスタマスターレプリカインスタンス」および「読み書き分離インスタンス」をご参照ください。
次の表に、各メトリック、そのしきい値、しきい値を超えた場合のビジネスへの影響、およびトラブルシューティング方法を示します。
| メトリック | しきい値 | 適用対象 | 影響 | 考えられる原因と次のステップ |
|---|---|---|---|---|
| CPU 使用率 | 60% | すべてのアーキテクチャ | 高い CPU 使用率はスループットを低下させ、応答時間を増加させます。クライアントが無応答になる可能性があります。 | 原因:複雑度の高いコマンド、ホットキー、または頻繁な接続作成。 詳細については、「インスタンスの CPU 使用率が高い場合のトラブルシューティング」をご参照ください。 |
| メモリ使用量 | 80% | すべてのアーキテクチャ | 持続的にメモリ使用量が高い場合、応答時間が増加し、秒間クエリ数 (QPS) が不安定になり、頻繁なキーのエビクションがトリガーされます。 | 原因:メモリ枯渇、または多数の大きなキーの存在。 詳細については、「インスタンスのメモリ使用量が高い場合のトラブルシューティング」をご参照ください。 |
| 接続使用量 (データノード) | 80% | 直接接続モードのクラスターインスタンスにのみ適用されます。クライアントがプロキシノード経由で接続する場合、代わりにプロキシノードレベルで接続をモニターします。 詳細については、「直接接続モードを有効にする」および「パフォーマンスモニタリングデータを表示する」をご参照ください。 | 接続数が上限に達すると、新しい接続リクエストはタイムアウトまたは失敗します。 | 原因:トラフィックスパイク、または解放されていないアイドル接続。 詳細については、「インスタンスセッション」をご参照ください。 |
| 受信トラフィック | 80% | すべてのアーキテクチャ | トラフィックがインスタンスタイプで提供される帯域幅を超えると、クライアントのパフォーマンスが低下します。 | 原因:ワークロードのスパイク、または大きなキーの頻繁な読み書き。 詳細については、「インスタンスのトラフィック使用量が高い場合のトラブルシューティング」をご参照ください。 |
| 送信トラフィック | 80% | すべてのアーキテクチャ |
リクエスト分散の偏り
クラスタアーキテクチャまたは読み書き分離アーキテクチャで実行されているインスタンスの場合、レポートはリクエストがデータノード間で均等に分散されているかどうかもチェックします。メトリックでリクエストの偏りが検出された場合は、どのノードが不均等な負荷を受け取っているかを特定します。
レポートは、次の両方の条件が満たされた場合にリクエストの偏りにフラグを立てます:
-
すべてのデータノードのピーク値が、以下の最小しきい値を超えている:
-
CPU 使用率:10%
-
メモリ使用量:20%
-
インバウンドおよびアウトバウンドトラフィック:5 Mbit/s
-
接続使用率:5%
-
-
バランススコアが 1.3 を超えている。バランススコアは、
max{すべてのデータノードの平均パフォーマンス値} / すべてのデータノードのパフォーマンス値の中央値として計算されます。たとえば、インスタンスに 4 つのデータノードがあり、平均 CPU 使用率が 10%、30%、50%、60% の場合、中央値は 40% で、バランススコアは 60% / 40% = 1.5 となります。1.5 > 1.3 であるため、レポートは CPU 使用率に偏りがあると見なします。
| 考えられる原因 | トラブルシューティング方法 |
|---|---|
| データノードに過剰なラージキーがある。 | オフラインキー分析機能または上位キー統計機能を使用して、それらを特定し、再分散します。 |
| データノードにホットキーがある。 | 上位キー統計機能を使用してホットキーを特定します。 |
| ハッシュタグが不適切に構成されている。同じハッシュタグを持つキーは常に同じデータノードに配置されます。多くのキーがハッシュタグを共有している場合、そのノードは過負荷になります。 | ハッシュタグの構成を見直し、キーがノード間に分散されるように調整します。 |
スロークエリが最も多い上位 10 ノード
スロークエリ数で上位 10 のデータノードを一覧表示し、それらのクエリに関する詳細を提供します。レポートは、2 つのソースのスローログデータから取得します:
-
システム監査ログ:4 日間保持されるスローログ
-
データノードログ:各データノードに直接保存される最新の 1,024 ログエントリ。redis-cli を使用してインスタンスに接続し、
SLOWLOG GETコマンドを実行して取得します。
r-bp***-db-0 と r-bp***-db-1 の 2 つのノードには、それぞれ 6 つのスロークエリがあります。主なスロークエリコマンドとその実行時間は次のとおりです:
-
keys *:最大実行時間約 86 ms、平均約 86 ms -
keys key:0000001*:最大実行時間約 62 ms、平均約 59 ms -
複数の
delコマンド:実行時間約 12~18 ms
スロークエリデータを使用して、パフォーマンスの問題を引き起こしているコマンドを特定します。
| 原因 | ソリューション |
|---|---|
O(N) の時間計算量または高い CPU コストを伴う、KEYS * |
FLUSHALL、KEYS、HGETALL などの高リスクコマンドを評価し、無効にします。詳細については、「高リスクコマンドの無効化」をご参照ください。 |
| ラージキーがデータノードから頻繁に読み書きされている | オフラインキー分析機能を使用してラージキーを分析し、ビジネス要件に基づいて分割します。 |