【テクニカル・上級編】 Luaスクリプト実行 – Redis

Redis Luaスクリプト：アトミック性の神話と、その深淵に潜む「支配」の技術

RedisにおけるLuaスクリプトの実行は、単なる「サーバーサイドでの処理」ではない。それは、Redisのシングルスレッドという制約を、唯一無二の強力な武器へと昇華させるための神聖な儀式だ。

多くのエンジニアは「アトミックに処理できるから便利」という浅瀬で泳いでいる。だが、真のアーキテクトであれば、その内部で何が起きているか、そして「なぜRedisはあえてLuaを採用し、その実行をどう制御しているか」を理解しなければならない。

今日は、その深淵を解剖しよう。

—

1. アトミック性の本質：止まる世界、動くロジック

RedisのLua実行において最も重要な事実は、「スクリプト実行中はRedis全体がブロックされる」という点だ。

これは欠点ではなく、アーキテクチャ上の設計思想そのものだ。`EVAL` が発行された瞬間、Redisのメインループは他のクライアントからのリクエストを停止し、Luaインタプリタに制御を委ねる。この間、他のコマンドは一切割り込めない。

真実: トランザクション（MULTI/EXEC）よりもLuaスクリプトが推奨される理由は、Lua内であれば「条件分岐（if-else）」を評価した上でキー操作ができるからだ。`WATCH` を使った楽観的並行制御によるリトライの嵐から解放される。

2. メモリとキャッシュの最適化：`EVALSHA` の賢明な利用

`EVAL` コマンドで毎回巨大なスクリプトをネットワーク越しに送りつけるのは、帯域の無駄であり、パースのオーバーヘッドも馬鹿にならない。

`SCRIPT LOAD` によるプリコンパイル

スクリプトは `SCRIPT LOAD` でサーバー側にキャッシュし、SHA1ハッシュを返す。クライアントはこのハッシュを `EVALSHA` で呼び出すのが定石だ。

— サーバー側にスクリプトをロードし、SHA1を得る
— 戻り値: “e0e15…”
SCRIPT LOAD “return redis.call(‘get’, KEYS[1])”

— 以降はハッシュのみを送信する
— ネットワーク帯域を極限まで節約できる
EVALSHA e0e15… 1 mykey

アーキテクトの視点: 大規模システムでは、アプリケーションのデプロイ時にスクリプトをプリロードするマイグレーションスクリプトを走らせるのが鉄則だ。存在しないSHA1を叩いたときのエラーハンドリング（`NOSCRIPT` を受けてから `EVAL` にフォールバックする）をクライアントライブラリに実装しているか？それが実務レベルの分水嶺となる。

3. Lua実行の「地雷」：ブロッキングとタイムアウト

Luaスクリプトは「無限ループ」に陥るリスクがある。Redisはこれを防ぐために `lua-time-limit`（デフォルト5秒）を設けている。

制限時間を超えると、Redisは `BUSY` 状態となり、他のコマンドを拒絶するようになる。この時、管理者が取れる選択肢は二つしかない。

1. `SCRIPT KILL`: 実行中のスクリプトを強制停止する。ただし、スクリプトが「書き込み（Write）」を行っていなかった場合に限る。
2. `SHUTDOWN NOSAVE`: 既にデータが書き換えられている場合、これ以外の手段はない。

教訓: Lua内で「何でもできる」と過信して複雑な計算やループを書いてはならない。RedisのLuaは、「高々数ミリ秒で終わるデータの集合操作」のためにある。重い処理はアプリケーション層で行い、Redisには結果を書き込ませるべきだ。

4. Luaスクリプトを「汚さない」ための規約

Redis 5.0以降、Luaスクリプトはレプリケーションにおいて決定論的（Deterministic）であることが強く求められる。

決定論の強制: `TIME` や `RANDOMKEY` など、実行するたびに結果が変わるコマンドはLua内では使用禁止だ。もし使った場合、Redisはエラーを投げる。これは、マスターとスレーブで同じ結果を再現するためだ。
副作用の制御: Lua内での操作は、すべて「キーベース」で行うこと。スクリプトがどのキーを操作するかをRedisに明示的に伝える（`KEYS` 配列）ことは、Redis Cluster環境において必須だ。これを行わないと、キーが異なるノードに分散している場合にルーティングエラーが発生する。

5. 伝説的アーキテクトからの提言

あなたがもし、RedisのLuaスクリプトを多用してシステムを組もうとしているなら、次の問いに答えられるようになってほしい。

1. 「そのスクリプトは1ms以内に終わるか？」

超えそうなら、アーキテクチャを再設計せよ。RedisはLuaのための計算機ではない。

2. 「レプリケーション遅延を許容できるか？」

マスターで重いLuaを実行すれば、スレーブの反映も同じ時間だけ遅れる。これは非同期レプリケーションの原則だ。

3. 「スクリプトのバージョン管理はできているか？」

SHA1ハッシュをハードコードしてはならない。コードベースとRedis内のスクリプトは常に同期させる必要がある。

Luaスクリプトは強力な劇薬だ。正しく使えばRedisは唯一無二の高速なバックエンドとなり、誤ればシステム全体を停止させる時限爆弾となる。

「賢いアーキテクトは、Luaの中にロジックを詰め込まない。ロジックの『結果』をLuaで安全に保護するのだ」

この視点を持てたとき、あなたはRedisを真に飼いならしたと言えるだろう。