2025년 3월 14일

Redis Lock을 활용한 endGame 중복 실행 방지

문제 상황

마피아 게임 서버에서 endGame 실행 시 WebSocket 이벤트가 여러 번 발생하며 동일한 데이터가 여러 번 저장되는 문제가 발생했다. 이는 같은 게임에 대해 여러 개의 WebSocket 이벤트가 동시에 실행되면서 중복 저장이 이루어진 것이 원인이었다.

해결 방법

1. 게임 서버 측 해결 방법

   • Redis의 lock:endGame:{roomId} 키를 활용하여 동일한 방에서 endGame이 한 번만 실행되도록 제한했다.
   • 락이 설정된 경우, 추가적인 endGame 실행 요청을 무시하도록 구현했다.

2. API 서버 측 해결 방법

   • Redis의 gameResult:{gameId} 및 gameAchievements:{gameId} 키가 존재하는 경우, 해당 게임 결과가 이미 저장된 것으로 간주하고 중복 저장을 방지했다.

Redis를 선택한 이유

Kafka나 RabbitMQ 같은 메시지 큐 시스템도 중복 메시지 방지 기능을 제공하지만, 다음과 같은 이유로 Redis를 선택했다.

• 추가적인 인프라 관리 부담 없음: 기존 Redis 인프라를 그대로 활용 가능하다.
• 빠른 응답 속도: WebSocket 기반 실시간 이벤트 처리에서는 Redis가 더 빠른 응답을 보장한다.
• 간단한 락 구현: Kafka나 RabbitMQ는 중복 메시지를 방지하기 위해 추가적인 설정(Offset, ACK 등)이 필요하지만, Redis는 간단한 Lock을 활용하여 해결할 수 있다.
• 분산 환경에서도 확장 가능: 멀티 서버 환경에서도 Redis Lock을 활용하면 endGame의 중복 실행을 방지할 수 있다.

Redis 락과 다른 분산 락 기술 비교

기술	특징	WebSocket 이벤트 처리 적합성
Redis 락	메모리 기반으로 속도가 매우 빠름, 운영이 단순함	✅ 적합
Zookeeper 락	분산 시스템 리더 선출, 락 획득 과정이 상대적으로 무거움	❌ 부적합
etcd 락	마이크로서비스 환경에서 설정 관리에 적합, WebSocket 처리 속도에는 부적합	❌ 부적합
Consul 락	분산 클러스터 관리, WebSocket 이벤트 처리에는 과한 솔루션	❌ 부적합

결론

Zookeeper, etcd, Consul과 같은 분산 시스템 솔루션은 WebSocket의 endGame 이벤트 처리에 비해 필요 이상으로 복잡한 기술이므로, 가볍고 빠른 Redis 락이 적절한 해결책이었다.

Redis는 메모리 기반으로 빠르며, 운영이 단순하고 유지보수 부담이 적다. 또한, Redlock을 활용하면 멀티 서버 환경에서도 중복 실행을 방지할 수 있다. 결과적으로 Redis를 활용한 락이 가장 적절한 선택이었다.