메모) 대규모 트랜잭션

 

• 단일 장애 포인트
  • 중앙 집중 DB의 장애가 전체 시스템으로 전파
  • 시스템 별로 도메인 설계, 각각의 저장소
  • 시스템간 메시지큐 기반 통신
  • 한 시스템이 장애 발생시 메시지큐의 지연 발생하지만 메시지 재소비 가능해 서비스 진행 가능
• 대용량 데이터
  • RDB 조인 연산으로 인한 조회 성능 하락
  • 주문내역 상세를 보여주기 위해선 여러 도메인 정보 필요(주문, 결제, 상품, ..) => 역정규화, 단일 도큐먼트
  • 주문 발생, command 모델 저장(rdb) => 주문 이벤트 발행 => 주문 이벤트 수신 => 주문 query 모델 저장(nosql)
• 대규모 트랜잭션
  • 주문수 증가로 인한 저장소 쓰기 처리량 한계 도달
  • 샤드 클러스터를 구성해 쓰기 부하 분산
  • 어플리케이션단에서 구성 - AOP
• 복잡한 이벤트 아키텍처
  • 규칙 없는 이벤트 발행으로 인한 서비스 복잡도 증가
  • spring event - 로직 수행 주체 파악의 어려움, 메시지 유실시 재처리 어려움
  • 이벤트 처리 주체의 단일화 (네트워크 비용보다 이벤트 처리 주체의 단일화시 관리 및 유지보수의 이점이 컸다)
  • 내부 / 외부 이벤트 정리 - 주문 도메인 이벤트는 내부 이벤트로 정의하고 서비스 로직은 외부 이벤트로 정의
    주문 API => SQS 도메인 이벤트 수신 => SQS 구독하는 이벤트 처리기가, 다시 한 번 서비스 로직을 실행하는 외부 이벤트를 발행
  • 내부 이벤트는 ZERO Payload 전략 (간단한 이벤트 정보), 이벤트 처리기가 필요한 정보를 저장소에서 직접 조회
  • 트랜잭션 안에서 이벤트 발행이 실패하는 경우, 도메인 로직 전체가 실패
    트랜잭션 밖에서 이벤트 발행이 실패하는 경우, 도메인 로직은 성공하지만 이벤트 발행 실패로 서비스 로직 미수행, 서비스 일관성이 깨짐 => 트랜잭션 아웃박스 패턴 (저장소에 이벤트 저장 후 트랜잭션 커밋, 추후 저장소에서 이벤트 읽어와서 이벤트 발행)