Kafka 대체 언제 써야할까(feat. MSA)

Kafka 특성

Kafka는 단순한 메시지 큐가 아니라, 고성능 이벤트 스트리밍 플랫폼

1. 로그 기반 저장소: 메시지가 삭제되지 않고 디스크에 유지되어, 과거 데이터를 재처리할 수 있습니다.
2. 비동기 Pub/Sub 모델: 생산자와 소비자가 직접 연결되지 않아 느슨한 결합 구조를 유지합니다.
3. 수평 확장성: 파티션 단위로 데이터를 분산 저장하며, 고성능 처리에 적합합니다.
4. 복수 구독자 허용: 하나의 이벤트를 여러 시스템이 동시에 처리할 수 있습니다.
5. 재처리 가능성: 오프셋 관리만 잘하면 과거 이벤트를 반복 소비할 수 있습니다.

 

REST API와 Kafka의 차이점

두 방식은 모두 모듈 간 통신에 사용되지만, 근본적으로 지향하는 구조와 사용 방식이 다릅니다.

	Rest api	Kafka
통신 방식	요청/응답 (동기)	이벤트 스트리밍 (비동기)
결합도	높음 (서비스 간 직접 연결)	낮음 (간접 연결)
장애 전파	한 서비스 장애 → 전체 영향	소비자 개별 장애 허용
데이터 보존	없음 (한 번 요청되면 끝)	있음 (디스크 저장, 재처리 가능)
복수 대상 전송	어려움 (N번 호출)	쉬움 (N명이 구독)
확장성	제한적	수평 확장 용이

 

 

MSA에서 Kafka를 적용하기

1. 하나의 이벤트를 여러 서비스가 처리해야 할 때
   • 예: 주문 발생 → 재고 감소, 결제 처리, 알림 발송, 추천 업데이트 등
2. 비동기 처리로 사용자 응답 속도를 최적화하고 싶을 때
   • 예: 결제 후 이메일 발송을 분리하여 사용자는 즉시 완료 응답 받음
3. 서비스 간 결합도를 낮추고 독립 배포/운영이 필요할 때
   • 예: 새로운 서비스가 추가되어도 기존 서비스는 수정 없이 이벤트만 발행
4. 데이터 이력 보존 및 재처리 요구가 있는 경우
   • 예: 과거 로그를 기반으로 알고리즘 변경 후 재분석 (DLQ 등)
5. 이벤트 기반 데이터 파이프라인 설계가 필요한 경우
   • 예: Kafka → Spark → Elasticsearch → Kibana 로 실시간 로그 분석(아직 안해본 케이스)

 

Kafka 대신 REST API로 통신하면?

1. 주문 서비스가 여러 API를 직접 호출해야 함
   • 결제 서비스 → 재고 서비스 → 알림 서비스 → 분석 서비스
2. 어느 하나가 실패하면 전체 실패 처리 필요
   • 재시도 로직과 트랜잭션 관리 복잡해짐
3. 서비스 간 강한 결합
   • 새로운 소비자(예: 로깅 시스템)가 생기면 기존 코드 수정 필요
4. 확장 어려움
   • 수십 TPS 수준 이상으로 올라가면 API 처리 병목 발생 가능

 

Kafka로 하면 REST API 보다 효율적인 경우

1. 주문 서비스는 단순히 Kafka에 이벤트만 발행
   • OrderCreated 이벤트를 발행하면 끝, 나머지 모듈들이 알아서 가져가서 서비스
2. 각 서비스는 필요한 이벤트만 구독해서 독립 처리
   • 결제, 재고, 마케팅, 알림 서비스가 각각 비동기로 동작
3. 서비스 간 결합도 낮음
   • 새로운 소비자도 Kafka 토픽만 구독하면 됨 → 코드 수정 無
4. 확장성과 장애 복원력 높음
   • 하나의 소비자 장애가 전체 시스템에 영향 주지 않음
5. 처리 이력 및 재시도 용이
   • 실패한 소비자는 나중에 오프셋부터 다시 읽기 가능

 

Kafka는 모든 곳에 필요하지 않지만, 이런 곳엔 필요하다

Kafka는 MSA 환경에서의 비동기 처리, 느슨한 결합, 고성능 이벤트 흐름을 필요로 할 때 특히 유용함
반대로 단순 API 호출만 필요한 상황, 낮은 TPS, 즉각적인 요청-응답이 필요한 경우에는 과함

 

끝.