DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

一般的なRedis接続問題とクライアントタイムアウトのトラブルシューティング

重要なRedis接続エラーとクライアントタイムアウトのトラブルシューティングをマスターします。このガイドでは、ネットワーク診断、`maxclients`制限やSlow Logによるスローコマンドなどのサーバーボトルネックの特定、そして安定した高性能運用のためのクライアント側のコネクションプーリングと再接続戦略の最適化を体系的にカバーします。

一般的なRedis接続問題とクライアントタイムアウトのトラブルシューティング

Redisの接続エラーは、同じアプリケーションの症状が複数のレイヤーから発生する可能性があるため、厄介です。リクエストが失敗する原因は、TCP接続がRedisに到達しなかった、Redisが接続を受け入れたが空きクライアントスロットがなかった、1つのスローコマンドがイベントループをブロックしてクライアントが諦めるまでの時間が長くなった、またはアプリケーションが自身のコネクションプールを使い果たしたなど、様々です。

最初の手がかりとして、正確なエラーテキストを扱います。Connection refusedは通常、ホストが応答したがそのポートで接続を受け入れるものがないことを意味します。Connection timed outは通常、パケットパスがブロックされているか、遅すぎることを意味します。RedisのLOADINGエラーは、サーバーは起動しているがまだデータを復元中であることを意味します。ERR max number of clients reachedは、サーバー側の接続制限を直接示します。コマンド送信後のクライアント側のタイムアウトは、多くの場合、レイテンシ、スローコマンド、またはプールの枯渇を示しています。

根本原因の診断：最初に確認すべき場所

最も迅速に証明できるレイヤーから始めます：サーバーがリッスンしているか、クライアントが到達できるか、Redisが応答しているか、クライアントがコマンド応答を待っている間にタイムアウトしているか。

1. ネットワークとファイアウォールの確認

接続障害は、多くの場合、最も簡単に解決できます。基本的なネットワークパスが開いており、安定していることを確認します。

A. ポートのアクセス可能性

Redisが期待されるアドレスとポートでリッスンしていることを確認します。デフォルトポートは6379ですが、マネージドRedisサービス、コンテナ、および強化されたデプロイメントでは、異なるネットワークパスが使用されることがよくあります。

実行可能な手順（Linuxサーバーチェック）： Redisホストでssを使用します：

# デフォルトポートのリッスンステータスを確認
ss -tuln | grep 6379
# 公開リッスンの例：
# tcp LISTEN 0 511 0.0.0.0:6379 0.0.0.0:*

127.0.0.1:6379でのリッスンはローカルのみのRedisには正しいですが、リモートクライアントは接続できません。0.0.0.0でのリッスンはプライベートネットワーク内で必要になる場合がありますが、Redisを直接パブリックインターネットに公開しないでください。必要に応じて、プライベートネットワーキング、ファイアウォールルール、認証、TLSを使用します。

B. レイテンシとパケットロス

クライアントホストから、ポートを直接テストします：

nc -vz redis.example.internal 6379
redis-cli -h redis.example.internal -p 6379 PING

PONGは、開いているTCPポート以上のものを証明します。Redisがコマンドを受け入れ、処理したことを証明します。ncは機能するがredis-cli PINGが機能しない場合は、認証、TLS要件、Redisプロテクトモード、およびコマンドレイテンシを確認します。

断続的なタイムアウトの場合は、mtr、クラウドネットワークメトリクス、またはパケットキャプチャを使用して、パケットロスやルーティングの変更を探します。Redisサーバーが正常でも、1つのアベイラビリティゾーン、NATゲートウェイ、サービスメッシュサイドカー、またはファイアウォールパスが原因でクライアントから見えるタイムアウトが発生する可能性があります。

2. Redisサーバーのリソース制約

Redisはほとんどのコマンドを単一のメイン実行パスで処理します。1つの高負荷コマンドが原因で、無関係なクライアントが待機する可能性があります。この待機は、多くの場合、明らかなRedisエラーではなく、クライアントのタイムアウトとして現れます。

A. 最大接続数制限（maxclients）

Redisがmaxclientsに達すると、新しいクライアントはERR max number of clients reachedなどのエラーを受け取る可能性があります。一部のアプリケーションライブラリはこれを適切に表面化しないため、Redisメトリクスも確認します。

クライアントが接続試行時にすぐに拒否エラーを受け取った場合は、サーバー構成を確認します：

CONFIG GET maxclients

また、現在のクライアントを検査します：

redis-cli INFO clients
redis-cli CLIENT LIST

connected_clientsが減少せずに増加する場合は、接続リーク、ワーカープロセスが多すぎる、プーリングの欠如、またはヘルスチェックが頻繁に新しい接続を作成していることが疑われます。maxclientsを増やすと時間を稼げるかもしれませんが、メモリ使用量も増加します。カウントが無制限の場合は、クライアントの動作を修正します。

B. スローコマンドとブロッキング操作

KEYS *、大規模なHGETALL、大規模なSMEMBERS、重いLuaスクリプト、大規模な削除などの長時間実行コマンドは、他の作業をブロックする可能性があります。永続化もレイテンシを追加する可能性があり、特にホストのCPU、メモリ、またはディスク帯域幅が不足している場合に顕著です。

