[TIL] 다시 시작해보는 프로젝트 TIL 16일차..

🌞 오늘은 어떤 하루였지..

오늘은 오전 내내 팀원들이 올려준 PR 확인하고 리뷰 다느라 시간을 다 보낸 것 같다.
하나하나 꼼꼼히 보다 보니 시간이 많이 지났는데, 코드 리뷰에 대한 요령이 아직은 부족한 것 같아서 시간이 많이 소요되는 것 같다.
그래도 하다 보니까 점점 속도가 붙는 느낌이라서 계속해서 하다 보면 익숙해져서 전보다는 짧은 시간 안에 코드 리뷰를 끝낼 수 있을 거란 생각이 들었다.

오후에는 선착순 할인 쿠폰 발급 동시성 문서화를 진행했다.
우선 아무런 작업도 하지 않은 기본적인 쿠폰 발급 로직을 JMeter에서 실행해서 데드락이 발생하는 현상을 눈으로 확인했다. 데드락을 잡기 위해서 비관적 락을 적용하여 DB에서 락을 걸어 정합성이 유지되게끔 할 수 있었다. 동시 스레드 수를 점차적으로 증가시키면서 속도를 확인했고, 배포했을 때의 분산 환경을 고려하여 Redisson 락도 구현하여 속도를 확인했다.
그 결과, 비관적 락이 Redisson 락보다 속도가 훨씬 빠르게 측정되었다. 왜 그런가 생각해보니 현재 환경은 단일 서버에서 실행 중이어서 Redis까지 다녀오는 오버헤드가 발생하여 비관적 락이 더 빠른 것으로 생각할 수 있었다.
하지만 배포까지 고려한다면 비관적 락만으로는 동시성을 제어할 수 없는 상황이었다. 그래서 추가적으로 어떤 방법으로 동시성을 제어할 수 있는지 찾아보았고, 분산 환경에서는 비관적 락 + 메시지 큐를 활용할 수 있다는 것을 알게 되었다. 선착순 할인 쿠폰 발급은 실시간성이 중요하였지만 비관적 락 + 메시지 큐는 실시간성이 보장되기 힘들어 최종적으로 Redisson 락을 활용하는 것으로 결정하였다.

그 뒤에는 인증/인가 부분에서 UNAUTHORIZED, FORBIDDEN 관련 예외 처리의 반환 값이 HTML로 반환되어 값을 알아볼 수 없어서 반환값을 수정하는 작업을 진행했다.
각각 상황에 맞게 값이 올바르게 반환될 수 있도록 수정했고, 테스트한 결과 무엇으로 인한 에러인지 확인할 수 있었다.

 

💡 새롭게 알게 된 내용은 뭐가 있더라..?!

메시지 큐 + 비관적 락

✅ 장점: 높은 처리량, 재시도 가능, 장애 복원력 우수
❌ 단점: 비동기 처리로 인한 실시간성 부족, 큐 구성 및 복잡도 증가

Redisson 분산 락

✅ 장점:
Redis 기반 분산 락으로 서버 간 정합성 유지
요청 시점에 즉시 락 획득 → 바로 응답 가능 (실시간성 우수)
락 범위(key)를 자유롭게 정의할 수 있어 유연한 제어 가능
❌ 단점: Redis I/O 오버헤드, TTL 설정 및 락 경합 시 성능 저하 가능성

 

🗓️ 내일은 뭐 하지?!

✔️ memberId 받아오는 방법 수정
✔️ API 명세서 추가 작성 및 수정
✔️ JWT에 리프레쉬 토큰 추가
✔️ 운동
✔️ TIL 작성