Redis와 Lua Script

예시 :

• 슬롯 게임의 잭팟(Jackpot) 시스템을 관리하는 것으로 Redis를 사용

• 이 떄 잭팟에 당첨되면 Lua Script를 활용하여, 잭팟 금액을 0으로 만들고, 누적된 금액을 반환하는 Lua Script를 활용하고 있었음

• 슬롯 게임의 잭팟 시스템은 **초당 수만 건의 업데이트(누적)**와 **단 한 번의 결정적 순간(당첨)**이 교차하는 지점이라 Redis가 아주 적합한 선택지이다.

잭팟 누적 시스템 아키텍처 진단

• 동시성 처리 :
  • 수많은 유저가 슬롯을 돌릴 때마다 발생하는 누적 금액 업데이트를 RDBMS에서 처리하면 DB Lock 경합으로 인해 처리량이 급격히 떨어진다.
  • Redis의 INCRBYFLOAT은 싱글 스레드 특성상 Race Condition 없이 안전하고 빠르게 누적을 처리한다.
• 실시간성 :
  • 잭팟 금액은 모든 유저에게 실시간으로 중계되어야 한다.
  • Redis에 저장된 값은 조회 성능이 O(1)이므로 API 응답 속도 최적화에 유리하다.
• 휘발성 대응
  • 잭팟 금액은 유실되면 안 되는 중요한 데이터이다.
  • 따라서 단순히 캐시로 쓰는게 아니라 AOF(Append Only File) 설정을 appendfsync everysec 정도로 유지하여 성능과 안정성의 타협점을 찾는 것이 일반적

Lua Script 실행 중 장애가 발생하면?

많은 분이 "Lua Script는 원자적(Atomic)이다" 라고 알고 있지만, 운영 관점에서는 "중간에 실패하지 않는다는 뜻이 아님을 주의해야 한다.

스크립트 실행 중 Redis 프로세스가 다운된다면?

Lua Script는 실행되는 동안 다른 명령어가 끼어들지 못하는 격리성을 보장하지만, 실행 도중 서버가 뻗으면 상황이 복잡해진다.

• 원자성의 한계 (All-or-Nothing이 아님)
  • Redis의 Lua Script는 관계형 데이터베이스의 트랜잭션과는 다르다.
  • 스크립트 중간에 에러가 발생하거나 서버가 죽으면, 에러 발생 직전까지 수행된 명령어들은 이미 데이터에 반영된 상태로 남는다
  • 즉, 롤백이 되지 않는다.
• AOF/Replication 상황 :
  • 스크립트가 완전히 끝나야 해당 로그가 AOF 파일에 기록되거나 Slave로 전파된다.
  • 만약 스크립트 실행 중간에 서버가 크래시 되면, Master에는 일부 데이터가 반영되었을 수 있지만 AOF나 Slave에는 해당 스크립트 전체가 기록되지 않아 데이터 불일치가 발생할 수 있다.