[카프카 챌린지] 2부: 카프카의 주요 개념들. 큰 그림 잡기

지난 글에서는 Kafka가 왜 등장했는지, 그리고 Kafka를 단순한 메시지 큐가 아니라 이벤트 스트리밍 플랫폼으로 이해해야 하는 이유를 다뤘다.

이번 글에서는 Kafka를 이해하기 위해 반드시 알아야 하는 주요 개념들을 정리해 보려고 한다.

 

 

Kafka, Cluster, Broker

Kafka는 분산 이벤트 스트리밍 플랫폼이다. 여기서 Kafka는 특정 서버 하나를 의미하기보다는 전체 시스템을 의미한다고 이해하는 것이 좋다. 애플리케이션에서 발생한 이벤트를 받아 저장하고, 필요한 시스템이 이를 읽어 처리할 수 있도록 도와준다.

 

Kafka Cluster는 Kafka가 동작하는 여러 서버 또는 프로세스의 집합이다. Kafka는 보통 하나의 서버가 아니라 여러 서버를 묶어서 하나의 클러스터로 구성한다.

Broker는 이 Kafka Cluster를 구성하는 각각의 서버를 의미한다. 예를 들어 Kafka 서버가 3대라면 Broker도 3개라고 보면 된다.

 

Kafka를 이렇게 Cluster로 구성하는 이유는 크게 두 가지다.

• 수평 확장성: Broker를 추가하면 처리량을 늘릴 수 있다.
• 장애 허용성: 일부 Broker에 장애가 발생해도 전체 시스템은 계속 동작할 수 있다.

 

Topic

Topic은 메시지를 분류하는 논리적인 단위다. 이벤트를 목적에 따라 나누는 카테고리 라고 보면 된다.

예를 들어 쇼핑몰 서비스에서는 다음과 같은 Topic을 만들 수 있다.

user_created
order_created
payment_completed
delivery_started
coupon_issued

Producer는 특정 Topic에 이벤트를 기록하고, Consumer는 필요한 Topic을 읽어서 처리한다.

중요한 점은 Topic은 논리적인 개념이고, 실제 데이터는 내부적으로 Partition 단위로 나뉘어 저장된다는 것이다.

 

 

Partition

Topic은 하나 이상의 Partition으로 나뉜다. Partition은 실제 메시지가 저장되는 단위다.

order_created
├─ partition-0
├─ partition-1
└─ partition-2

Kafka가 Partition을 사용하는 이유는 병렬 처리 때문이다. Partition이 여러 개 있으면 Producer는 여러 Partition에 동시에 데이터를 쓸 수 있고, Consumer도 여러 Partition을 나눠 읽을 수 있다.

또한 Partition은 여러 Broker에 분산 저장될 수 있어 확장성과 안정성을 동시에 확보할 수 있다.

 

Partition의 중요한 특징은 append-only 구조다. 메시지는 끝에 계속 추가되며, 기존 데이터를 수정하거나 중간에서 삭제하지 않는다.

 

 

Offset

Offset은 Partition 안에서 메시지의 위치를 나타내는 번호다.

partition-0: offset 0, 1, 2, 3 ...
partition-1: offset 0, 1, 2, 3 ...
partition-2: offset 0, 1, 2, 3 ...

Offset은 Partition마다 따로 존재한다. 따라서 Offset은 항상 Partition과 함께 이해해야 한다.

 

Consumer는 Offset을 기준으로 어디까지 읽었는지를 추적한다.

 

 

Topic 전체 순서 vs Partition 내부 순서

Kafka에서는 Topic 전체 순서가 아니라 Partition 내부 순서만 보장된다. 즉, 서로 다른 Partition에 있는 메시지 간의 순서는 보장되지 않는다.

 

그래서 순서가 중요한 데이터는 반드시 같은 Partition으로 들어가도록 설계해야 한다. 이를 위해 보통 메시지 Key를 사용한다.

 

Topic, Partition, Offset 관계 정리

 

Producer와 Partitioner

Producer는 Kafka에 이벤트를 기록하는 역할을 한다.

Producer는 메시지를 보낼 때 다음을 결정해야 한다.

• 어떤 Topic으로 보낼지
• 어떤 Partition에 저장할지

이때 Partition을 결정하는 역할을 하는 것이 Partitioner다.

• Key가 있는 경우 → 같은 Key는 같은 Partition으로
• Key가 없는 경우 → 설정된 Partitioner 전략에 따라 Partition 선택

 

Consumer

Consumer는 Kafka에 저장된 이벤트를 읽어서 처리하는 역할을 한다.

 

Kafka의 특징은 하나의 이벤트를 여러 시스템이 동시에 사용할 수 있다는 점이다.

메시지를 읽었다고 해서 바로 삭제되지 않기 때문이다.

 

 

Consumer Group

Consumer Group은 같은 목적을 가진 Consumer들의 묶음이다.

 

예를 들어 order_created Topic을 읽어 알림을 보내는 Consumer가 있다고 해보자. 주문량이 적을 때는 Consumer 하나로도 충분하지만, 주문량이 많아지면 하나의 Consumer가 모든 메시지를 처리하기 어려울 수 있다.

 

이때 같은 역할을 하는 Consumer를 여러 개 띄우고 하나의 Consumer Group으로 묶을 수 있다. 같은 Consumer Group 안의 Consumer들은 Topic의 Partition을 나눠서 처리한다.

