RedisのLuaスクリプト：その「魔法」と「毒」を極限まで使いこなすための設計哲学
エンジニア諸君。Redisを単なる「高速なKVS」として使っているなら、それはまだ入り口に過ぎない。
Redisの真のポテンシャルを引き出すための強力な武器、それがLuaスクリプトだ。しかし、この武器は両刃の剣である。使い方を誤れば、Redisを瞬時に「ブラックホール（停止状態）」へと叩き込む。
今日は、表層的な使い方ではなく、運用現場で生き残るための「Luaスクリプトの極意」を授ける。
—
1. なぜ「アトミック」にこだわるのか
Redisにおいて複数のコマンドを連続して実行したい場合、通常は `MULTI/EXEC`（トランザクション）を検討するだろう。しかし、これには致命的な欠点がある。「条件分岐」ができないことだ。
「値がAならBを書き込み、そうでなければCを返す」といったロジックをクライアント側で書くと、ネットワークRTT（往復時間）の増加だけでなく、レースコンディション（競合）のリスクが排除できない。
Luaスクリプトは、Redisサーバーの内部で実行される。スクリプト実行中、Redisはシングルスレッドの特権を活かし、他のコマンドを完全にブロックする。つまり、記述したコード全体が単一のアトミックな操作として完結する。これが最強の理由だ。
—
2. 実践的設計パターン：レートリミッター
Web APIの設計で頻出するレートリミッター。これをRedisのLuaで実装するとどうなるか見てみよう。
— keys[1]: リミッターのキー (例: rate_limit:user123)
— argv[1]: 許容数 (例: 10)
— argv[2]: 期限 (秒) (例: 60)
local current = redis.call(‘get’, KEYS[1])
— カウンタが存在しない場合は作成し、期限を設定
if not current then
redis.call(‘setex’, KEYS[1], ARGV[2], 1)
return 1
end
— 許容数を超えていないかチェック
if tonumber(current) < tonumber(ARGV[1]) then
redis.call('incr', KEYS[1])
return 1
else
return 0
end
なぜこれが「正しい」のか
- ネットワークコストの削減: 判定ロジックと書き込みが1往復で終わる。
- 整合性の保証: 途中で他のリクエストが割り込む余地がないため、カウンタの不整合が起きない。
—
3. 絶対に守るべき「3つの鉄則」
現場でRedisを止めてしまうエンジニアは、例外なく以下の3つを破っている。
① スクリプトは「瞬時」に終わらせろ
LuaはRedisのメインスレッドを占有する。計算量の多いループや、巨大なソート処理をLuaに書くのは重罪だ。
- NG: `KEYS`コマンドで何万ものキーを取得してループする。
- OK: 必要なキーを引数で渡し、定数時間（O(1)に近い操作）で完了させる。
② `EVAL` ではなく `SCRIPT LOAD` を使え
毎回スクリプトの文字列をRedisに送るのは無駄な帯域消費だ。
1. `SCRIPT LOAD` でスクリプトをRedisにキャッシュし、SHA1ハッシュを受け取る。
2. 以降は `EVALSHA` でハッシュのみを送る。
これだけでネットワーク負荷は激減する。
③ 決定論的（Deterministic）であること
LuaスクリプトはRedisのレプリケーション（主従同期）において重要だ。スクリプト内の実行結果が実行するたびに変わるような実装（`os.time()`を直接使うなど）は避けろ。時間は必ず引数として渡すこと。
—
4. チーフアーキテクトからの忠告
Luaスクリプトは便利だが、「隠れたデッドロック」や「パフォーマンスのボトルネック」の温床にもなる。
- デバッグの困難さ: Lua内部のエラーは追跡が難しい。プロダクションに投入する前に、ローカルで徹底的にユニットテストを行うこと。
- Redis 7.0以降の `Functions`: 最新のRedisではLuaスクリプトの進化版である「Redis Functions」が導入されている。ライブラリ化が容易で、状態管理も洗練されている。可能ならこちらへの移行を視野に入れろ。
まとめ
Luaスクリプトは、Redisに「知能」を与える機能だ。
しかし、その知能は「シンプルかつ高速であること」を前提にしている。複雑なビジネスロジックを詰め込む場所ではない。それはアプリケーションサーバー（Node.js, Go, Pythonなど）の仕事だ。
Redisには「データに近い場所で、どうしても必要なアトミック性だけ」を委譲する。その境界線を引けるエンジニアこそが、真にスケーラブルなシステムを構築できる。
さあ、コードを書いてくれ。ただし、そのスクリプトが「Redisを止める原因にならないか」、一度深呼吸して見直すことだ。それがプロフェッショナルの流儀だ。
コメント