본 리드미는 본인(이승희)이 기술적으로 기여한 기능 중심으로 작성되었습니다.
개발기간: 2024.11.12 ~ 2024.12.19 (6주)
영화의 다양한 관점을 공유하는 플랫폼 POV 에서 담당한 기능은 다음과 같습니다:
- 시사회 응모 및 결제
- 일정 시간에 열리는 한정된 인원의 영화 시사회에 응모 및 결제할 수 있습니다.
- 영화 리뷰 조회
- 모든 영화의 리뷰 목록과 상세 정보를 조회할 수 있습니다.
- 자신이 작성한 리뷰 목록과 상세 정보를 조회할 수 있습니다.
- 가입한 클럽별 리뷰 목록과 상세 정보를 조회할 수 있습니다.
- 관리자 기능
좋아요 관리: 일일 단위로 하루에 좋아요를 가장 많이 받은 상위 10개의 영화와 좋아요 수를 조회할 수 있습니다. 해당 데이터는 큐레이션을 생성하는 데 참고 자료가 됩니다.리뷰 관리: 백오피스에서 리뷰 검색을 통해 특정 리뷰를 숨김 처리하여 리뷰를 관리합니다.
- 시사회 CRUD
- 관리자는 영화 시사회를 CRUD 할 수 있습니다.
- 사용자는 영화 시사회 조회할 수 있습니다.
- 선착순 응모 시스템의 DB 정합성 보장을 위한 트러블 슈팅
- 안전한 결제 서비스를 제공하기 위한 고민들
- DB 형상 관리를 위한 Flyway 적용기
- 프로젝트 회고
- 컨벤션 규칙 (Team | GitHub | Jira | TestCode | DTO | Method | Exception)
- API 명세서
문제: 시사회 응모는 선착순으로 진행되는데, 수 천/만 명이 동시 접속 시 트랜잭션 충돌로 인한 데이터 정합성 깨짐
관련 문서: 선착순 응모 시스템의 DB 정합성 보장을 위한 트러블 슈팅
- 응모부터 결제까지의 구간에 Redisson 기반 분산 락을 적용하여 동시성 제어 및 데이터 정합성 보장
- 결제 실패 시,
ExponentialBackOffPolicy전략을 통해 최대 3회까지 재시도 - 모든 실패는 로그로 기록하고, 슬랙 알림을 통해 실시간 오류 대응 가능
시나리오: 선착순 100명 대비 1,000명의 동시 응모 요청
목표: 100건의 응모 데이터 저장 & 최소 500 TPS 보장
- 분산 락의 동시성 제어 안정성을 검증하기 위해 별도의 테스트 프로젝트(fcfs-entry-test)에서 시나리오 기반 테스트를 진행
- DB Lock, Redis Lua Script 등 다양한 동시성 제어 방식을 비교 및 검토
- 테스트 도구: JMeter, nGrinder
아래 결과는 일부 Redisson 과 Lua Script 의 테스트 결과입니다. 자세한 내용은 관련 문서를 참고하세요!
- Redisson 결과
- TPS 160~200 사이를 유지
- 에러 발생 없이 데이터 정합성 보장
- 두 결과 평균 응답 시간은 4.5s 로 느린 편
- Lua Script 결과
- TPS 470~865 사이를 유지, 목표 TPS 충분히 달성
- 에러 발생 없이 데이터 정합성 보장 & 완만한 TPS 제공으로 안정성 확보
- 두 결과 평균 응답 시간은 1.3s 로 양호한 편
문제: 결제 과정에서 발생할 수 있는 예외 상황(ex. 중복 결제, 결제 실패)에 대한 대응 필요
관련 문서: 안전한 결제 서비스를 제공하기 위한 고민들
- 중복 결제 방지: 응모 요청 시 멱등키를 생성하여 결제 요청 시 헤더에 포함. TTL을 설정을 통해 중복 처리 차단
- 결제 실패 대응:
ExponentialBackOffPolicy전략을 활용해 최대 3회 재시도 - 모니터링 및 알림: 재시도 실패 시 에러 로그 기록 및 슬랙 알림으로 실시간 대응 체계 구축
