Redis パフォーマンス監視 | レイテンシ、メモリ、スロークエリの最適化

はじめに

この実験では、Redis のパフォーマンス問題を監視およびトラブルシューティングする方法を学びます。この実験では、レイテンシ問題の特定と対処、メモリ使用量の分析、クエリパフォーマンスの最適化に焦点を当てます。

レイテンシの診断には LATENCY DOCTOR コマンド、メモリ使用量の確認には MEMORY STATS、スロークエリの分析には SLOWLOG GET、メモリの最適化には MEMORY PURGE を使用します。ステップバイステップのガイドに従うことで、応答性が高く効率的な Redis デプロイメントを維持するための実践的な経験を積むことができます。

事前設定された環境

信頼性の高いデモンストレーションを確保するため、この実験環境は以下のように事前設定されています。

ユーザーデータを含む 1000 個の文字列キー (user:1 から user:1000)
ユーザープロファイル情報を含む 50 個のハッシュオブジェクト (profile:1 から profile:50)
ログエントリを含む 20 個のリストオブジェクト (logs:app1 から logs:app20)
タグデータを含む 10 個のセットオブジェクト (tags:1 から tags:10)
パフォーマンス監視のために最適化された Redis 設定
即時分析のためのレイテンシおよびスローログデータの事前生成

LATENCY DOCTOR でレイテンシを監視する

このステップでは、Redis の LATENCY DOCTOR コマンドを使用してレイテンシの問題を診断およびトラブルシューティングする方法を探ります。レイテンシの理解と対処は、応答性が高く効率的な Redis デプロイメントを維持するために不可欠です。

レイテンシとは？

レイテンシとは、Redis サーバーにリクエストを送信してから応答を受信するまでの遅延を指します。高いレイテンシはアプリケーションのパフォーマンスに悪影響を与え、応答時間の遅延やユーザーエクスペリエンスの低下につながる可能性があります。

LATENCY DOCTOR の紹介

LATENCY DOCTOR コマンドは、Redis に組み込まれた強力なツールであり、レイテンシの潜在的な原因を特定するのに役立ちます。Redis のさまざまな操作を分析し、遅延の原因となっている可能性のあるものについての洞察を提供します。

ステップバイステップガイド

Redis への接続：

まず、redis-cli コマンドを使用して Redis サーバーに接続します。LabEx VM でターミナルを開き、以下を実行します。
```
redis-cli
```
これにより、Redis コマンドラインインターフェイスが開きます。
現在の設定の確認：

この環境では、レイテンシ監視が有効になるように事前設定されています。現在の設定を確認できます。
```
CONFIG GET latency-monitor-threshold
```
これにより、しきい値が 10 ミリ秒に設定されていることが表示されるはずです。
LATENCY DOCTOR の実行:

次に、LATENCY DOCTOR コマンドを実行してシステムを分析します。
```
LATENCY DOCTOR
```
これは、顕著なレイテンシの問題がない正常な Redis インスタンスであるため、以下のような出力が表示される可能性が高いです。
```
Dave, no latency spike was observed during the lifetime of this Redis instance, not in the slightest bit. I honestly think you ought to sit down calmly, take a stress pill, and think things over.
```
このユーモラスなメッセージ（「2001 年宇宙の旅」の HAL 9000 を参照）は、Redis が設定されたしきい値を超えるレイテンシのスパイクなしに良好に動作していることを示しています。
LATENCY DOCTOR の応答の理解：

LATENCY DOCTOR が「Dave」メッセージを表示する場合、それは次のことを意味します。
- コマンドがレイテンシ監視のしきい値（この場合は 10ms）を超えていません。
- Redis はパフォーマンスのボトルネックなしに効率的に動作しています。
- システムはレイテンシの観点から健全です。
実際のレイテンシの問題がある本番環境では、以下を含む詳細な分析が表示されます。
- 特定のレイテンシのスパイクとその原因
- 最適化のための推奨事項
- 遅い操作の詳細な内訳
スローログの調査（代替分析）:

