카프카

비동기 통신, Kafka의 구조, 그리고 RabbitMQ와의 차이

 

비동기 통신

 

서비스 아키텍처가 단순할 때는 한 서비스가 다른 서비스에 직접 요청하고, 그 요청에 대한 응답을 기다리는 동기적 통신 방식만으로도 충분하다. 마치 무전기로 대화하듯이 한쪽이 말하면 다른 쪽이 듣고 있어야 하고, 상대의 상태를 알고 있어야만 정상적인 통신이 가능하다. 하지만 시스템이 커지고 마이크로서비스처럼 여러 서비스가 서로 데이터를 주고받아야 하는 환경에서는 이러한 동기 방식이 점점 부담이 된다. 한 서비스가 여러 대상에게 데이터를 보내야 하고, 수신자의 처리 속도나 상태에 따라 전체 연쇄 지연이 발생할 수 있기 때문이다.

 

이런 문제를 해결하기 위해 사용하는 것이 바로 비동기 통신이다. 비동기 방식에서는 요청을 보내는 쪽이 응답을 기다릴 필요가 없다. 메시지를 일단 “어딘가에” 맡기고 자신의 일을 계속할 수 있다. 이때 등장하는 것이 메시지 브로커(Message Broker)이다. 메시지 브로커는 Producer가 보낸 메시지를 임시로 보관하고, Consumer가 필요할 때 가져가도록 해준다. 즉, 발신자와 수신자를 직접 연결하지 않고 중간에서 역할을 나눔으로써 서로 독립적으로 움직일 수 있게 만들어주는 시스템이다.

 

메시지 브로커를 택배함에 비유하면 이해가 쉽다. 택배를 보내는 사람(Producer)은 배송 차량(Consumer)이 제때 오지 않아도 상관없이 택배함에 물건을 넣고 떠나면 된다. 택배함은 정해진 기간 동안 물건을 안전하게 보관하며, 수신자가 가져가지 않았다고 해서 물건이 사라지지 않는다. 이런 구조 덕분에 메시지를 유실하지 않고 전달할 수 있고, 생산자와 소비자가 서로 강하게 연결될 필요도 없다. 또한 소비자 수를 늘리거나 줄여도 전체 시스템에 영향을 주지 않아 수평적 확장이 쉬워진다. 이런 특성 때문에 메시지 브로커는 빠른 응답보다 안정적인 메시지 전달·확장성·서비스 간 독립성이 중요한 환경에서 널리 사용된다. 대표적으로 이메일 시스템, 로그 수집 파이프라인, 실시간 데이터 스트리밍, 그리고 MSA 환경에서의 이벤트 전달 등에 적합하다.

 

Kafka의 구조와 특징

 

Kafka는 대표적인 메시지 브로커 중 하나로, 특히 대용량 데이터를 안정적으로 처리하는 데 강점을 가진다. Kafka가 다른 브로커와 구별되는 가장 중요한 특징은 메시지를 로그 형태로 디스크에 순차적으로 저장한다는 점이다. 일반적인 메시지 큐는 메시지를 소비자가 가져가면 삭제되지만, Kafka는 메시지를 삭제하지 않고 저장해 둔다. 메시지는 각자 고유한 offset이라는 번호를 갖고 있고, Consumer는 자신이 마지막으로 읽은 offset만 기억하면 된다. 이 방식 덕분에 Consumer는 필요할 때 메시지를 다시 읽을 수도 있고, 다른 Consumer 그룹이 같은 데이터를 병렬로 처리할 수도 있다.

 

