이벤트 기반 아키텍처: Kafka vs RabbitMQ 실무 비교 및 선택 기준

📌 핵심 요약

  • 강한 결합(HTTP)을 끊어내기 위한 비동기 이벤트 처리의 필요성
  • RabbitMQ(메시지 브로커): 복잡한 라우팅과 작업 큐에 최적화 (Smart Broker)
  • Kafka(이벤트 스트리밍): 대용량 데이터 처리와 로그 저장에 최적화 (Dumb Broker)
  • 실무 아키텍처링 시 고려해야 할 순서 보장과 멱등성(Idempotency) 이슈

마이크로서비스(MSA)가 도입되면서 서비스 간의 통신 방식이 중요해졌습니다. A 서비스가 B 서비스를 호출할 때, HTTP(REST) 같은 동기 방식을 사용하면 A는 B가 응답할 때까지 기다려야 합니다. B가 죽으면 A도 같이 느려지거나 죽습니다.

이 강한 결합(Tight Coupling)을 끊기 위해 우리는 중간에 중개자(Broker)를 두고 메시지를 던져놓는 비동기 이벤트 기반 아키텍처(EDA)를 사용합니다. 이때 가장 많이 고민하는 두 가지 선택지, RabbitMQ와 Kafka의 결정적 차이를 파헤쳐 봅니다.

Kaflka, RabbitMQ

1. 기본 개념: 전화 vs 이메일

이해를 돕기 위해 비유를 들어보겠습니다.

  • HTTP (REST): 전화 통화와 같습니다. 상대방이 전화를 받을 때까지 기다려야 하고, 통화 중에는 다른 일을 못 합니다. 즉각적인 응답이 필요할 때 씁니다.
  • Message Queue (Kafka/RabbitMQ): 이메일이나 슬랙과 같습니다. 나는 메시지를 보내놓고 내 할 일을 합니다. 상대방은 자기가 편할 때 메시지를 확인하고 처리합니다.

2. RabbitMQ: "똑똑한 우체부" (Smart Broker)

RabbitMQ는 전통적인 메시지 브로커입니다. 메시지를 받아서 적절한 소비자(Consumer)에게 배달해 주고, 배달이 완료되면(Ack) 메시지를 삭제합니다.

특징 및 장점

  • 복잡한 라우팅: Exchange라는 기능을 통해 메시지를 특정 큐로 보내거나(Direct), 여러 큐에 뿌리거나(Fanout), 패턴에 맞춰 보내는(Topic) 기능이 매우 강력합니다.
  • 신뢰성: 메시지 전달 보장이 강력하며, 소비자가 처리를 못 하면 다시 큐에 넣거나 Dead Letter Queue로 보낼 수 있습니다.
  • 휘발성: 기본적으로 소비된 메시지는 사라집니다. (이벤트 저장소가 아님)

3. Apache Kafka: "거대한 로그 파일" (Dumb Broker)

Kafka는 메시지 큐라기보다는 이벤트 스트리밍 플랫폼입니다. 메시지를 배달해 주는 것이 목적이 아니라, 메시지를 파일에 기록(Log)하고 소비자가 알아서 읽어가게 둡니다.

특징 및 장점

  • 압도적인 처리량(Throughput): 디스크의 순차 저장(Sequential I/O) 방식을 사용하여 초당 수백만 건의 이벤트를 처리합니다.
  • 영속성(Persistence): 소비자가 메시지를 읽어가도 삭제되지 않습니다. 설정된 기간(예: 7일) 동안 보관되므로, 나중에 다시 처음부터 읽을 수 있습니다(Replay).
  • 단순한 라우팅: RabbitMQ 같은 복잡한 라우팅 기능이 없습니다. 그냥 토픽(Topic)에 쌓고 읽어갈 뿐입니다.

4. 비교 요약표 (면접 필수)

구분 RabbitMQ Apache Kafka
설계 철학 Smart Broker, Dumb Consumer
(브로커가 똑똑함)		 Dumb Broker, Smart Consumer
(소비자가 알아서 읽어감)
처리량 높음 (수만 TPS) 매우 높음 (수십~수백만 TPS)
메시지 보관 소비(Ack) 즉시 삭제 설정 기간 동안 디스크에 보관
추천 용도 복잡한 라우팅, 작업 큐, 실시간 메시징 로그 수집, 스트림 처리, 빅데이터 파이프라인

5. 주의사항: "순서"와 "중복"

이벤트 시스템을 도입할 때 반드시 해결해야 할 난제가 있습니다.

⚠️ 멱등성 (Idempotency) 보장 필수

네트워크 문제로 인해 메시지가 두 번 전송(At-least-once)될 수 있습니다. "결제 요청" 이벤트가 두 번 오더라도, 실제 결제는 한 번만 이루어지도록 코드를 작성해야 합니다. (예: 결제 ID로 중복 체크)

또한, Kafka는 파티션(Partition) 내에서는 순서를 보장하지만, 여러 파티션을 사용할 경우 전체 순서를 보장하지 않습니다. 순서가 중요한 로직(예: 재고 차감 -> 결제 완료)은 반드시 같은 파티션 키를 사용해야 합니다.

6. 결론

"대용량 데이터 스트리밍과 로그 수집이 필요하다면 Kafka, 복잡한 메시지 라우팅과 즉각적인 작업 처리가 필요하다면 RabbitMQ"가 정답에 가깝습니다.

최근에는 MSA 환경에서 데이터 동기화(CDC)나 이벤트 소싱 용도로 Kafka가 표준처럼 쓰이고 있지만, 단순한 비동기 작업 처리(이메일 발송 등)에는 RabbitMQ가 훨씬 가볍고 운영하기 쉽습니다. 도구의 특성을 이해하고 적재적소에 배치하는 것이 아키텍트의 역량입니다.

