[야식마차 선착순 신청] - 데이터 모델 2안 · 동시성 전략 3안 비교

[wlgns12370]

비즈니스 요구사항

배경

기존 야식마차는 학생들이 30~60분 전부터 오프라인 줄을 서는 문제가 있었다. 이를 해결하기 위해 모바일 기반 선착순 신청 시스템을 도입하고, 오프라인 대기열을 온라인으로 전환한다. 야식마차 직접 도입 전 간식마차를 시범 운영하여 리스크를 검증한다. 신청자 정보에 대해서는 현장 QR에서 정보를 한번 더 수집한다. 전체 인원은 약 1,400명이고 아마 동시에 400명 정도는 확정적으로 접근할 것으로 예상

운영 정책

항목	내용
운영 기간	3일 (매일 독립 신청)
1일 정원	100명 or 150명 (고정, 변경 없음)
신청 오픈	매일 17:30 정각
수령 시간	18:00 ~ 18:30
노쇼 처리	DB 기록만 (페널티 없음)
중복 신청	동일 날짜 1인 1회, 3일 각각 독립 신청 가능

야식마차와 간식마차는 하루에 2개를 다 할 가능성은 0으로 보고 하루에 하나의 행사를 진행한다.

핵심 기능

• 선착순 신청: 17:30 정각 버튼 활성화, 마감 시 즉시 비활성화
• QR 티켓 발급: 신청 성공 시 고유 토큰 기반 QR 화면 제공
• 수령 확인: 관리자가 QR 스캔으로 수령 처리
  • 18:00 ~ 18:20: 신청자만 스캔 가능
  • 18:20 이후: 미신청자도 스캔 가능 (잔여 물량 현장 배부)
• 노쇼 자동 만료: 18:30 이후 미수령 티켓 자동 만료 처리

위 비즈니스 요구사항을 토대로 데이터 모델링 방법과 동시성 처리 전략에 대해서 고민하고 있습니다. 모델링 방법 1개와 동시성 처리 전략 1개를 선정하는 형태로 답변을 주시면 감사하겠습니다.

동시성 해결 전략

문제 정의

오후 5:30 신청 오픈 시, 수백 명이 동시에 "신청하기"를 누르는 상황에서 Race Condition이 발생한다.

잔여 수량 조회 (remaining = 100)
         ↓
잔여 수량 감소 (remaining - 1)

이 두 단계 사이에 다른 요청이 끼어들면 100명 정원인데 150명이 동시에 성공 응답을 받을 수 있다.

---

방안 1 — DB 원자적 UPDATE 선점 전략

remaining 필드를 두어 전체 정원에서 차감해 나가는 방식입니다.

장점

• 지금 시도위는 Redis는 없는데 MySQL이 있어 추가적인 인프라 비용이 없습니다.
• 구현 2줄, 가장 단순
• 다중 컨테이너 환경에서도 DB가 직렬화 처리

단점

• 모든 요청이 DB를 한 번씩 거침 (핫스팟 row 부하)
• 이 규모(100150명 정원, 수백수천 경쟁)에서는 충분히 감당 가능

---

방안 2 — 캐시(Redis)를 활용하는 원자적 선점 전략

Redis
장점

• DB를 사용하는 선점 방식보다 처리량이 높음

단점

• Redis 컨테이너 추가 필요
• Redis 장애 감지 시스템 필요

---

방안 3 — DB SKIP LOCKED 분산 슬롯 선점 전략

슬롯 100개를 행으로 미리 생성한다. FOR UPDATE SKIP LOCKED로 각 요청이 서로 다른 행을 경합 없이 선점한다. 이미 락이 걸린 행을 건너뛰기 때문에 대기(blocking) 없이 병렬 처리된다.

장점

• 추가 인프라 없음
• 경합 없이 각 트랜잭션이 다른 슬롯 선점 → 높은 처리량

단점

• 슬롯 사전 생성 로직 필요
• 노쇼 반환 시 복구 로직 필요

---

데이터 모델링 전략

모델 A — events 테이블 포함

members (1) ──── (N) applications (N) ──── (1) events

events
├── id
├── event_date   DATE
└── status       ENUM(SCHEDULED, OPEN, CLOSED)

applications
├── id
├── member_id    FK → members
├── event_id     FK → events
├── ticket_token VARCHAR
├── status       ENUM(PENDING, CONFIRMED, NO_SHOW)
└── confirmed_at DATETIME

UNIQUE (member_id, event_id)

---

모델 B — events 테이블 없음