보통 "디스크는 메모리보다 느리다"라고 생각하지만, Kafka는 디스크를 매우 효율적으로 사용한다. 이유는 Kafka가 디스크에 순차적으로 데이터 쓰기를 하기 때문이다. HDD든 SSD든 순차 쓰기는 랜덤 쓰기보다 훨씬 빠르고, 헤더 이동이 적어 성능 저하가 거의 없다. 이 점이 Kafka의 높은 처리량을 가능하게 한다. 또한 Kafka는 내부적으로 메시지를 한 건씩 처리하지 않고 배치로 묶어서 처리하며, 여러 브로커에 분산 저장하도록 설계되어 있다. 이러한 구조 덕분에 Kafka는 실시간 로그 수집, 대용량 데이터 파이프라인, 스트리밍 분석 등에서 사실상 표준처럼 사용된다.

 

RabbitMQ vs Kafka — 무엇이 다를까?

 

RabbitMQ와 Kafka는 모두 메시지 브로커로 사용되지만, 철학과 구조가 완전히 다르다.

 

RabbitMQ는 큐(Queue) 기반으로 메시지를 관리한다. 메시지가 들어오면 FIFO 방식으로 쌓이고, Consumer가 가져가면 브로커에서는 그 메시지를 제거한다. 라우팅 키, 익스체인지 타입, 메시지 우선순위, TTL 등 다양한 메시지 라우팅 기능을 제공해 매우 유연한 처리가 가능하다. 반면 메모리에 의존하는 구조이기 때문에 메시지를 아주 많은 양으로 밀어 넣을 경우 유실 가능성이 존재하며, 클러스터링 구성도 상대적으로 까다롭다. 대신 RabbitMQ는 작업 큐 처리나 실시간 트랜잭션성 업무처럼 메시지가 빠르게 사라지는 형태의 처리에 적합하다.

 

Kafka는 메시지를 로그(Log) 형태로 디스크에 저장하고, 메시지를 소비해도 삭제하지 않는다. Consumer가 현재 offset만 관리하면 되기 때문에 같은 데이터를 여러 Consumer가 서로 다른 속도로 읽는 것이 자연스럽게 지원된다. 메시지가 대량으로 쌓여도 디스크 기반 구조 때문에 안정적이고, 분산 클러스터링이 기본적으로 쉬워 고가용성과 확장성에 매우 유리하다. 대신 RabbitMQ처럼 복잡하고 정교한 라우팅 기능은 제공하지 않으며, 메시지가 즉시 처리되어야 하는 "작업 큐" 용도로는 적합하지 않다. Kafka는 대규모 스트리밍, 로그 집계, 데이터 파이프라인처럼 대량의 데이터를 안정적으로 처리해야 하는 경우에 최적화되어 있다.

 

구분	RabbitMQ	Kafka
메시지 저장 방식	큐(Q) 형태, FIFO(선입선출)	로그(Log) 형태, 디스크에 저장
메시지 삭제 시점	컨슈머가 가져가면 브로커에서 제거	컨슈머가 가져가도 로그에 남아 있음 (오프셋 관리)
신뢰성	컨슈머 완료 신호 확인 가능 → 안정적	컨슈머가 중복/재처리 가능, 장애 복구 용이
저장 위치	주로 메모리	디스크
성능	빠름, 유실 위험 있음	디스크 저장, 배치 처리로 높은 처리량 가능
클러스터링	어려움 (실시간 동기화 필요)	용이 (분산 클러스터)
활용 분야	작업 큐, 이미지 처리, 트랜잭션 처리	로그 수집, 스트리밍 데이터 파이프라인, 대용량 처리

RabbitMQ

• 스마트 브로커 + 단순 큐
• 메시지 라우팅, 우선순위, TTL, 안정성 있는 처리 가능
• 작은 규모, 복잡한 라우팅, 신뢰성 중심

Kafka

• 브로커가 단순, 컨슈머가 오프셋 관리
• 메시지 디스크 저장 → 안전, 대규모 분산 처리 유리
• 빠른 처리량, 스트리밍 데이터 처리에 최적

 

Kafka의 내부 구조: 브로커, 파티션, 오프셋, 컨슈머 그룹

 

Kafka가 어떻게 대규모 메시지를 안정적으로 처리하는지 이해해보자.

