Redisの「見えざるメモリリーク」を断つ：`client-output-buffer-limit` の極限チューニング
エンジニアの皆さん、こんにちは。テックリードの私だ。
今日のコードレビュー、あるいは本番障害のポストモーテム（事後検証）で、こんな恐怖を味わったことはないだろうか？
「特に高負荷なクエリを発行したわけでもないのに、Redisノードが突然 OOM (Out Of Memory) キラーに狩られた」
「スレーブ（Replica）の同期が無限ループのようになり、マスター側のメモリがみるみるうちに食いつぶされていく」
もし心当たりがあるなら、原因はRedisのデータ構造でも、スロークエリでもない。犯人は 「クライアント出力バッファ（Client Output Buffer）」 だ。
今日は、Redisのメモリ管理において最も看過されやすく、かつ本番環境の生死を分ける `client-output-buffer-limit` について、アーキテクトの視点から容赦なく、そして実務に直結する形で解説する。
—
1. なぜ「出力バッファ」はメモリを暴走させるのか？
Redisはシングルスレッドで動作するインメモリデータベースでありながら、数万〜数十万のクライアントからの並行接続をさばく。
ここで重要なのは、「Redisはクライアントへデータをプッシュする際、即座にソケットに書き込めるわけではない」 という事実だ。
ネットワークの帯域制限、クライアント側の処理遅延、あるいはPub/Subでのメッセージ爆発などにより、OSのソケットバッファが溢れると、Redisはデータをアプリケーション側のメモリ（出力バッファ）に一時退避させざるを得なくなる。
もし、次のような悪夢のようなシナリオが発生したらどうなるか？
1. Pub/Subの暴走: 1つの遅いコンシューマー（あるいは切断しかけているクライアント）に向かって、巨大なチャンネルへ秒間数万件のメッセージが流れ込む。
2. 重いレプリケーション: マスター・スレーブ間のネットワークが一時的に細くなり、スレーブへの初期同期（PSYNC/SYNC）のデータストリームがバッファに溜まり続ける。
これらを放置すれば、Redisプロセスは瞬発的に数GBのメモリを消費し、LinuxのOOM Killerによって無慈悲に殺害される。この「クライアント起因のメモリ爆発」を防ぐ防波堤こそが、`client-output-buffer-limit` である。
—
2. `client-output-buffer-limit` のメカニズムと評価基準
Redisでは、クライアントの性格（性質）を以下の3つのクラスに分類し、それぞれ個別にバッファ制限を設けている。
1. `normal`: 通常のクライアント接続（アプリケーションからのコマンド送信）
2. `slave` (Replica): レプリカサーバーからの接続
3. `pubsub`: Pub/Subチャンネルを購読しているクライアント接続
設定の構文とトリガー条件
設定値は `redis.conf` または `CONFIG SET` で以下のように定義する。
client-output-buffer-limit
- Hard Limit（ハードリミット）:
即座に発動する閾値。出力バッファのサイズがこのバイト数を超えた瞬間、Redisは容赦なくそのクライアントの接続を切断する。
- Soft Limit（ソフトリミット） & Soft Seconds（継続時間）:
猶予付きの閾値。出力バッファがソフトリミットを超えた状態が、指定された秒数（`soft seconds`）連続して続いた場合、その時点でクライアントは切断される。
—
3. 実務で直面するデフォルト値の罠
多くのLinuxディストリビューションやクラウドのマネージドRedis（AWS ElastiCacheなど一部を除く）のデフォルト設定は、実のところ「開発環境向け」であり、大規模なプロダクション環境では危険な場合がある。
デフォルトの典型的構成例を見てみよう。
通常クライアント: 基本的に無制限（0）だが、運用上非常に危険
client-output-buffer-limit normal 0 0 0
レプリカ: 256MB超え、または 64MB超えが60秒続いたら切断
client-output-buffer-limit slave 256mb 64mb 60
Pub/Sub: 32MB超え、または 8MB超えが60秒続いたら切断
client-output-buffer-limit pubsub 32mb 8mb 60
なぜデフォルトでは危ういのか？
1. `normal 0 0 0` の恐怖:
デフォルトでは通常のクライアントに対する制限がない（`0`）。もしバッドクエリ（例: 数百万件のキーを持つ巨大なHash全体を `HGETALL` するなど）を発行するクライアントが現れると、そのクライアントのバッファはメモリ限界まで膨れ上がり、Redis全体を巻き込んでクラッシュする。
2. `pubsub` の過小評価:
デフォルトの `32mb` というハードリミットは、マイクロサービスのイベント駆動アーキテクチャにおいて、JSONペイロードの肥大化やコンシューマーの目詰まりによって、意外なほど簡単に突破されてしまう。
—
4. 堅牢な設計パターン：本番環境の推奨値とチューニング
テックリードとして、設計レビュー時に私が指定する「守りの設定指針」を伝授しよう。
パターンA: 通常クライアント (`normal`)
「信頼できるアプリケーションサーバーからの接続だから無制限でいいや」という甘えを捨てろ。
アプリケーションのバグや、意図しない巨大データの取得からRedisを守るため、必ず上限を設定する。
例: 50MBを超えたら即座に切断、20MB超えが10秒続いたら切断
client-output-buffer-limit normal 50mb 20mb 10
※注意: アプリケーション側がこの切断（Connection Reset）を検知し、適切に再接続・リトライする耐障害設計（Resilience）が前提となる。
パターンB: レプリカ (`slave`)
レプリカの切断は、マスターからの再同期（Full Resync）を引き起こし、さらなるネットワークとCPUの負荷を生む。そのため、ある程度の余裕を持たせる必要がある。
特に巨大なデータセット（数十GB超）を扱う場合、デフォルトの `256mb` では一瞬で溢れる。
例: 巨大データセット向け（1GB超え、または 512MBが60秒）
client-output-buffer-limit slave 1073741824 536870912 60
パターンC: Pub/Sub (`pubsub`)
メッセージの流通量とペイロードサイズから逆算する。
例: 100MB / 32MB (60秒)
client-output-buffer-limit pubsub 100mb 32mb 60
—
5. 監視とトラブルシューティングの極意
「設定したから安心」ではない。プロのエンジニアは常にメトリクスを監視する。
現在のバッファ使用状況の確認
CLIから `CLIENT LIST` コマンドを叩くことで、現在各クライアントがどれだけ出力バッファを消費しているか（`omem` フィールド）が一目瞭然になる。
redis-cli client list | grep -E “addr=|omem=”
出力例:
id=4 addr=10.0.1.50:54322 … omem=1048576 …
- `omem=1048576` は、約1MBの出力バッファが消費されていることを示す。
- この値が常に高止まりしているクライアントがいたら、それはコードの設計不良か、メモリリークの予兆だ。
INFO命令でのモニタリング
`INFO clients` コマンドで、現在バッファ制限に引っかかっているクライアントの傾向を掴むこともできる。
redis-cli info clients
出力中の `client_longest_output_list` などの指標に注目せよ。ここに異常な数値が出ている場合、出力バッファが逼迫している動かぬ証拠だ。
—
最後に：アーキテクトからのメッセージ
`client-output-buffer-limit` は、いわばRedisという巨艦が沈没するのを防ぐための「防水区画の自動隔壁（バルクヘッド）」である。
この設定を適切に行うことは、単なるメモリの節約ではない。「一箇所の不具合や遅延が、システム全体を巻き込むカスケード障害（連鎖倒産）を引き起こすのを防ぐ」ための、極めて高度なリスクヘッジなのだ。
今日のレビューから、君のプロダクトの `redis.conf` を見直してほしい。
デフォルトのまま放置されている箇所があれば、それは技術的負債であり、時限爆弾に他ならない。
プロフェッショナルなエンジニアなら、今すぐ適切な値を算出し、システムの堅牢性をその手で高め給え。
コメント