MSA환경에서 Kafka를 활용한 데이터 동기화 포스팅에서 MSA환경에서 카프카를 활용하여 두 마이크로서비스간의 데이터를 동기화하기 위한 방법들에 대해 알아보았고 아래 이미지처럼 4가지 경우의 수에 대해서 알아보았다.
도메인 이벤트별 토픽 나누는 방식에서 도출될 수 있는 문제(3, 4)
도메인 이벤트별 토픽을 나누는 방식(ex. order-create-topic, order-cancel-topic, order-change-topic)에서 도출될 수 있는 문제로는 컨슈머의 처리 순서에 대해 보장할 수 없다는 점이다.
예를 들어, 주문 생성되어야 했을때 처리되어야 하는 로직이 10초가 걸리고, 주문이 취소 됐을때 처리되는 로직이 1초가 걸린다고 해보자.(극단적으로 이해를 돕기 위한 예시이다)
만약 주문이 생성되자마자 바로 취소 이벤트가 발생한다고 해보자. 주문이 생성되는 도중에 취소 처리 로직이 실행되기 때문에 로직상 문제가 발생하거나 데이터 정합성이 깨질것이다.(생성된 주문이 없음에도 주문 취소 처리를 하려고 하기 때문에 방어 로직을 넣는다 해도 정합성 문제는 해결될 수 없을 것이다)
또한 컨슈머 애플리케이션에 장애가 발생하여 shutdown되었을때도 문제가 된다.
소프트웨어 개발에서 중요한 요소 중 하나는 장애 복구이다. 장애가 발생했을때 이를 쉽고 완벽하고 빠르게 복구를 할 수 있어야 한다.
주문 마이크로서비스에 장애가 발생하고 다시 재기동을 했을 때 컨슈머는 consume 하지 못한 offset의 메시지부터 읽을 것이다.
그런데 어느 토픽의 메시지부터 읽는다는 것을 보장할 수가 없게 된다.(주문 생성 토픽부터 다 처리하고, 주문 취소 이벤트를 다 처리하고, 주문 변경 이벤트를 다 처리해라 라는 식으로 할 수 없다)
위와 같은 문제들로 도메인 이벤트별 토픽을 나누는 방식은 장애에 취약하게 될 수 있다.
따라서 연관된 도메인 이벤트들을 단일 토픽으로 발행하는게 데이터 정합성을 잘 유지하면서 장애 복구에 용이한 구조가 될 수 있을것 같다.
카프카 파티셔닝 기반 처리 성능 개선
제품이 점점 성장하게되면서 단일 파티션으로 처리하는데 큰 지연시간이 발생할 것이다.
이를 해결하기 위해선 토픽의 파티션수를 늘리고, 원본 데이터의 PK를 메시지 Key로 사용하여 카프카 토픽에 파티셔닝 하는 것이다.
주문 토픽의 파티션을 3개로 늘리고, 주문 순번으로 파티셔닝을 하면 하나의 주문 데이터에 대해선 동일한 파티션에 메시지가 발행될 것이다. 왜냐하면 순번에 해쉬함수를 적용한 값으로 어느 파티션에 메시지를 보낼지 결정되기 때문이다.
예를 들어, PK 기준 1번 주문 데이터와 관련된 도메인 이벤트 메시지는 0번 파티션으로만 쌓이게 될 것이고, 2번 주문 데이터와 관련된 도메인 이벤트 메시지는 1번 파티션으로만 쌓이게 될 것이다.
따라서 도메인 이벤트들에 대한 처리 지연 문제를 개선할 수 있을것이다.
위 포스팅에 대해 잘못된 내용 또는 추가되면 좋을 것 같은 내용이 있다면 아래 코멘트로 언제든지 피드백 부탁드립니다😀
출처
- https://11st-tech.github.io/2022/05/16/junior-developer-first-msa-design-and-development/#api-%EB%A9%B1%EB%93%B1%EC%84%B1%EA%B3%BC-%EB%8D%B0%EC%9D%B4%ED%84%B0%EC%9D%98-%EC%88%9C%EC%84%9C-%EB%B3%B4%EC%9E%A5
- https://devocean.sk.com/blog/techBoardDetail.do?ID=164096
- https://www.popit.kr/msa%EC%97%90%EC%84%9C-%EB%A9%94%EC%8B%9C%EC%A7%95-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0/