Redis Luaサンドボックスの深層：決定論的実行とグローバル汚染の完全掌握
Redisの内部で動くLuaスクリプトは、トランザクションや複雑なインメモリ処理をアトミックに実行するための強力な刃である。しかし、この刃の切れ味を過信し、内部構造を理解せずに振り回すエンジニアは、往々にしてレプリケーションの崩壊やクラスタの分裂という致命傷を負う。
本稿では、RedisがLuaスクリプトをどのようにサンドボックス化し、いかにして「決定論的（Deterministic）な実行」を担保しているのか。その内部メカニズムと限界を、アーキテクトの視点から極限まで掘り下げて解説する。
—
1. 決定論的実行という絶対律：なぜ非決定性を排除するのか
Redisはシングルスレッドのイベントループを基本としつつ、AOF（Append Only File）とレプリケーションによってデータ durability（耐久性）と高可用性を実現している。
ここで根本的な問いを立てよう。
「もしLuaスクリプト内で非決定的な処理が許可されていたら、何が起きるか？」
答えは単純かつ破滅的である。マスターノードで実行されたスクリプトの結果と、それを非同期で再実行するレプリカ（あるいはAOFリプレイ）での結果が乖離する。
- `math.random()` による乱数生成
- `os.time()` による現在時刻の取得
- ポインタやメモリ上のアドレスに依存したハッシュ順序（Luaのテーブル走査順序の非決定性）
- ネットワークI/Oや外部システムへのアクセス
これらはすべて、分散システムにおける「スプリットブレイン」や「レプリケーションのデシク（不整合）」を引き起こす毒だ。RedisのLuaサンドボックスは、この毒をコンパイル時および実行時に対水圧工法で完全に遮断している。
—
2. グローバル変数の厳格な制限とサンドボックスの正体
Redis（内部的にはLua 5.1インタプリタをベースに拡張）は、スクリプト実行時に厳格なグローバル変数の汚染防止策を講じている。
グローバル汚染の検知メカニズム
RedisのLua環境では、スクリプトが新規にグローバル変数を作成しようとすると、即座にエラーとして弾かれる。
— ❌ 意図しないグローバル変数の定義
function bad_script()
my_global_cache = “dangerous” — エラーになる
return redis.call(‘GET’, ‘foo’)
end
なぜこれが禁止されているのか？
Redisはパフォーマンスとメモリ効率のため、Luaのステート（`lua_State`）をリクエスト間で使い回す（Pooling）。もしスクリプトAがグローバル変数に状態を残した場合、次に同じWorkerで実行されるスクリプトBがその汚染された状態を読み書きすることになり、予期せぬバグやセキュリティ上の脆弱性（データ漏洩）に直結するからだ。
対策：`local` の強制とメタテーブルによるプロテクション
Redisは、Luaの `_G`（グローバル環境）テーブルに対してメタテーブル（`__newindex`）を設定し、実行中のスクリプトがグローバル名前空間へ直接書き込むことをランタイムで検知・ブロックしている。
したがって、変数は必ず `local` でスコープを限定しなければならない。
— ⭕ 正しい実装：すべての変数をローカルスコープに閉じ込める
local user_id = KEYS[1]
local rate_limit = tonumber(ARGV[1])
local current = redis.call(‘GET’, user_id)
if current and tonumber(current) >= rate_limit then
return 0
end
redis.call(‘INCR’, user_id)
return 1
—
3. Lua内部の「擬似決定論」：時間と乱数のコントロール
「どうしてもスクリプト内で時刻や乱数を使いたい」という要求は実務上存在する。しかし前述の通り、`os.time()` や `math.random()` は直ちにブロック、あるいは制限される。
これに対処するため、Redisは「決定論的ラップ」というアプローチをとっている。
タイムスタンプの固定
Redisは、Luaスクリプトの実行を開始する直前に、現在のサーバー時刻を内部的にキャッシュする。スクリプト内で `redis.call` や特殊なAPIを通じて取得される時間は、すべてこの「実行開始時の固定された時間」である。
これにより、同じスクリプトをマスターで実行しようが、AOFをリプレイしようが、まったく同じタイムスタンプが参照されることが保証される。
乱数のシード固定
RedisのLua環境では、`math.randomseed()` を呼び出すことが制限されるか、あるいは決定論的なアルゴリズムに強制される。純粋なエントロピー源（ハードウェアノイズなど）へのアクセスはサンドボックス外へと完全にルーティングされている。
—
4. Redis 5以降の革命：EVALからFUNCTIONへのパラダイムシフト
従来の `EVAL` および `EVALSHA` には、アーキテクチャ上の大きな課題があった。それは「スクリプトがクライアント側で管理され、サーバー側はハッシュ（SHA1）かコードそのものを毎回送信してもらう必要がある」という点だ。
Redis 5/6を経て、Redis 7で導入された `FUNCTION`（Lua Libraries） は、このサンドボックスの概念をさらに一段上のレイヤへと引き上げた。
ライブラリ形式によるカプセル化
関数をRedisサーバー側に常駐させることで、以下のようなメリットが生まれる。
— Redis 7以降のファンクション定義例
!lua name=my_library
redis.register_function(‘rate_limiter’, function(keys, args)
local current = redis.call(‘GET’, keys[1])
— 決定論的な処理ロジック…
return current
end)
このアーキテクチャでは、スクリプトは単なる「その場しのぎのコード断片」ではなく、サーバーメモリ内に安全にコンパイル・保持される「ファーストクラスのストアドプロシージャ」となる。
グローバル変数の制限や決定論の強制といったサンドボックスの戒律はそのままに、モジュール単位での依存関係管理やバージョン管理が可能になった。
—
5. アーキテクトが知るべきパフォーマンスの限界とアンチパターン
最後に、現場の現場で踏みがちなLuaサンドボックスの地雷を指摘しておく。
1. O(N) 処理によるイベントループのブロック
Luaはサンドボックス内でアトミックに実行される。つまり、Luaスクリプトが実行されている間、そのRedisインスタンスのメインスレッドは完全に停止（ブロック）する。数百万件のキーを走査するような重い `for` ループをLua内で回した瞬間、そのRedisは他のすべてのクライアントリクエストを拒絶する死んだノードと化す。
2. メモリ肥大化の罠
Luaステート内で巨大なテーブル（配列や辞書）を構築し続けると、Redis自体のメインメモリを圧迫し、`maxmemory` 制限によるEviction（データ削除）や OOM Killerの標的になる。Luaスクリプトはあくまで「薄い制御ロジック」にとどめるべきであり、重いデータ構造の保持はRedis本体のネイティブなデータ型（Hash, Sorted Setなど）に任せるべきだ。
結言
RedisのLuaサンドボックスは、単なる「お行儀の悪いコードを防ぐための機能」ではない。それは、インメモリDBという超高速な実行基盤において、分散システムの整合性を担保するための究極の防壁である。
このサンドボックスの制約（グローバル変数の禁止、非決定性の排除、アトミック実行によるブロック特性）を正確に理解し、コードを最適化すること。それこそが、真にスケーラブルで頑健なアーキテクチャを構築する唯一の道である。
コメント