선착순 이벤트 시스템 개발하려고 하는데 제가 알고있는 지식이 맞는지 궁금합니다.

Question

안녕하세요. 현재 스프링으로 선착순 쿠폰 기능을 개발하고 고도화하고있습니다.비관적 락을 쓰다가 Redis 분산락 + RedisStream으로 개선을 하였습니다. 현재 RedisStream은 이벤트 순서 보장을 위해 단일 컨슈머로 구성되어 있으며, 하나의 Stream에서 순차적으로 메시지를 처리합니다. 현재 초당 2,200건의 요청을 보냈을 때 응답속도가 0.3초, TPS가 2,200정도 나옵니다.근데 생각해보니 굳이 락 없어도 Redis가 싱글 스레드 기반이니,현재 Redis의 락 기능만을 사용하고있는데 Redis DB에 이벤트별로 목표금액과 이벤트 상태에 대해서 넣어놓고, 요청이 올 때마다 목표금액을 차감하고 목표금액이 0원에 도달하면 이벤트 상태를 종료로 바꾸면 동시성이 알아서 보장되지않을까? 라는 생각을 하게되었습니다. 애초에 Redis를 사용하면 순차적으로 처리된다고 생각하였습니다.(이게 맞는 지 잘 모르겠습니다.)또 이벤트 순서 보장을 위해 단일 컨슈머로 구성된다고 했으나, Redis DB로 목표금액을 차감하고 상태를 관리하게되면 이후의 처리들은 다중 컨슈머를 두어서 병렬로 처리되어도 상관없지않을까라는 생각을 하였습니다.마침 더 성능 고도화를 해보고자 초당 요청 수를 늘릴예정인데,갑자기 수만건의 요청을 보내면 견디지 못하고 서버가 죽을 것이라고 생각하여 Kafka나 RabbitMQ와 같은 메시지 큐를 도입하여 여러 파티션을 두고(RabbitMQ라면 큐를 두고) 대용량 트래픽에 대한 핸들링을 하려고 합니다.그래서 생각한 방법이,Redis에서 이벤트별ID로 목표 금액과 이벤트 상태를 넣어놓고, 사용자가 요청을 하면 오면 Redis의 목표금액을 감소시킵니다.최종적으로 목표 금액이 0원이 되면 Redis의 이벤트 상태가 종료로 바뀌게되며, 마지막 사용자가 당첨되는 구조입니다.이벤트 상태가 종료로 바뀌면 이후의 요청들은 다 실패합니다.이후 사용자의 포인트를 감소시키거나, 포인트 내역을 발급하는 등의 처리는 Redis 처리 직후 RabbitMQ 등 MQ에 메시지로 전송하여 eventId를 기준으로 큐를 N개로 샤딩해 병렬 처리합니다.이런 구조인데요.진행하기 전에 제 지식이 맞는지 좀 확인해보고싶은데요. 헷갈려서 제가 이해한 게 맞는지 확인해주실 수 있나요?수만건의 요청을 받아도(멀티 스레드로 동작해도) Redis는 싱글 스레드 기반이기때문에 순차적으로 처리하는 것이 맞나요? (이것 때문에 동시성이 보장되는 것 같은데 확실하게 알고싶습니다.)목표 금액을 감소시키고 나서는 순서가 상관없어 비동기로 작동해도 상관없는데, 이러한 경우 Kafka나 RabbitMQ에 여러 파티션을 두고 처리해도 상관없는건가요?Redis 분산락과 RedisStream을 통해서 성능 개선을 한 과정은 대용량 트래픽 처리라고 볼 수 없는거지요? 그냥 부하 테스트를 해본 경험이라고 할 수 있는걸까요?위에서 말한 방향이 맞는 방향일까요?감사합니다.

kyuho · Accepted Answer