LATENCY DOCTOR が問題を示さない場合でも、スローログを調べて、他の操作と比較して最も時間がかかっている操作を確認できます。
```
SLOWLOG GET 10
```
実行時間とともに最近のコマンドが表示されます。エントリは以下を示します。
- 一意の ID: 各エントリの連番識別子
- タイムスタンプ： コマンドが実行されたときの Unix タイムスタンプ
- 実行時間： マイクロ秒単位の時間（例：1954 マイクロ秒 = 1.954 ミリ秒）
- コマンド： 実行されたコマンド（Redis の内部操作では「COMMAND」と表示されることが多い）
- クライアント情報： クライアントの IP アドレスとポート
例：
```
1) 1) (integer) 10
   2) (integer) 1753255495
   3) (integer) 1954
   4) 1) "COMMAND"
   5) "127.0.0.1:42212"
   6) ""
```
これは、実行に 1,954 マイクロ秒（約 2 ミリ秒）かかったコマンドを示しています。
redis-cli の終了:

コマンドがログに記録されていることを確認するには、次のように入力して redis-cli を終了します。
```
exit
```

重要性の理解

LATENCY DOCTOR を使用し、スローログを分析することで、Redis デプロイメントのパフォーマンスに関する貴重な洞察を得ることができます。「Dave」メッセージで示されるようにすべてが正常に見える場合でも、定期的な監視は継続的な良好なパフォーマンスを確保し、発生する可能性のある問題を早期に検出するのに役立ちます。

MEMORY STATS でメモリを確認する

このステップでは、Redis の MEMORY STATS コマンドを使用してメモリ使用量を監視および理解する方法を学びます。効率的なメモリ管理は、Redis サーバーの安定性とパフォーマンスにとって非常に重要です。

メモリを監視する理由

Redis はインメモリデータストアであり、すべてのデータを RAM に保存します。Redis のメモリが不足すると、パフォーマンスの低下、データの損失、あるいはクラッシュにつながる可能性があります。メモリ使用量を監視することで、潜在的なメモリ関連の問題を事前に特定し、対処することができます。

MEMORY STATS の紹介

MEMORY STATS コマンドは、Redis のメモリ消費量の詳細な概要を提供します。メモリ使用量をさまざまなカテゴリに分類し、メモリがどこで使用されているかについての洞察を与えます。

ステップバイステップガイド

Redis への接続：

redis-cli コマンドを使用して Redis サーバーに接続します。LabEx VM でターミナルを開き、以下を実行します。
```
redis-cli
```
これにより、Redis コマンドラインインターフェイスが開きます。
MEMORY STATS の実行:

接続したら、MEMORY STATS コマンドを実行します。
```
MEMORY STATS
```
Redis はメモリ統計情報を収集し、結果を表示します。
出力の解釈：

MEMORY STATS の出力はキーと値のペアの辞書であり、各キーはメモリ統計情報を表し、値はその対応する値を示します。サンプル出力を確認し、主要なメトリックの一部を説明しましょう。
```
127.0.0.1:6379> MEMORY STATS
 1) "peak.allocated"
 2) (integer) 1114480
 3) "total.allocated"
 4) (integer) 1114480
 5) "startup.allocated"
 6) (integer) 948480
 7) "replication.buffer"
 8) (integer) 0
 9) "clients.slaves"
10) (integer) 0
11) "clients.normal"
12) (integer) 6456
13) "aof.buffer"
14) (integer) 0
15) "lua.vm"
16) (integer) 0
17) "overhead.total"
18) (integer) 165992
19) "keys.count"
20) (integer) 0
21) "keys.bytes-per-key"
22) (integer) 0
23) "dataset.bytes"
24) (integer) 948488
25) "dataset.percentage"
26) "0.00%"
27) "bytes-per-replica.avg"
28) (integer) 0
29) "bytes-per-replica.min"
30) (integer) 0
31) "bytes-per-replica.max"
32) (integer) 0
33) "allocator.fragratio"
34) "1.00"
35) "allocator.fragbytes"
36) (integer) 0
37) "allocator.rss"
38) (integer) 835584
39) "allocator.peak"
40) (integer) 1114112
41) "total.system"
42) (integer) 4194304
43) "allocator.resident"
44) (integer) 835584
```
主要なメトリックの一部を以下に示します。
- peak.allocated: Redis が起動して以来、割り当てたメモリの最大量。
- total.allocated: 現在 Redis によって割り当てられているメモリの総量。
- dataset.bytes: Redis に保存されているデータの合計サイズ（オーバーヘッドを除く）。
- overhead.total: Redis のオーバーヘッド（例：データ構造、メタデータ）に使用されるメモリの総量。
- keys.count: 現在 Redis に保存されているキーの数。
- allocator.fragratio: メモリ割り当てのフラグメンテーション比率。値が高いほどフラグメンテーションが多いことを示します。
- allocator.rss: オペレーティングシステムによって報告される Redis が使用しているメモリ量（Resident Set Size）。
- total.system: システムで利用可能なメモリの総量。
redis-cli の終了:

