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

Redis Luaスクリプト：アトミシティの代償と「単一スレッド」の深淵

多くのエンジニアが「RedisのLuaスクリプトは便利だ」というレベルで止まっている。しかし、システムが極限の負荷にさらされたとき、その実装が「劇薬」にも「特効薬」にもなり得ることを理解している者は少ない。

RedisのLuaスクリプトは、単なる手続きのバッチ実行ではない。Redisという広大なメモリ空間における「隔離された計算領域」であり、その背後にはシングルスレッドアーキテクチャ特有の冷徹な制約が横たわっている。

1. アトミシティの真実：独占とブロッキング

Redisの全コマンドは単一スレッドでシリアライズされる。Luaスクリプトも例外ではない。重要なのは、「スクリプトの実行中は、他のクライアントからのリクエストは一切処理されない」という事実だ。

この仕様は、ACIDの「A（Atomicity）」を担保する最強の武器となる。しかし、同時にシステム全体を停止させる「爆弾」にもなり得る。

アーキテクトの視点：実行時間の呪縛

Luaスクリプト内に重い処理（特に計算量の多いループや複雑な再帰）を記述した場合、Redisは瞬時に「応答不能」に陥る。

イベントループの停止: スクリプトが戻るまで、Redisは新しい接続を受け付けず、既存の通信もスタックする。
回避策: Lua内で実行する命令はあくまで「メモリ上のポインタ操作や単純な判定」に限定すべきだ。外部サービスへの通信などは論外であり、Redisのプロセスをデッドロックさせる要因になる。

2. スクリプトキャッシュとメモリ最適化：SHA1の魔法

Redisは、スクリプトのソースコードそのものを毎回転送させる非効率を避けるために、`EVALSHA`という機構を用意している。

— スクリプトを計算し、キャッシュに格納する（厳密にはSCRIPT LOAD）
— 戻り値としてSHA1ハッシュが返却される
local sha = redis.call(‘SCRIPT’, ‘LOAD’, ‘return redis.call(“GET”, KEYS[1])’)
— 以降はSHA1を送るだけで実行可能（ネットワーク帯域の極小化）
redis.call(‘EVALSHA’, sha, 1, ‘my_key’)

ここで知っておくべき極限の知見は、「SCRIPT FLUSHでキャッシュが消えると、アプリケーション側のEVALSHAが例外を吐き、システムが雪崩を起こす」という点だ。大規模システムでは、キャッシュの永続性を前提としたデプロイフローを設計しなければならない。

3. Luaスクリプトにおける「メモリリーク」の罠

Luaの環境（`Lua State`）は、Redisのプロセス内で永続化されている。そのため、不用意な変数の定義や、グローバル変数の汚染は致命的なメモリ増大を招く。

グローバル変数の禁止: Luaスクリプト内で `local` を付け忘れると、それはLua環境のグローバルテーブルに残り続ける。これが蓄積すると、GCが機能せず、Redisの物理メモリを圧迫し、最終的にOOM（Out of Memory）を誘発する。
対策: `strict.lua` のような仕組みを意識し、常にスコープを閉じること。複雑なロジックを組む際は、GCの挙動を考慮した「使い捨て」の設計を徹底せよ。

4. なぜ「MULTI/EXEC」ではなく「Lua」なのか

トランザクションを必要とする場合、`MULTI/EXEC` という選択肢もある。しかし、熟練のエンジニアはLuaを選ぶ。理由は明確だ。

1. 条件分岐の可視化: `MULTI/EXEC` はクライアントとRedisの往復回数が増え、かつコマンド投入後にロジックが分岐できない。Luaはサーバーサイドで完結するため、ネットワークレイテンシを排除し、かつ複雑なif-else条件に基づいたデータ書き込みが可能だ。
2. 実行効率の差異: Luaスクリプトはコンパイル（バイトコード化）され、内部的にキャッシュされる。これはRedisの実行コンテキスト内において、最もオーバーヘッドの少ない手続きの実行方法である。

結論：深淵を覗く者へ

Luaスクリプトは、Redisのシングルスレッドという「制約」を、エンジニアの工夫次第で「特権」に変えるためのツールだ。

処理時間はミリ秒単位で計測せよ
スクリプトのSHA1管理はデプロイパイプラインの必須要件とせよ
グローバル変数という「メモリの癌」を徹底的に排除せよ

これらを守れないのであれば、Luaを使う資格はない。Redisの内部構造を理解し、そのシングルスレッドの鼓動を感じ取れる者だけが、真に高パフォーマンスなキャッシュ層を設計できる。

我々はデータベースを操っているのではない。メモリという名の「計算リソースの極限」を管理しているのだ。その自覚があるなら、明日のコードからLuaの書き方が変わるはずだ。