메시지 큐와 Kafka

메시지 큐란

메시지 큐(message queue) 는 생산자(producer)가 넣은 메시지를 보관했다가 소비자(consumer)에게 넘기는 중간 저장소다. 생산자와 소비자가 서로의 속도·가용성에 묶이지 않게 떼어 놓는 것이 핵심이다. 비동기 처리와 생산자·큐·소비자의 기본 구성은 웹 확장성의 구성 요소에 있다.

고를 때 보는 기준

Kafka를 직접 운영할지 관리형 스트림을 쓸지도 갈린다. Kafka는 브로커가 「누가 어디까지 읽었나」를 메시지마다 기록하지 않고 소비자가 오프셋을 들고 가는 분산 커밋 로그라 커넥터 생태계가 가장 넓지만, 브로커 운영을 떠안는다(관리형 Kafka로 덜 수 있다). Amazon Kinesis Data Streams는 운영이 없는 대신 샤드 단위 한도 안에서 설계해야 한다.

Google Cloud Pub/Sub은 샤드를 드러내지 않는 대신 순서는 순서 키 단위로만 보장한다.

구조의 변화: 큐에서 로그로

flowchart LR
  a["전통 메시지 큐<br/>(IBM MQ)"] --> b["브로커 라우팅 큐<br/>(RabbitMQ)"] --> c["분산 로그<br/>(Kafka)"] --> d["서빙·저장 분리<br/>(Pulsar)"]

오래된 메시지를 싼 오브젝트 스토리지로 내려 보관하는 계층형 저장(tiered storage) 은 Pulsar가 먼저 기본으로 내세웠고, Kafka도 3.6부터 정식 기능으로 들어왔다.

큐(queue)와 로그(log)의 차이가 고르는 기준이 된다. 큐는 「작업을 한 소비자에게 한 번 넘기고 지운다」, 로그는 「일어난 일을 순서대로 남기고 여러 소비자가 각자 읽는다」. 그래서 처리할 작업(커맨드) 을 워커에게 나눠 줄 때는 메시지 큐가, 일어난 사실(이벤트) 을 여러 시스템이 각자 읽고 다시 읽어야 할 때는 이벤트 스트림이 맞는다. 커맨드와 이벤트의 구분은 이벤트 기반 아키텍처 설계에 있다.

Kafka와 RabbitMQ

둘의 경계는 좁아지고 있다. RabbitMQ는 Raft로 복제하는 쿼럼 큐(quorum queue)와 로그처럼 다시 읽는 스트림(stream)을 지원하고, Kafka는 공유 그룹(share group, 「Queues for Kafka」)으로 파티션 하나를 여러 소비자가 레코드 단위로 확인하며 나눠 읽는 큐 방식을 4.2에서 정식 기능으로 넣었다.

점대점과 발행·구독을 함께 쓰기

그래서 대부분의 시스템은 구독 그룹 사이에는 토픽처럼, 그룹 안에서는 큐처럼 동작하는 모델을 제공한다. Kafka의 컨슈머 그룹, ActiveMQ·Amazon MQ의 Virtual Topic(논리 토픽에 발행하면 브로커가 구독 그룹마다 물리 큐를 만든다), SNS 토픽 → 서비스별 SQS 큐 팬아웃이 같은 생각이다. 생산자를 고치지 않고 소비자를 늘리고 줄일 수 있다.

큐와 토픽이 흔히 주는 기능

관리형 큐(Amazon SQS, RabbitMQ)와 발행·구독 서비스(Amazon SNS, Google Pub/Sub)를 고를 때 보는 기능들이다.

발행·구독 쪽은 다음을 더 본다.

큐에 쌓인 양이 메모리를 넘으면 디스크로 밀려 처리가 더 느려지는 악순환이 생긴다. 그래서 큐 길이에 상한을 두고, 가득 차면 생산자나 클라이언트에 「바쁘다」(HTTP 503)를 돌려 지수 백오프로 나중에 다시 오게 하는 배압을 건다(배압 전략).