Redis DB로 목표금액을 차감하고 상태를 관리, 1번 질문쿠폰 선착순 기능에서 “잔여 수량 확인 → 감소 → 상태 변경 → 응답” 흐름을 단순히 여러 Redis 명령으로 나뉘어서 실행 될텐데, 락 없이 사용하는 경우에는 RDB에서 발생할 수 있는 lost update가 동일하게 발생할 수 있어요.다만, 앞에 분산락을 그대로 사용하면 동시성 보장은 가능해요. Redis 공식 문서에 분산 락 파트 한번 읽어보시면 많은 도움 되실 것 같아요. https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/목표 금액을 감소시키고 나서는 순서가 상관없어 비동기로 작동해도 상관없는데, 이러한 경우 Kafka나 RabbitMQ에 여러 파티션을 두고 처리해도 상관없는건가요?네, 메시지 중복이나 순서만 잘 고려한다면 상관 없어요. 큐 시스템을 처음부터 도입해야 한다면, AWS SNS + SQS 조합도 고려해볼 수 있겠네요.Redis 분산락과 RedisStream을 통해서 성능 개선을 한 과정은 대용량 트래픽 처리라고 볼 수 없는거지요? 그냥 부하 테스트를 해본 경험이라고 할 수 있는걸까요?"대용량 트래픽 처리"는 정의하기 나름이라서 잘 포장하면 되지 않을까 싶긴하지만, 단순 성능 개선의 영역이라고 생각해요. 부하 테스트는 시스템이 어느 정도의 요청까지 견디는지 측정하는 행위에 집중하는 거라 분리해서 보시는게 좋을 것 같아요.

chytonpide · Answer

