예약 프로젝트

박태현·2025년 6월 22일
0

예약 프로젝트

목록 보기
5/8

티켓 예약 로직을 구성하여 좌석 선택 → 예약 → 결제 , 포인트 리워드 지급의 일련의 과정에서 멱등적인 API와 동시성을 다뤄보고 해결해보고자 하는 프로젝트입니다.

멱등성을 기반으로 예약, 취소, 리워드 지급 로직에서 API의 중복 호출로 인한 오류를 방지했으며, 중복된 요청의 경우에는 이전에 저장해둔 응답을 그대로 반환함으로써 불필요한 연산과 리소스 소모를 줄였습니다.

동시성 문제가 발생할 수 있는 예약, 리워드 지급 등의 핵심 로직에 Redis 분산 락 ( metex )을 도입하여 충돌을 방지했습니다.

동시성 이슈


흔히 따닥 이슈라고 불리는 문제는, 사용자가 버튼을 빠르게 여러 번 클릭하면서 동일한 API 요청이 중복으로 발생하는 현상을 말합니다.

이러한 문제가 발생하면, 비즈니스 로직에 예외 처리를 해두었더라도 여러 요청이 예외 없이 모두 정상 처리되는 상황이 생길 수 있습니다.

이는 예약이 중복으로 처리되거나, 리워드가 중복 지급되는 등 심각한 문제의 원인이 됩니다.

이번 프로젝트에서 좌석 예약과 리워드 지급 로직을 다루고 있는 만큼 이에 대한 문제를 해결해보려고 합니다.

해결 방안

동시성을 제어하는 여러 방법이 존재하지만, Redis를 활용한 분산 락 방식을 선택했습니다

그 이유는 Redis가 단일 서버 환경뿐만 아니라 분산 서버 환경에서도 락을 효과적으로 관리할 수 있고, 동시성 제어는 애플리케이션 레이어에서 처리하는 것이 유지보수에 더 효과적이라고 생각했으며, 컨트롤러나 서비스 단에서 빠르게 실패를 유도할 수 있어, 리소스 낭비를 최소화할 수 있을 것이라고 생각했기 때문입니다.

반면, DB 베타 락은 예외가 저장소 계층에서 발생하기 때문에, 불필요하게 로직이 모두 실행된 후에 실패를 감지하게 되는 문제가 있다고 보았습니다.

왜 DB락을 사용하지 않고 분산락을 사용하는지 ???

⇒ 쿼리 실행까지 가야 락이 적용됨→ DB 부하 증가

⇒ 트랜잭션 커밋 직전 또는 예외 발생 시점→ 로직이 모두 실행되고 나서야 실패


구현

Redis 분산 락은 Mutex Lock 방식을 사용하여 구현하였습니다.

Mutex Lock은 지정한 최대 대기 시간 내에 지속적으로 락을 획득할 때까지 확인하며 기다리고, 락을 획득하지 못하면 실패하도록 하여 리소스 낭비를 줄이고 빠르게 실패를 처리할 수 있도록 했습니다.

profile
꾸준하게

0개의 댓글