【実務・中級編】 PEXPIREコマンド – Redis

Redisのミリ秒精度の罠と真実：`PEXPIRE`を制する者がキャッシュ戦略を制す

おい、設計レビューを始めるぞ。

今、お前らが提出したセッション管理とレートリミッターのシーケンス図を見ている。キャッシュの有効期限（TTL）の設定に `EXPIRE`（秒単位）を平然と使っているな。
「これで十分だ」と思ったか？甘い。

ミリ秒単位の緻密な制御が求められる現代の分散システムにおいて、秒単位の粗いTTL設計は、高負荷時に致命的な競合やメモリリークを引き起こす。ここで登場するのが `PEXPIRE` だ。

今回は、Redisのデータ構造とメモリ管理の深部まで潜り込み、`PEXPIRE` をいかにしてプロダクションレベルで正しく、かつ極限まで効率的に使い倒すか、その全知見を授ける。

—

1. `PEXPIRE` の基本メカニズムと `EXPIRE` との決定的な違い

まず、Redisの内部表現を思い出せ。Redisのキー空間は、すべてのキーと値のメタデータをハッシュテーブルで管理している。そして、有効期限を持つキーは、通常のキー空間とは別に 「expires dictionary（有効期限辞書）」 というメタデータ領域で管理されている。

`EXPIRE` と `PEXPIRE` の違いは、単に「引数が秒かミリ秒か」だけではない。

`EXPIRE key seconds`: 内部的にミリ秒へ変換されるが、APIの入力インターフェースが秒単位。
`PEXPIRE key milliseconds`: ミリ秒単位での絶対的な精度で期限を直指定する。

なぜ「ミリ秒」が必要なのか？

秒単位では、例えば「1.5秒後に失効させたい」「高頻度トレーディングのオーダーバッファ（有効期限500ms）」といったユースケースに対応できない。また、分散ロックのリース期間（Lock TTL）において、秒単位の誤差はスプリットブレインやデッドロックの原因となる。`PEXPIRE` は、この「ミリ秒の境界線」を完全に制御するためのコマンドだ。

—

2. 実務におけるユースケース：ミリ秒が命運を分ける瞬間

コードレビューでよくあるアンチパターンとして、「ミリ秒単位の制御が必要なのに、アプリケーション側で計算して `EXPIRE` に秒単位で丸めて渡す」という実装がある。これでは精度が粗すぎて使い物にならない。

実務で `PEXPIRE` が必須となる代表的なパターンを2つ挙げよう。

パターンA: 高精度分散ロック（Redlock系アルゴリズムの微調整）

スレッドやプロセス間の排他制御を行う際、ロックの自動解放時間をミリ秒単位で設定する必要がある。

import redis
import time

client = redis.Redis(host=’localhost’, port=6379, db=0)

def acquire_lock_with_pexpire(lock_key, client_id, ttl_ms):
Acquires a lock with millisecond precision using PEXPIRE.
# NX: キーが存在しない場合のみ設定, PX: ミリ秒単位のTTL
acquired = client.set(lock_key, client_id, px=ttl_ms, nx=True)
return acquired

500ミリ秒（0.5秒）で自然消滅するクリティカルセクション用ロック
lock_acquired = acquire_lock_with_pexpire(“lock:order:9921”, “worker-node-01”, 500)
if lock_acquired:
try:
# 処理を実行
pass
finally:
# 実際にはLuaスクリプトで原子性を担保してDELするべき
pass

※注：内部的に `SET … PX` は `PEXPIRE` と同等のミリ秒有効期限設定をアトミックに行う。

パターンB: マイクロバッチのウィンドウ制御・APIレートリミッター

APIの連打を防ぐスロットリングにおいて、例えば「直近200ミリ秒間に3回まで」といったバースト制御を行う場合、キーの生存期間をミリ秒単位で更新・管理する必要がある。

—

3. パフォーマンス上の注意点：O(1)の幻想とバックグラウンド処理

Redisのコマンドリファレンスには、`PEXPIRE` の時間計算量は `O(1)` と書かれている。
しかし、現場のエンジニアならこう疑うべきだ。「本当に、常に純粋な O(1) なのか？」と。

1. メモリの遅延削除（Lazy Deletion）のコスト

Redisは、期限切れになったキーを即座に全削除するわけではない。以下の2つのアプローチでメモリを解放している。

パッシブ削除: クライアントがキーにアクセスした際、期限切れであればその場で削除する。
アクティブ削除: Redisのバックグラウンドタスク（デフォルトで1秒間に10回＝100msごとに実行）が、期限切れ辞書からランダムにキーをサンプリングし、期限切れのものを削除する。

大量のキーに対して一斉に `PEXPIRE` を設定し、それらがまったく同じミリ秒に一斉に失効するように設計してしまうとどうなるか？
アクティブ削除のサイクルで一度に膨大なキーの削除が発生し、主スレッドがブロック（レイテンシアイクスパイク）を引き起こす。

> 【チーフアーキテクトからの教訓】
> ミリ秒単位で一斉に期限切れを迎えるキーを大量に作るな。負荷を分散させるために、TTLにランダムな揺らぎ（Jitter）を持たせる設計を徹底しろ。

—

4. 堅牢な設計パターン：コードレビューの視点

ここで、俺が実際のレビューで即座にリジェクトするコードと、合格とするコードを示そう。

❌ 悪い設計（レビュー却下）

ユーザーごとのAPIコール制限：一律で綺麗に1000msを設定
def rate_limit_bad(user_id):
key = f”rate:{user_id}”
current = client.incr(key)
if current == 1:
# 常に一斉に失効するため、1秒後にパージ負荷のピークが来る
client.pexpire(key, 1000)

理由: ユーザーがアクセスした瞬間に綺麗に1000msがセットされるため、アクセスが集中した時間帯からちょうど1秒後に「消去の嵐」が起き、CPU使用率が跳ね上がる。

⭕ 優れた設計（本番推奨）

import random

def rate_limit_robust(user_id):
key = f”rate:{user_id}”
pipe = client.pipeline()
pipe.incr(key)
pipe.pttl(key) # 現在の残りTTLを確認
results = pipe.execute()

current = results[0]
if current == 1:
# ジッター（揺らぎ）を付与：900ms〜1100msの間に散らす
jitter_ms = random.randint(-100, 100)
client.pexpire(key, 1000 + jitter_ms)

理由: 有効期限にミリ秒単位の揺らぎ（Jitter）を入れることで、期限切れのイベントが時間軸上に綺麗に分散され、Redisのシングルスレッドイベントループへの負荷を平準化できる。

—

5. まとめ：Redisのミリ秒を支配する者

`PEXPIRE` は、単に「細かい時間で消すためのコマンド」ではない。
分散システムのタイミング同期、リソースの競合回避、そしてRedisのシングルスレッド特性を理解した上での「負荷分散のコントロールポイント」だ。

秒単位で足りない要件には迷わず `PEXPIRE`（または `SET` の `PX` オプション）を使え。
しかし、ミリ秒の精度にこだわりすぎて「同一時刻の大量失効（Thundering Herd）」を生まないよう、必ずジッターを考慮しろ。

プロのアーキテクトなら、APIの仕様書を見るだけで、その背後にあるRedisのメモリ上の挙動までビジュアライズできなければならない。
次のレビューでは、このレベルの設計思想がコードに表れていることを期待する。

さて、手を動かそうか。