시작하기 전

목표

• 스케일 아웃 환경에서도 안정적으로 동작
• 알림 데이터 영속성 / 캐싱 : MongoDB + Redis
• 장애 복구 기능
  • 애플리케이션 서버 또는 DB가 다운 됐을 때 어떻게 대응할지
  • Redis 터지고 재시작하면 데이터를 MongoDB에서 읽어오기?
• API 서버와 알림 서버 분리 가능성 염두

현재 구조

• 애플리케이션 서비스에서 알림 이벤트 발행 (Spring Event)
• Spring Event Listener에서 이벤트 수신
  • 알림 데이터 저장 (Redis)
  • 알림 발송 (Websocket + ActiveMQ 사용)

구상 내용

DB 동기화

• 데이터 영구 보관 목적의 MongoDB, 캐싱 용도의 Redis 두 DB에 데이터를 write 해야 함

  → 데이터 정합성 보장 필요

• 애플리케이션 로직 내에서 순차적으로 두 DB에 저장하는 방식 : 초기 구현이 비교적 간단

• But, 데이터 정합성을 보장하기 어려움

  • MongoDB에는 쓰기가 성공했는데, 네트워크 문제나 Redis 서버 장애로 Redis에는 쓰기가 실패한 경우 ⇒ 데이터 불일치 발생!
  • 재시도 로직 구현 또는 트랜잭션으로 묶기 → 서로 다른 종류의 DB이므로 적용하기가 복잡하고 성능 저하 일으킴

CDC (Change Data Capture) 사용

• 동작 방식
  • 애플리케이션(Producer)에서 MongoDB에 데이터 저장
  • CDC에서 DB 변경 감지하여 이벤트를 메시지큐로 발행
  • Consumer에서 메시지큐 구독하여 Redis 데이터 저장
  • 알림 푸시는 어디서?
• MongoDB Change Streams, Debezium 등이 있음