https://jeonyoungho.github.io/posts/Kafka-도메인-이벤트-순서-보장하기

위 포스팅과 연관된 실제 도메인 이벤트 순서 보장 문제 해결 기록을 남기고자 합니다😀

배경

현재 MSA 환경에서 제품내 인사 데이터(코드, 조직, 구성원)는 Kafka 도메인 이벤트 기반으로 동기화 되고 있다.

cms 서비스로부터 인사 데이터 변경이 발생되면 Kafka 도메인 이벤트를 발행하고 각 마이크로서비스에서 Zero-Payload 방식으로 동기화를 시켜주고 있다. 이때 도메인 이벤트별 토픽(code-create-topic, organization-create-topic, member-create-topic)이 나눠져서 발행되고 있는 구조였다.

기존 구현된 마이크로서비스들은 각자 관리하는 RDB 테이블에 외래키를 걸지 않은채 단순하게 HTTP 요청을 통해 조회한 데이터를 그대로 동기화시켜주고 있었다. 그러다보니 특정 조직에 할당된 구성원이 먼저 생성된후 해당 조직이 나중에 생성되어도 문제가 발생하지 않았다.

하지만 10년된 레거시 프로젝트(인사평가 모듈)를 마이크로서비스로 전환하는 과정에서 다음과 같은 이슈가 도출되었다.

• 기존 마이크로서비스들은 당시 보안 이슈를 고려하여 고객사별 DB 스키마를 분리하는 방식으로 멀티테넌시를 구현하다보니, 구성원/조직 식별값(member_id, org_id)이 고객사마다 중복될 수 있는 구조였음
• 레거시 프로젝트에서 관리되는 조직, 구성원 테이블은 단일 테이블로 모든 고객사의 데이터가 고유한 식별값(member_sn, org_sn)을 가지는 구조였음
• 또한 레거시 프로젝트의 식별키 값의 타입을 변경하는 것은 프로젝트 일정상 어려운 상황이었음. 따라서 모든 고객사의 데이터를 고유하게 식별할 수 있어야했기에 auto increment로 생성되는 독자적인 식별값을 가져야만 했음
• 이때 CMS 서비스에서 조직을 대량으로 생성하고 바로 구성원을 대량으로 생성하면 구성원에 생성되지 않은 조직을 할당하려하여 오류가 발생하였음

도메인 이벤트 순서 보장 해결 방안

도메인 이벤트 순서 보장 문제를 해결하기 위해 단일 토픽(cms-hr-operation topic)으로 메시지를 발행하도록함으로써 해결할 수 있었다.

단일 토픽으로 연관된 도메인 이벤트들이 순서를 보장하여 발행되다보니 레거시 프로젝트에서의 이벤트 순서 보장 문제를 해결할 수 있었다.

더 나은 개선에 대한 고민

제품이 성장하다보면 단일 토픽의 파티션 하나로 모든 도메인 이벤트들을 처리하기엔 큰 지연시간이 발생할 수 있다.

이때 원본 데이터의 테넌트값과 PK를 카프카 메시지 Key로 사용하여 토픽에 파티셔닝함으로써 메시지 처리 순서를 보장함과 동시에 메시지 처리 성능을 개선할 수 있을 것이다.