PEXPIREの深層：ミリ秒精度の裏側と、大規模分散系における時間統治の限界
Redisを単なる「インメモリKVS」と呼ぶ者は、その本質を見誤っている。Redisは、極限まで最適化された「インメモリデータ構造オペレーティングシステム」であり、その心臓部は時間（Time）の制御機構にあると言っても過言ではない。
多くのエンジニアは、キーの有効期限設定といえば `EXPIRE`（秒単位）を思い浮かべるだろう。しかし、ミリ秒単位の精度の要求される高スループットなシステム、あるいは分散ロックやセッションの厳密なライフサイクル管理において、`PEXPIRE` は避けて通れないプリミティブである。
今回は、この `PEXPIRE` コマンドを単なるAPIの使い方としてではなく、Redisの内部アーキテクチャ、メモリ構造、そしてC言語レイヤのイベントループに至るまで、極限の低レイヤ視点から解剖する。
—
1. `PEXPIRE` の基本とレイヤード・シグネチャ
まずは定義を確認する。`PEXPIRE` は、指定したキーに対してミリ秒単位の生存期間（Time To Live: TTL）を設定する。
キー “session:token:42a9” に 1500ミリ秒（1.5秒）のTTLを設定
127.0.0.1:6379> PEXPIRE session:token:42a9 1500
(integer) 1
戻り値が `1`であれば有効期限の設定成功、`0`であればキーが存在しない、または設定に失敗したことを示す。
内部表現：なぜミリ秒が必要なのか
Redisの内部において、キーの有効期限は `redisDb` 構造体内の `expires` という辞書（Dict）によって管理されている。
キーそのものを指すポインタと、ミリ秒単位のUnixタイムスタンプ（`long long`型）がマッピングされているのだ。
// Redisの内部構造体（概念モデル）のイメージ
typedef struct redisDb {
dict dict; // すべてのキーとバリューを保持する辞書
dict expires; // 有効期限を持つキーと、失効時刻（ミリ秒）を保持する辞書
// … その他のフィールド
} redisDb;
`EXPIRE`（秒）を使おうが `PEXPIRE`（ミリ秒）を使おうが、Redis内部の `expires` 辞書に格納される値の解像度は、最終的にはミリ秒（あるいはそれ以上）の絶対時刻に正規化される。しかし、APIとして `PEXPIRE` を叩く意味は、クライアント側からミリ秒オーダーのジッター（揺らぎ）を許容しない厳密なライフサイクルを駆動できる点にある。
—
2. 内部メカニズム：期限切れはどのように「検知」されるのか
ここで、多くのエンジニアが犯す最大の誤解に言及しておかねばならない。
「Redisは、PEXPIREで指定したミリ秒が経過した瞬間に、バックグラウンドスレッドがキーを即座にパージする」というのは幻想である。
Redisはシングルスレッド（正確にはメインのイベントループはシングルスレッド）で動作している。数百万のキーに対してタイマー割り込みを毎ミリ秒発生させるような設計は、CPUキャッシュの効率を破壊し、スループットを壊滅させる。
では、どのように期限切れを処理しているのか？ Redisは以下の2つのアプローチをハイブリッドで採用している。
① パッシブ・エクスパイレーション（受動的削除）
クライアントがそのキーにアクセスしようと `GET` や `HGET` などのコマンドを発行した瞬間、Redisは対象キーの `expires` 辞書をチェックする。
もし現在時刻が失効時刻を過ぎていれば、その場でキーは削除され、キーが存在しないかのように振る舞う。
② アクティブ・エクスパイレーション（能動的削除 / 惰性削除）
アクセスされないまま放置された期限切れキーがメモリを圧迫し続けるのを防ぐため、Redisはバックグラウンドで定期的に（デフォルトでは毎秒10回＝100msごとに）以下のアルゴリズムを実行する。
1. `expires` 辞書からランダムに 20個 のキーをサンプリングする。
2. サンプリングされたキーのうち、期限切れになっているものをすべて削除する。
3. 期限切れだったキーの割合が 25%を超えている場合、即座にステップ1に戻る。
この仕組みを理解していれば、`PEXPIRE` でミリ秒単位の細かい期限を設定したとしても、アクセスされないキーのメモリ解放は最大で100ms（あるいはアクティブ削除のバッチ処理サイクル）の遅延を持ち得るというアーキテクチャ上の制約が見えてくるはずだ。
—
3. 実務における罠：レプリケーションと永続化（RDB/AOF）のタイムラグ
高可用性（HA）構成やクラスタ環境において、`PEXPIRE` を扱う際には「時間」の扱い方に細心の注意が必要となる。
マスター・レプリカ間の不整合
Redisのレプリケーションにおいて、マスターはキーを削除したとき、あるいは `PEXPIRE` を受け取ったときに、レプリカへ `DEL` や `PEXPIRE`（内部的には絶対時刻に変換された `PEXPIREAT`）のコマンドを非同期で伝播させる。
ここで問題になるのが 「時計のズレ（Clock Drift）」 である。
マスターとレプリカのOSのシステムクロックがNTP等で完全に同期していない場合、ミリ秒単位で設定した有効期限の切れ方に微妙なズレが生じる。特に、フェイルオーバーが発生してレプリカがマスターに昇格した瞬間、予期せぬタイミングでキーが生存していたり、逆に早く消失したりする現象に直面する。
AOF（Append Only File）の記録メカニズム
AOFファイルに書き出される際、`PEXPIRE` はそのまま記録されるのではなく、失効する絶対ミリ秒タイムスタンプを持つ `PEXPIREAT` に変換されて記録される。
AOFに記録される際のイメージ
3
$9
PEXPIREAT
$16
session:token:42a9
$13
1718012400500
これにより、AOFのリプレイ時にコマンド実行時点からの相対時間を計算し直す必要がなくなり、再起動時の時間のズレを最小限に抑えることができる。
—
4. 極限の最適化：Luaスクリプトと `PEXPIRE` の原子性
ミリ秒単位の厳密な制御が必要なケース（例：レートリミッターや分散ロックの延長）では、複数のコマンドをアトミックに実行する必要がある。
例えば、「キーが存在し、かつ現在のTTLが特定の範囲内の場合のみ、`PEXPIRE` で延長する」という処理を考えてほしい。これを通常のクライアント側からの複数コマンドで行うと、レースコンディションが発生する。
ここで投入すべきが、Redisサーバー内で実行される Luaスクリプト である。
— Luaスクリプト例: 指定したキーが存在し、TTLが設定されている場合にミリ秒単位で延長する
local key = KEYS[1]
local extension_ms = tonumber(ARGV[1])
— 現在のTTLを取得（ミリ秒）
local current_ttl = redis.call(‘PTTL’, key)
if current_ttl > 0 then
— TTLが存在する場合のみ、PEXPIREを適用
return redis.call(‘PEXPIRE’, key, current_ttl + extension_ms)
else
— キーが存在しないか、TTLがない場合は何もしない
return 0
end
このスクリプトを `EVAL` コマンドで実行することで、Redisのシングルスレッドモデルの恩恵を受け、他のクライアントからの割込みを完全に排除したアトミックなミリ秒単位の期限操作が担保される。
—
5. チーフアーキテクトからの提言
`PEXPIRE` は、単に「細かい期限が設定できる便利なコマンド」ではない。
これは、「限られたメモリ空間上で、エントリのライフサイクルをミリ秒オーダーの解像度で自律的に調停するための低レイヤAPI」である。
大規模な分散システムを設計する際、われわれエンジニアは常に「ネットワークの遅延」「クロックの不完全性」「ガベージコレクションやイベントループのブロック」という物理的な制約と戦っている。ミリ秒精度の `PEXPIRE` を過信し、厳密なリアルタイム処理のタイマーとして依存してはならない。
真に堅牢なアーキテクチャとは、Redisの持つパッシブ/アクティブ削除の特性やレプリケーションの挙動を深く理解し、仮に期限切れの検知が数ミリ秒〜数百ミリ秒遅延したとしても、システム全体として整合性が保たれるように設計されたシステムのことである。
道具の仕様を知るな。道具の背後にある物理的・論理的制約を支配せよ。それこそが、真のエンジニアリングである。
コメント