Redis Streams: ログ管理の理想と、その内部に潜む「メモリの深淵」
Redis Streams（`X`系コマンド）は、単なる「Redis版Kafka」などという陳腐な表現では到底括れない。これは、永続的なログ構造をメモリ上でいかに効率的に管理し、かつディスクI/Oのボトルネックをいかに回避するかという、データベースエンジン設計の粋が詰まった実装だ。
今日は、表面的なコマンド解説は捨て、Streamsを支える内部データ構造と、アーキテクトが知るべき「限界性能」を引き出すための設計指針を紐解く。
—
1. 内部構造：Radix Tree と Listpack の共生
まず理解すべきは、Redis Streamsが「単なる連結リスト」ではないという点だ。
- Radix Tree (Patricia Trie): ID（タイムスタンプとシーケンス番号）の検索を高速化するために用いられる。O(log N)の効率で特定のID範囲を特定する。
- Listpack: 複数のエントリを一つの連続したメモリブロックにパックする構造。以前の`ziplist`の課題であった「カスケード更新（連鎖的なメモリ再配置）」を解消し、メモリ効率とキャッシュローカリティを極限まで高めている。
Streamsにおける `XADD` は、単にデータを挿入するのではなく、このListpackを適切に分割（Split）し、Radix Tree上にインデックスを構築する作業だ。大量のデータを投入する際、メモリ使用量が想定以上に膨らむなら、それはエントリの断片化ではなく、この「ブロック単位での管理」によるオーバーヘッドを考慮できていない証拠である。
—
2. 破壊的な操作と設計のアンチパターン：XDELの真実
多くの開発者が `XDEL` を「削除コマンド」として安易に使用するが、これは設計上のトラップだ。
- 内部挙動: `XDEL` は実際にはエントリを即座にメモリからパージしない。内部的には「削除フラグ（Tombstone）」を立てるだけだ。
- アーキテクトの警告: 頻繁な `XDEL` は、メモリ効率を劇的に低下させる。もしログのライフサイクルを管理したいのであれば、`XDEL` ではなく `XTRIM` を使え。`XTRIM` はListpack単位での破棄を伴うため、メモリの再利用効率が圧倒的に高い。
1000エントリ以上を保持しないことで、Listpackの効率的な破棄をトリガーする
MAXLENを使用し、メモリの断片化を最小限に抑える設計が鉄則だ
XADD mystream MAXLEN ~ 1000 field value
—
3. レンジクエリの極意：XRANGE と XREVRANGE
ログの読み出しにおいて、`XRANGE` と `XREVRANGE` の使い分けは、CPUキャッシュの有効活用に直結する。
- XRANGE: 時系列の順方向スキャン。Radix Treeのリーフノードを順に辿る。
- XREVRANGE: 逆方向。これはRadix Treeの構造上、順方向よりも若干のオーバーヘッドが生じる可能性がある。
もしあなたが「最新のログを常に監視する」アーキテクチャを組むなら、`XREVRANGE` を無暗にループさせるのではなく、`XREAD` によるブロックモードを活用すべきだ。ポーリングはRedisへの無駄な負荷であるだけでなく、ネットワークのRTT（Round Trip Time）を浪費する。
タイムレンジを指定した効率的なフェッチ
IDの内部構造（timestamp-sequence）を理解し、クエリを最適化せよ
XRANGE mystream 1672531200000-0 + COUNT 100
コメント: タイムスタンプ部分を直接指定することで、Radix Treeの不要なノードを即座にスキップさせる
—
4. パフォーマンスの限界を突破する：XLEN の罠
`XLEN` は `O(1)` で動作する。これはRedisがストリーム全体の要素数を内部メタデータとしてキャッシュしているからだ。しかし、この数値を鵜呑みにしてはならない。
大規模システムでは、`XLEN` で取得した「全件数」と、実際に `XRANGE` で取得できる「有効なエントリ数」は、`XDEL` やトリミングのタイミングによって乖離する。厳密な整合性が求められるログ管理においては、IDの範囲指定による再集計を行うのが、エンジニアとしての矜持である。
—
結論：アーキテクトへの提言
Redis Streamsを使いこなすということは、「メモリの断片化と戦う」ことと同義だ。
1. メモリ配置を意識せよ: `XADD` の大量投入時には `MAXLEN` を指定し、Listpackが肥大化・断片化する前に切り捨てるサイクルを確立せよ。
2. 削除はトリミングで行え: `XDEL` は非常用。永続ログ管理における削除は、常に `XTRIM` で行うこと。
3. IOを減らせ: クエリは常に必要な範囲を最小限のID指定で行う。広範囲のスキャンはRedisのシングルスレッドを占有し、システム全体のレイテンシを悪化させる。
Redisは決して「ブラックボックス」ではない。内部でListpackがどう呼吸し、Radix Treeがどう枝を広げているか。その鼓動を感じながらコードを書く者だけが、このDBの真のパワーを解き放てる。
現場からは以上だ。次は、Consumer Groupの並列性とメモリ消費の相関について語るとしよう。
コメント