동시성 처리를 위한 데이터 베이스 설계

[wlgns12370]

배경

저희 요구사항을 요약하자면, "환전소는 7일전에 오픈과 클로즈 시간까지 30분 단위의 데이터베이스 행에서 디폴트로 6명 예약할 수 있습니다. (실제 인원은 변경 가능합니다.)"

환전소 별 한정된 자리에 예약하는 테이블 구조는 위와 같습니다. 해당 구조를 설계 했을 때, Race Condition 문제가 발생합니다. 이를 해결하기 위한 방법으로 아래와 같이 생각했습니다.

---

해결방안

방안 A: 1 Row LOCKED

BranchTimeSlot에 remaining field를 두고 비관적 락을 통해 차감하는 방식입니다.

락 경쟁은 BRANCH_TIME_SLOT 행 하나(1 row)에서 일어납니다. 락을 잡은 스레드가 remaining > 0을 확인하고 차감한 뒤에만 RESERVATION에 자신의 행을 INSERT합니다. 모든 스레드가 이 하나의 잠긴 행을 순서대로 통과해야 하므로, N쪽 행은 항상 한 번에 하나씩, 락을 획득한 순서대로만 생성됩니다.

방안 B: SKIP LOCKED (신청 슬롯 사전 생성)

일주일 전부터 예약을 할 수 있기 때문에 일주일전에 batch를 통해 Reservation Row를 미리 생성합니다. 신청 요청은 SELECT ... FOR UPDATE SKIP LOCKED LIMIT 1로 잠기지 않은 슬롯을 원자적으로 선점하고, 해당 row를 신청자 정보로 UPDATE합니다.

N쪽 행 6개는 어떤 요청이 오기도 전에 이미 다 만들어져 있습니다. (time_slot_id, member_id) 복합 인덱스로 각 스레드는 비어있는(member_id가 null인) 행을 O(log N)에 찾은 뒤 SELECT ... FOR UPDATE SKIP LOCKED LIMIT 1로 그 행을 잠급니다. R1이 이미 잠근 행은 R2, R3이 건너뛰고 다음 빈 행으로 넘어갑니다.

---

방안별 장단점

방안 A: 1 Row LOCKED

장점

• 구현이 단순합니다. SELECT ... FOR UPDATE로 remaining을 확인하고 차감한 뒤 커밋하는 한 단계로 끝나고, 배치나 사전 생성 로직이 필요 없습니다.
• 예약이 확정되는 시점에만 Reservation row가 생성되므로, 방안 B에서 발생하는 주인 없는(unclaimed) row 문제가 없습니다.

단점

• 처리량이 슬롯 정원(최대 6)에 의해 사실상 상한이 걸립니다. 같은 슬롯에 요청이 몰리면 나머지 요청은 락 대기열에 쌓여 응답 지연이 커집니다.
• DAU가 늘어나 인기 슬롯에 요청이 집중되면 이 구조로는 감당이 안 될 수 있고, 그때는 SKIP LOCKED나 캐시 계층으로 옮기는 재설계가 필요합니다.

방안 B: SKIP LOCKED

장점

• 서로 다른 행을 잠그기 때문에 요청이 몰려도 대기 없이 병렬로 처리됩니다 — 처리량이 슬롯 정원에 묶이지 않습니다.
• 예약자 정보가 이미 만들어진 행에 UPDATE로만 들어가므로, 조회 시점에 항상 실제 예약 상태를 그대로 볼 수 있습니다.

단점

• 예약 가능 기간(일주일) 전에 정원만큼 행을 미리 만들어야 해서 별도 배치 잡이 필요하고, 그 배치가 실패하거나 지연되면 예약 자체가 불가능해지는 새로운 장애 지점이 생깁니다.
• 주인 없는(member_id가 null인) row가 항상 존재하는 상태가 정상이라, 데이터 정합성 관점에서는 다소 낯선 모델입니다.
• 정원(capacity)이 바뀌면 이미 생성된 N개의 행을 늘리거나 줄이는 별도 로직이 필요해서, 방안 A보다 정원 변경에 대한 대응이 복잡합니다.

---

의견 요청