members (1) ──── (N) applications

applications
├── member_id    FK → members   -- PK
├── event_date   DATE           -- PK (이벤트 구분자)
├── ticket_token VARCHAR
├── status       ENUM(PENDING, CONFIRMED, NO_SHOW)
└── confirmed_at DATETIME

PRIMARY KEY (member_id, event_date)

선택 근거

• 정원·오픈시간이 고정값 → DB에 저장할 이유 없음
• 정원 변경·삭제 없음 → 정규화 실익 없음
• 이벤트 통계는 GROUP BY event_date COUNT 쿼리로 충분
• 정원 초과 방지는 WAS 또는 Redis 레벨에서 처리

---

지금까지의 비즈니스적 명세로 봤을때 어떤 전략의 조합이 가장 타당할지 고민이 됩니다.

[chjh1211]

2번 추가 내용
(1) 야식마차 테이블을 따로 만들지 않아도 된다고 생각하는 이유

• 메뉴는 행사마다 수요조사가 이루어지므로 이전의 정보를 저장할 이유가 없음.
• 신청 테이블에 야식마차 날짜 속성만 추가하면 된다고 생각.
• 일정 시간 지난 후에는 온라인 서비스를 이용하지 않은 사람들도 야식마차를 수령할 수 있기 때문에 오프라인으로 따로 명부를 받아둠. 매 야식마차마다 excel 파일로 신청자를 저장하기 때문에 따로 테이블을 만들 필요가 없다고 생각합니다.

[BGMSound]

이벤트 테이블 자체는 이것저것 요구사항이 생겼을 때 감안해서 필요해보이고,
방안4나 5는 코드적으로 좋지 못한 구조같아서

레디스 분산락 + DB Update구조로 가는게 무난하지 않을까 싶습니다.

[BGMSound]

아니면 uuidv7같은걸로 id매겨서 락없이 insert한다음에 선착순 n명 (재고 갯수만큼) 해주는 방식도 있을 것 같아요.
밀리세컨드단위까지 처리하고 동일ms단위에서는 랜덤하게 순서가 결정된다는 문제가 있긴 한데 크게 문제될 것 같지 않기는 합니다

[polyglot-k]

@BGMSound 단일 서버 기준이면 Redis는 불필요한 것 같군요,,

[jumdo12]

이벤트 테이블은 필요해보이고 레디스 없이 DB Update만으로 충분할 것 같네요

[BGMSound]

저도 이거 좀 비슷한 생각이긴 한게 그냥 디비 스케일업으로도 충분할 것 같긴 해서 그냥 스트레스테스트 한번 해보고 멀쩡하면 디비만 쓰는게 좋아보이긴 해요

[wlgns12370]

사실 저도 테이블 넣고 DB로만 처리하는 게 효율적이라는 생각이 들었어요. 규민님 말씀대로 일단 이 방식으로 빠르게 구현해서 K6로 스파이크 테스트랑 스트레스 테스트 한번 해서 RPS 지표 보고 더 이야기해보면 좋을 것 같네요

[polyglot-k]

p2; events 테이블을 한다고하면, 해당 이벤트 이름은 따로 설정을 못하나요? event_date 를 봤을 때 이벤트가 진행하는일자 같은데, 확장성을 고려해서 DATETIME 과 시작이랑 끝 시간대를 받고 처리하는게, 조금 더 나을 것 같다는 생각이 듭니다.

[wlgns12370]

좋습니다! DATETIME을 가져가서 재오픈이나 버그가 발생해서 해결할때, DATE 타입보다는 유용하게 사용할 수 있을 것 같습니다.

[polyglot-k]

ask; 전체 인원은 약 1,400명이고 아마 동시에 400명 정도는 확정적으로 접근할 수 있다면, 400tps 정도로 추산하고 있다고 하는건데, DB 기준으로 ms 만큼 단위로 처리가 된다고 추산하면, 1000개 정도 될 것 같고, 커넥션 자원이나 로스율을 고려하더라도 400tps 정도는 DB로 충분히 대응이 가능할 것 같습니다

ms단위는 기본적 disk 속도의 평균 단위대를 기준으로 말씀드린겁니다

또한 서비스의 특성상 장기적보다는 단발적으로 사용될 확률이 높아서, 단순성이 더 큰 이점으로 작용할 것 같습니다.
오히려 처리량에 대한 부분을 약간 개선하고자 한다면, 한개의 WAS 자원에서 접근할 수 있는 thread 공유가 되는 메모리 자원을 통해서, 일괄적으로 처리량 제어를 하게 되면, 좀 더 안정적으로 가능 할 것 같습니다.

