レスポンス低下を未然に防ぐ！Redis/Valkey監視のキホンと重要メトリクスまとめ
メディア統括本部 サービスリライアビリティグループ（SRG）の小林（@berlinbytes）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、Redis/Valkeyの安定運用に不可欠な監視の考え方を解説し、レスポンス低下を未然に防ぐための具体的なメトリクスや実践的なステップを紹介するものです。
はじめに
弊社においてRedisやそのオープンソースフォークであるValkeyは、非常に高速なインメモリデータストアとして、キャッシュ、セッションストア、リアルタイム分析、プライマリデータベースなど、多岐にわたる用途で活用されています。
その特徴は、データをメモリ上で直接操作することによる圧倒的な低レイテンシです。
しかしその高速性ゆえに、わずかなパフォーマンスの低下がシステム全体の応答性に影響を及ぼし、ユーザー体験を損なう原因となり得ます。
この記事では、RedisとValkeyの安定運用に不可欠な監視の考え方をまとめ、レスポンス低下を未然に防ぐための具体的なメトリクスや実践的なステップを紹介したいと思います。
監視を構成する5つの重要レイヤー
効果的な監視体制を築くために、システムを複数のレイヤーに分けて考えることが有効です。
ここでは、押さえるべき5つの監視レイヤーについて解説します。
1. パフォーマンス（レイテンシ & スループット）
パフォーマンスはユーザー体験に最も直結する指標です。
アプリケーション視点での往復レイテンシと、サーバー内部でのコマンド処理遅延の両方を測定することが重要です。
秒間あたりの処理コマンド数とキャッシュヒット率を併せて監視し、パフォーマンスの全体像を把握します。
Redis/Valkeyは通常サブミリ秒で応答するため、わずかなレイテンシの増加も重要な変化の兆候です。
また、Redis/Valkeyは基本的にシングルスレッドであるため、CPU使用率もサーバーパフォーマンスの重要な指標になります。
問題解析には、低速クエリを記録するや、レイテンシの発生源を診断するコマンド群（, など）が役立ちます。
2. メモリの健全性
インメモリデータベースであるRedis/Valkeyにとって、メモリは最も重要なリソースです。
メモリ使用量と最大メモリ設定の比率、メモリ上限到達によるキーの強制削除数（）、そしてメモリの断片化率を継続的に監視します。
断片化率は、1.5を継続的に超える場合は断片化が進みすぎているサインです。
逆に1.0未満が続く場合は、OSによるスワップが発生している可能性があり、注意が必要です。
3. レプリケーションとクラスタ
可用性を高めるためにレプリケーションやクラスタ構成を取る場合、その健全性の監視も不可欠です。
プライマリとレプリカ間のデータ同期の遅延（レプリケーションラグ）、同期位置の差分（オフセット）、接続状態（リンクステータス）などを監視します。
AWS ElastiCacheやGoogle Cloud Memorystoreなどのマネージドサービスでは、これらのメトリクスが標準で提供されていることが多いです。
4. 永続化とフォークの影響
データの永続化のためにスナップショット（RDB）や追記専用ファイル（AOF）を利用する場合、バックグラウンドでの保存処理がパフォーマンスに影響を与えることがあります。
特に、RDB保存やAOFリライト時にはシステムコールが実行され、一時的にメモリ使用量が増加し、レイテンシが悪化する可能性があります。
バックグラウンド保存処理の実行状況を示すフラグや、処理にかかった時間を記録することで、パフォーマンス問題が発生した際の切り分けに役立ちます。
5. クライアントと接続
クライアントからの接続状況も重要な監視対象です。
現在の接続クライアント数、ブロッキングコマンドによって待機中のクライアント数、そして接続拒否数を監視します。
接続拒否が発生している場合、設定された最大クライアント数に達している可能性があり、リソースの見直しやアプリケーション側の接続プーリング設定の確認が必要です。
最優先で監視すべき主要メトリクスとアラート
監視を始めるにあたり、特に重要となるコアメトリクスと、異常を検知するためのアラート設定例を紹介します。
コアメトリクス一覧
- メモリ
- 使用率 ( / )
- 断片化率 ()
- キー削除数 ()
- アクティブデフラグ関連 ()
- CPU使用率
- メインスレッドのCPU使用状況
- 高負荷時には注意
- アクティビティ
- クライアント接続数 ()
- レプリケーションラグ
- レイテンシ
- コマンドの処理遅延。アプリケーションからの応答時間と合わせて評価します。
- キャッシュ効率
- キャッシュヒット率。キャッシュとして利用している場合の効率を示します。
- ネットワーク
- クライアントとインスタンス間のラウンドトリップタイム（RTT）。
実践的なアラート設定例
- 高レイテンシ: アプリケーションのp95レイテンシがサービスレベル目標（SLO）を超過した場合や、コマンドでスパイクを検知した際に通知します。
- キーの強制削除: が0より大きい状態が継続する場合。これはメモリ容量不足の明確なサインです。
- メモリ逼迫: メモリ使用率が80%を超え、かつ断片化率も高い状態が続く場合。
- レプリケーション遅延: レプリケーションラグが事前に定めた許容値（例: 1〜3秒）を超えて継続する場合。
- クライアントブロック: が0より大きい状態が継続する場合。長時間実行されるコマンドの存在が疑われます。
効果的な監視ダッシュボードの作り方
メトリクスをただ収集するだけでなく、一目で状況を把握できるダッシュボードを作成することが運用効率を大きく向上させます。
以下にダッシュボードの構成例を示します。
- 可用性パネル: コマンドの成功率、接続失敗数、レプリカ遅延（秒）を表示し、基本的な死活監視を行います。
- レイテンシパネル: アプリケーション視点の応答時間（p50/p95/p99）と、/など主要コマンド別のレイテンシを並べて表示します。
- メモリパネル: メモリ使用率、、断片化率、Active Defragのヒット数などをまとめ、メモリの状態を多角的に評価します。
- スループットパネル: 秒間コマンド処理数（OPS）、ネットワーク送受信量、レプリケーションで転送されるデータ量などを表示し、負荷の傾向を把握します。
- クライアントパネル: 接続クライアント数、ブロックされたクライアント数、接続拒否数、認証失敗数などのトレンドを監視します。
- キャッシュ効率パネル: キャッシュヒット率を独立した大きなパネルで表示し、急な低下を早期に検知できるようにします。
監視の導入に向けたアクションプラン
最後に、これから監視を導入するための具体的なアクションプランを紹介します。
ベースラインの確立
まずは、通常時のシステムの挙動を把握します。
1〜2週間かけて、レイテンシやメモリ使用量、OPS、接続数などの主要メトリクスを記録し、時間帯や曜日ごとの傾向（ベースライン）を確立します。
初期アラートの設定
ベースラインを基に、現実的な閾値でアラートを設定します。
例えば、レイテンシは「ベースライン + 5ms」、メモリ使用率は「80%」や「90%」といった値から始め、接続拒否やクライアントブロックは発生即通知するように設定します。
分析サイクルの定着
アラートが発生した際の原因調査を定着させます。
を定期的に取得する仕組みや、を活用して、パフォーマンススパイクの原因を特定し、チームで知見を蓄積していくサイクルを回します。
継続的な閾値の調整
運用を続ける中で、サービスの成長とともにキャッシュヒット率や断片化率などの平常時の範囲が変わってくると思います。
そのデータに基づき、誤検知を減らしつつ、異常をより早期に検知できるようアラートの閾値を継続的に見直し改善していくことが必要です。
終わりに
ご紹介したようなステップを通じてプロアクティブな監視体制を構築することが、Redis/Valkeyを活用したサービスの安定稼働と、優れたユーザー体験の提供につながっていくと思います。
最後に、各種クラウドサービスや公式の構成や運用に関係したベストプラクティスへのリンクを紹介しておきます。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。