コマンドがログに記録されていることを確認するには、次のように入力して redis-cli を終了します。
```
exit
```

情報の活用

MEMORY STATS によって提供される情報は、以下に使用できます。

メモリリークの特定。
メモリ使用量を削減するためのデータ構造の最適化。
メモリ効率を改善するための Redis 設定パラメータの調整。
Redis サーバーで利用可能な RAM の量を増やす必要があるかどうかを判断。

SLOWLOG GET でスロークエリを分析する

このステップでは、Redis の SLOWLOG GET コマンドを使用してスロークエリを分析することについて詳しく説明します。スロークエリの特定と最適化は、応答性が高く効率的な Redis デプロイメントを維持するために不可欠です。最初のステップの LATENCY DOCTOR が示唆するように、スローログの分析はレイテンシの問題をデバッグするための重要なステップです。

スローログとは？

スローログは、指定された実行時間を超えるクエリをログに記録する Redis のシステムです。これにより、予想よりも時間がかかっている、またはパフォーマンスに影響を与えている可能性のあるクエリを特定できます。

ステップバイステップガイド

Redis への接続：

redis-cli コマンドを使用して Redis サーバーに接続します。LabEx VM でターミナルを開き、以下を実行します。
```
redis-cli
```
これにより、Redis コマンドラインインターフェイスが開きます。
スローログ設定の確認：

この環境では、適切なスローログ設定が事前構成されています。現在の設定を確認できます。
```
CONFIG GET slowlog-log-slower-than
```
```
CONFIG GET slowlog-max-len
```
これらは、Redis が 1000 マイクロ秒（1 ミリ秒）を超えるコマンドをログに記録し、最大 128 件のスローログエントリを保存するように構成されていることを示すはずです。

スローログエントリの取得：

SLOWLOG GET コマンドを使用してスローログエントリを取得します。最も最近のスローログエントリ 10 件を取得するには、次のコマンドを使用します。

SLOWLOG GET 10

以下のような出力が表示されます（最近の Redis 内部操作を示しています）。

 1) 1) (integer) 10
    2) (integer) 1753255495
    3) (integer) 1954
    4) 1) "COMMAND"
    5) "127.0.0.1:42212"
    6) ""
 2) 1) (integer) 9
    2) (integer) 1753255494
    3) (integer) 4795
    4) 1) "COMMAND"
    5) "127.0.0.1:41444"
    6) ""
 3) 1) (integer) 8
    2) (integer) 1753255494
    3) (integer) 1599
    4) 1) "COMMAND"
    5) "127.0.0.1:41004"
    6) ""

出力の解釈：

SLOWLOG GET の出力はスローログエントリの配列です。各エントリには 6 つの情報が含まれています。
1. 一意の ID: スローログエントリの連番識別子（例：10, 9, 8...）
2. タイムスタンプ： クエリが実行されたときの Unix タイムスタンプ
3. 実行時間： マイクロ秒単位の実行時間（例：1954 = 1.954 ミリ秒）
4. コマンド配列： 実行されたコマンド（Redis 内部操作では「COMMAND」と表示されることが多い）
5. クライアント IP とポート： クライアントの IP アドレスとポート（例："127.0.0.1:42212"）
6. クライアント名： クライアントの名前（通常は空で、"" と表示されます）
時間の理解：
- 1954 マイクロ秒 = 1.954 ミリ秒
- 4795 マイクロ秒 = 4.795 ミリ秒
- 1599 マイクロ秒 = 1.599 ミリ秒
一般的なパターンの分析：

この環境では、通常以下のようなものが見られます。
- 「COMMAND」エントリ： コマンドの解析や処理など、Redis の内部操作を表します。
- マイクロ秒単位のタイミング： ほとんどの操作は非常に高速です（1〜5 ミリ秒）。
- ローカル接続： すべての接続は 127.0.0.1（localhost）から行われています。
より詳細なスロークエリの生成：

