Redisを極める者への扉：`redis.call` の真髄と、プロダクション環境で事故らないための設計作法
こんにちは。テックリードの私だ。
今日のコードレビューで、また「なんとなく動く」だけの危険なLuaスクリプトを見かけた。
「Redisの処理をアトミックにしたいからLuaを書きました。中に `redis.call` を並べておけば安全ですよね？」と彼は言った。
……甘い。実戦のトラフィックを舐めてもらっては困る。
RedisのLuaスクリプト内における `redis.call` は、単なるコマンド実行のラッパーではない。正しく扱えばシステムを救う強力な武器となるが、一歩間違えばクラスタ全体を巻き込む時限爆弾に化ける。
今回は、`redis.call` の挙動の裏側、エラーハンドリングの真実、そしてエンタープライズ環境で耐えうる堅牢な設計パターンについて、私の知見のすべてを叩き込む。
—
1. `redis.call` とは何か：そのメカニズムと絶対的ルール
まず前提を揃えよう。`redis.call` は、Luaスクリプトの実行コンテキストからRedisのコマンドを同期的に呼び出すための関数だ。
最大の特性は、「コマンド実行時にエラーが発生した場合、即座にLuaスクリプトの実行を中断し、呼び出し元にLuaのエラー（Ruby/Python等でいう例外）をスローする」点にある。
— 例：存在しないキーに対して不正な操作を試みる
local val = redis.call(‘GET’, KEYS[1])
— もしvalが想定外の型であればここで処理を止めたい、といった場合
redis.call(‘HSET’, KEYS[2], ‘field’, val) — ここで型エラーが起きれば即死する
`redis.pcall` との決定的な違い
ここで思い出してほしいのが `redis.pcall` だ。こちらはエラーをスローせず、Luaのテーブル形式（`{ err = “…” }`）でエラーを返す。
「じゃあ安全のために全部 `pcall` にすればいいのでは？」と思ったそこのあなた。それは設計の放棄だ。
- `redis.call`: 予期せぬ異常系で即座に処理をアボートし、中途半端な状態でのコミットを防ぎたいとき（Fail-Fastの原則）に使う。
- `redis.pcall`: エラーをあえてキャッチし、Lua側でフォールバック処理やリトライを書きたいときだけに限定すべきだ。
—
2. 実務で直面する「やってはいけないアンチパターン」
コードレビューで私が一喝する典型的なアンチパターンを挙げておく。
アンチパターン①：ループ内での無謀な `redis.call` 連打
Luaスクリプトを使う最大の理由は「ネットワークラウンドトリップの削減」と「アトミシティ（原子性）」のはずだ。しかし、スクリプト内で数千回の `redis.call` を回すコードを時々見かける。
Redisはシングルスレッドで動いている。複雑なLuaスクリプトがCPUを占有している間（デフォルトでは `lua-time-limit` の5秒間）、Redisインスタンス全体が完全フリーズする。他のすべてのクライアントのリクエストがブロックされる地獄絵図だ。
アンチパターン②：キーの動的生成とルーティングの破壊
Redis Cluster環境下で、スクリプト内で `KEYS` 引数を使わずに、適当な文字列結合でキーを動的生成して `redis.call` に渡していないか？
Clusterはキーのハッシュスロットに基づいてルーティングを行う。スクリプトの冒頭で宣言された `KEYS` 以外のキーを勝手に操作すると、クロススロットエラーが発生するか、最悪の場合クラスタのデータ整合性が崩壊する。
—
3. 実践：堅牢な設計パターン（アトミックなレートリミッター）
では、実務でどう書くべきか。
「トークンバケットアルゴリズム」をベースにした、極めて堅牢なレートリミッターのLuaスクリプトを提示しよう。`redis.call` の戻り値を厳密に検証し、予期せぬデータ構造の崩壊から身を守る実装だ。
— KEYS[1]: レートリミット対象のキー
— ARGV[1]: 許可する最大リクエスト数 (Capacity)
— ARGV[2]: 補充レート（秒間あたりの回復量、今回は簡略化のため固定値消費とする）
— ARGV[3]: 現在のタイムスタンプ (Epoch seconds)
local key = KEYS[1]
local max_tokens = tonumber(ARGV[1])
local now = tonumber(ARGV[2])
— 現在の状態を取得
local bucket = redis.call(‘HMGET’, key, ‘tokens’, ‘last_updated’)
local tokens = tonumber(bucket[1])
local last_updated = tonumber(bucket[2])
if tokens == nil then
— 初回アクセス時は初期化 (Fail-Safeな初期値設定)
tokens = max_tokens
last_updated = now
end
— ここでビジネスロジックの計算
if tokens > 0 then
tokens = tokens – 1
— 状態を更新
redis.call(‘HMSET’, key, ‘tokens’, tokens, ‘last_updated’, now)
— 有効期限を明示的に設定（メモリリーク防止の鉄則）
redis.call(‘EXPIRE’, key, 60)
return 1 — 許可
else
return 0 — 拒否（レートリミット超過）
end
このコードの美しいポイント
1. 厳密な型変換: `redis.call` の返す値はRedisの型からLuaの型に自動変換されるが、計算に使う前には必ず `tonumber()` で安全性を担保している。
2. TTLの強制: 永続化ストレージではない一時的なカウンターであっても、`redis.call(‘EXPIRE’, …)` をセットで呼び出すことで、ゴミデータによるメモリ圧迫を防いでいる。
—
4. パフォーマンスと運用の極意
最後に、チーフアーキテクトとして運用上の絶対的な知見を共有する。
1. スクリプトの事前ロード (`SCRIPT LOAD` と `EVALSHA`)
毎回 `EVAL` でスクリプトのソースコード全体をネットワーク経由で送信してい無いか？ スクリプトが数KBある場合、ネットワーク帯域の無駄であり、パースコストもバカにならない。
プロダクションでは、デプロイ時に `SCRIPT LOAD` でスクリプトをRedisに常駐させ、アプリケーションからは `EVALSHA`（SHA1ハッシュを指定して実行）を使うこと。`redis.call` のパフォーマンスを限界まで引き出すための基本だ。
2. 非同期レプリケーションへの配慮
RedisのLuaスクリプトは、マスターで実行された結果がそのままスレーブやAOF（Append Only File）に伝播する（非決定的な処理、例えば `TIME` や `MATH.random` をそのまま使うとレプリケーションが崩壊する）。
`redis.call` の中で時刻やランダム値を生成してはならない。必要な値は必ずアプリケーション側から `ARGV` として注入せよ。これは鉄則だ。
—
結びにかえて
`redis.call` は、Redisという超高速なメモリデータベースのポテンシャルを極限まで引き出すための「劇薬」だ。
その挙動とエラーの伝播メカニズムを正確に理解し、防衛的なコードを書くこと。それこそが、障害に強い堅牢な分散システムを作り上げるエンジニアの矜持である。
今日のレビューからは、甘えたコードはすべて容赦なく弾く。
さて、コードを修正してもらおうか。
コメント