Redisチーフアーキテクトが説く、`redis.pcall`の真髄：堅牢なLuaスクリプト設計の極意
こんにちは。システムアーキテクチャのレビューをしていると、未だに「とりあえず `redis.call` を使っておけば動く」という安易なコードに遭遇することがある。
RedisのLuaスクリプト（EVAL / EVALSHA）は、複数コマンドをアトミックに実行するための強力な武器だ。しかし、トランザクションの途中で予期せぬエラーが発生したとき、その場しのぎのエラーハンドリングではシステム全体を巻き込む障害に繋がりかねない。
今回は、Redisにおけるエラーハンドリングのゲームチェンジャーである `redis.pcall` に焦点を当てる。標準の `redis.call` と何が決定的に違うのか、そして本番環境で「落ちないスクリプト」を書くための設計パターンを、アーキテクトの視点からロジカルかつシャープに伝授しよう。
—
1. `redis.call` vs `redis.pcall`：その決定的な違い
まずは前提を揃えよう。どちらもRedisのコマンドをLuaスクリプト内から実行するための関数だが、エラー時の挙動が根本的に異なる。
- `redis.call(command, …)`
- コマンドの実行に失敗した場合（例：型ミスマッチ、存在しないキーへの不正操作）、Luaのランタイムエラーをスロー（raise）する。
- スクリプトは即座に中断され、それまでの変更は（通常はトランザクションの性質上）ロールバックされ、呼び出し元にエラーが返る。
- `redis.pcall(command, …)`
- （Protected Callの略）コマンドが失敗しても、例外をスローせず、エラー情報を含んだテーブル（エラーオブジェクト）を返す。
- スクリプトは中断されず、次の行へ処理を継続できる。
百聞は一見にしかず。REPLでの挙動の違いを確認しよう。
— 【redis.callの挙動】
— 文字列型に対してハッシュ系のコマンドを実行（当然エラーになる）
local res1 = redis.call(‘HGET’, ‘string_key’, ‘field’)
— ここでスクリプトの実行が強制終了し、以降のコードは実行されない
return res1
— 【redis.pcallの挙動】
local res2 = redis.pcall(‘HGET’, ‘string_key’, ‘field’)
if type(res2) == ‘table’ and res2.err then
— エラーオブジェクトを検知し、安全にフォールバック処理を行える
return “Handled error gracefully: ” .. res2.err
end
return “Success”
この「例外を飛ばさずに戻り値として受け取れる」という特性こそが、実務における高度なエラーハンドリングの基盤となる。
—
2. なぜ実務で `redis.pcall` が必要なのか？
「エラーが起きたらそのままスクリプトを落として、クライアント側でハンドリングすればいいのでは？」
そう思ったそこのあなた。甘い。
大規模分散システムにおいて、RedisのLuaスクリプトは「アトミックに完了すべき極小のビジネスロジック」として実装されることが多い。ここで以下の課題に直面する。
1. 部分的な失敗の許容（フォールバック）:
メインの処理（例：キャッシュの更新）が何らかの理由でコケても、ログの記録やカウンターのインクリメントといった周辺処理（サイドエフェクト）だけは完遂させたい場合。
2. クリーンアップ処理の保証:
処理の途中でリソースのロック取得や一時的なキーの作成を行った後、予期せぬエラーを踏んだ場合でも、確実に後始末（ロック解放など）を行ってから終了したい場合。
`redis.pcall` なしでは、これらを安全に記述することは不可能に近い。
—
3. 実践：堅牢な設計パターン（分散ロックの安全な解放）
実務で最もよくあるアンチパターンは、分散ロックの解放処理で `redis.call` を使い、キーの型不一致や想定外の状態でスクリプトがクラッシュし、デッドロックを誘発するケースだ。
以下に、`redis.pcall` を駆使して「絶対に途中で止まらない」堅牢なリソース解放スクリプトの設計パターンを示す。
シナリオ：所有権を検証した上での安全なキー削除とメトリック記録
— KEYS[1]: 対象のロックキー
— ARGV[1]: クライアント固有のトークン（UUIDなど）
— ARGV[2]: エラーメトリック記録用のキー
local lock_key = KEYS[1]
local token = ARGV[1]
local metric_key = ARGV[2]
— 1. 現在のロックホルダーを確認
local current_token = redis.pcall(‘GET’, lock_key)
— pcallの結果がエラーテーブルかどうかの厳密なチェック
if type(current_token) == ‘table’ and current_token.err then
— Redis内部エラーが発生した場合のフォールバック
redis.call(‘INCR’, metric_key .. ‘:get_errors’)
return {err = “Critical: Failed to read lock key -> ” .. current_token.err}
end
— 2. トークンの一致確認と削除
if current_token == token then
— 削除コマンドを実行（ここでもpcallで安全に倒す）
local del_res = redis.pcall(‘DEL’, lock_key)
if type(del_res) == ‘table’ and del_res.err then
redis.call(‘INCR’, metric_key .. ‘:del_errors’)
return {err = “Failed to delete lock: ” .. del_res.err}
}
return 1 — 正常解放
else
— 所有権がない、またはすでにexpireしている
return 0
end
この設計の優れている点
- 二重障害の防止: `GET` や `DEL` といった基本操作自体がRedisのメモリ破損や予期せぬ型競合で失敗しても、スクリプト全体がパニックを起こさない。
- オブザーバビリティ（可観測性）の確保: 内部でエラーが発生した際、即座に例外を投げて握りつぶすのではなく、メトリック用キー（`metric_key`）にカウンタを残しつつ、構造化されたエラーを返している。
—
4. パフォーマンス上の注意点とアーキテクトからの忠告
`redis.pcall` は強力だが、銀の弾丸ではない。アーキテクトとして、以下のパフォーマンスおよび設計上のトレードオフを厳守してほしい。
① 「エラーを隠蔽する麻薬」にしてはならない
`redis.pcall` を使うと、バグに起因するエラー（コードの書き間違いによるコマンド引数の誤りなど）さえも握り潰せてしまう。
本番環境で「なぜか処理が失敗するが、エラーログが出ずにサイレントに無視される」という悪夢のデバッグを避けるため、想定外のエラーはログに記録するか、適切に上位へ伝播させる設計にすること。
② Luaスクリプト内のオーバーヘッド
`redis.pcall` は、内部でエラーキャッチのコンテキストを構築するため、純粋な `redis.call` と比較してごく僅かながらオーバーヘッドが存在する。
ミリ秒単位のレイテンシを極限まで削るホットパス（高頻度で実行される数行のスクリプト）において、すべてのコマンドを惰性で `pcall` にするのはナンセンスだ。エラーハンドリングが必要なクリティカルなセクションにのみ限定して使用せよ。
—
結び：コードレビューの基準として
エンジニアのスキルは、エラーが起きたときの「想定内」の広さに比例する。
「うまく動くハッピーパス」だけを書くのはジュニアクラスの仕事だ。シニア、そしてテクニカルリードたる者、「最悪の事態（Failure）が起きたときに、Redis内でどうハンドリングし、システム全体をいかに守るか」をデザインできなければならない。
次に君がRedisのLuaスクリプトを書くとき、あるいはチームメンバーのコードをレビューするとき、こう問いかけてほしい。
> 「おい、その `redis.call`、万が一の異常系を踏んだとき、アトミック性を保ったまま安全にリカバリできるのか？ `redis.pcall` を使うべきじゃないのか？」
その問いかけができるようになった時、あなたのシステムの堅牢性は、確実に次のステージへと引き上げられているはずだ。
コメント