Slow Logを使用した診断： Redisは、定義された実行時間（slowlog-log-slower-than）を超えるコマンドを追跡するための強力なSlow Logを提供します。

  1. 構成の確認：
    CONFIG GET slowlog-log-slower-than
CONFIG GET slowlog-max-len
  2. ログエントリの表示：
    SLOWLOG GET 10  # 最後の10件のスローエントリを表示

Slow Logエントリがクライアントのタイムアウトと一致する場合は、コマンドパターンを修正します。KEYSの代わりにSCAN、完全なハッシュ読み取りの代わりにHSCAN、非常に大きなキーにはDELの代わりにUNLINK、コレクション全体を取得する代わりにページネーションを使用します。

C. 永続化の影響（AOF/RDB）

AOF fsync、AOF書き換え、またはRDBスナップショットに関連するディスクI/Oは、レイテンシを追加する可能性があります。Redisがログ、バックアップ、他のデータベース、またはノイズの多いコンテナノードとディスクを共有している場合、その影響はさらに悪化します。

確認：

redis-cli INFO persistence
redis-cli LATENCY LATEST

BGSAVEまたはBGREWRITEAOF中にタイムアウトが発生する場合は、メモリヘッドルームを増やし、その期間中の書き込みチャーンを減らし、Redisをより高速なストレージに移動するか、永続化のタイミングを調整します。データが本当に使い捨て可能でない限り、永続化を単に無効にしないでください。

クライアント側の構成とタイムアウト管理

クライアントライブラリは、コネクションプーリングとタイムアウトの期待値を管理するためのパラメータを提供します。誤って構成されたクライアントは、サーバーの不安定性の認識される原因として頻繁に発生します。

1. クライアントタイムアウトの最適化

クライアントタイムアウトは、アプリケーションが応答を待ってから諦めるまでの時間を定義します。サーバーが遅い場合、クライアントは十分に長く待つ必要がありますが、無期限ではありません。

  • 短いタイムアウト： アプリケーションが安全にデータベースやデフォルトの応答にフォールバックできるキャッシュ読み取りに役立ちます。
  • 長いタイムアウト： 積極的な再試行がインシデントを悪化させる可能性がある操作に役立ちますが、Redisが異常な場合にリクエストスレッドを占有する可能性があります。

アプリケーションの動作からタイムアウトを選択します。Redisがベストエフォートキャッシュである場合は、迅速に失敗し、グレースフルに劣化します。Redisがログインセッションに必要な場合、タイムアウトはより長くする必要があるかもしれませんが、1つのRedisインシデントですべてのWebワーカーを消費しないように、サーキットブレーカーも必要です。

2. コネクションプーリングとリーク

不適切に管理されたコネクションプールは、利用可能なサーバースロットの枯渇や、クライアントが古い接続を保持することにつながる可能性があります。

  • プールの枯渇： プールサイズが小さすぎると、リクエストがキューイングされ、Redisサーバーが正常でもアプリケーションレベルのタイムアウトにつながる可能性があります。
  • 接続リーク： 接続が開かれた後、使用後にプールに戻されない場合、プールが枯渇し、新しいリクエストが接続に失敗します。

Redisだけでなく、アプリケーションのプールメトリクスを確認します。アクティブな接続、アイドル接続、プールされた接続の待機時間、接続の借用中の失敗、再接続回数を把握する必要があります。すべてのアプリケーションスレッドが1つの小さなプールを待っている場合、正常なRedisサーバーは役に立ちません。

3. 切断の処理と再接続戦略

ネットワークの不具合により、一時的な切断が発生します。堅牢なクライアントは、これらのイベントをグレースフルに処理する必要があります。

再接続には、ジッターを伴う指数バックオフを使用します。ネットワークの瞬断後に数百のアプリケーションワーカーが同時に再接続する場合、即時の再試行ループは2回目の停止を引き起こす可能性があります。

  1. 短い期間（例：1秒）待機して再試行します。
  2. 再度失敗した場合は、待機時間を2倍にします（2秒、4秒など）。
  3. ビジネス要件に基づいて、合計再試行時間に上限を設定します。

ほとんどの成熟したクライアントは基本的な再接続を処理しますが、デフォルトは異なります。再接続中にコマンドがキューイングされるかどうか、再試行によって書き込みが重複する可能性があるかどうか、フレームワークがリクエストレイテンシがすでに高くなるまでRedisエラーを隠していないかどうかを確認します。

実用的なトラブルシューティングの順序

インシデント中はこの順序を使用します：

ステップ 領域 確認/アクション 症状の一致
1 サーバーリッスン ss -tuln、Redisサービスステータス 接続拒否
2 サーバー制限 CONFIG GET maxclients 接続拒否
3 サーバーパフォーマンス SLOWLOG GET 断続的なタイムアウト
4 永続化 BGSAVE/BGREWRITEAOFアクティビティの確認 レイテンシスパイク/タイムアウト
5 クライアント構成 クライアントタイムアウト設定とプールサイズの確認 クライアント側エラー

最も有用なRedisタイムアウト修正は、単独で「タイムアウトを上げる」ことではありません。時にはそれが必要ですが、遅延がネットワーク到達可能性、サーバー制限、スローコマンド、永続化の負荷、またはプールの枯渇のいずれであるかを把握した後に行うべきです。実際に失敗しているレイヤーを修正し、次にタイムアウトを調整して、次回Redisが遅いときにアプリケーションが予測可能に動作するようにします。