Redis Pub/Subの深淵：その「非永続性」とどう向き合うべきか
RedisのPub/Sub機能。多くのエンジニアが「高速なメッセージング基盤」として安易に導入し、そして本番環境で痛い目を見る機能でもある。
いいか、RedisのPub/Subは「魔法の杖」ではない。アーキテクチャの観点から言えば、これは「極めて揮発性の高い、一過性の信号伝達メカニズム」だ。これを理解せずに使うのは、地図を持たずに夜の荒野を走るようなものだ。
今日は、Redis Pub/Subを「ただの機能」としてではなく、堅牢なシステムの一部として組み込むための深層知見を授ける。
—
1. Pub/Subの残酷な真実：なぜメッセージは消えるのか
まず、Redis Pub/Subの設計思想を理解してくれ。これは「Fire and Forget（投げて忘れる）」の極致だ。
- 永続性ゼロ: メッセージはどこにも保存されない。
- オフライン配送なし: サブスクライバー（購読者）が接続を切断している間に送られたメッセージは、永遠に失われる。再接続しても遡ることはできない。
- バッファ制限: サブスクライバーの処理が遅く、Redis側の出力バッファが溢れれば、Redisはその接続を強制切断する。
この特性を理解せずに「信頼性の高いキュー」として使うのは設計上の致命傷だ。メッセージの欠落が許されないのであれば、それはRedis Pub/Subの役割ではない。その場合は `Redis Streams` や `Kafka` を検討すべきだ。
—
2. それでもなぜ我々はPub/Subを選ぶのか
では、なぜこれほどまでに愛されているのか？ それは「オーバーヘッドの極小化」と「シンプルさ」にある。
- 超低遅延: ネットワーク通信とメモリ内コピーのみで完結するため、ミリ秒未満の応答が必要なリアルタイム通知系には最適。
- 疎結合なアーキテクチャ: パブリッシャーは誰が受け取っているかを知る必要がない。マイクロサービス間での「状態更新通知」や「サーバー間イベントバス」として、これ以上の手軽さはない。
—
3. 堅牢な設計パターンのための「鉄則」
現場で障害を起こさないための、アーキテクトとしての推奨事項を並べる。
A. メッセージの「構造」を標準化する
単なる文字列を送るな。JSONでスキーマを定義し、バージョン番号を含めろ。将来的なスキーマ変更時に、サブスクライバー側が死ぬのを防ぐためだ。
// 送信されるメッセージの例
{
“version”: “1.0”,
“event_type”: “user.updated”,
“payload”: { “id”: 123, “name”: “Alice” },
“timestamp”: 1672531200
}
B. 「再接続」のハンドリングは必須
ネットワークの瞬断は必ず起こる。サブスクライバー側のクライアントライブラリで、指数バックオフを用いた再接続ロジックを実装していないコードは、レビューで即座に弾く。
C. チャンネルの命名規則を厳格化せよ
`”chat”` といった曖昧なチャネル名は避けろ。
`”service:auth:event:user_created”` のように、`<ドメイン>:<サービス名>:<イベントタイプ>:<リソースID>` の形式を強制する。これにより、Redisの `PUBSUB CHANNELS` コマンドでデバッグする際の可読性が劇的に上がる。
—
4. パフォーマンスの境界線：メモリとCPU
Redisはシングルスレッドベースのアーキテクチャだ。Pub/Subのトラフィックが過大になると、他のキャッシュ操作（GET/SET）にまで影響が出る可能性がある。
- クライアントバッファ制限の監視:
`CONFIG SET client-output-buffer-limit pubsub …` を適切に設定しろ。デフォルト値のまま本番運用するのはリスクが高い。負荷試験を行い、自社のメッセージ量に合わせて調整するんだ。
- ワイルドカード購読の乱用を避ける:
`PSUBSCRIBE`（パターン購読）は便利だが、大量のチャネルを監視させると、マッチングの計算コストが無視できなくなる。可能な限り明示的な購読を優先せよ。
—
5. 次の一手：Pub/SubからStreamへの移行
もし君が、「メッセージの欠落が許されない」「過去のログを追いたい」「処理が追いつかない場合に備えてバッファさせたい」と考えるようになったら、それは成長の証だ。
Redisには `Redis Streams` (XADD/XREAD) という強力な選択肢がある。Pub/Subのリアルタイム性に、永続性とコンシューマーグループによる負荷分散の概念を持ち込んだものだ。
- Pub/Sub: 「今この瞬間の信号を伝えたいだけ」の場合に使う。
- Streams: 「イベントを記録し、確実に処理しきりたい」場合に使う。
—
最後に
Redis Pub/Subは、システムの「神経系」だ。速いが、脆い。
しかし、その脆さを理解した上で、「消えてもいいデータ」と「信頼性が求められるデータ」を峻別して設計できるエンジニアこそが、スケーラブルなシステムを構築できる。
コードを書く前に自問しろ。「このメッセージが消えた時、システムはリカバリー可能か？」と。その答えが「No」なら、Pub/Sub以外の選択肢を検討する勇気を持て。
君たちのプロダクトが、高負荷に耐え、かつエレガントに動くことを期待している。健闘を祈る。
コメント