Kafka의 구조

Kafka는 분산 이벤트 저장소이자 스트리밍 플랫폼이다. 원래 대규모 로그 처리를 위해 만들어져, 메시지를 보존 기간이 끝날 때까지 남겨 두고 소비자가 자기 속도로 끌어가게(pull) 한다.

flowchart TB
  prod["Producer"] --> topic["Topic #quot;orders#quot;"]
  topic --> p0["Partition 0: [0][1][2][3][4] ...<br/>리더는 Broker 1, 복제본은 Broker 2·3"]
  topic --> p1["Partition 1: [0][1][2] ...<br/>리더는 Broker 2"]
  topic --> p2["Partition 2: [0][1][2][3] ...<br/>리더는 Broker 3"]
  subgraph ga["Consumer Group A"]
    a1["컨슈머 a1"]
    a2["컨슈머 a2"]
  end
  subgraph gb["Consumer Group B (같은 데이터를 독립적으로 읽는다)"]
    b1["컨슈머 b1"]
  end
  p0 --> a1
  p1 --> a2
  p2 --> a2
  p0 --> b1
  p1 --> b1
  p2 --> b1

클러스터 메타데이터는 과거에 ZooKeeper가 관리했지만, Kafka 4.0부터는 Kafka 자체의 합의 프로토콜인 KRaft 만 지원한다.

왜 빠른가

일반 전송 (복사 4번, 문맥 전환 여러 번)

flowchart LR
  d["디스크"] --> pc["OS 페이지 캐시"] --> ab["애플리케이션 버퍼"] --> sb["소켓 버퍼"] --> nic["NIC"]

제로 카피 (sendfile)

flowchart LR
  d["디스크"] --> pc["OS 페이지 캐시"] --> nic["NIC"]

제로 카피는 브로커가 저장한 바이트를 그대로 내보낼 수 있을 때만 된다. TLS로 암호화해 보내면 사용자 공간에서 암호화해야 하므로 이 이점이 사라진다.

전달 보장 수준

메시지 시스템이 「몇 번 전달하느냐」에 대해 약속하는 수준이다.

정확히 한 번이 어려운 이유

보낸 쪽은 확인 응답이 오지 않았을 때 메시지가 안 간 것인지, 처리됐는데 응답만 잃은 것인지 구별할 수 없다(분산 시스템의 시간과 장애). 다시 보내면 중복이 생기고, 안 보내면 유실이 생긴다. 소비자 쪽도 같다. 「처리」와 「처리했다는 기록(오프셋 커밋, ack)」은 서로 다른 시스템에 쓰는 두 동작이라, 둘 사이에 죽으면 둘 중 하나만 남는다. 그래서 네트워크 전달만으로는 정확히 한 번을 만들 수 없고, 최소 한 번 전달 + 멱등한 처리(같은 메시지를 여러 번 처리해도 결과가 한 번과 같게)로 효과상 정확히 한 번(effectively once) 을 만든다.

Kafka의 정확히 한 번(EOS)

Kafka는 읽고-처리하고-쓰는(consume-transform-produce) 흐름이 Kafka 안에서 닫혀 있을 때 정확히 한 번을 보장한다.

Kafka 밖의 DB나 외부 API에 쓰는 순간 이 보장은 끝난다. 그쪽은 멱등한 쓰기나 「결과와 오프셋을 같은 DB 트랜잭션에 저장」으로 맞춘다(Kafka 운영의 오프셋 관리). 멱등성을 적용하는 방법은 장애 확산을 막는 복원력 패턴에 있다.

메시지는 어디서 유실되나

「Kafka는 메시지를 잃지 않는다」는 설정이 맞을 때의 이야기다. 유실은 세 구간에서 생긴다.

