Redis Streamの深層：実務で迷わないログ設計とパフォーマンスの極意
テックリードの私だ。コードレビューをしていると、未だに「とりあえずログだからList（LPUSH/RPOP）でいいか」「いや、RDBのテーブルに突っ込もう」という安易な設計を見かける。
だが、現代の分散システムにおいて、時系列イベントやメッセージキューの基盤としてRedisを本気で採用するなら、選ぶべきはStream型一択だ。Kafkaほど大げさにしたくない、しかしPub/Subのような「忘却の彼方に消えるメッセージ」では耐えられない。そんな絶妙な隙間を、Redis Streamは完璧に埋めてくれる。
今回は、Streamの基本操作である `XADD`, `XDEL`, `XLEN`, `XRANGE`, `XREVRANGE` を題材に、単なるコマンドのリファレンスではなく、「プロの現場でどう使い倒すか」という設計の急所を叩き込む。
—
1. Streamの本質：なぜListやZSETではダメなのか？
まず、頭を切り替えよう。
- List: ただのFIFO/LIFOだ。オフセット指定でのランダムアクセスは遅い（$O(N)$）。コンシューマーグループの概念もない。
- ZSET（Sorted Set）: スコア順にソートされるが、同一スコアの扱いが面倒であり、何より「メッセージの構造化（フィールド・バリューのペア）」がネイティブではない。JSONなどを詰め込むハメになる。
Streamは、「追記型（Append-only）のログでありながら、各エントリが一意なIDを持ち、マルチコンシューマーを前提としたストリーム処理基盤」として設計されている。
エントリIDの魔術
Streamの各エントリは、`
Redisが自動生成（“を指定）するため、ミリ秒単位の時系列順序が保証されるだけでなく、同一ミリ秒内に複数発火してもシーケンス番号で一意性と順序が完全に担保される。このIDの構造こそが、後述する範囲検索の強力な武器になる。
—
2. 基本コマンド群の「実務的」解釈と使い方
それでは、ログ管理のライフサイクルに沿って主要なコマンドを見ていこう。
`XADD`: 構造化ログのインジェクション
まずはログの書き込みだ。
センサーID「sensor-01」の温度データをStream「iot:logs」に追記する
を指定することで、Redisサーバー側でタイムスタンプベースのIDを自動付与させる
127.0.0.1:6379> XADD iot:logs sensor_id sensor-01 temperature 23.5 status OK
“1700000000000-0”
【プロの知見：MAXLENによるメモリ防衛線】
ログデータは放置すれば無限にメモリを食いつぶし、やばい事故を引き起こす。実務では、`XADD`の時点で `MAXLEN`（または `MINID`）を必ず検討すべきだ。
近似的な上限（~）を設け、古いエントリを自動パージさせながら書き込む
127.0.0.1:6379> XADD iot:logs MAXLEN ~ 10000 sensor_id sensor-01 temperature 24.1
完全な厳密さ（`MAXLEN 10000`）を指定するとパフォーマンスに影響が出るため、実務では `~`（Approximate）を使い、メモリ枯渇を防ぎつつパフォーマンスを維持するのが定石だ。
—
`XLEN`: ストリームの「現在の重み」を知る
単に現在のメッセージ数を確認する。
127.0.0.1:6379> XLEN iot:logs
(integer) 42
$O(1)$で実行できるため、ヘルスチェックやモニタリング用メトリクスとして気軽に叩いて構わない。
—
`XRANGE` & `XREVRANGE`: 時系列データのスライス
ログ管理において最も重要なのが範囲検索だ。`XRANGE`は古い順（正順）、`XREVRANGE`は新しい順（逆順）で取得する。
古い順に、特定のID範囲を指定して取得
127.0.0.1:6379> XRANGE iot:logs 1700000000000-0 1700000005000-0
【極意】最新のログを「直近5件」だけ取得したい場合
+ は無限大、- は負の無限大を表す。XREVRANGEとCOUNTの組み合わせは鉄板だ。
127.0.0.1:6379> XREVRANGE iot:logs + – COUNT 5
【コードレビューでの指摘ポイント】
「全件取得してアプリ側でスライスする」というコードを見かけたら、即座にリジェクトしてほしい。データ量が増えた瞬間にRedisのCPUが張り付き、ネットワーク帯域が爆発する。必ず `XRANGE` / `XREVRANGE` に `COUNT` を組み合わせて、ページング処理として実装すること。
—
`XDEL`: 「消去」に関する残酷な現実
「特定のログエントリを消したい」という要件で `XDEL` を使いたくなる気持ちはわかる。
127.0.0.1:6379> XDEL iot:logs 1700000000000-0
(integer) 1
しかし、アーキテクトとして警告しておく。`XDEL` は「エントリのIDポインタを削除済みとマークする」だけであり、即座にメモリが解放されるわけではない。
Streamの内部構造（Radix Tree）の特性上、個別の `XDEL` 多用はフラグメンテーションの原因になり得る。もし古いデータを消したいのであれば、前述の `XADD` 時の `MAXLEN` や、後続で解説する定期的な切り詰め（`XTRIM`）を活用するべきだ。個別削除が必要なビジネス要件なら、そもそもStreamではなくHashやRDBを使うべきシグナルである。
—
3. 実践：堅牢なログ管理・参照システムの設計パターン
では、これらのコマンドを組み合わせて、実務で耐えうる「時系列ログバッファ」のパターンを構築しよう。
パターン：直近N件のダッシュボード用APIバックエンド
Webダッシュボードで「直近のシステムエラーログを最大50件表示する」という要件を想定する。
import redis
client = redis.Redis(host=’localhost’, port=6379, decode_responses=True)
def fetch_recent_error_logs(limit=50):
“””
XREVRANGEを使い、最新のログから効率的に指定件数取得する
“””
# ‘+’ は最も新しいID、 ‘-‘ は最も古いIDを意味する
logs = client.xrevrange(‘system:errors’, max=’+’, min=’-‘, count=limit)
formatted_logs = []
for entry_id, fields in logs:
formatted_logs.append({
“id”: entry_id,
“timestamp”: entry_id.split(‘-‘)[0],
fields # フィールドの展開
})
return formatted_logs
この実装の美しい点は、Redis側でソートとスライスが完了しているため、アプリケーションサーバー側でメモリやCPUを無駄に消費しないことだ。データが100万件にスケールしようとも、`COUNT 50` であればレスポンスタイムは常に一定（$O(N)$ where $N=50$)を維持する。
—
4. パフォーマンス上の注意点（チーフからの最後のアドバイス）
1. 巨大なStreamを作らない
1つのStreamキーに数千万件のエントリを詰め込んではならない。メモリ効率が悪化し、リサイズ時のレイテンシスパイクを招く。日付ごと（例: `iot:logs:2023-11-20`）にキーを分割するか、適切な `MAXLEN` を設定して常にスリムに保つこと。
2. ブロッキング操作（XREAD / XREADGROUP）への布石
今回は基本操作に絞ったが、Streamの真価は「コンシューマーグループ」を用いたメッセージングにある。今回学んだ `XADD` でデータを積み、必要に応じて `XREAD` や `XREADGROUP` でコンシューマーにプッシュ（またはプル）していくことで、堅牢な非同期処理パイプラインが完成する。
総括
Redis Streamは、適切に使えばシステム全体のスループットを劇的に引き上げるキラー機能となる。
コマンドをただ覚えるのではなく、「データがどう流れ、どこに溜まり、どうパージされるか」のライフサイクル全体を頭に描きながら設計してほしい。
君たちの次のアーキテクチャレビューを楽しみにしている。
コメント