Redisの魂「Luaスクリプト」とエラーハンドリング：`redis.error_reply`の真価を看破する
こんにちは。テックリードの私だ。
今日のコードレビューで、また「Luaスクリプト内で適当な文字列を`return`しているコード」を見かけた。
— 【アンチパターン】これではダメだ
local val = redis.call(‘GET’, KEYS[1])
if not val then
return “ERR key not found” — ただの文字列返却
end
君たちは、RedisのLuaスクリプトからエラーを返す際、単なるLuaの文字列や `error()` 関数を使っていないだろうか？もしそうなら、今すぐその手を止めてこの記事を読んでほしい。
Redis 5で導入された `redis.error_reply()` は、単なるシンタックスシュガーではない。クライアントライブラリ、パイプライン、そして分散システムの堅牢性を根底から支える、極めて重要なプリミティブだ。
今日は、Redisの内部構造を知り尽くしたアーキテククトの視点から、この `redis.error_reply` の正体と、実務で絶対に守るべき設計パターンを伝授しよう。
—
1. なぜ「単なる文字列返却」や「`error()`」では地獄を見るのか？
まず、Redisにおけるエラー応答のプロトコルレベルの仕様を思い出してほしい。
Redisはクライアントとの通信にRESP（REdis Serialization Protocol）を使用している。
- 通常の文字列（Simple String）: `+OK\r\n`
- エラー（Error）: `-ERR some error message\r\n`
- バルク文字列（Bulk String）: `$4\r\ndata\r\n`
Luaスクリプト内で単に `”ERR something”` という文字列を返すと、クライアント側（Pythonのredis-pyやNode.jsのioredisなど）からは、「エラー」ではなく「普通の文字列データ」として受信されてしまう。これでは、アプリケーション層での例外ハンドリングが完全に崩壊する。
かといって、Lua標準の `error(“something”)` を使った場合はどうなるか？
Luaの `error()` はスクリプト全体をアボートさせ、Redisは以下のような汎用的なラッパーエラーを返す。
`-ERR Error running script (call to f_…): user script:1: something`
これでは、スクリプト内で何が起きたのか（ビジネスロジック上の想定されたガードなのか、予期せぬバグなのか）の判別が極めて困難になる。
ここで登場するのが `redis.error_reply()` だ。
—
2. `redis.error_reply()` とは何か？
`redis.error_reply(error_string)` は、LuaスクリプトからRedisの正規のエラー応答（RESP Errorタイプ）を直接生成するためのヘルパー関数だ。
これを使うと、Redisサーバーは、あたかも通常のRedisコマンドがエラーを返したかのように、プレフィックス `-` を付与したエラーレスポンスをクライアントに返却する。しかも、余計な `Error running script (…)` といったラッパーを取り除き、指定したエラーメッセージをそのままクリーンに伝播させることができる。
基本的な使い方
— 健全なエラーハンドリングの例
local current = redis.call(‘GET’, KEYS[1])
if current then
return redis.error_reply(“ERR critical: resource already locked”)
end
redis.call(‘SET’, KEYS[1], ARGV[1])
return “OK”
クライアント側（例：Python）での振る舞いを見てみよう。
import redis
r = redis.Redis()
try:
r.eval(lua_script, 1, “my_lock”, “owner_A”)
except redis.ResponseError as e:
# “ERR critical: resource already locked” が正確に捕捉できる
print(f”Caught expected Redis error: {e}”)
この「クライアントが型としてエラーを識別できる」という点が、システム全体の堅牢性を担保する上で極めて重要なのだ。
—
3. 実務で使える：アトミックな「楽観的ロック＋バリデーション」パターン
では、実際のプロダクション環境を想定した設計パターンを見ていこう。
テーマは 「レートリミッターとクォータ管理の複合処理」 だ。
ユーザーのリクエスト数と消費トークン量をアトミックに検証し、違反している場合は `redis.error_reply` で明確な理由を添えて拒否するスクリプトを書いてみる。
Luaスクリプト：`consume_quota.lua`
— KEYS[1]: ユーザーのレートリミットキー
— KEYS[2]: ユーザーのクォータ残高キー
— ARGV[1]: 許可する最大リクエスト数 (Limit)
— ARGV[2]: 今回消費するトークン数 (Cost)
local limit = tonumber(ARGV[1])
local cost = tonumber(ARGV[2])
— 1. レートリミットのインクリメント
local current_requests = redis.call(‘INCR’, KEYS[1])
if current_requests == 1 then
— 初回アクセス時は有効期限（例: 60秒）を設定
redis.call(‘EXPIRE’, KEYS[1], 60)
end
if current_requests > limit then
— レートリミット超過エラーを明確に返す
return redis.error_reply(“ERR_RATE_LIMIT_EXCEEDED: Too many requests”)
end
— 2. クォータ残高のチェック
local quota_balance = redis.call(‘GET’, KEYS[2])
if not quota_balance then
return redis.error_reply(“ERR_QUOTA_NOT_FOUND: User quota account does not exist”)
end
quota_balance = tonumber(quota_balance)
if quota_balance < cost then
-- 残高不足エラーを返す（※この手前でインクリメントしたレートリミットを巻き戻すべきか、ビジネス要件と相談）
return redis.error_reply("ERR_INSUFFICIENT_QUOTA: Not enough tokens available")
end
-- 3. クォータの減算
local remaining = redis.call('DECRBY', KEYS[2], cost)
return { "OK", remaining }
チーフアーキテクトからの設計上の指摘
1. エラーコードのプレフィックス化:
`ERR_RATE_LIMIT_EXCEEDED` のように、メッセージの先頭に一意なエラーコードを含めること。これにより、呼び出し側のアプリケーション（Go, Node.js, Python等）で文字列パースや正規表現による分岐が可能になり、i18n（国際化）やフロントエンドへの適切なステータスコード返却が容易になる。
2. 副作用のロールバック:
上記のスクリプトでは、途中でエラー（クォータ不足など）になった場合、事前に実行した `INCR` がそのまま残る。厳密なアトミシティが必要な場合は、処理順序を工夫するか、エラー発生時に `DECR` で巻き戻す処理を挟むこと忘れないように。
—
4. パフォーマンスと運用の注意点
`redis.error_reply` 自体は非常に軽量な組み込み関数であり、パフォーマンス上のオーバーヘッドはほぼ無視できる。しかし、Luaスクリプトの運用において以下の鉄則を破ってはならない。
- スクリプトの肥大化を避ける:
エラーハンドリングを恐れてスクリプト内に複雑な分岐を書きすぎると、Redisのシングルスレッドイベントループをブロックし、レイテンシスパイクを引き起こす。複雑なバリデーションはアプリケーション層で行い、RedisのLuaで行うのは「アトミック性を担保すべき最小限のインメモリ処理」に絞るべきだ。
- SIGHUPやレプリケーションへの影響:
`redis.error_reply` はメモリの状態を変更しないため、Replication（Master-Replica間）やAOF（Append-Only File）において安全である（エラーを返した時点でスクリプトの実行はアボートするか、あるいは値の変更がロールバックされるため不整合は起きない）。安心して利用してほしい。
—
結びにかえて
プログラミングの本質は「異常系の設計」に宿る。
正常系を動かすのはジュニアエンジニアでもできるが、異常系をいかに美しく、堅牢に、予測可能な形でハンドリングするかこそが、シニアやテックリードの腕の見せ所だ。
RedisのLuaを書くときは、単にデータを返すのではなく、「クライアントがこのエラーをどう解釈すべきか」までをデザインし、`redis.error_reply()` を適切に配置してほしい。
君たちの書くコードが、深夜のPagerDutyアラートを鳴らさないエレガントなものであることを期待している。
コメント