order_created
├─ partition-0 -> consumer-1
├─ partition-1 -> consumer-2
└─ partition-2 -> consumer-3

이렇게 하면 여러 Consumer가 메시지를 병렬로 처리할 수 있다.

 

주의할 점은 하나의 Partition은 같은 Consumer Group 안에서 동시에 하나의 Consumer만 처리할 수 있다는 것이다. 따라서 Consumer 수가 Partition 수보다 많으면 놀고 있는 Consumer가 생길 수 있고, Partition 수가 Consumer 수보다 많으면 Consumer 하나가 여러 Partition을 맡을 수 있다.

 

 

서로 다른 Consumer Group

서로 다른 Consumer Group은 같은 Topic을 독립적으로 읽을 수 있다.

 

예를 들어 order_created Topic을 알림 시스템과 통계 시스템이 함께 사용한다고 해보자. 알림 시스템은 주문 생성 이벤트를 읽어 사용자에게 알림을 보내고, 통계 시스템은 같은 이벤트를 읽어 매출 통계를 계산할 수 있다.

 

이때 두 시스템은 서로 다른 Consumer Group으로 구성할 수 있다. 각 Consumer Group은 자신만의 Offset을 관리하므로, 알림 시스템이 어디까지 읽었는지와 통계 시스템이 어디까지 읽었는지는 서로 영향을 주지 않는다.

 

이 구조 덕분에 Kafka에서는 하나의 이벤트를 여러 시스템이 각자의 목적에 맞게 사용할 수 있다.

 

서로 다른 consumer group은 같은 topic도 독립적으로 consume

 

 

Event, Message, Record

Kafka를 공부하다 보면 Event, Message, Record라는 표현이 함께 나온다. 세 단어는 대부분 같은 데이터를 가리키지만, 강조하는 관점이 조금 다르다.

• Event: 비즈니스 관점에서 발생한 일
• Message: Producer와 Consumer 사이에서 전달되는 데이터
• Record: Kafka 내부에 저장되는 데이터 단위

결국 같은 데이터를 어떤 관점에서 바라보느냐의 차이라고 이해하면 된다.

 

 

Log와 Segment

Kafka의 Partition은 append-only log 구조로 동작한다.

메시지는 Partition의 끝에 계속 추가되고, 기존 메시지를 중간에서 수정하거나 삭제하는 방식으로 다루지 않는다. 이 구조 덕분에 Kafka는 메시지를 순차적으로 저장하고 처리할 수 있다.

 

다만 하나의 파일에 모든 메시지를 계속 저장하면 관리가 어렵기 때문에, Kafka는 Partition의 데이터를 여러 Segment로 나누어 관리한다.

 

 

Retention

Kafka는 Consumer가 메시지를 읽었다고 바로 삭제하지 않는다.

대신 Retention 정책에 따라 데이터를 일정 기간 보관한다. 이 덕분에 다른 Consumer Group이 같은 데이터를 읽을 수 있고, 필요한 경우 아직 보관 중인 메시지를 다시 읽을 수도 있다.

 

그래서 Kafka는 단순히 메시지를 꺼내면 사라지는 Queue라기보다는, 이벤트를 일정 기간 저장해 두는 분산 로그에 가깝게 이해할 수 있다.

 

 

Replication

Replication은 데이터를 여러 Broker에 복제하는 기능이다.

중요한 점은 Replication이 Topic 단위가 아니라 Partition 단위로 이루어진다는 것이다. 하나의 Partition은 여러 Broker에 복제될 수 있고, 이를 통해 일부 Broker에 장애가 발생해도 데이터를 계속 사용할 수 있다.

 

 

Leader와 Follower

복제된 Partition 중 하나는 Leader가 되고, 나머지는 Follower가 된다.

Leader는 해당 Partition의 읽기와 쓰기 요청을 처리한다. Follower는 Leader의 데이터를 복제해서 따라간다.

만약 Leader가 있는 Broker에 장애가 발생하면, Follower 중 하나가 새로운 Leader가 될 수 있다.

 

 

ISR

ISR은 In-Sync Replicas의 약자다.

쉽게 말하면 Leader와 정상적으로 동기화되고 있는 Replica들의 집합이다. Leader에 장애가 발생하면 Kafka는 이 ISR 안에 있는 Replica 중 하나를 새로운 Leader로 선택할 수 있다.

"복제본 중에서도 Leader를 잘 따라가고 있는 복제본들의 목록" 정도로 이해하면 된다.

 

 

ZooKeeper와 KRaft

과거 Kafka는 클러스터 메타데이터 관리를 위해 ZooKeeper를 사용했다.

하지만 ZooKeeper를 별도로 운영해야 했기 때문에 운영 복잡도가 있었다. 최근 Kafka는 KRaft 구조를 통해 ZooKeeper 없이 Kafka 내부에서 메타데이터를 관리하는 방향으로 바뀌었다.

 

 

---

 

본 글은 쉬운코드 유튜브 채널의 회원 전용 Kafka 챌린지 라이브 강의를 기반으로 개인 학습 및 복습 목적으로 정리한 내용입니다.

원본 영상은 아래 링크에서 확인할 수 있습니다.

https://www.youtube.com/live/VCSjdgV6d2c