🚨 문제 상황 (Problem)
한정판 드랍(Drops) 도메인에서 재고 차감 및 상태 전이 로직에
낙관적 락(Optimistic Lock)을 도입했다.
초기에는 단일 인스턴스 환경이고 충돌이 잦지 않을 것이라 예상하여,
성능상 이점이 있는 낙관적 락을 선택했다.
하지만 서비스 오픈 시점에 트래픽이 몰리는 상황을 고려해 본 결과,
다음과 같은 심각한 부작용이 예상되었다.
- Retry Storm 발생: 수많은 요청이 동시에 동일한
version을 읽고
수정을 시도하면서 연쇄적인 충돌이 발생한다. - DB 부하 가중: 충돌 발생 시 애플리케이션 레벨에서 재시도를 반복하게 되는데,
이는 DB에 불필요한 요청을 계속 쏟아부어 전체 시스템 성능을 저하시킨다. - 높은 실패율: 재시도 횟수가 소진되면 대부분의 요청이 예외로 처리되어
사용자 구매 경험이 급격히 나빠진다.
💡 문제 해결 과정
1. 비관적 락(Pessimistic Lock) 검토 → 기각
비관적 락은 정합성을 강력하게 보장하지만, 트래픽이 폭주하는 환경에서는
DB 커넥션 풀 고갈과 병목 현상의 주범이 된다.
이전에 포인트 도메인에서 비관적 락이 유효했던 이유는,
동일 사용자의 단일 Row에 요청이 집중되는 구조라 충돌 빈도가 예측 가능하고
요청 규모도 제한적이었기 때문이다.
반면 드랍 도메인은 불특정 다수의 요청이 순간적으로 폭주하는 구조라
병목의 규모 자체가 달라 같은 전략을 적용할 수 없다.
멀티 인스턴스 환경에서의 확장성까지 고려하면 선택지에서 제외하는 것이 맞다고 판단했다.
2. Redis 분산 락(Distributed Lock) 단독 검토 → 불완전
Redis를 활용해 트래픽을 애플리케이션 진입 단계에서 직렬화하면
DB 부하를 획기적으로 줄일 수 있다.
하지만 Redis는 외부 인프라 자원이기에 다음과 같은 엣지케이스에서
정합성이 깨질 가능성이 존재한다.
- 락 해제와 커밋 시점의 불일치: Redis 락이 해제된 직후,
DB 트랜잭션이 최종 커밋되기 전의 찰나에 다른 스레드가 락을 획득하고 진입할 수 있다. - TTL 만료 및 네트워크 순단: 예상보다 로직이 길어져 락이 자동 해제되거나,
Redis 장애 시 락 없이 요청이 DB에 도달할 위험이 있다.
Redis가 아무리 안정적이어도 외부 시스템인 이상 정합성을 완전히 위임하는 것은 위험하다.
3. 최종 선택: Redis 분산 락 + DB 낙관적 락 조합
두 기술의 역할을 명확히 분리하여 성능과 안정성을 모두 잡는 2중 방어 체계를 구축했다.
- 1차 관문 (Redis 분산 락): 트래픽을 직렬화하여 대부분의 충돌을
애플리케이션 레이어에서 걸러낸다. DB의 Retry Storm을 방지하고 부하를 최소화한다. - 최후 방어선 (DB 낙관적 락): 분산 락의 TTL 만료나 커밋 시점의 간극으로 인해
발생하는 희귀한 동시 접근까지 DB 레벨에서 차단한다.
Redis가 앞단에서 대부분의 요청을 걸러주기 때문에 DB에 도달하는 요청은 소수가 된다.
이 덕분에 "충돌이 드물다"는 낙관적 락의 전제가 다시 성립하여 정상적으로 작동하게 된다.
📊 락 조합 전략 요약
| 항목 | Redis 분산 락 | DB 낙관적 락 |
|---|---|---|
| 주 역할 | 트래픽 제어 및 완충 | 데이터 무결성 보장 |
| 핵심 이점 | DB 부하 방지, 성능 최적화 | 외부 인프라 장애 시에도 정합성 유지 |
| 충돌 시 처리 | 대기 또는 즉시 실패 (구현 전략에 따라 결정) | 즉시 실패 (분산 락이 뚫린 비정상 상황이므로) |
| 의존성 | 외부 (Redis) | 내부 (DB Transaction) |
