Redisが高いCPU使用率を示す理由：デバッグと最適化のテクニック
超高速なインメモリパフォーマンスで知られるRedisは、キャッシング、セッション管理、リアルタイムデータ処理において重要なコンポーネントです。しかし、RedisインスタンスのCPU使用率が突然急上昇すると、パフォーマンスは急速に低下し、依存するすべてのアプリケーションに影響を与える可能性があります。これが起こる理由を理解することが、修正への第一歩です。本ガイドでは、非効率なコマンドからバックグラウンドI/Oに至るまで、RedisのCPU使用率が高くなる一般的な原因を深く掘り下げ、システムの健全性を即座に回復させるための実用的なデバッグおよび最適化手法を提供します。
RedisのアーキテクチャとCPU負荷の理解
Redisは、コアコマンドを処理するために主にシングルスレッドアプリケーションとして動作します。これは、ほとんどの操作が1つのCPUコア上で逐次的に実行されることを意味します。したがって、高いCPU使用率は、この単一スレッドが過負荷になっているか、または永続化やネットワークI/Oなどのバックグラウンドプロセスが大量のリソースを消費していることを示している場合が多いです。
RedisのCPU負荷に影響を与える主要因
- コマンド実行時間: 複雑またはリソースを大量に消費するコマンドはメインスレッドをブロックします。
- 永続化操作: データをディスク（RDBまたはAOF）に保存する操作は、一時的なCPUスパイクとレイテンシを引き起こす可能性があります。
- ネットワーク負荷: 高いトラフィックや非効率なクライアントの動作が、I/O処理能力に負担をかけることがあります。
- データ構造のオーバーヘッド: 非常に大きなデータ構造に対する操作。
CPU使用率が高い場合のデバッグ
最適化を行う前に、負荷の原因を正確に特定する必要があります。監視ツールとRedisの組み込みコマンドが診断に不可欠です。
1. INFO コマンドと LATENCY コマンドの使用
INFO コマンドはサーバー状態のスナップショットを提供します。CPUセクションとコマンド統計に焦点を当ててください。
redis-cli INFO cpu
used_cpu_sys や used_cpu_user のようなメトリクスの高い値を探します。used_cpu_user が高い場合は、重いコマンド処理が原因であることが多く、used_cpu_sys が高い場合は、I/Oやメモリ管理に関連するカーネルとのやり取りを示している可能性があります。
LATENCY コマンドは、一貫したレイテンシスパイクを引き起こしているコマンドを特定できます。
redis-cli LATENCY HISTORY command
2. SLOWLOG を使用した遅いコマンドの特定
Redisスローログは、指定された実行時間を超えたコマンドを記録します。これは、パフォーマンスの悪い操作を見つけるための最も直接的なツールです。
設定: redis.conf ファイル内で、または CONFIG SET を介して動的に slowlog-log-slower-than（マイクロ秒）と slowlog-max-len が適切に設定されていることを確認してください。
設定例:
# 1000マイクロ秒（1ms）を超えるコマンドをログに記録
SLOWLOG-LOG-SLOWER-THAN 1000
SLOWLOG-MAX-LEN 1024
ログの取得:
redis-cli SLOWLOG GET 10
出力内容を確認し、実行時間を支配しているコマンド（例: KEYS、大きな HGETALL、複雑なLuaスクリプト）を特定します。
3. ネットワークとクライアントアクティビティの監視
MONITOR コマンドは（オーバーヘッドが高いため）注意して使用するか、外部ツールやOS監視（netstat、ss）に頼って、アクティブな接続数と総ネットワークスループットを確認します。接続数や1秒あたりのコマンド数の急増は、シングルスレッドを圧倒する可能性があります。
一般的な原因と最適化戦略
問題のあるコマンドやプロセスを特定したら、的を絞った最適化手法を適用します。
1. ブロッキングコマンドの排除
シングルスレッドモデルにおけるCPUスパイクの主な原因は、ブロッキング操作です。本番環境でデータセット全体をスキャンするコマンドを絶対に使用しないでください。
| 非効率なコマンド | 高CPUの原因 | 最適化 / 代替手段 |
|---|---|---|
KEYS * |
全キー空間をスキャンする。O(N)。 | SCAN を反復的に使用するか、データアクセス方法を再構築する。 |
FLUSHALL / FLUSHDB |
全てのキーを削除する。 | 明示的な削除、または大きなキーに対しては UNLINK（非ブロッキング削除）を使用する。 |
HGETALL、SMEMBERS（非常に大きなセットの場合） |
構造全体をメモリに読み込み、シリアル化する。 | HSCAN、SSCAN を使用するか、大きな構造を小さなキーに分割する。 |
ベストプラクティス：非常に大きなキーに対しては DEL よりも UNLINK を使用します。 DEL はキーを削除する間、メインスレッドをブロックします。UNLINK は実際の削除をバックグラウンドで非同期に実行するため、大きなキーの削除時のCPU負荷スパイクを大幅に軽減します。
# DEL large_key の代わりに
UNLINK large_key
2. 永続化（RDBとAOF）の最適化
バックグラウンド保存操作は BGSAVE コマンドの実行をトリガーし、オペレーティングシステムの fork() メカニズムを利用します。データセットが大きいシステムでは、fork() がCPUと時間を大量に消費し、短時間ではあるものの、大きな負荷を引き起こす可能性があります。
- RDBスナップショット: 頻繁に保存する（例：毎分）場合、繰り返し発生する
fork()呼び出しが定期的なCPUスパイクを引き起こします。自動保存の頻度を減らしてください。 - AOFの書き換え: AOFの書き換え（
BGREWRITEAOF）もリソースを大量に消費します。Redisは最小限のI/Oでこれを最適化しようとしますが、プロセス中はCPU使用率が上昇します。
最適化のヒント: 永続化中に許容できないレイテンシが発生する場合は、save 間隔を調整するか、ピーク負荷時に永続化を一時的に一時停止することを検討してください（ただし、これはデータ損失のリスクを高めます）。
3. メモリ断片化とスワッピングの処理
メモリの問題は高メモリ使用量と関連付けられることが多いですが、深刻なメモリ断片化、あるいはそれ以上に、OSがRedisデータをディスクにスワップし始める（スラッシング）と、カーネルがメモリ管理のために奮闘するため、CPU使用率は劇的に増加します。
- スワップの確認: OSツール（
vmstat、top）を使用して、システムがRedisプロセスのメモリページを積極的にスワップしているかどうかを確認します。 - メモリ断片化率:
INFO memoryの出力でmem_fragmentation_ratioを確認します。1.0を大幅に超える比率は、高い断片化を示唆しており、メモリの割り当て/解放中にCPU負荷を増加させる可能性があります。
スワップが発生する場合の解決策は、常にデータセットサイズを減らすか、物理RAMを追加することです。Redisはスワップされた状態で効率的に動作するように設計されていません。
4. ネットワークの最適化とパイプライン処理
CPU負荷がコマンドのスループットと直接相関する場合、レイテンシは多数のネットワーク往復のオーバーヘッドによって引き起こされている可能性があります。
パイプライン処理: 100個の個別の SET コマンドを送信する代わりに、クライアントライブラリを使用してそれらを単一のコマンドブロックにグループ化します。これにより、ネットワークレイテンシと、Redisのシングルスレッドによって処理されるコマンドごとのオーバーヘッドが減少し、バルク操作の全体的なCPU効率が向上します。
持続的なパフォーマンスのためのベストプラクティス
将来のCPUスパイクを防ぐために、以下のアーキテクチャと設定のベストプラクティスを採用してください。
- 非同期削除の使用: 大容量になり得るキーに対しては、常に
DELよりもUNLINKを優先します。 KEYSの使用禁止: 本番環境でのキー検索にはSCANを使用します。- クライアント動作の監視: アプリケーション開発者が使用するRedisコマンドの複雑性の影響を理解していることを確認します。
- 永続化頻度の調整: RDBの保存ポイントをピークトラフィック時間と重複しないように調整するか、RDBのforkが主な原因である場合はAOFにより重点を置きます。
- 垂直スケーリング（必要な場合）: 最適化を行っても1つのコアが常に飽和している場合は、Redis Clusterまたはクライアント側シャーディングを使用して、データセットを複数のRedisインスタンスにシャーディングすることを検討してください。
結論
RedisのCPU使用率が高いことはめったに謎ではありません。通常、シングルスレッドのイベントループが非効率なコマンドや過剰なバックグラウンド永続化によって過負荷になっている症状です。SLOWLOG を体系的に使用し、KEYS のようなブロッキングコマンドを排除し、永続化設定を調整することで、根本原因を効果的に診断および解決し、Redisインスタンスが特徴的な高性能を維持できるようにすることができます。