[Review] 회원 서비스 개선을 위한 Redis Streams 아키텍처 설계

들어가며

• 통합회원 서비스: 기존 3개 도메인별 회원 DB CRUD 변경 사항을 통합회원 DB와 동기화
• 기존 도메인 서비스가 통합회원 DB로 완전히 전환되지 않아, 사이드이펙트 발생 가능성을 고려
• JTA 기반 분산 트랜잭션으로 3개 도메인 DB + 통합회원 DB 묶어 동기화 처리
• 2PC 패턴으로 인한 성능 저하 및 서비스 지연 다수 발생
• 개선 방향: 비동기 이벤트 기반 아키텍처로 전환 검토

Spring Event 비교한 도입시 장점

• 현재 Spring Event를 사용할 경우, 이벤트 발생 후 내부에서 여전히 대상 서버의 API를 호출하여 처리가 이루어지고 있음.
• 반면, 별도의 Streams를 사용할 경우, 통합회원 시스템에서는 이벤트만 발행하면 이후 처리 과정은 별도로 신경 쓰지 않아도 되며, 시스템 간 의존성이 낮아짐.
• 또한 이벤트 발행과 관리가 보다 유연하고 체계적으로 가능하며, 장애 발생 시에도 재처리, 알림, 모니터링이 가능.
• 현재는 포인트 시스템만 이벤트 처리 대상이지만, 추후 온라인/오프라인 시스템까지 확장성을 고려할 때는 Streams 기반 설계가 적합할 것으로 판단

메시지 큐로 Redis Streams 선택 이유

• 프로젝트 후반부, 일정이 넉넉하지 않아 빠른 적용 가능
• 낮은 러닝커브와 운영 편의성
• 상대적으로 낮은 트래픽 환경에 적합
• 기존 Redis 인프라 활용 가능
• 재처리 기능 제공

아키텍처 구조 설계 ( 회원 - 포인트 동기화 및 포인트 ID 전달 )

• 회원 모듈 내 신규 회원 가입시 포인트 모듈 동기화 요청 이벤트 발행
• 동기화 이후 생성된 포인트 ID 이용, 회원 정보 업데이트 요청

 

1. 이벤트 발행 및 소비
   1. 통합회원: 회원 등록 요청 → 트랜잭션 완료 후 “회원 등록” 이벤트 발행
   2. 멤버십: 이벤트 구독 → 처리 → “등록 완료” 이벤트 발행
   3. 통합회원: “등록 완료” 이벤트 구독 및 처리
2. Consumer Group
   1. 동일 도메인 컨슈머 N대를 하나의 그룹으로 묶어 중복 처리 방지
3. 순서 보장
   1. 동일 회원 ID 기준 발생 이벤트는 순서대로 처리 필요 (개발 우선순위 낮음)
      1. ex) 등록, 수정, 수정 요청시 순서대로 이벤트 처리가 되어야 데이터 정합성 유지 가능
4. 재처리 및 소비되지 않은 이벤트의 보관
   1. Redis Streams: 이벤트 Read → PEL로 이동 → ACK 시 PEL 삭제
   2. 처리 실패 시: PEL에 남음
   3. 재처리: PEL 적재 이벤트 재처리를 위한 주기적 배치처리 (일정 횟수 재처리 실패시 알림)
   4. 재처리 실패 시: DLQ 이동 (개발 우선순위 낮음)
      1. DLQ 수동 처리 로직은 현재 구조에서 과한 설계로 판단, 실패 시 PEL 유지
5. 모니터링
   1. Redis 메타데이터 이용 Grafana로 모니터링
   2. PEL 적재 데이터 주기적 배치 + 메신저 웹훅 연동