• Kafka 클러스터: 여러 개의 브로커(Kafka 서버)로 구성된 집합체
• 브로커(Broker): 메시지를 저장하고 관리하는 실제 서버 단위
• 토픽(Topic): 메시지를 저장하는 논리적 단위, 파티션으로 나뉨
• 파티션(Partition): 토픽 내 메시지 저장 단위, 브로커에 분산 저장됨

 

프로듀서가 메시지를 보낼 때

1. 프로듀서는 메시지를 특정 토픽에 보내겠다고 Kafka 클러스터에 요청을 보낸다.
2. Kafka 클러스터는 내부적으로 토픽의 파티션과 브로커 정보를 확인
3. 실제로 메시지는 클러스터 내 특정 브로커의 해당 파티션에 저장

 

 

Kafka를 이해하기 위해서는 먼저 Kafka 내부에서 메시지가 어떻게 흘러가는지, 그리고 그 과정을 담당하는 구성요소들이 무엇인지 알아야 한다. Kafka에서 가장 중요한 요소는 프로듀서, 컨슈머, 그리고 토픽이다. 이 세 가지는 Kafka 구조의 기초이자, 메시지가 만들어지고, 분류되고, 처리되는 전체 흐름을 결정하는 핵심 개념이다.

 

• 프로듀서

Kafka에 메시지를 전달하는 주체로, 쉽게 말하면 데이터를 "보내는 사람"이다. 사용자가 새로운 주문을 생성하거나 이메일 발송 요청이 들어오는 상황을 떠올려보면 된다. 이런 이벤트가 발생할 때 서비스는 이를 메시지 형태로 만들어 Kafka에 전달하는데, 이 역할을 하는 것이 바로 프로듀서다. 메시지는 단일 텍스트가 될 수도 있고, JSON 형태의 구조화된 데이터일 수도 있으며, 어떤 처리를 요구하는 요청 정보일 수도 있다. 중요한 점은 서비스가 직접 다른 서비스와 통신하는 것이 아니라, Kafka라는 중간 지점에 데이터를 보내는 방식으로 분리된 구조를 만든다는 점이다.

 

• 컨슈머

메시지가 Kafka에 저장되면 이를 실제로 처리하는 주체는 컨슈머. 컨슈머는 Kafka로부터 메시지를 직접 가져와 실질적인 작업을 수행한다. 예를 들어 이메일 발송 요청 메시지가 들어왔다면, 이메일 발송을 담당하는 컨슈머가 해당 메시지를 읽어 실제 이메일을 보내는 식이다. 또 주문 생성 메시지가 들어오면 주문 처리 컨슈머가 재고를 차감하거나 결제 과정을 진행할 수 있다. 컨슈머는 Kafka에 저장된 메시지를 지속적으로 조회하면서 새로운 메시지가 있는지 확인하고, 있다면 그것을 가져와 지정된 로직에 따라 처리한다. 이로 인해 프로듀서와 컨슈머는 서로 직접 연결될 필요 없이 독립적으로 동작할 수 있게 된다.

 

• 토픽

이때 모든 메시지가 한곳에 뒤섞여 저장된다면 관리가 매우 어렵기 때문에 Kafka는 메시지를 종류별로 구분하기 위해 토픽이라는 개념을 사용한다. 토픽은 메시지를 분류하는 공간으로, 이메일 전송 메시지는 이메일 관련 토픽에, 주문 생성 메시지는 주문 관련 토픽에, 사용자 비밀번호 변경 메시지는 해당 토픽에 저장하는 식으로 나눌 수 있다. 중요한 점은 Kafka가 메시지를 자동으로 분류해주는 것이 아니라, 프로듀서가 메시지를 보낼 때 “이 메시지는 어느 토픽에 넣을 것인지”를 명확히 지정해야 한다는 점이다. 마치 이메일함에서 폴더를 지정해 메일을 정리하듯이, 프로듀서가 토픽을 지정하고 Kafka는 그 토픽에 메시지를 저장한다. 그리고 컨슈머는 자신이 담당하는 토픽을 구독해 필요한 메시지만 가져오면 되기 때문에 전체 시스템이 훨씬 단순해지고 효율적으로 관리된다.

