【実務・中級編】 List型：基本操作 – Redis

Redis List型を舐めてはいけない：双方向連結リストの裏側と、実務で絶対に踏み抜けない設計アンチパターン

テックリードの私だ。コードレビューやアーキテクチャ設計レビューを見ていると、RedisのList型（`LPUSH`, `RPUSH`, `LPOP`, `RPOP`, `LLEN`）を「ただの配列の代わり」「とりあえずキューに使える便利な箱」として思考停止で実装しているコードに遭遇することがよくある。

「データの出し入れができるから動く」――それはプロトotypes（試作品）の段階の話だ。
本番環境で数百万件のデータが流れ込み、メモリが枯渇し、レイテンシがスパイクした時、「なぜ動かないのか分からない」と絶望したくないなら、RedisのList型が内部でどう息をし、どうメモリを喰い潰しているのかを正確に理解しなければならない。

今回は、RedisのList型のプリミティブな操作を深掘りし、スタックやキューとしての正しい実務活用法、そして絶対に踏み抜いてはならないパフォーマンスの罠を、容赦なく叩き込む。

—

1. そもそもRedisのListとは何か？（内部構造の真実）

まず、基礎の認識をアップデートしよう。RedisのListは、名前に反して、実は「純粋な双方向連結リスト（Linked List）」だけではない。

バージョン2.2以降、RedisはList型の内部表現として Quicklist（クイックリスト） という高度なデータ構造を採用している。
Quicklistとは何か？一言で言えば、「双方向連結リストと、圧縮されたチャンク（Ziplist / 厳密にはRedis 7.0以降はListpack）のハイブリッド」だ。

個々のノードが双方向ポインタで繋がれている。
しかし、各ノードの中身は単なる1要素ではなく、複数の要素をメモリ上に連続してパッキングした塊（バッファ）になっている。

なぜこのような面倒な構造にしているのか？
純粋な連結リストは、要素の追加・削除（`O(1)`）には強いが、メモリ効率が最悪だ。ポインタを維持するために膨大なオーバヘッド（メモリの断片化）が発生する。逆に配列はメモリ効率が良いが、途中の挿入・削除にコストがかかる。
Quicklistはこのジレンマを解決し、「メモリ効率を最大化しつつ、両端の操作を高速に行う」という魔改造を施した代物なのだ。

—

2. 基本操作の解剖：O(1)の魔力とLLENの落とし穴

提供されている基本コマンドは極めてシンプルだ。

`LPUSH / RPUSH`: リストの左（先頭）/ 右（末尾）への要素追加
`LPOP / RPOP`: リストの左 / 右からの要素取り出し＆削除
`LLEN`: リストの長さ取得

これらの計算量（Time Complexity）は、基本的に $O(1)$ である。
なぜなら、双方向連結リストのヘッドとテールへのポインタをRedisは常にメモリ上で保持しているため、要素数が10個だろうが1,000万個だろうが、追加・削除の速度は一瞬（数マイクロ秒オーダー）だからだ。

ただし、`LLEN` には注意しろ

「リストの長さを測るだけだから `LLEN` は安全」――そう思っていないか？
Redisのインメモリデータ構造において、`LLEN` はQuicklistのメタデータ（要素カウンター）を参照するだけなので $O(1)$ で動作する。数百万件あっても瞬時に返る。
だが、後述する「アンチパターン」でリストが肥大化した際、その「長さ」を頻繁に監視する設計自体が、スケーラビリティのボトルネックになることがある。数値を監視したいなら、List自体の長さではなく、カウンタ用の別キー（AtomicなINCR/DECR）を検討すべきケースもある。

—

3. 実務での活用パターン：堅牢なスタックとキューの実装

では、具体的なユースケースを見ていこう。メモリ効率と速度を活かした王道の使い方だ。

パターンA：FIFOキュー（先入れ先出し）

メッセージングのバッファや、非同期タスクのエンキュー・デキューに使われる。
「右から入れて、左から出す（RPUSH + LPOP）」、あるいはその逆。

プロデューサー側：タスクを右端に追加
127.0.0.1:6379> RPUSH task:queue “task_id_1001”
(integer) 1

ワーカー側：左端からタスクを取り出して処理
127.0.0.1:6379> LPOP task:queue
“task_id_1001”

パターンB：LIFOスタック（後入れ先出し）

「直近の操作履歴」「ブラウザの戻る機能のスタック」など。
「左から入れて、左から出す（LPUSH + LPOP）」。

ページ閲覧履歴を左側に追加していく
127.0.0.1:6379> LPUSH user:100:history “/settings”
(integer) 1
127.0.0.1:6379> LPUSH user:100:history “/profile”
(integer) 2

直近の履歴を取得（POPせずに覗き見る場合は LINDEX 0 も使えるが、消費するなら LPOP）
127.0.0.1:6379> LPOP user:100:history
“/profile”

—

4. 【重要】実務で絶対に避けるべき設計アンチパターン

ここからが本題だ。私がコードレビューで一刀両断するポイントを授けよう。

🚨 アンチパターン1：要素数が無限に膨れ上がる「ゴミ屋敷」リスト

「とりあえずデータを溜めておこう」と、`LPUSH` し続けて `LPOP` するのを忘れたり、削除処理が追いつかなくなったりするシステムが多すぎる。
Redisはメモリデータベースだ。RAMの容量を超えた瞬間、OSのOOM Killerに殺されるか、maxmemory設定によって古いデータが勝手に eviction（削除）されるか、あるいは書き込みが拒絶される。

【対策】Capping（要素数の上限管理）を徹底せよ
リストにデータを突っ込むときは、同時に `LTRIM` コマンドを組み合わせて、常にリストの最大長を制限しろ。例えば「直近100件のログだけ保持する」場合：

新しいログを左に追加
LPUSH app:logs “error: database connection failed”

常に最新の100件（インデックス0から99まで）だけを残し、他は切り捨てる
LTRIM app:logs 0 99

この `LPUSH` + `LTRIM` のコンボは、時系列データの直近バッファリングにおける黄金律だ。トランザクション（`MULTI / EXEC`）や Luaスクリプトでアトミックに実行するのが鉄則である。

🚨 アンチパターン2：インデックス直接指定の暴力（`LINDEX` / `LSET` の乱用）

RedisのListは「配列」ではないと心せよ。
`LINDEX key index`（指定インデックスの要素取得）や `LSET` は、実は $O(N)$（厳密には $O(index)$、端から数えていく必要がある）のコストがかかる場合がある。Quicklist構造をたどって該当のチャンクまでシークしなければならないからだ。

リストのサイズが数万、数十万件ある状態で、`LINDEX key 50000` のようなアクセスを頻発させる設計にしているエンジニアがいたら、今すぐそのキーの設計をRDBかSorted Set（ZSET）に変更させろ。
「Listの真価を発揮できるのは、両端（Head/Tail）の操作のみである」。これ絶対のルール。

—

5. テックリードからの最終提言

RedisのList型は、刃物と同じだ。使い方を誤ればシステム全体をクラッシュさせる凶器になるが、その特性（メモリ効率と両端アクセスの爆速性）を正しく理解していれば、これほど頼りになるインメモリ・プリミティブはない。

両端（Push/Pop）以外の操作をさせようとするな。
常に上限（LTRIM等）を意識し、無限肥大化を防げ。
重いインデックスアクセスが必要なら、迷わず ZSET や Hash を選べ。

次の設計レビューでは、これらの原則がコードに体現されているか、私が厳しくチェックさせてもらう。健闘を祈る。