既存のデータでより具体的なスロークエリを確認するために、データセットをスキャンする操作を実行しましょう。
```
KEYS user:*
```
このコマンドはすべてのユーザーキー（1000 件）をスキャンし、スローログに表示されるはずです。

更新されたスローログを確認します。
```
SLOWLOG GET 3
```
以下のような形式で、KEYS user:* コマンドがスローログに表示されるはずです。
```
1) 1) (integer) 11
   2) (integer) [timestamp]
   3) (integer) [execution_time]
   4) 1) "KEYS"
      2) "user:*"
   5) "127.0.0.1:[port]"
   6) ""
```
MEMORY PURGE によるメモリ最適化：

メモリ最適化も実演しましょう。まず、現在のメモリ使用量を確認します。
```
MEMORY STATS
```
出力の total.allocated の値を確認します。次に、未使用のメモリをパージしてメモリを解放しましょう。
```
MEMORY PURGE
```
再度メモリ使用量を確認します。
```
MEMORY STATS
```
total.allocated の値を比較して、メモリが解放されたかどうかを確認します。MEMORY PURGE コマンドは、Redis によってアクティブに使用されていないメモリを解放しようとします。
redis-cli の終了:

コマンドがログに記録されていることを確認するには、次のように入力して redis-cli を終了します。
```
exit
```

情報の活用

スローログを分析することで、スロークエリを特定し、それらを最適化するための手順を実行できます。主な洞察には以下が含まれます。

コマンドの頻度： スローコマンドがどれくらいの頻度で表示されるか。
実行パターン： 特定の操作がスローログに一貫して表示されるかどうか。
パフォーマンスの傾向： 時間の経過に伴う実行時間の変化。
リソース使用量： 過剰な CPU またはメモリを消費する可能性のあるコマンド。

この情報は、以下に役立ちます。

アプリケーションクエリの最適化。
問題のあるパターンの特定。
スケーリングと容量の計画。
本番環境でのパフォーマンス問題のデバッグ。

まとめ

この実験では、Redis のパフォーマンス監視ツールが実際に組み込まれた事前構成済みの環境を使用して、Redis のパフォーマンス監視技術を調査しました。

まず、LATENCY DOCTOR コマンドを使用して、Redis がレイテンシの問題をどのように診断するかを理解しました。正常な環境では、レイテンシのスパイクが検出されなかったことを示す特徴的な「Dave」メッセージが表示され、システムが正常に機能している場合の Redis のレイテンシ監視フィードバックの解釈方法を学びました。

次に、MEMORY STATS コマンドを調べて Redis のメモリ使用パターンを分析しました。1000 件の文字列キー、50 件のハッシュオブジェクト、20 件のリスト、10 件のセットという事前構成済みのデータセットを使用して、現実的なメモリ割り当てを観察し、total.allocated、dataset.bytes、overhead.total などの主要なメモリメトリックを特定する方法を学びました。

その後、SLOWLOG GET コマンドを調査してクエリパフォーマンスを分析しました。6 要素のスローログエントリの読み方、マイクロ秒単位の実行時間の理解、Redis の内部「COMMAND」操作がスローログにどのように表示されるかを学びました。また、KEYS user:* のようなパターンマッチングコマンドを使用してカスタムスロークエリを生成する方法も実演しました。

最後に、MEMORY PURGE コマンドを使用したメモリ最適化を実演し、パージの前後のメモリ使用量を比較して、Redis がメモリを効率的に管理する方法を理解しました。

この実験を通して、以下の方法を学びました。

「正常なシステム」メッセージを含む LATENCY DOCTOR の出力を解釈する。
実際のデータセットメトリックを使用して MEMORY STATS でメモリ使用パターンを分析する。
6 要素の構造を持つスローログエントリを読み、理解する。
パターンマッチング操作を使用してスロークエリを生成し、分析する。
MEMORY PURGE でメモリ使用量を最適化する。
パフォーマンス監視において、Redis の内部操作とユーザーコマンドを区別する。

Redis の組み込みパフォーマンス監視ツールを使用したこの実践的な経験は、本番環境で応答性が高く効率的な Redis デプロイメントを維持するための基盤となります。