결국 Kafka는 프로듀서가 생성한 메시지를 토픽별로 저장하고, 컨슈머가 이를 가져가 처리하는 구조를 통해 서비스 간의 결합도를 낮추고, 대규모 데이터를 비동기적으로 안정적으로 처리할 수 있게 해준다. 이 세 가지 개념만 이해해도 Kafka가 왜 비동기 처리와 MSA 환경에서 강력한 도구로 활용되는지 기본적인 감을 잡을 수 있다. 다음 단계에서는 Kafka의 내부 저장 방식과 분산 구조를 구성하는 브로커, 파티션, 오프셋, 컨슈머 그룹에 대해 알아보면 Kafka의 전체 그림이 훨씬 명확해질 것이다.

 

Kafka는 여러 서버가 함께 동작하는 분산 시스템이다. 먼저 Kafka 클러스터는 하나가 아닌 여러 개의 Kafka 서버로 구성되는데, 이 서버 한 대 한 대를 브로커라고 부른다. 프로듀서가 메시지를 전송하면 이 메시지는 특정 브로커에 저장되고, 컨슈머는 이 브로커로부터 메시지를 가져가 처리한다. 시스템이 커져도 브로커를 추가하기만 하면 되기 때문에 Kafka는 수평적 확장이 매우 쉽다는 특징을 가진다.

 

• 파티션

Kafka의 또 하나의 핵심 개념은 파티션. 토픽이라는 메시지 분류 단위를 설명했는데, Kafka는 이 토픽을 다시 여러 파티션으로 나눠 저장한다. 파티션을 쉽게 말하면 "토픽의 메시지가 나뉘어 저장되는 여러 줄"이라고 생각하면 된다. 파티션이 여러 개라면 프로듀서는 메시지를 여러 서버에 분산해서 기록할 수 있고, 컨슈머 또한 여러 파티션을 동시에 읽을 수 있어 전체 처리량이 크게 증가한다. Kafka가 대규모 데이터를 빠르게 처리할 수 있는 이유 중 하나가 바로 이 파티션 기반 분산 처리 방식

 

• 오프셋

파티션 안에 저장된 메시지들은 순서대로 번호가 부여되는데, 이 번호를 오프셋이라고 한다. 오프셋은 Kafka가 메시지를 삭제하지 않고 디스크에 차곡차곡 쌓아두면서도, 컨슈머가 어디까지 읽었는지 추적할 수 있게 해준다. 예를 들어, 컨슈머가 오프셋 15까지 처리했다면 다음번 조회 시에는 오프셋 16부터 메시지를 읽는것이다. 이 방식 덕분에 컨슈머가 일시적으로 중단되어도 재시작 후 정확히 이어서 메시지를 처리할 수 있고, 필요하다면 같은 메시지를 다시 읽으며 재처리하는 것도 가능해진다.

 

• 컨슈머 그룹

컨슈머 그룹은 여러 개의 컨슈머가 하나의 토픽을 협력하여 처리할 수 있도록 묶어놓은 단위이다. 예를 들어, 하나의 토픽에 3개의 파티션이 있고, 컨슈머 그룹에 3개의 컨슈머가 있다면 각 컨슈머는 한 파티션씩 담당하여 병렬 처리할 수 있다. 컨슈머가 많아지면 처리량이 증가하고, 하나가 고장 나도 다른 컨슈머가 대신 처리할 수 있어 안정성도 높아진다.

 

즉,Kafka는 단순히 메시지를 저장하고 전달하는 브로커일 뿐만아니라 분산 시스템, 파티션을 통한 수평 확장, 오프셋 기반의 안정적 메시지 처리, 그리고 컨슈머 그룹을 통한 병렬 처리 구조를 통해 뛰어난 성능을 제공하는 플랫폼이다.