[MSA, Kafka] 공통 데이터 셀프컨테이닝?

MSA에서 공통 데이터를 어떻게 다뤄야 할까?

MSA(Microservice Architecture)를 도입하면 각 도메인의 독립성과 확장성이 강화되는 장점이 있지만, 공통 데이터(예: 코드 테이블, 공통 설정 등)를 어떤 식으로 관리할지에 대한 고민이 생긴다.
특히 대용량 트래픽이 들어오는 서비스(예: support, display)가 공통 데이터를 실시간으로 조회하거나 수정해야 한다면?

중앙 집중형 공통 테이블을 호출하면 성능 병목이 발생할 수 있고, 공통 서비스가 죽으면 전체 장애로 이어질 수도 있다.
그래서 우리가 선택한 전략은 "셀프컨테이닝 + 캐싱 + 이벤트 동기화" 였다.

셀프컨테이닝 방식이란?

각 도메인이 자신이 필요한 공통 데이터만 갖고 있는 방식이다.
다시 말해, 모든 공통 데이터를 하나의 서비스/DB에서 관리하는 게 아니라,
도메인마다 구독 중인 공통 데이터만 별도로 저장하고 사용하는 방식이다.

• 예: 도메인 A는 공통코드 중 '국가 코드', '통화 코드'만 사용 → A의 DB에 이 두 개만 저장
• 예: 도메인 B는 '언어 코드', '시간대' 사용 → B의 DB에만 저장

MSA에서 셀프컨테이닝 장점

• 고가용성: 공통 DB가 죽어도 각 도메인은 영향을 받지 않음
• 확장성: 도메인별 요구사항에 맞게 자유롭게 캐싱/TTL 설정 가능
• 성능 최적화: 트래픽이 많은 support, admin에서 공통 테이블을 반복 조회하지 않음
• 의존성 최소화: 도메인 간 의존도 감소로 유지보수가 쉬움

설계 방식 요약

1. 공통 데이터의 구독 구조
   • 각 도메인은 자신이 필요로 하는 공통데이터만 "구독"
   • admin 서비스는 공통코드 CRUD의 중심, 수정 시 Kafka 이벤트 발행
2. Kafka 이벤트 동기화
   • Kafka 토픽을 통해 각 도메인에 변경 이벤트 전파
   • 각 도메인은 본인의 DB에 저장된 공통 데이터와 캐시를 갱신
3. 도메인 내부 구조
   • 공통데이터는 로컬 DB + 캐싱 서비스에서 관리
   • 주기적 polling 없이, 이벤트 기반으로 최신 상태 유지

 

Kafka 이벤트 처리 시 Exactly-Once 보장 전략

이벤트 기반 아키텍처에서 가장 중요한 것은 정합성.
한 번만 처리되어야 할 이벤트가 중복되거나, 유실되면 데이터가 꼬일 수 있다.
이를 방지하기 위해 아래와 같은 전략을 사용한다.

 

방법 1: Kafka + 트랜잭션 연동 (Transactional Outbox 패턴)

• Kafka 메시지를 consume → DB에 저장 → Kafka offset 커밋을 하나의 트랜잭션으로 묶음
• 예: 이벤트 ID와 처리 결과를 이벤트 로그 테이블에 저장
• DB insert에 성공하면 commit, 실패하면 rollback → 메시지는 다시 소비됨

방법 2: Idempotent + Retry 전략

• 이벤트마다 고유한 ID 사용 (UUID, timestamp 등)
• 처리한 이벤트 ID를 DB에 저장해 중복 방지
• 실패 시 재시도해도 동일 ID면 중복 실행 없이 무시

이 방법은 processed_event 같은 테이블로 구현 가능하고, Kafka 재처리에도 안전하다.

결론

공통 데이터를 하나의 중앙 서비스에서 관리하기보다는
셀프컨테이닝 방식으로 도메인별 분산 저장 + Kafka 이벤트로 동기화
하는 방식은 다음과 같은 장점을 준다.

• 각 도메인의 독립성 강화
• 시스템 전체 안정성 향상
• 공통 데이터 변경 시 빠르고 안전한 전파
• 캐싱과 로컬 저장으로 성능 개선

MSA에서 공통 데이터를 다루는 데 고민 중이라면, 이 전략이 좋은 대안이 될 수 있다! 🚀