【実務・中級編】シングルスレッドイベントループ – Redis

Redisの「シングルスレッド」という名の戦略的孤高：なぜ私たちはこの制約を愛するのか

多くのエンジニアがRedisを「高速なKVS」と呼ぶ。だが、その本質を理解せずに使うのは、フェラーリを近所のコンビニへの買い物だけに使うようなものだ。

Redisの心臓部は、極めてシンプルかつ狂気的なまでに洗練された「シングルスレッド・イベントループ」で駆動している。なぜ現代のマルチコア全盛時代に、あえて単一スレッドに固執するのか。そして、その設計が我々のシステム設計にどのような制約と恩恵をもたらすのか。

今日は、表面的なドキュメントを飛び越え、アーキテクチャの深淵から語ろう。

—

1. 「ロック」という悪魔を物理的に排除する

マルチスレッドアーキテクチャにおいて、最も避けるべきは「共有メモリへのアクセス競合」だ。スレッドセーフを担保するためにミューテックス（Mutex）やスピンロックを多用すれば、コンテキストスイッチのオーバーヘッドとデッドロックの恐怖が付きまとう。

Redisは、「そもそも共有するな」という哲学を貫いた。

イベントループの隔離: 全てのコマンド処理は単一のスレッドでシリアライズされる。つまり、メモリ上のデータ構造（ハッシュ、リスト、ソートセット等）を操作する際、ロックの獲得・解放を一切考える必要がない。
アトミック性の保証: `INCR`や`LPUSH`といったコマンドが、外部から見ればアトミックに実行されるのは、この「直列処理」の副産物だ。

教訓: Redisでアプリケーション層の排他制御（分散ロック）を実装する場合、Redisのコマンドがアトミックであることを前提に設計する。だが、その「アトミックな操作」を連結させる必要がある時は、Luaスクリプトの出番だ。

—

2. Luaスクリプト：シングルスレッドの特権を最大限に活かす

LuaスクリプトはRedisのシングルスレッドモデルを最大限に活かすための「最強の武器」だ。

— Luaスクリプト例: 複数の操作を不可分（アトミック）に実行する
— 読み取りと書き込みを一度の実行単位としてRedisに送り込む
local current = redis.call(“GET”, KEYS[1])
if current and tonumber(current) > tonumber(ARGV[1]) then
return redis.call(“SET”, KEYS[1], ARGV[1])
else
return nil
end

このスクリプトが実行されている間、他のクライアントからのコマンドは完全にブロックされる。「他のリクエストが割り込めない」という性質は、競合状態を心配するエンジニアにとって究極の安心感を与える。

ただし、これは諸刃の剣だ。重い計算やループをLuaに書けば、Redis全体が停止する。これが「O(N)以上のコマンドを叩くな」という鉄則の理由だ。

—

3. なぜ「Redis 6.0+」でマルチスレッドが導入されたのか

「Redisはシングルスレッドである」という神話は、6.0で少しだけ修正された。IOスレッドの導入だ。

しかし、誤解してはならない。コマンドの実行（データ操作）は依然としてシングルスレッドだ。 6.0で導入されたマルチスレッドは、ネットワークIO（パケットの読み書き）を別スレッドで捌くためのものだ。

ボトルネックの転換: 近年のRedisはCPUよりもネットワーク帯域やメモリ帯域が先に限界に達する。IOをマルチスレッド化することで、Redisの最大の弱点であった「ネットワークIOの処理待ち」を解消したのだ。

—

4. 実務で「やってはいけない」アーキテクチャ

設計レビューで私がよく指摘するのは、以下のアンチパターンだ。

1. KEYSコマンドの乱用: `KEYS ` は実行された瞬間にイベントループを数秒間凍結させる可能性がある。本番環境では `SCAN` を使え。これは絶対だ。
2. 巨大なバリューの保持: 1つのキーに数メガバイトのデータを突っ込むな。シングルスレッドでのメモリコピーやメモリ割り当ては、イベントループの停止時間を増大させる。
3. ブロッキング操作の混入: `BLPOP` や `BRPOP` は適切に使えば強力だが、接続数やスレッド管理が甘いとコネクション枯渇を招く。

—

5. 結論：設計者の心得

Redisのシングルスレッドアーキテクチャは、「パフォーマンスの予測可能性」を我々に提供している。

マルチスレッドは、負荷が増大した時に「いつ、どのスレッドで競合が起き、どの処理がスタックするか」を予測するのが極めて困難だ。一方でRedisは、特定のコマンドがどれくらいの時間を食うかが物理的に予測できる。

「複雑な並行処理はアプリケーション層で解決し、Redisには極めて単純で高速なアトミック操作だけを委譲せよ。」

これが、Redisを使いこなすアーキテクトの唯一の正解だ。
君たちが書くコードが、Redisのイベントループを汚さないことを祈っている。もしレビューで不適切なコマンドを見つけたら、即座に修正を命じる。

さあ、設計に戻ろう。Redisのポテンシャルを最大限に引き出すのは、君たちの設計力だ。