TIL

08. Lua Scripting

• EVAL/EVALSHA로 Lua 스크립트를 서버에서 원자적으로 실행하는 기능
• 강점
  • 여러 명령을 race 없이 하나로 묶음 (read-modify-write를 스크립트 안에서 처리)
  • WATCH 재시도 없이 원자성 확보
  • EVALSHA로 단일 RTT, 서버 측 처리로 데이터 이동 최소화
• 트랜잭션의 “낙관적 재시도” 대신 “처음부터 끼어들 수 없게” 막는 방식

핵심 명령

EVAL

• EVAL script numkeys key [key ...] arg [arg ...]
• numkeys로 키 개수를 알려주고, 키는 KEYS[n], 나머지 인자는 ARGV[n]로 접근 (1-indexed)

EVAL "return redis.call('GET', KEYS[1])" 1 stock:evt_123

EVALSHA / SCRIPT LOAD

• 매번 스크립트 본문을 보내지 않고 SHA1 해시로 실행해 대역폭 절약
• SCRIPT LOAD로 미리 캐시에 올리고 해시를 받아 EVALSHA로 실행

SCRIPT LOAD "<script>"              # → sha1 반환
EVALSHA <sha1> 1 stock:evt_123 3    # numkeys=1, KEYS[1]=stock:evt_123, ARGV[1]=3

• 캐시에 없으면 NOSCRIPT 에러 → 클라이언트가 EVAL로 폴백
• SCRIPT EXISTS로 캐시 여부 확인, SCRIPT FLUSH로 캐시 비움

KEYS와 ARGV

• KEYS: 스크립트가 접근하는 키, ARGV: 키가 아닌 인자(값·수량 등)
• 키를 하드코딩하지 말고 반드시 KEYS로 넘겨야 함
  • Redis Cluster가 키 슬롯을 보고 라우팅하기 때문
  • 한 스크립트가 만지는 키는 모두 같은 슬롯이어야 함 (해시 태그 활용)

원자성

• 스크립트 전체가 단일 실행 단위 — 실행 중 다른 명령·스크립트가 끼어들 수 없음
• 그래서 “읽고 → 판단 → 쓰기”를 스크립트 안에서 그대로 해도 race가 없음 (WATCH·재시도 불필요)

-- KEYS[1]=재고 키, ARGV[1]=차감 수량
local left = tonumber(redis.call('GET', KEYS[1]))
if left == nil then return -2 end                 -- 키 없음
if left < tonumber(ARGV[1]) then return -1 end    -- 재고 부족
return redis.call('DECRBY', KEYS[1], ARGV[1])     -- 차감 후 잔량 반환

redis.call vs redis.pcall

• redis.call(...): 명령 실행, 에러 나면 스크립트 전체가 중단되고 에러 전파
• redis.pcall(...): 보호 호출, 에러를 Lua 테이블로 반환해 직접 처리 가능

실행 모델과 한계

단일 스레드 블로킹

• 스크립트가 원자적으로 도는 동안 서버 전체가 블로킹 → 모든 클라이언트가 대기
• 따라서 스크립트는 짧고 빨라야 함
• lua-time-limit(기본 5초) 초과 시 다른 요청에 BUSY 응답 → 쓰기 전이면 SCRIPT KILL, 아니면 SHUTDOWN NOSAVE로만 회복

쓰기 스크립트는 마스터 전용

• 쓰기를 포함한 스크립트는 마스터에서만 실행 → 읽기 복제본으로 분산 불가
• 재고 차감처럼 쓰기가 있는 로직은 마스터에 부하가 몰림 (Lua를 기피하는 실무 사례의 주된 이유)
• 읽기 전용은 EVAL_RO/EVALSHA_RO(7.0+)로 복제본에서 실행 가능

롤백 없음

• 트랜잭션과 마찬가지로 스크립트 중간에 실패해도 이미 실행된 쓰기는 되돌아가지 않음

결정성과 effects replication

• 과거: 스크립트가 복제본에 그대로(verbatim) 복제돼, 랜덤·시간 의존 같은 비결정적 연산이 마스터/복제본 불일치를 유발 → 결정성 요구
• 현재(5.0+): effects replication이 기본 — 스크립트가 만든 실제 쓰기 명령을 복제하므로 비결정성 제약이 완화됨

Redis Functions (7.0+)

• FUNCTION LOAD로 함수를 등록하는 신형 방식 — 스크립트와 달리 서버에 영속되고 재시작·복제에도 유지
• EVALSHA처럼 매번 로드/폴백을 신경 쓸 필요가 줄어듦

Transaction vs Lua 비교

기준	Transaction (WATCH/MULTI)	Lua Script
원자성 확보	낙관적 — 감시 키 변경 시 취소 → 재시도	스크립트 전체를 단일 실행 단위로 강제
read-modify-write	WATCH로 우회(읽기는 트랜잭션 밖)	스크립트 안에서 직접 처리
재시도	고경합 시 필요 (retry storm)	불필요
읽기 복제본 분산	가능	쓰기 스크립트는 마스터 전용(불가)
블로킹	짧음	긴 스크립트는 서버 전체 블로킹
네트워크	명령들 왕복(파이프라인)	EVALSHA로 단일 RTT
가독성·디버깅	명령 단위로 명확	별도 Lua라 디버깅·테스트 어려움
롤백	없음	없음 (중간 실패해도 이전 effect 유지)
적합 상황	단순 CAS, 저경합	복잡한 다단계 원자 연산, 고경합

• 정리: 저경합 단순 비교-갱신은 트랜잭션, 복잡한 원자 로직·고경합은 Lua가 유리
• 단 Lua는 마스터 전용·블로킹 비용이 있어 무조건 정답은 아님 → 트레이드오프로 선택 (07. Redis Transaction 참고)

참고

• Redis 공식 — Scripting with Lua (EVAL)
• Redis 공식 — Redis Functions