Redis Streamsの深淵：XREADとXREADGROUPの背後にある「生存戦略」
Redis Streamsは、単なる「ログ構造のデータ型」ではない。これは、Redisのメモリモデルと非同期イベントループの限界を押し広げるために設計された、極めて洗練されたステートマシンだ。
多くのエンジニアは `XREAD` と `XREADGROUP` を単なるコマンドとして消費するが、真のアーキテクトであれば、その背後にあるポインタの移動、ラディックスツリー（Radix Tree）の走査、そしてACKトラッキングのメモリコストを意識せねばならない。
本稿では、Redisの内部挙動に踏み込み、なぜ大規模システムにおいてこの二者が決定的な差を生むのかを解剖する。
—
1. XREAD：ステートレスな「観測」の限界
`XREAD` は、ストリームの特定のIDから単にデータを引き剥がすだけの単純なコマンドではない。内部的には、指定されたIDを起点に、Radix Treeのノードを辿り、該当するエントリをシーケンシャルにスキャンする。
アーキテクチャの真実
`XREAD` は、クライアントが「どこまで読んだか」という状態を一切管理しない。これは分散システムにおける「疎結合」の極致だが、裏を返せば、クライアント側のコードがポインタ管理を誤れば、データは永遠にロストするか、重複処理の無限ループに陥ることを意味する。
最後のID $ を指定して新規メッセージのみをポーリングする
ブロック時間を 0 (無期限) に設定し、クライアント側のアイドル負荷を最小化する
XREAD BLOCK 0 STREAMS mystream $
アーキテクトの視点:
`XREAD` のコストは、走査するメッセージ数と、レスポンスをシリアライズしてネットワークバッファへコピーする際のメモリフットプリントに依存する。高頻度なストリームに対して `COUNT` を指定せずに `XREAD` を発行するのは、Redisのイベントループをブロッキングし、後続のコマンド処理をスタベーション（飢餓）させる危険な行為だ。
—
2. XREADGROUP：分散処理の要諦と「PEL」の呪縛
コンシューマーグループは、単なる「読み取りポインタの共有」ではない。Redis内部では、PEL (Pending Entries List) と呼ばれる、極めて高度な追跡メカニズムが動作している。
なぜ `XREADGROUP` なのか
`XREADGROUP` を実行すると、以下のプロセスがアトミックに行われる。
1. ポインタの更新: グループ内の `last_delivered_id` が更新される。
2. PELへの登録: 処理中であることを示すエントリが `PEL` に書き込まれる。
この `PEL` こそが、分散システムにおける「確実な処理」を担保する心臓部だ。
グループ mygroup 内のコンシューマー C1 が、未処理のメッセージを読み込む
> は「まだどのコンシューマーにも配送されていないメッセージ」を意味する
XREADGROUP GROUP mygroup C1 COUNT 10 STREAMS mystream >
内部のメモリコスト
`PEL` は、Redisのメモリを確実に消費する。もし、コンシューマーが `XACK` を忘れると、`PEL` は肥大化し続け、最悪の場合、メモリプレッシャーを引き起こしてRedisインスタンス全体をOOM（Out of Memory）に追い込む。
極限の知見:
`XREADGROUP` を使用する場合、`XACK` は単なる「完了報告」ではない。「メモリの解放」という極めて重要な資源管理タスクであることを忘れてはならない。大規模運用では、ゾンビ化したコンシューマーが保持する `PEL` を監視し、`XPENDING` と `XCLAIM` を用いたリカバリプロセスを自動化することが、アーキテクトとしての最低限の責務だ。
—
3. パフォーマンスとスケーラビリティへの提言
Redis Streamsを極限まで使いこなすための、私からの「三つの指針」を提示する。
① パイプラインを信じるな、バッチを信じろ
`XREADGROUP` で1件ずつ処理するのは愚策だ。ネットワークRRT（往復時間）は、分散システムの最大のボトルネックである。`COUNT` オプションで一度に 50〜100 件のメッセージをフェッチし、アプリケーション側で並列処理を行うこと。
② Radix Treeの深さとメモリ効率
Redis StreamsはRadix Treeを利用している。IDにタイムスタンプ（例: `1672531200000-0`）を使用するのは非常に理にかなっている。時系列順にデータが挿入されるため、ノードの断片化が最小限に抑えられ、メモリキャッシュの局所性が最大化されるからだ。
③ 監視すべきは「ラグ」ではない、「PELの深さ」だ
運用指標として多くの者が「ストリームの長さ（LEN）」を見るが、それは本質的ではない。「`XPENDING` で滞留しているメッセージ数」こそが、システムが崩壊に向かっているかどうかを示す唯一の先行指標である。
—
結びに代えて
Redis Streamsは、分散キューとしての役割を完璧に果たすが、それは「魔法」ではない。内部でデータがどのようにフラグメント化され、メモリがどう確保され、どのタイミングで `PEL` がクリーンアップされるのか。このメカニズムを理解して初めて、あなたのシステムは真に耐障害性を備えることになる。
もし、あなたがこの説明を読んで「`XACK` を怠ることはシステムの死を意味する」と直感できたなら、あなたは既にRedisのアーキテクチャの本質を掴んでいる。
さあ、コードを書け。ただし、メモリの断片化とPELの追跡を忘れるな。
コメント