이하 GPT 답변입니다.안녕하세요! 선착순(쿠폰/예산 소진) 이벤트 구조를 멋지게 다듬고 계시네요.핵심부터 정리하고, 질문에 하나씩 정확히 답한 뒤, 권장 설계/스크립트 예시와 운영 팁을 드리겠습니다.TL;DR (핵심 결론)“Redis가 싱글스레드니까 동시성이 자동 보장된다” → 명령 단위로만 맞습니다.DECRBY, INCRBY, SADD 같은 단일 명령은 원자적입니다. 하지만 “읽고-판단하고-쓰기”처럼 여러 명령을 조합하면 경쟁 조건이 생깁니다. 따라서 락 대신 Lua 스크립트(EVAL) 또는 MULTI/EXEC(WATCH)로 원자적 1회 처리를 만드시는 게 정석입니다. (보통 Lua 권장)“목표금액(재고/예산) 차감”은 Redis에서 원자적으로 끝내고, 이후 작업은 MQ로 비동기 처리가 좋습니다.Kafka/RabbitMQ에 이벤트 단위로 파티셔닝해 병렬 처리하면 됩니다. 다만 *아이템포턴시(중복 방지)*와 엔티티 단위 순서 보장(필요하다면 eventId/userId 파티셔닝)을 반드시 고려하세요.분산락 + Redis Streams의 단일 컨슈머로 2,200 TPS → 병목을 제거했다는 의미는 있지만, “대용량 처리의 종단 구조”라고 보기는 어렵습니다. 락을 없애고 Lua로 게이팅(승/패 판정)을 한 방에 처리하면 더 큰 TPS도 충분히 나옵니다. 실제 대규모 트래픽 대비에는 백프레셔, 아이템포턴시, 파티셔닝, 장애/재시도 전략까지 포함해야 합니다.지금 생각하신 방향(차감은 Redis, 후속은 MQ 병렬)은 맞는 방향입니다.단, 오버셀 방지/중복방지/상태전환까지 전부 하나의 Lua 스크립트에서 처리하고, 동일 스크립트 내에서 스트림(outbox)로 기록(또는 Kafka로 릴레이할 로컬 outbox)에 남겨 정합성 + 전달 보장을 챙기시면 훨씬 견고해집니다.질문별 정확한 답변1) “수만 건을 동시에 보내도 Redis가 싱글스레드라 순차 처리 → 동시성 보장?”부분적으로만 맞습니다. Redis는 명령 실행 자체는 단일 스레드라 각 명령은 원자적입니다.하지만 다음은 원자성 보장 안 됨:GET으로 남은 금액 확인 → 조건 판단 → DECRBY 로 차감 (여러 명령): 사이에 끼어들 여지가 있어 오버셀 위험.정답: 모든 판정과 갱신을 한 번에 하는 Lua 스크립트를 쓰세요. 그러면 한 요청 = 한 원자적 명령이 되어 순서/경쟁 이슈가 사라집니다.Redis Cluster를 쓰면 샤드(파티션)별 단일 스레드입니다. 여러 키가 서로 다른 샤드에 있으면 전역 순서는 없습니다. 이벤트별 키들을 같은 해시 슬롯에 묶는(예: event:{123}:remaining) 식으로 키 태깅을 권장합니다.2) “목표 금액 감소 후엔 비동기여도 되니 Kafka/RabbitMQ 파티션 늘려도 문제 없나?”네. 차감·상태전환까지 Redis에서 확정하고, 그 결과(승/패, 잔여량, 시퀀스 등) 만 MQ로 보내 후속 처리(포인트 차감/내역 발급) 를 병렬로 하시면 됩니다.필수 고려사항아이템포턴시: eventId + userId + requestId 등으로 중복 처리 방지 키를 잡고, 소비자 측은 멱등하게 만드세요.순서 필요 범위 정의: 사용자별 혹은 이벤트별로만 순서가 필요하면 그 키 기준 파티셔닝(Kafka partition key, RabbitMQ는 큐 샤딩)으로 충분합니다.재시도/실패 처리: DLQ, 최대 재시도 횟수, 지연 재시도(backoff), 운영 알람까지 세트로.3) “Redis 분산락 + RedisStream 성능 개선 = 대용량 트래픽 처리 경험인가?”락/단일 컨슈머 구조는 본질적으로 병목입니다. TPS 2,200, 응답 0.3s는 나쁘지 않지만 Redis 자체가 훨씬 더 높은 처리량도 가능하므로 락 제거 + 원자 연산/스크립트가 먼저입니다.따라서 현 구조는 *‘부하 테스트 경험’*에 가깝고, 대용량(수십만/수백만 RPS급) 설계로 가려면 락리스·파티셔닝·백프레셔·아이템포턴시·장애 시나리오까지 아우르는 설계가 필요합니다.권장 아키텍처(요약)[Clients] | v [API (Spring)] | | (1) Lua 스크립트 1회 호출로 승/패 확정 + 상태전환 + outbox 기록 v [Redis] <—(XADD)—— [Outbox Stream (event:{id}:outbox)] | | | v | [Outbox Consumer(여러대, Consumer Group)] | | | (2) Kafka/RabbitMQ 로 릴레이 | | v v 즉시 응답(승/패) [Point 서비스/DB] (아이템포턴시 보장, 재시도/DLQ) (1) API ↔ Redis: Lua로 차감/중복검사/상태전환/XADD outbox를 원자적으로 처리 → 오버셀/중복 없음.(2) Outbox → MQ: Redis Stream을 내부 outbox로만 쓰고(원자성 확보), 별 컨슈머가 MQ에 안전하게 전달. 이후는 MQ 소비자들이 병렬 처리.Lua 스크립트 예시 (원자 처리)개념 예시입니다. 키 네이밍/만기/필드 등은 팀 규칙에 맞춰 조정하세요.키KEYS[1] = event:{id}:remaining (남은 금액/수량)KEYS[2] = event:{id}:status (OPEN/CLOSED)KEYS[3] = event:{id}:winners (Set: userId 모음, 1인 1회 보장용)KEYS[4] = event:{id}:reqdedup (Set: requestId 멱등 처리)KEYS[5] = event:{id}:outbox (Stream: 후속 처리용 outbox)인자ARGV[1] = cost (차감 금액/수량, 보통 1)ARGV[2] = nowMsARGV[3] = eventIdARGV[4] = userIdARGV[5] = requestIdARGV[6] = dedupTtlMs (요청 중복키 만료)-- return codes: -- 1=WIN(성공), 0=LOSE(매진/종료), 2=DUP(중복), 3=INVALID(이벤트 미존재 등) local remainingKey = KEYS[1] local statusKey = KEYS[2] local winnersKey = KEYS[3] local reqDedupKey = KEYS[4] local outboxStream = KEYS[5] local cost = tonumber(ARGV[1]) local nowMs = ARGV[2] local evId = ARGV[3] local userId = ARGV[4] local reqId = ARGV[5] local dedupTtl = tonumber(ARGV[6]) -- 멱등: 동일 requestId 재처리 방지 if redis.call('SISMEMBER', reqDedupKey, reqId) == 1 then return {2, 'DUP_REQUEST'} end local status = redis.call('GET', statusKey) if status == 'CLOSED' then redis.call('SADD', reqDedupKey, reqId); redis.call('PEXPIRE', reqDedupKey, dedupTtl) return {0, 'CLOSED'} end local remaining = tonumber(redis.call('GET', remainingKey) or '-1') if remaining < 0 then return {3, 'NOT_FOUND'} end -- 1인 1회 제한: 이미 승자면 중복 if redis.call('SISMEMBER', winnersKey, userId) == 1 then redis.call('SADD', reqDedupKey, reqId); redis.call('PEXPIRE', reqDedupKey, dedupTtl) return {2, 'ALREADY_WINNER'} end -- 잔여 체크 + 차감 if remaining < cost then redis.call('SADD', reqDedupKey, reqId); redis.call('PEXPIRE', reqDedupKey, dedupTtl) return {0, 'SOLD_OUT', remaining} end local newRemaining = redis.call('DECRBY', remainingKey, cost) -- 승자 등록 redis.call('SADD', reqDedupKey, reqId); redis.call('PEXPIRE', reqDedupKey, dedupTtl) redis.call('SADD', winnersKey, userId) local newStatus = 'OPEN' if newRemaining == 0 then redis.call('SET', statusKey, 'CLOSED') newStatus = 'CLOSED' end -- outbox에 원자적으로 적재 (후속 처리용) redis.call('XADD', outboxStream, '*', 't', nowMs, 'eventId', evId, 'userId', userId, 'reqId', reqId, 'cost', cost, 'remaining', newRemaining, 'status', newStatus) return {1, newStatus, newRemaining} 이 스크립트 하나로 승/패 판정 + 잔여 차감 + 상태 전환 + 중복 방지 + outbox 기록이 원자적으로 끝납니다.API 서버는 이 반환값만 보고 즉시 “성공/실패” 응답을 합니다.Spring(lettuce/jedis) 구현 팁애플리케이션 시작 시 SCRIPT LOAD로 SHA 로드 → 런타임에는 EVALSHA 사용.타임아웃을 짧게, 커넥션 풀/네트워크 RTT 최소화, 파이프라이닝 금지(이 호출은 1회 원자성 유지가 목적).이벤트별 키는 해시태그(event:{123})로 묶어 Cluster에서도 같은 슬롯에 유지.Redis Streams vs Kafka/RabbitMQStreams(내부 outbox 용도): 상기 Lua와 원자적으로 XADD가 가능 → “승자 확정과 기록”이 같은 트랜잭션 안에 들어갑니다. 이후 컨슈머 그룹으로 MQ로 릴레이(At-least once).Kafka: 매우 높은 처리량/파티션별 순서 보장. eventId/userId로 파티셔닝하면 순서 요구를 충족하면서 수평 확장 용이.RabbitMQ: 라우팅 유연·간단, 워커 수평 확장 쉬움. 큐 샤딩으로 병렬성 확보.일반 패턴: “정합성 중요한 결정(승/패)”은 Redis에서 확정, “무거운 후속 작업”은 MQ로 비동기.성능/안정성 체크리스트락 제거: 분산락/비관적락은 최대한 배제. 원자 명령/스크립트로 전환.핫키 대비: 동일 이벤트 키가 초고열이면, 서버/네트워크가 먼저 병목. API 앞단에 레이트리미트/대기실/샘플링으로 초당 유입 제어.아이템포턴시: requestId(예: 클라이언트 UUID) 강제, 만약 재시도 폭탄이 와도 안전.Failover/지속성:Redis는 마스터에만 쓰기. 읽기 복제본에선 읽지 마세요(지연/스테일).AOF 정책(매 1초 fsync vs always)과 성능/내구성 트레이드오프를 결정.승인 강화를 원하면 WAIT(레플리카 적용 확인) 사용을 검토하되 지연 증가 감안.백프레셔/재시도: MQ는 DLQ/지연 재시도(backoff), 소비자 멱등 처리.모니터링: 승/패 비율, 오버셀 0, Lua 오류율, Stream PEL, MQ 재시도 수, Redis CPU/lat/RPS, 키 사이즈/만기 등 대시보드화.테스트 시나리오:동시 다발 요청에서 오버셀 0 보장중복 요청(네트워크 재전송/클라 재시도) → 1회 처리마감 임박(잔여 1~5)에서 정확한 마감/상태 전환Outbox 컨슈머 다운/복구 시 유실 없이 MQ 전달Redis 마스터 장애 전환, AOF 리라이트, 네트워크 지연 상황“내 구조, 맞는 방향인가?”에 대한 최종 코멘트네, *“Redis에서 선착순 판정 확정 → MQ로 후속 처리 병렬화”*는 업계 표준에 가까운 올바른 방향입니다.보완 포인트는 딱 두 가지입니다:락 제거하고 Lua(혹은 WATCH/MULTI) 로 원자적 1회 처리로 바꾸기.아이템포턴시 + outbox 패턴으로 정합성과 전달 보장을 같이 챙기기.이렇게 정리하시면 수만 건 급증에도 “정합성 보장 + 즉시 응답 + 후속 병렬 처리”가 깔끔하게 돌아갑니다.

선착순 이벤트 시스템 개발하려고 하는데 제가 알고있는 지식이 맞는지 궁금합니다.

2개의 답변

#mq 목록