부하 테스트의 형태도 예상해보면, 초반 추세가 강하고 ( 1분 정도 ), 그 이후에는 크게 리스크가 강할 정도의 트래픽이 생기지는 않을 것 같습니다

[wlgns12370]

좋은 것 같습니다! 일단 RDB만으로 테스트를 한번 해보고 수치를 보고 감당하기 어렵다면 메모리 레벨에서 선착순 처리를 고려하겠습니다.

[polyglot-k]

p4; 오히려, 실험하는 때에 유실이나 기타 장애등으로 긴급 Hotfix 가 배포되어야한다면, 중단 없이 잘 배포가 되는지, 뭔가 처리되는 것이 있으면 Graceful하게 처리되는지에 대한 부분을 신경쓴다면 완성도가 더 높을 것으로 보입니다.

[wlgns12370]

넵 실제 서비스를 하면서 서비스 장애가 발생했을때 완벽하게 종료되는지 파악하고 반영해두겠습니다.

[wlgns12370]

포스트모템처럼 장애가 발생했을때 로그 기반으로 앞으로 똑같은 문제를 해결할 수 있게 해야합니다. 근데 지금 로그 시스텀이 어떻게 되어있는지 파악이 필요할듯 합니다.

[polyglot-k]

그냥 생각난 부분은 분산락 제어가 필요하다면, DB 1개 기준으로, Redis 만큼의 처리량이 불필요하다면 Named Lock 을 활용해볼 수도 있을 것 같습니다.

Redis를 쓰게 된다면, ZSET 형태를 활용해보는 것도 좋은 방향이겠지만, 현재 산정된 SLA 기준으로는 있는 것이 오히려 관리 비용을 높일 것 같음

[jbh010204]

앞서 다른 분들이 대부분 좋은 주제로 달아주셨네요! 저도 가볍게만 남기자면
Model A + DB atomic UPDATE 방향에 동의합니다. 야식마차는 신청 취소 기능을 두지 않는 전제로 잡으니까 지금 구조도 좋은 것 같습니다!

그리고 태현님께서 오픈 시간을 정책상 미룰 수 있으니, 신청시간을 DATETIME 변경 및 신청시간 판단을 Java가 아니라 원자적 UPDATE 안에서 처리하면 좋을듯 합니다!

또한 단일 원자적 UPDATE에서 RPS를 늘리는 방향으로 Comit 단일 WAS인 점을 활용해 DB 앞에 인메모리 게이트를 두고 명백한 초과분은 DB까지 안 보내고 즉시 거절하는 게 가성비가 좋다고 봅니다.정확한 정원 컷의 최종 보증은 항상 위 조건부 UPDATE가 맡고, 인메모리는 부하만 덜어주는 보조 역할!

항상 파이팅입니다 😎

[adorableco]

글 잘 읽었습니다 ~ ^^
저도 Redis 같은 다른 인프라 없이 DB 단에서 충분히 해결 가능할 것이라고 생각합니다.
최근에 Shopify에서 재고 예약 기능을 Redis에서 MySQL의 SKIP LOCKED 기능을 사용하는 것으로 전환했다는 소식을 접해서, 개인적으로는 이 서비스에서도 SKIP LOCKED 방안으로 어떻게 풀어나갈 수 있을지 궁금하긴 하네요 ㅎㅎ
근데 해당 방식은 이벤트가 있을 때마다 제한 개수만큼의 레코드를 생성해야하는 작업이 필요하다는 단점이 있기 때문에 결국에는 DB Atomic UPDATE 방안이 가장 간단한 해결책인 것 같습니다!

[wlgns12370]

400명 기준 부하테스트를 완료했습니다. 실제로 400RPS정도가 나왔는데 600, 800명까지 올라갔을때 약 250~300RPS가 나왔네요. 일단 이번 서비스를 하면서 오류가 발생하거나 서버가 중단되는 문제는 발생하지 않을 것 같습니다. 이번에는 이대로 진행하고 매트릭을 보고 next step 도입을 고려해도 될 것 같습니다.

그래도 학부 전체 인원은 1,400명이니까 당장의 next step으로는 1. 데이터 베이스 스킵락, 2.WAS 메모리에서 선착순 처리 로직 수행, 3. MySQL innodb buffer pool 튜닝이 떠오르네요. 다들 좋은 의견 많이 내주셨는데 next step에 대한 고민은 다른 디스커션에서 이야기 해봅시다!