flowchart LR
  subgraph prod["프로듀서"]
    send["send()"] --> acc["레코드 누산기(버퍼)"] --> th["송신 스레드"]
  end
  subgraph broker["브로커"]
    pc["리더 페이지 캐시"] -->|"비동기 flush"| disk["디스크"]
    pc --> rep["팔로워 복제"]
  end
  subgraph cons["컨슈머"]
    poll["poll()"] --> proc["처리"] --> commit["오프셋 커밋"]
  end
  th --> pc
  broker --> poll

처리한 뒤 커밋하면 커밋 직전에 죽었을 때 같은 메시지를 다시 처리한다. 즉 유실을 막으면 중복이 생기므로 소비자 처리를 멱등하게 만드는 것이 한 세트다. acks와 min.insync.replicas 조합별로 쓰기가 성공·실패하는 조건, 오프셋 커밋 방식의 비교는 Kafka 운영: 복제, 컨슈머 그룹, 튜닝, 모니터링에 있다.

Kafka가 쓰이는 곳

스트림 처리와 배치 처리

Kafka는 둘 다의 입력이 된다. 보존 기간 동안 로그가 남아 있으므로 같은 토픽을 스트림 처리기(Kafka Streams, Flink)가 실시간으로 읽고, 배치 작업이 오프셋 범위를 정해 한꺼번에 읽을 수도 있다. 로직을 바꾸면 오프셋을 되돌려 로그를 다시 재생해 결과를 새로 만드는 것도 된다. 배치 계층과 실시간 계층을 따로 두는 람다 아키텍처 대신 스트림 하나와 재생으로 둘을 대신하는 구조를 카파 아키텍처(Kappa architecture)라고 한다. 배치·스트림·ETL의 일반 용어는 데이터 파이프라인과 저장소 용어에 있다.

NoSQL 저장소로 내보낼 때

Kafka 토픽을 MongoDB·Cassandra·Elasticsearch 같은 저장소에 싱크할 때 맞출 것은 다음과 같다.

직접 컨슈머를 짜기보다 Kafka Connect 싱크 커넥터(MongoDB, Cassandra, Elasticsearch 커넥터)를 쓰면 오프셋·재시도·DLQ를 프레임워크가 맡는다.

처리 실패와 DLQ

소비자가 메시지를 처리하다 실패하면 무한히 다시 시도할 수도, 버릴 수도 없다. 실패를 종류별로 나눠 다룬다.

Kafka에는 브로커가 제공하는 DLQ가 없다. 실패한 메시지를 별도 토픽에 쓰는 것이 DLQ다.

flowchart LR
  orders["orders"] -->|"컨슈머"| fail["처리 실패"]
  fail -->|"일시적"| r1["orders.retry.1m"] --> r10["orders.retry.10m"] --> still["(그래도 실패)"]
  fail -->|"영구적"| dlt["orders.dlt"]
  dlt -->|"원인 수정 뒤 재처리 도구가 원래 토픽으로 다시 보낸다"| orders

• DLQ 메시지에는 원래 토픽·파티션·오프셋, 예외 종류·메시지, 실패 시각을 헤더로 붙여 원인을 추적하고 재처리할 수 있게 한다.
• DLQ는 쌓이기만 하면 소용없다. 적재량에 경보를 걸고, 원인을 고친 뒤 다시 흘려보낼 재처리 경로를 처음부터 만든다.
• Spring for Apache Kafka는 DefaultErrorHandler + DeadLetterPublishingRecoverer(막는 재시도)와 @RetryableTopic(재시도 토픽 체인)을 제공한다. Kafka Connect는 싱크 커넥터에 errors.tolerance=all과 errors.deadletterqueue.topic.name을 주면 변환·직렬화에 실패한 레코드를 DLQ 토픽으로 보낸다.

Kafka 생태계: Connect, Streams, 스키마 레지스트리

Kafka Connect

flowchart LR
  src["원천 DB"] --> sc["소스 커넥터<br/>(Debezium 등)"] --> t["Kafka 토픽"] --> sk["싱크 커넥터<br/>(Elasticsearch, JDBC, S3 등)"] --> dst["검색 엔진·DW·NoSQL"]