JVM 로컬 캐시나 Redis 같은 글로벌 캐시로도 이 race condition을 해결할 수 있다고 생각했지만, 캐시를 두면 DB와의 정합성까지 관리해야 해서 지금 단계에서는 오버엔지니어링이라고 판단해 RDB만으로 우선 해결하기로 했습니다. 그 안에서 방안 A와 B의 장단점을 정리해봤지만, 저희끼리 결론을 내리기보다 최종 판단은 멘토님께 맡기고 싶습니다.

궁금한 점은 다음과 같습니다.

• 캐시 도입을 보류하고 RDB로 우선 해결하기로 한 판단이 타당한지 궁금합니다.
• 위 장단점을 보셨을 때 방안 A와 B 중 이 상황에서는 무엇을 추천하시는지, 혹은 저희가 놓친 제3의 방향이 있는지 궁금합니다.
• 실무에서는 이런 동시성 문제를 어떤 기준으로 판단하고 결정하는지 궁금합니다.

[GyunHeee]

동시성 처리 방안 검토 — 방안 A 채택 제안 (Discussion #13 관련)

결론

방안 A(1 Row LOCKED, 비관적 락) 채택을 제안합니다.

근거

1. 락 대기열 리스크가 제한적입니다
슬롯 정원이 6명으로 하드캡되어 있어, 방안 A의 최대 단점인 "락 대기열"의 상한도 사실상 정해져 있습니다. 최악의 경우에도 짧은 트랜잭션이 순차로 6번 처리되는 수준이고, 7번째 요청부터는 락을 기다릴 필요 없이 곧바로 마감 응답을 줄 수 있어 우려되는 지연이 실제로는 크지 않을 것으로 예상됩니다.

2. 방안 B는 지금 단계엔 운영 비용이 큽니다
사전 생성 배치라는 새로운 장애 지점이 생기고(배치 실패 시 예약 자체 불가), 정원이 바뀔 때마다 행을 재조정하는 로직이 추가로 필요합니다.

3. 검증되지 않은 트래픽을 미리 가정하지 않습니다
단순한 구조로 시작하는 게 합리적이라고 판단했습니다. 캐시 도입을 보류하고 RDB로 우선 해결하기로 한 결정과도 같은 맥락으로, 일관성 있는 방향입니다.

대규모 트래픽 대비 — 측정 기반 전환 계획

방안 A 채택 후, 특정 슬롯에 요청이 몰리는 상황을 가정한 부하테스트를 설계해 아래 지표를 실측합니다.

지표	설명
락 대기 시간	슬롯당 락 획득까지 걸리는 시간
p95 / p99 응답 지연	예약 요청 응답 시간 분포
데드락 발생 여부	트랜잭션 충돌로 인한 데드락 발생 유무
처리량 (TPS)	초당 처리 가능한 예약 요청 수

위 지표에 임계치를 미리 정의해두고(예: 락 대기 200ms 초과, 특정 TPS 초과), 임계치를 넘는 것이 관측되면 방안 B(SKIP LOCKED)로 전환하는 것을 로드맵에 명시합니다.

멘토 논의 필요 사항

• "A로 시작 → 부하테스트로 검증 → 조건부 B 전환" 흐름이 실무 판단 기준으로도 합리적인지
• 부하테스트 진행 시점 (MVP 완성 직후 vs 실사용 트래픽 데이터 축적 후)
• 전환 트리거로 삼을 임계치(락 대기 시간, TPS 등)를 실무에서는 보통 어떻게 잡는지

[hyun7586]

제한된 기간 내에 전체 비즈니스 플로우를 빠르게 완성하는 것이 우선이므로, 구현이 간편한 방안 A를 먼저 도입하고 추후 방안 B로 확장할 여지를 두는 방향을 제안합니다.

슬롯당 예약 정원은 최대 상한선이 존재하므로 우려되는 락 대기열 병목 리스크도 크지 않을 것 같긴 합니다.
또한 구현 및 실측 지표가 없는 상황에서 개념 논의만으로 고비용의 방안 B를 선택하는 것 또한 부담일 것 같습니다.

따라서 방안 A로 플로우를 신속히 구현한 뒤, 추후 부하 테스트 성능 실측 데이터를 기반으로 방안 B로의 전환을 검증하는 로드맵이 가장 합리적이라고 생각합니다.