Redisの限界を突破する：EVALSHAとLuaスクリプトエンジン内部の深淵
Redisを単なる「高速なキーバリュー・ストア」として扱っているうちは、その真のポテンシャルの半分も引き出せていない。ミリ秒単位のレイテンシーを極限まで削ぎ落とし、数百万QPSのトラフィックをさばくアーキテクチャにおいて、ネットワークラウンドトリップ（RTT）とアトオリティ（原子性）の確保は常にエンジニアリングの核心的課題である。
トランザクションを安全に、かつノーロックで処理するための切り札がLuaスクリプトであり、その実行効率を極限まで高めるのが `EVALSHA` コマンドだ。
本稿では、リファレンスには載っていないRedisのLuaエンジン内部メカニズム、SHA1ハッシュキャッシュのライフサイクル、そしてプロダクション環境で踏み抜きやすい致命的な落とし穴について、チーフアーキテクトの視点から徹底的に解き明かす。
—
1. なぜ `EVAL` ではなく `EVALSHA` なのか？ —— 帯域とパースコストの支配者
`EVAL` コマンドは非常に強力だが、致命的な構造的欠陥を抱えている。それは、リクエストごとに数キロバイトに及ぶLuaスクリプトのソースコード全体をクライアントからRedisサーバーへ転送し、サーバー側で毎回構文解析（Lex/Yaccベースのパース）とバイトコードへのコンパイルを行っている点だ。
高負荷な分散システムにおいて、これは明らかな無駄である。
[Client] –(数KBのLuaスクリプト送信)–> [Redis Server]
├── 1. ネットワーク帯域の圧迫
├── 2. スクリプトのパース処理
└── 3. バイトコードコンパイル
対して `EVALSHA` は、事前にサーバーへ登録（キャッシュ）されたスクリプトの SHA1 ダイジェスト（40文字のHEX値）のみを送信する。
[Client] –(40bytesのSHA1のみ送信)–> [Redis Server]
└── 1. キャッシュヒット → 即座にVM実行
ネットワークとCPUのコスト比較
- `EVAL`: スクリプトの文字数に比例したネットワーク帯域の消費 ＋ 毎回のコンパイルコスト（CPUバウンド）
- `EVALSHA`: 固定 40 バイトのネットワークフットプリント ＋ キャッシュルックアップ（$O(1)$ のハッシュテーブル探索）
数万コネクションが同時に押し寄せる環境において、この差はネットワークI/Oの枯渇とCPU使用率の急増を防ぐための決定的な差別化要因となる。
—
2. 内部アーキテクチャ：Redis内部におけるLuaスクリプトの生存戦略
Redisは内部に独立した Lua 5.1 の仮想マシン（VM）を内包している。スクリプトキャッシュの実態は、Redisのグローバル空間に存在する `dict`（ハッシュテーブル）構造体、`server.lua_scripts` である。
// Redis内部表現の概念図（実際はserverStruct内）
dict lua_scripts; // Key: SHA1 digest (sds), Value: robj (Luaスクリプトの関数オブジェクト)
スクリプトキャッシュのライフサイクルと揮発性
ここで、多くのシニアエンジニアすら誤解している重要な事実を指摘しておこう。
RedisのLuaスクリプトキャッシュは、永続化されない（Non-persistent）。
- `RDB` スナップショットや `AOF`（Append-Only File）には、`EVALSHA` で実行されたスクリプトのコード自体は保存されない（AOFには `EVAL` コマンドに変換されて記録される）。
- したがって、Redisサーバーが再起動（Restart）した瞬間、サーバー側のスクリプトキャッシュは完全に消滅する。
再起動後にクライアントが直接 `EVALSHA` を叩いた場合、Redisは以下のエラーを返す。
(error) NOSCRIPT No matching script. Please use EVAL.
この挙動を考慮せず、「常に `EVALSHA` だけを送る」という素朴な実装を行うと、フェイルオーバーやメンテンス後の初動でシステム全体が雪崩を打ってエラーを引き起こす。
—
3. 実践：フェイルセーフな `EVALSHA` パターンの構築
プロダクションコードにおける正しいアプローチは、「まず `EVALSHA` を試し、`NOSCRIPT` エラーを受け取った場合のみ、自動的に `SCRIPT LOAD` または `EVAL` にフォールバックする」という楽観的実行戦略（Optimistic Execution）の実装である。
以下に、堅牢なアプリケーション層での疑似コード（TypeScript風）を示す。
async function executeRedisScript(redisClient, sha1, luaCode, keys, args) {
try {
// 1. まず高速な EVALSHA を試行
return await redisClient.evalsha(sha1, keys.length, …keys, …args);
} catch (err) {
if (err.message.includes(“NOSCRIPT”)) {
// 2. キャッシュミス（再起動後など）の場合、スクリプトをロードして再実行
console.warn(“Script cache miss. Falling back to EVAL / SCRIPT LOAD.”);
return await redisClient.eval(luaCode, keys.length, …keys, …args);
}
// その他のエラー（ランタイムエラーやメモリ不足など）はそのままスロー
throw err;
}
}
このパターンを徹底することで、通常時は `EVALSHA` の恩恵（低レイテンシー・低帯域）を100%受けつつ、サーバー再起動耐性を完全に担保できる。
—
4. 極限のチューニング：Redis Luaスクリプトの罠とアンチパターン
最後に、Redisのアーキテクチャを踏まえた上で、Luaスクリプトおよび `EVALSHA` 運用における致命的なアンチパターンに言及する。
① 非決定性（Non-determinism）の排除
Redisのレプリケーション（Master-Replica）およびAOFによる復元は、「スクリプトが同じ入力に対して常に全く同じ副作用（データ変更）をもたらすこと（決定性）」を前提としている。
- `Math.random()` や `os.time()` をスクリプト内で直接呼び出してはならない。
- 内部で時刻や乱数が必要な場合は、必ずクライアント側から `ARGV` として渡すこと。
※ Redis 5.0以降、非決定的な操作を行うスクリプトは検出され次第エラーとなるが、古いバージョンや複雑なロジックでは見落とされやすい。
② ブロッキングとアトオリティの代償
Redisはシングルスレッド（I/Oおよびスクリプト実行）で動作するため、Luaスクリプトの実行中は他のすべてのクライアントリクエストがブロックされる。
- 1つのスクリプトの実行に数秒〜数十秒かかるような重い処理（数百万件のキーを走査する `keys()` の乱用など）を書いた瞬間、Redis全体が停止する。
- スクリプト内でのループ処理は極力最小限に抑え、計算量は $O(N)$ のオーダーを厳しく監視すること。万が一暴走した場合は、`SCRIPT KILL`（データ変更前のみ）または `SHUTDOWN NOSAVE` で緊急停止する覚悟を持たなければならない。
—
5. チーフアーキテクトからの提言
`EVALSHA` は、単なる「コードを短く送るためのテクニック」ではない。それは、ネットワークとCPUのボトルネックを極限まで排除し、Redisを真の超高スループット・トランザクションエンジンへと昇華させるためのキーテクノロジーである。
しかし、その裏にある揮発性（再起動時のキャッシュ消滅）やシングルスレッド制約を理解せずして使うことは、時限爆弾を抱えるようなものだ。
インフラストラクチャの物理制約をコードのレベルで理解し、フォールバック機構を備えた洗練されたクライアントを設計すること。それこそが、真にスケーラブルなシステムを構築する唯一の道である。
コメント