파이프라인은 REST API로 커넥터 설정(JSON)을 등록해 만든다. 맞는 커넥터가 없으면 직접 만든다.

Kafka Streams와 상태 저장소

Kafka Streams는 별도 클러스터 없이 애플리케이션 인스턴스를 늘리는 것으로 확장하는 라이브러리다. 입력 토픽의 파티션이 처리 단위(태스크)가 되고, 같은 application.id를 쓰는 인스턴스들이 컨슈머 그룹처럼 태스크를 나눈다.

상태가 클수록 장애 뒤 변경 로그 재생이 오래 걸린다. 대기 복제본, 로컬 상태 디렉터리(state.dir)를 재시작 뒤에도 남기는 배포, 정적 멤버십으로 태스크가 다른 인스턴스로 옮겨 다니지 않게 하는 것이 복원 시간을 줄인다.

스키마 레지스트리

생산자와 소비자는 서로 다른 시기에 배포된다. 메시지 형식이 말없이 바뀌면 소비자가 역직렬화에 실패하거나 필드를 잘못 읽는다. 스키마 레지스트리는 토픽별 스키마 버전을 한곳에 두고 호환성 규칙을 강제한다.

flowchart LR
  subgraph p["프로듀서"]
    p1["스키마 등록<br/>(호환성 검사 통과해야 등록)"] --> p2["스키마 ID 받음"] --> p3["[매직 바이트][스키마 ID 4바이트][Avro 바이트] 전송"]
  end
  subgraph c["컨슈머"]
    c1["메시지 앞의 스키마 ID로 레지스트리에서<br/>스키마를 받아(캐시) 역직렬화"]
  end

• 메시지마다 스키마 전체가 아니라 ID만 실어 크기를 줄인다.
• 호환성 규칙(backward, forward, full)을 어기는 변경은 등록 단계에서 거절되므로, 깨지는 배포가 운영에 나가기 전에 막힌다. 규칙의 뜻과 안전한 변경 방법은 데이터 관리 패턴의 스키마 진화에 있다.
• Avro, Protobuf, JSON Schema를 지원한다.

운영 설계: 공유 클러스터와 보존 정책

정리

• 큐는 작업을 한 번 넘기고 지우고, 로그는 일어난 일을 남겨 여러 소비자가 다시 읽게 한다. Kafka는 로그 쪽이다.
• Kafka의 순서는 파티션 안에서만 보장되고, 컨슈머 그룹의 병렬도는 파티션 수가 상한이다.
• 속도는 순차 I/O, 페이지 캐시, 제로 카피, 배치에서 나온다.
• 유실을 막으려면 프로듀서 acks=all·멱등성, 브로커 복제·min.insync.replicas, 컨슈머 「처리 후 커밋」을 함께 맞춘다.
• 정확히 한 번은 최소 한 번 전달에 멱등한 처리를 더해 만든다.
• 처리 실패는 일시적·영구적으로 나눠 재시도 토픽과 DLQ로 보내고, 재처리 경로를 함께 만든다.
• 외부 시스템 연동은 Kafka Connect, 상태 있는 스트림 처리는 Kafka Streams, 형식 계약은 스키마 레지스트리가 맡는다.

더 읽을거리: 「스케일아웃없이 순간 급증하는 주문 처리하기 (Microservice with Kafka)」(영상)

관련 노트: Kafka 운영: 복제, 컨슈머 그룹, 튜닝, 모니터링, 이벤트 기반 아키텍처 설계, 웹 확장성의 구성 요소: 한 장으로 보는 웹 아키텍처, 데이터 관리 패턴: CDC, 이벤트 소싱, CQRS, 최종 일관성, 실시간 추천과 실험: 밴딧, 피드백 지연, A/B 테스트, 대기열 시스템(가상 대기실) 설계, 큐와 덱