이 블로그의 인기 게시물

Docker 컨테이너 'Connection Refused' (Errno 111) 오류 해결 가이드

이미지
🎯 타겟 독자: Docker 입문자, 컨테이너를 띄웠으나 localhost 로 접속이 안 되는 백엔드 개발자, MSA(마이크로서비스) 구축 중 통신 오류를 겪는 엔지니어. 📝 요약: Docker 접속 오류(Errno 111)의 90%는 애플리케이션이 '0.0.0.0'이 아닌 '127.0.0.1' 로 바인딩 되어 있거나, 포트 포워딩(-p) 설정이 누락되어 발생합니다. 이 글에서는 네트워크 인터페이스의 차이를 이해하고, 외부 접속을 허용하는 올바른 설정법을 정리합니다. 1. 문제 정의: "컨테이너는 떴는데 접속이 안 돼요" Docker 입문자들이 가장 흔하게 겪는 상황입니다. docker ps 로 확인하면 상태(STATUS)는 분명히 Up 인데, 브라우저나 Postman으로 접속하면 즉시 연결이 거부됩니다. curl: (7) Failed to connect to localhost port 8080: Connection refused Python: ConnectionRefusedError: [Errno 111] Connection refused 이 문제는 방화벽 때문이 아닙니다. "누구의 요청을 들을 준비가 되었는가(Listen Address)" 에 대한 설정이 잘못되었기 때문입니다. 2. 원인 분석: 127.0.0.1의 함정 핵심은 Loopback(127.0.0.1) 과 Any Address(0.0.0.0) 의 차이입니다. 로컬 PC에서 개발할 때 서버를 localhost 로 띄우는 건 보안상 좋은 습관입니다. 하지만 Docker 컨테이너는 독립된 IP를 ...
자세한 내용 보기

Redis 캐싱 전략 완벽 가이드: Look Aside부터 Write Back까지 (DB 부하 줄이기)

이미지
🎯 타겟 독자: 사용자가 몰릴 때마다 DB CPU가 100%를 치는 상황을 겪는 백엔드 개발자, Redis를 단순히 get/set 으로만 쓰고 있는 주니어 엔지니어. 📝 요약: 캐시(Cache)는 성능 향상의 치트키지만, 잘못 쓰면 데이터 불일치(Inconsistency) 라는 재앙을 부릅니다. 이 글에서는 가장 대중적인 Look Aside(Lazy Loading) 패턴과 쓰기 성능을 극대화하는 Write Back 패턴의 작동 원리, 장단점, 그리고 언제 무엇을 써야 하는지 명확한 기준을 제시합니다. 1. 캐싱 패턴이 왜 중요한가요? "그냥 Redis에 넣으면 되는 거 아닌가요?"라고 묻는다면 반은 맞고 반은 틀립니다. 캐시를 데이터베이스(DB)와 어떤 순서로 연동하느냐에 따라 시스템의 데이터 정합성 과 성능 이 완전히 달라지기 때문입니다. 2. 패턴 ① Look Aside (Lazy Loading) - 국룰 전략 현업에서 80% 이상 사용되는 가장 일반적인 읽기 전략입니다. 캐시를 옆(Aside)에 두고 필요할 때만 데이터를 가져옵니다. 작동 순서 앱이 데이터를 찾을 때 먼저 캐시(Redis)를 찌릅니다. 캐시에 데이터가 있으면(Cache Hit) 바로 반환합니다. (DB 부하 0) 없으면(Cache Miss) DB에서 조회 하여 가져옵니다. 가져온 데이터를 캐시에 저장 하고 반환합니다. public User getUser(Long id) { // 1. 캐시 조회 User user = redisTemplate.opsForValue().get("user:" +...
자세한 내용 보기

브라우저 렌더링 원리: Reflow와 Repaint 최적화 가이드 (CRP 심층 분석)

이미지
📌 핵심 요약 CRP(Critical Rendering Path) 의 5단계: DOM → CSSOM → Render Tree → Layout → Paint 성능의 주범 Reflow(Layout) 와 Repaint 의 차이점 애니메이션 성능 최적화: 왜 top/left 대신 transform 을 써야 하는가? (GPU 가속과 Composite) "사용자가 주소창에 URL을 입력하고 엔터를 쳤을 때, 화면에 네이버 메인이 뜨기까지 무슨 일이 일어나는가?" 이 질문은 네트워크 관점(DNS, TCP/IP)에서도 답변할 수 있지만, 프론트엔드 개발자라면 렌더링 엔진(Rendering Engine)이 HTML과 CSS를 해석해서 픽셀로 바꿔주는 과정, 즉 CRP(Critical Rendering Path)를 설명할 수 있어야 합니다. 이 원리를 알아야 "왜 리액트가 Virtual DOM을 쓰는지", "왜 애니메이션이 버벅이는지" 이해할 수 있습니다. 1. 렌더링 파이프라인 (The Pipeline) 브라우저는 다음 5단계를 거쳐 화면을 그립니다. DOM 트리 생성: HTML 문서를 파싱 하여 태그 간의 관계(부모-자식)를 트리 구조로 만듭니다. CSSOM 트리 생성: CSS 파일과 인라인 스타일을 파싱 하여 스타일 규칙 트리를 만듭니다. Render Tree 생성: DOM과 CSSOM을 결합하여 "실제로 화면에 표시될 노드" 만 추려냅니다. Layout (Reflow): 각 노드가 화면의 어느 위치에, 어떤 크기(px) 로 배치될지 기하학적 계산을 수행합니다. ...
자세한 내용 보기