[4주차] 3단 캐시 구조 및 분산락 적용, RateLimit 적용

[youngyin]

작업 요약

좌석 예약 API 구현 및 분산 락 적용

• 예약 API 구현: 사용자 요청 기반으로 특정 좌석 예약 기능 구현
• Redisson 기반 분산 락(@distributedlock) 적용으로 중복 예약 방지
  • tryLock() 사용해 락 획득 후 existsByScheduleIdAndSeatId로 중복 여부 확인
  • 예약 성공 시 unlock()으로 락 해제
• 테스트: CountDownLatch, invokeAll()을 통해 100개 스레드 동시 요청 시 충돌 여부 테스트
• JPA 비관적 락/낙관적 락과의 차이점 비교도 병행 실습

RateLimit 설계 및 적용

• 조회 API: 기술 정책으로 간주, AOP 기반 @RateLimited 어노테이션으로 IP별 요청 횟수 제한
  • Redis + Lua Script로 처리, 1분 50회 초과 시 1시간 차단
• 예약 API: 비즈니스 정책으로 간주, 유즈케이스 내부에서 DsRateLimitReserveSeatService 통해 처리
  • 같은 유저는 동일 시간대 스케줄에 5분 내 1회만 예약 가능
  • Redis TTL과 Lua Script를 조합하여 처리

---

어려웠던 점/궁금한점

1. Redisson 기반 분산 락 테스트의 적절한 방법

• 현재는 invokeAll, CountDownLatch, 여러 포트를 띄운 서버로 테스트했으나 실제로 레이스 컨디션이 명확하게 잡히는지 확신이 없습니다. 테스트가 실제 분산 환경에서 발생할 수 있는 충돌을 얼마나 잘 재현할 수 있을까요? 혹은 더 현실적인 테스트 방법이 있을까요?

2. RateLimit 동작 테스트

• IP별로 제한을 두기 위해 MockMvc에서 RemoteAddr을 바꾸는 방법이 필요한데, MockMvc 레벨에서 적절히 mock 처리를 하지 못해 실제 Redis 기록이 예상과 다르게 쌓였습니다. **RateLimit 테스트를 효과적으로 하기 위해 어떤 접근 방식이 좋을까요? 로컬에서 IP를 다르게 설정하거나, 테스트에서 Redis를 mocking 없이 활용하는 방향이 괜찮을까요?

3. AOP 적용 경계와 도메인 정책 구분

현재는 기술 정책(AOP) / 비즈니스 정책(유즈케이스 내부)으로 나누어 처리했는데, 경계가 모호한 경우도 있을 수 있습니다. 이런 정책적 구분이 적절해 보이시는지, 혹은 보다 명확하게 나누는 기준이 있을까요?

4. Hexagonal 구조에서 기술 정책(AOP, RateLimit, Redis 락 등)을 어디까지 Infra로 보고, 어디까지 Application Layer에서 다뤄야 할지 경계를 잡는 기준이 있을까요? 또는 도메인 로직과 기술 정책이 어느 정도 섞이는 것을 허용할 수 있는지, 그 판단 기준은 어떻게 가져가야 할까요?

5. Redis 용도와 활용

지금 과제에서는 Redis를 통해 분산 락이나 RateLimit, 캐시 등 다양한 기술 정책을 구현해보았습니다. 실무에서.. 캐시, 통계 데이터 저장, 세션 관리 외에도 자주 쓰이는 패턴이 있을까요? API Gateway나 WAF, 프레임워크 설정 레벨에서 처리할수도 있을것 같은데, 분산 락이나 RateLimit 같은 기능을 직접 구현해서 사용하는 경우가 흔한가요???

[ann-mj]

리뷰가 늦어지고 있네요. 순차적으로 진행하겠습니다. 잠시만 기다려주세요!