MSA 로 구성된 환경에서 카프카를 활용하여 도메인 이벤트를 기반으로 처리를 할 땐 아래 요소들을 고민해야 한다.
- 어떤 방식으로 데이터를 주고 받을 것인지? (Full-Payload 방식 or Zero-Payload 방식)
- 토픽을 어떻게 나눌 것인지?(도메인 이벤트를 기준으로 나눌 것인지 or 도메인 기준으로 나눌 것인지)
위 두 가지 사항에 대해 먼저 고민해보자.
아래 설명에서 사용되는 예제로는 두 마이크로서비스(주문서비스, 배송서비스)를 기준으로 설명할 것이다.
1) 어떤 방식으로 데이터를 주고 받을 것인지?
아래에서 설명하겠지만 토픽을 나누는 방식도 두 가지가 있는데 핵심 설명을 위해 도메인 별 토픽을 나누는 방식으로 설명할 것이다.
1-1) Full-Payload 방식
카프카 도메인 이벤트가 발생했을 때 카프카 메시지에 해당 도메인 이벤트와 관련된 데이터 전부를 담아서 보내주는 방식이다.
예를 들어, 다음과 같을 것이다.
Order 마이크로서비스에서 주문과 관련된 이벤트가 발생할 경우 카프카 클러스터로 위 이미지와 같이 주문과 관련 데이터 전부를 메시지에 담아서 보내주게 될 것이다.
해당 토픽(order-topic)을 구독하고 있는 Delivery 마이크로서비스 에선 이를 consume 하여 주문 생성 이벤트를 기준으로 해당 메시지에 담겨져있는 페이로드를 기반으로 배송 마이크로서비스에 해야될 책임을 수행하게 될 것이다.
1-2) Zero-Payload 방식
Zero-Payload 방식의 경우엔 많은 사람들이 기존에 많이 접해봤을 수도 있다.
배민 마이크로서비스 여행기에서 소개되었던 내용이기도 하고, 이벤트의 순서 보장 문제를 없애기 위해서이다.
카프카 메시지에 도메인 이벤트와 관련된 PK값과 이벤트 타입만 넣어줘서 도메인 이벤트를 전파하는 방식이다.
위 이미지와 같이 주문 마이크로서비스에서 주문과 관려된 이벤트가 발생할 경우 위 이미지와 같이 주문의 순번값과 이벤트 타입만 메시지에 담아서 보내줄 것이다.
해당 토픽(order-topic)을 구독하고 있는 Delivery 마이크로서비스 에선 이를 consume 하여 Order 마이크로서비스 로 http 요청을 통해 최신화된 데이터를 받아오게 될 것이다.
받아온 최신화된 주문 데이터를 기반으로 배송 마이크로서비스에서 해야될 책임을 수행하게 될 것이다.
2) 토픽을 어떻게 나눌 것인지?
데이터를 주고 받는 방식으론 위에서 설명된 Zero-Payload 방식을 기준으로 설명할 것이다.
2-1) 도메인 이벤트를 기준으로 토픽 나누기
예를 들어, 주문 생성 이벤트 토픽(order-create-topic), 주문 취소 이벤트(order-cancel-topic), 주문 변경 이벤트(order-change-event) 등으로 도메인 이벤트 별로 토픽을 분리하는 것이다.
위 이미지와 같이 나눌 때 이벤트 메시지에는 이벤트 타입에 대한 정보가 필요 없게 된다.
배송 마이크로서비스에선 메시지를 컨슘해 해당 토픽을 구독하고 있는 컨슈머별로의 각 처리를 수행하면 된다. 예를 들어, 주문 생성 토픽을 구독하는 컨슈머는 주문 생성 발생시 처리되야 하는 사항들을 수행하면 되고 주문 취소 토픽을 구독하는 컨슈머는 주문 취소 발생시 처리되야 하는 사항들을 수행하면 된다.
2-2) 도메인 기준으로 나누기
주문이라는 도메인 기준으로 하나의 토픽에 메시지를 발행하는 것이다.
위 이미지와 같이 이벤트 타입을 같이 보내주게 되어 해당 이벤트 타입에 맞도록 컨슈머가 처리를 하게 될 것이다.
MSA 로 구성된 환경에서 카프카를 활용하여 하나의 도메인 모델에 대한 동기화를 할 땐 고려해야 하는 포인트 정리
결론적으로는 위 네가지 경우의 수가 생기게 될 것이다.
위 네가지 방식의 단점들과 해결 방법에 대해 Kafka 도메인 이벤트 순서 보장하기 포스팅에서 더 깊이 있는 고찰을 해보자.