Kafka는 데이터 스트리밍을 처리하는 강력한 메시징 시스템으로, 토픽을 어떻게 설계하느냐에 따라 시스템의 확장성과 유지보수성이 크게 달라진다.
Kafka 토픽 설계 방식에는 크게 비즈니스 기반(Business-Oriented) 과 이벤트 기반(Event-Oriented) 접근 방식이 있다.
1. 비즈니스 기반 토픽 설계
비즈니스 기반 설계는 도메인 또는 서비스의 역할을 기준으로 토픽을 정의하는 방식이다.
토픽이 특정 비즈니스 개념과 1:1로 매칭되므로, 서비스별 데이터 흐름을 명확하게 정리할 수 있다.
EX)
order-topic
execution-topic
settlement-topic
matching-topic
- 특징
✔ 직관적 구조: 토픽 이름이 도메인 개념과 직결되어 있어 이해하기 쉽다.
✔ 팀 단위 관리 용이: 마이크로서비스 아키텍처에서 서비스별로 토픽을 관리하기 좋다.
✖ 확장성 부족: 새로운 이벤트가 추가될 때 기존 토픽을 변경해야 할 수도 있다.
✖ 재사용 어려움: 이벤트 유형별로 다룰 때 비효율적일 수 있다.
2. 이벤트 기반 토픽 설계
이벤트 기반 설계는 발생하는 이벤트를 중심으로 토픽을 정의하는 방식이다.
이벤트 소스(Event Source) 또는 특정한 액션(Action)을 기준으로 토픽을 분류한다.
EX)
user.created
order.placed
payment.processed
inventory.updated
- 특징
✔ 확장성 뛰어남: 새로운 이벤트 유형을 쉽게 추가할 수 있다.
✔ 재사용성 높음: 여러 서비스에서 동일한 이벤트를 소비할 수 있어 데이터 흐름이 유연하다.
✖ 이해도 요구됨: 이벤트 흐름을 정확히 파악해야 한다.
✖ 권한 관리 복잡: 여러 서비스가 같은 이벤트를 사용할 경우, 컨슈머 관리가 어려울 수 있다.
트레이딩 시스템의 Kafka topic구조 설계
비즈니스 기반 + 일부 이벤트 기반 (하이브리드 설계)
Kafka 토픽 설계: 비즈니스 기반 + 일부 이벤트 기반 (하이브리드 설계)
MSA 기반 트레이딩 시스템에서는 기본적으로 비즈니스 기반 토픽 설계를 따르면서도, 특정 상황에서 이벤트 기반 방식을 도입한 하이브리드 토픽 설계를 적용했다.
1. 기본적인 비즈니스 기반 설계
- 서비스 단위로 토픽을 분리하여
order-topic,matching-topic,execution-topic,settlement-topic,notice-topic을 운영함. - 각 토픽에서 주문 생성, 매칭, 체결, 정산 등 각 모듈이 자체적으로 이벤트를 관리.
- 이를 통해 서비스별 로직을 독립적으로 유지하면서도, 필요 시 특정 서비스만 스케일링할 수 있도록 설계.
2. 이벤트 기반 요소를 추가한 이유
(1) 실패 처리의 효율성 → Failure Topic 사용
이유: 서비스 간 결합도를 낮추고, 롤백 및 재처리를 용이하게 하기 위함.
execution-failure-topic,settlement-failure-topic을 별도로 분리하여 체결 및 정산 실패 시 해당 이벤트만 별도로 관리하도록 함.- 만약 하나의
execution-topic에서 실패 이벤트까지 처리하려 하면, 실패 이벤트가 기존 정상 체결 이벤트 흐름과 섞여 복잡성이 증가할 수 있음. - 따라서 실패 시 별도의 토픽으로 분리하여 비동기적으로 재처리 가능하도록 설계.
- 또한,
DLT(Dead Letter Topic)도 각 모듈별로 나누어 서비스별 장애를 독립적으로 관리하도록 함.
(2) 알림의 성격에 따라 분리 → Filling Notice vs. General Notice
이유: 알림 유형별로 중요도가 다르고, 목적이 다르기 때문.
filling-notice-topic(체결 알림): 유저에게 거래 체결 내역을 즉시 전달해야 하는 실시간성 요구.notice-topic(일반 공시 알림): 금융 공시 등 상대적으로 중요도가 낮고, 대량으로 전송될 수 있는 알림.- 만약 두 개의 알림을 하나의
notice-topic에서 처리한다면, 공시 알림이 많아질 경우 체결 알림 전송이 지연될 가능성이 있음. - 따라서 체결 알림을 우선적으로 보장하기 위해 두 개의 알림을 서로 다른 토픽으로 분리함.
3. 하이브리드 설계를 선택한 근거
- 트레이딩 시스템 특성상 서비스 단위 토픽 구조(비즈니스 기반)가 적합
- 주문, 매칭, 체결, 정산이 각각 독립적으로 동작하며, 서비스별 확장성을 고려해야 하기 때문.
- 모든 이벤트를 작은 단위로 분리하면 오히려 관리 복잡성이 증가할 가능성이 큼.
- 실패 이벤트 처리는 이벤트 기반 설계가 더 적합
- 체결 및 정산 실패 시, 재처리 및 장애 관리가 중요하므로 별도 토픽(
failure-topic)을 통해 장애를 격리하고 처리.
- 체결 및 정산 실패 시, 재처리 및 장애 관리가 중요하므로 별도 토픽(
- 알림 서비스는 이벤트 특성을 반영할 필요가 있음
- 체결 알림과 공시 알림을 분리함으로써 우선순위를 고려한 효율적 전송이 가능하도록 함.
