배민 이벤트 기반 아키텍처

배달 서비스 우아콘
강한 일관성 ?
- 배달이 변경되었을 때, 관련 기능도 “동시에” 반영되어야한다.
결과적 일관성 ?
- 배달이 변경되었을 때, 관련 기능이 “언젠가” 반영되면 된다.
강한 일관성을 갖지 않고 결과적 일관성만을 요구하는 알림, 통계, 쿠폰 등의 관심사는 이벤트 기반 아키텍처를 따르는 것이 합리적

이벤트의 목적/정의/구성요소

목적 ? 배달에서 발생한 행위를 알려주고 싶어(배달의 변경사항을 잘 알려주는 것)
정의 ? 도메인에 영향을 주는 관심사에 대한 기록
이벤트의 구성요소(ex 배달이 A라이더에서 11시에 배차되었다 라는 이벤트)
- 대상
  - 대상의 식별자 정보를 제공한다.
  - 배달이 A라이더에게 11시에 배차되었다
  - 어떤 배달이 변경됐는지 알려주는 정보
- 행동
  - 단순 상태변경이 아닌 도메인에 일어난 모든 사건들을 표현
  - 이미 벌어진 사건이므로 과거형으로 표현
  - 배달이 A라이더에게 11시에 배차되었다
- 정보
  - 행위와 관련된 값들을 표현
  - 배달이 A라이더에게 11시에 배차되었다
  - ‘A라이더에게’는 ‘배차되었다’라는 행위와 밀접하게 관련이 있음
  - 필요하다면 행위 외의 값도 추가 가능 (ex. 배달이벤트이지만 주문식별자도 들어갈 수 있음)
  - 비즈니스 상황을 고려해 정보에 들어갈 값을 정함
- 시간
  - 행위가 발생한 시간을 표현한다.
  - 배달이 A라이더에게 11시에 배차되었다
- Domain Event 필드 구성
```
배달이 A라이더에게 15시에 배치되었다.
{
	"eventId": "D배달",
	"eventType": "배치완료",
	"data": {
			"state": "배치완료",
			"riderId": "A라이더"
	}
	"occurenceDateTime": "2023-11-15 15:00:00"
}

라이더가 자전거로 11시에 운행시작하였다.
{
	"eventId": "D라이더",
	"eventType": "운행시작",
	"data": {
			"state": "운행중",
			"배달수단": "자전거"
	}
	"occurenceDateTime": "2023-11-15 11:00:00"
}
```

적용 후 장점 및 주의사항

적용 후 장점
- 요구사항 추가에도 배달 시스템 자체에는 복잡도 영향 없음
- 소비처(consumer)와의 결합도 감소
  - 배달 변경 사항을 이벤트 자체에서 파악할 수 있기때문에 consumer가 상세정보를 조회하는 api를 요청하거나 할 필요가 없음
- 데이터 분석
  - 도메인 히스토리 파악에 용이하여 분석 정보로 활용이 가능함
적용시 주의사항
- 이벤트 데이터의 무분별한 추가 주의
  - 행위자(producer) 기반의 데이터 정의가 필요함
  - 소비처 요구사항에 대한 무분별한 데이터 추가시 소비처의 비즈니스에 영향을 받기 쉬움
- 이벤트의 순서
  - 주문취소 후 주문 생성 이벤트가 들어왔다 !?
  - 이벤트 파이프라인
    - 카프카 선택 이유
      - 순서보장 - 토픽의 파티션을 통해 key별로 순서보장
      - 고성능/고가용성 - 파티션 증대, 메시지 배치 발행(?), 페이지캐시(?), 브로커 클러스터
      - 통합도구 - Kafka Streams, Kafka Connect
      - 전담팀 지원 - 우형에는 카프카팀이 있음..ㅎ
    - 네트워크 문제로 이벤트 발행 실패 → 재시도 처리 → 이벤트 순서 뒤바뀜
      - 도메인상태 ≠ 이벤트 발행결과
      - 트랜잭셔널 아웃박스 패턴 적용하여 해결
        
        발행해야할 이벤트를 도메인의 처리 트랜잭션과 묶어 아웃박스 테이블에 저장(일관성 보장)
        
        message relay가 아웃박스 테이블에 있는 레코드를 순차적으로 읽어 이벤트 발행
        
        message Relay
        
        Debezium 선택 이유
        
        데이터베이스 시스템에서 발생한 변경된 사항을 감지하여 타 시스템에 전송하는 오픈소스 플랫폼(CDC에서 자주 사용)
        
        저비용
        
        카프카커넥트로 제공되는 debezium 사내에 이미 환경 구축되어있음. 설정을 통해 커넥트 등록하여 사용… 모니터링도…. 되어있음
        
        안정성
        
        Binary log를 순서대로 읽어 순차 보장
        
        offset을 활용한 발행 보장
        
        순단이 발생하더라도 발행이 실패한 오프셋부터 읽어 재시도 함
        
        처리량
        
        발행 이벤트가 많아지는 경우 debezium도 처리량이 증대되어야함
        
        보통은 커넥트의 태스크 수 조정으로 처리 가능
        
        mySQL은 커넥트의 태스크 수 1개 고정임(바이너리 로그 순차적으로 읽어야해서 그런듯) → outbox테이블 파티셔닝을 통한 처리량 증대
        
        outbox테이블 n개
        
        프로듀서가 이벤트 키를 기반으로 이벤트 파티셔닝
        
        각 테이블에 dbzium 커넥터를 붙임!

이벤트 활용 사례

순서가 보장된 이벤트는 이벤트 스트림을 구성하고 이 스트림 기반으로 CQRS 적용
- 쿼리 모델 분리
- 쿼리 모델이 커맨드에 영향을 주지 않음
데이터 분석 환경 구축
- 이벤트 스트림을 S3에 저장
- AWS 데이터 분석 서비스 활용
집계
- 카프카 스트림즈