Kafka 데이터 관리의 핵심, 토픽과 파티션 이해하기

1.1 들어가며: Kafka의 성능을 결정하는 토픽과 파티션#

Kafka를 처음 접하면 토픽과 파티션이라는 개념을 가장 먼저 만나게 됩니다.

토픽은 메시지를 논리적으로 분류하는 단위이고, 파티션은 토픽의 데이터를 실제로 나누어 저장하는 단위입니다.

쉽게 생각하면 토픽은 데이터의 이름표이고, 파티션은 실제로 데이터를 나누어 처리하는 작업 공간에 가깝습니다.

예를 들어 쇼핑몰에서 다음과 같은 이벤트가 발생한다고 생각해 보겠습니다.

  • 주문 생성
  • 결제 완료
  • 상품 배송 시작
  • 회원 가입
  • 상품 조회

이러한 데이터를 하나의 토픽에 모두 저장할 수도 있지만, 일반적으로는 데이터의 성격과 소비 주체에 따라 적절한 토픽으로 분리합니다.

Kafka Cluster
│
├── orders
│   ├── Partition 0
│   ├── Partition 1
│   └── Partition 2
│
├── payments
│   ├── Partition 0
│   └── Partition 1
│
└── user-events
    ├── Partition 0
    ├── Partition 1
    └── Partition 2

여기서 중요한 것은 토픽의 개수보다 파티션 설계가 Kafka의 처리량과 확장성에 직접적인 영향을 준다는 점입니다.

Kafka를 단순히 메시지를 저장하는 시스템으로 이해하면 토픽과 파티션의 중요성을 놓치기 쉽습니다.

Kafka의 강력한 처리 성능은 데이터를 파티션으로 나누고 여러 프로듀서와 컨슈머가 이를 병렬로 처리할 수 있도록 설계된 구조에서 나옵니다.

1.2 토픽이란 무엇일까요?#

토픽은 Kafka에서 메시지를 논리적으로 분류하는 이름 있는 스트림입니다.

예를 들어 다음과 같이 서비스의 목적에 따라 토픽을 구성할 수 있습니다.

orders
payments
user-events
product-events
notifications
logs

프로듀서는 특정 토픽으로 메시지를 보내고, 컨슈머는 특정 토픽에서 메시지를 읽습니다.

Producer
   │
   │ 주문 이벤트
   ▼
orders Topic
   │
   ├── Partition 0
   ├── Partition 1
   └── Partition 2
          │
          ▼
      Consumer Group

토픽 자체가 메시지를 하나의 파일에 모두 저장하는 것은 아닙니다.

실제 데이터 저장과 병렬 처리의 기본 단위는 파티션입니다.

토픽의 주요 특징#

  • 논리적인 데이터 분류 단위
  • 고유한 이름을 가짐
  • 하나 이상의 파티션으로 구성
  • 프로듀서가 메시지를 전송하는 대상
  • 컨슈머가 메시지를 읽는 대상
  • 메시지의 보존 정책을 설정할 수 있음
  • 파티션 수를 기반으로 병렬 처리 규모를 결정할 수 있음

따라서 토픽은 단순한 데이터 저장 공간이라기보다 하나의 데이터 스트림을 정의하는 논리적 단위라고 이해하는 것이 좋습니다.

1.3 왜 토픽을 여러 개로 나눌까요?#

Kafka에서는 하나의 클러스터에 수많은 토픽을 생성할 수 있습니다.

예를 들어 전자상거래 시스템이라면 다음과 같이 설계할 수 있습니다.

orders
payments
shipments
users
product-events
notifications

이렇게 데이터를 분리하면 각 데이터 스트림을 독립적으로 관리할 수 있습니다.

데이터의 성격을 분리할 수 있습니다#

주문 이벤트와 결제 이벤트는 서로 다른 비즈니스 의미를 가지고 있습니다.

따라서 하나의 토픽에 모두 넣기보다는 각각의 토픽으로 분리하는 것이 관리하기 편합니다.

orders
  → 주문 서비스

payments
  → 결제 서비스

shipments
  → 배송 서비스

서로 다른 컨슈머가 데이터를 사용할 수 있습니다#

하나의 이벤트를 여러 시스템이 필요로 하는 경우 Kafka의 장점이 더욱 잘 드러납니다.

                 ┌── 주문 서비스
                 │
orders ──────────┼── 통계 서비스
                 │
                 ├── 추천 시스템
                 │
                 └── 데이터 파이프라인

각 시스템은 서로 다른 컨슈머 그룹으로 같은 토픽을 독립적으로 소비할 수 있습니다.

데이터 보존 정책도 목적에 맞게 설정할 수 있습니다#

예를 들어 로그 데이터는 며칠만 보관하고, 주문 이벤트는 장기간 보관해야 할 수 있습니다.

따라서 토픽별로 서로 다른 보존 정책을 적용할 수 있습니다.

1.4 파티션이란 무엇일까요?#

파티션은 Kafka에서 메시지를 실제로 분할하여 저장하고 처리하는 기본 단위입니다.

하나의 토픽은 여러 개의 파티션으로 구성될 수 있습니다.

orders

Partition 0
├── Message 0
├── Message 1
├── Message 2
└── Message 3

Partition 1
├── Message 0
├── Message 1
└── Message 2

Partition 2
├── Message 0
├── Message 1
├── Message 2
└── Message 3

Kafka는 각 파티션을 append-only log 형태로 관리합니다.

새로운 메시지는 일반적으로 파티션의 뒤쪽에 추가됩니다.

각 메시지는 파티션 내부에서 offset이라는 순번을 가집니다.

Partition 0

offset
  0 → 주문 A
  1 → 주문 B
  2 → 주문 C
  3 → 주문 D

이 offset은 Kafka 컨슈머가 어디까지 데이터를 읽었는지 관리하는 데 핵심적인 역할을 합니다.

1.5 Kafka에서 메시지의 순서는 어디까지 보장될까요?#

Kafka를 사용할 때 반드시 기억해야 하는 중요한 원칙이 있습니다.

메시지 순서는 토픽 전체가 아니라 파티션 내부에서 보장됩니다.

예를 들어 다음과 같은 메시지가 있다고 하겠습니다.

Partition 0
A → B → C → D

이 파티션에서는 A, B, C, D의 순서를 유지할 수 있습니다.

하지만 다음처럼 여러 파티션에 메시지가 분산되면 이야기가 달라집니다.

Partition 0
A → C → E

Partition 1
B → D → F

Kafka는 Partition 0과 Partition 1 사이의 전체 메시지 순서를 보장하지 않습니다.

따라서 특정 데이터의 순서가 중요하다면 동일한 키를 사용하여 같은 파티션으로 보내는 설계가 중요합니다.

예를 들어 사용자 ID를 키로 사용하면 다음과 같이 구성할 수 있습니다.

user-100
  → 주문
  → 결제
  → 배송

같은 key
     ↓
같은 partition
     ↓
순서 유지

1.6 파티션이 Kafka의 성능을 높이는 이유#

파티션의 가장 중요한 역할 중 하나는 병렬 처리입니다.

파티션이 하나뿐이라면 데이터를 처리하는 데 한계가 있습니다.

orders
└── Partition 0
       │
       ▼
   Consumer 1

파티션을 여러 개로 나누면 여러 컨슈머가 동시에 처리할 수 있습니다.

orders
├── Partition 0 ──→ Consumer 1
├── Partition 1 ──→ Consumer 2
├── Partition 2 ──→ Consumer 3
└── Partition 3 ──→ Consumer 4

이 구조 때문에 파티션은 Kafka의 수평 확장성과 병렬 처리 능력을 결정하는 중요한 요소가 됩니다.

다만 파티션을 많이 만든다고 해서 성능이 무한히 증가하는 것은 아닙니다.

파티션이 증가하면 다음과 같은 관리 비용도 증가합니다.

  • 브로커가 관리해야 하는 로그 파일 증가
  • 파일 디스크립터와 메모리 사용 증가
  • 복제본 관리 비용 증가
  • 리밸런싱 비용 증가
  • 컨슈머 관리 복잡성 증가
  • 장애 복구 시 처리해야 할 로그 증가

따라서 파티션 수는 필요한 처리량과 운영 환경을 기준으로 결정해야 합니다.

1.7 파티션과 컨슈머 그룹의 관계#

Kafka에서 파티션의 의미를 제대로 이해하려면 컨슈머 그룹을 함께 이해해야 합니다.

하나의 컨슈머 그룹에서는 일반적으로 하나의 파티션을 동시에 하나의 컨슈머만 소비하도록 할당합니다.

예를 들어 파티션이 4개이고 컨슈머가 4개라면 다음과 같이 처리할 수 있습니다.

Partition 0 ──→ Consumer 1
Partition 1 ──→ Consumer 2
Partition 2 ──→ Consumer 3
Partition 3 ──→ Consumer 4

하지만 컨슈머가 6개라고 해서 6개 모두 동시에 데이터를 처리할 수 있는 것은 아닙니다.

Partition 0 ──→ Consumer 1
Partition 1 ──→ Consumer 2
Partition 2 ──→ Consumer 3
Partition 3 ──→ Consumer 4

Consumer 5 → 대기
Consumer 6 → 대기

즉, 하나의 컨슈머 그룹에서는 동시에 작업할 수 있는 기본적인 병렬성의 상한이 파티션 수에 의해 결정됩니다.

이 때문에 파티션 수를 결정할 때 컨슈머의 예상 병렬 처리 규모도 함께 고려해야 합니다.

1.8 파티션 키는 어떻게 메시지를 분배할까요?#

프로듀서가 메시지를 Kafka에 보낼 때 메시지에는 key를 지정할 수 있습니다.

예를 들어 다음과 같은 메시지를 보낼 수 있습니다.

key = user-100
value = 주문 생성
key = user-200
value = 주문 생성

Kafka 프로듀서는 파티셔너를 이용하여 메시지를 어느 파티션으로 보낼지 결정합니다.

키가 있는 경우 일반적으로 동일한 키의 메시지가 동일한 파티션으로 매핑되도록 동작합니다.

user-100
  ├── 주문
  ├── 결제
  └── 배송
       ↓
Partition 1

이러한 특성은 사용자별 이벤트 순서를 유지해야 하는 시스템에서 매우 중요합니다.

키를 사용하는 대표적인 사례#

사용자 ID
상품 ID
주문 ID
계좌 ID
기기 ID
테넌트 ID

예를 들어 결제 시스템에서 주문 ID를 키로 사용하면 하나의 주문과 관련된 이벤트를 동일한 파티션에 배치하는 설계를 할 수 있습니다.

단, 키를 사용한다고 해서 전체 데이터의 순서가 보장되는 것은 아닙니다.

보장되는 범위는 기본적으로 같은 파티션 내부입니다.

1.9 키가 없는 메시지는 어떻게 될까요?#

메시지에 키가 없다고 해서 단순히 항상 고정된 방식으로 라운드 로빈된다고 생각하면 안 됩니다.

Kafka 프로듀서의 파티셔너 구현과 설정에 따라 동작이 달라질 수 있으며, 최신 Kafka 프로듀서에서는 키가 없는 레코드에 대해 sticky partitioning 방식이 사용되어 동일한 파티션에 일정량의 메시지를 묶어 보내는 동작이 활용됩니다.

이러한 방식은 지나치게 작은 요청이 여러 파티션으로 분산되는 것을 줄이고 배치 효율을 높이는 데 도움이 됩니다.

따라서 실무에서는 다음과 같이 이해하는 것이 정확합니다.

Key 있음
   ↓
파티셔너가 key를 기준으로 파티션 결정

Key 없음
   ↓
프로듀서 파티셔너의 정책에 따라 결정
   ↓
최신 Kafka에서는 sticky partitioning 활용 가능

1.10 파티션 수를 늘리면 성능이 얼마나 좋아질까요?#

파티션을 1개에서 3개로 늘린다고 해서 처리량이 정확히 3배가 되는 것은 아닙니다.

성능은 다음과 같은 요소의 영향을 함께 받습니다.

  • 프로듀서 처리량
  • 컨슈머 처리량
  • 메시지 크기
  • 네트워크 대역폭
  • 디스크 성능
  • CPU
  • 브로커 수
  • 복제 계수
  • 배치 크기
  • 압축 방식
  • 컨슈머 애플리케이션의 처리 속도

따라서 파티션 증가는 병렬 처리의 가능성을 높이는 방법이지, 성능을 자동으로 몇 배 향상시키는 버튼이 아닙니다.

간단한 실습#

먼저 파티션 하나를 가진 토픽을 생성합니다.

kafka-topics.sh \
  --create \
  --topic orders-single \
  --partitions 1 \
  --replication-factor 1 \
  --bootstrap-server localhost:9092

파티션 개수를 확인합니다.

kafka-topics.sh \
  --describe \
  --topic orders-single \
  --bootstrap-server localhost:9092

이후 파티션 수를 늘려볼 수 있습니다.

kafka-topics.sh \
  --alter \
  --topic orders-single \
  --partitions 3 \
  --bootstrap-server localhost:9092

그리고 컨슈머 그룹을 여러 개의 컨슈머로 실행하여 파티션이 어떻게 분배되는지 확인합니다.

핵심은 단순히 속도를 비교하는 것이 아니라 파티션 증가 → 컨슈머 병렬성 증가 → 처리량 변화라는 관계를 직접 확인하는 것입니다.

1.11 파티션 수는 줄일 수 있을까요?#

Kafka에서 토픽의 파티션 수를 증가시키는 것은 가능하지만, 일반적으로 기존 파티션 수를 줄이는 것은 지원되지 않습니다.

따라서 파티션 수를 처음부터 지나치게 많이 설정하면 나중에 운영 부담이 될 수 있습니다.

예를 들어 처음부터 다음과 같이 1,000개의 파티션을 만드는 것보다,

orders
├── P0
├── P1
├── ...
└── P999

예상 처리량과 컨슈머 병렬성을 기준으로 적절한 초기값을 정하고 실제 부하를 측정하는 접근이 더 안전합니다.

또한 파티션을 나중에 증가시키면 키 기반 파티셔닝의 분배 결과가 달라질 수 있다는 점도 주의해야 합니다.

따라서 파티션 수 변경은 단순한 성능 튜닝이 아니라 데이터 분배와 운영에 영향을 줄 수 있는 변경입니다.

1.12 Kafka의 데이터 보존 정책#

Kafka는 메시지를 소비했다고 즉시 삭제하는 시스템이 아닙니다.

Kafka는 설정된 보존 정책에 따라 메시지를 일정 기간 또는 일정 크기까지 디스크에 유지합니다.

대표적인 설정은 다음과 같습니다.

retention.ms
retention.bytes

시간 기반 보존#

retention.ms는 메시지를 얼마나 오래 보존할지 결정하는 기준입니다.

예를 들어 다음과 같이 설정할 수 있습니다.

retention.ms = 604800000

이는 7일에 해당합니다.

메시지 생성
    ↓
1일
    ↓
3일
    ↓
7일
    ↓
보존 정책에 따라 삭제 대상

Kafka의 로그 세그먼트가 정리되는 과정에서 보존 조건을 만족한 데이터가 삭제됩니다.

크기 기반 보존#

retention.bytes는 파티션별 로그가 사용할 수 있는 최대 크기를 기준으로 보존하는 설정입니다.

따라서 retention.bytes를 이해할 때는 토픽 전체 크기 하나를 단순히 제한하는 설정이라고 생각하면 안 됩니다.

파티션 수가 많아지면 전체 디스크 사용량 역시 달라질 수 있습니다.

1.13 메시지는 왜 삭제하지 않고 보관할까요?#

Kafka의 중요한 특징 중 하나는 이벤트를 다시 읽을 수 있다는 것입니다.

예를 들어 주문 이벤트가 다음과 같이 저장되어 있다고 생각해 보겠습니다.

offset 0 → 주문 A
offset 1 → 주문 B
offset 2 → 주문 C
offset 3 → 주문 D

컨슈머가 데이터를 읽었다고 해서 Kafka에서 해당 메시지가 바로 사라지는 것은 아닙니다.

새로운 컨슈머 그룹은 보존 기간 안에 있는 데이터를 다시 읽을 수 있습니다.

orders
   │
   ├── 주문 서비스
   ├── 통계 서비스
   ├── 데이터 분석
   └── 신규 서비스

이러한 구조 때문에 Kafka는 단순한 메시지 큐를 넘어 이벤트 스트리밍 플랫폼으로 활용됩니다.

1.14 토픽의 이름은 어떻게 정해야 할까요?#

토픽 이름은 시간이 지날수록 시스템 전체에서 중요한 식별자가 됩니다.

따라서 처음부터 일정한 규칙을 정하는 것이 좋습니다.

예를 들어 다음과 같은 형태를 사용할 수 있습니다.

orders
payments
user-events
product-events
inventory-events

조직에 따라 환경이나 도메인을 이름에 포함할 수도 있습니다.

prod.orders
prod.payments
dev.orders
dev.payments

다만 토픽 이름에 환경 정보를 포함할지 여부는 운영 환경과 클러스터 분리 정책에 따라 결정해야 합니다.

토픽 이름을 설계할 때 고려할 것#

  • 이름만 보고 데이터의 목적을 이해할 수 있는가?
  • 환경을 구분해야 하는가?
  • 도메인을 구분해야 하는가?
  • 이벤트인지 명령인지 구분할 필요가 있는가?
  • 장기적으로 이름을 변경하지 않아도 되는가?

좋은 이름은 기술적인 의미뿐 아니라 조직의 데이터 구조를 설명하는 역할도 합니다.

1.15 파티션 수를 결정하는 실무 기준#

파티션 수를 정할 때 특정 숫자를 무조건 적용하는 것보다 예상되는 시스템 요구사항을 계산하는 것이 중요합니다.

처리량#

예상되는 메시지 처리량을 확인합니다.

초당 입력 메시지
+
초당 소비 메시지
+
메시지 크기

컨슈머 병렬성#

컨슈머를 몇 개까지 병렬로 실행할 것인지 고려합니다.

예상 Consumer = 6개
↓
Partition도 충분한 병렬성을 제공해야 함

브로커 규모#

파티션과 복제본이 여러 브로커에 분산되므로 브로커의 CPU, 메모리, 네트워크, 디스크 성능도 함께 고려해야 합니다.

메시지 크기와 저장량#

하루에 얼마나 많은 데이터가 발생하는지 계산해야 합니다.

예를 들어 하루 100GB의 데이터가 발생하고 7일 동안 보관한다면 원본 데이터만 단순 계산해도 약 700GB입니다.

여기에 복제 계수와 운영 여유 공간까지 고려해야 합니다.

1.16 복제와 파티션은 함께 생각해야 합니다#

Kafka 운영에서 파티션만 보고 설계하면 부족합니다.

실제 운영 환경에서는 replication factor도 함께 고려해야 합니다.

예를 들어 다음과 같이 구성할 수 있습니다.

Topic: orders
Partitions: 3
Replication Factor: 3

개념적으로는 다음과 같이 여러 브로커에 복제본을 배치할 수 있습니다.

Broker 1
├── P0 Replica
└── P1 Replica

Broker 2
├── P1 Replica
└── P2 Replica

Broker 3
├── P2 Replica
└── P0 Replica

이렇게 하면 특정 브로커에 장애가 발생하더라도 다른 브로커에 복제본이 존재할 수 있습니다.

따라서 실제 Kafka 설계에서는 다음 세 가지를 함께 봐야 합니다.

Partition
    +
Replication
    +
Broker

이 세 요소가 Kafka의 확장성과 장애 대응 구조를 결정합니다.

1.17 실습: 토픽과 파티션 직접 확인하기#

토픽 생성#

kafka-topics.sh \
  --create \
  --topic orders \
  --partitions 3 \
  --replication-factor 1 \
  --bootstrap-server localhost:9092

토픽 목록 확인#

kafka-topics.sh \
  --list \
  --bootstrap-server localhost:9092

토픽 상세 정보 확인#

kafka-topics.sh \
  --describe \
  --topic orders \
  --bootstrap-server localhost:9092

실행 결과에서는 파티션 번호, 리더 브로커, 복제본 등의 정보를 확인할 수 있습니다.

테스트 메시지 전송#

kafka-console-producer.sh \
  --topic orders \
  --bootstrap-server localhost:9092

메시지를 입력합니다.

order-001
order-002
order-003
order-004

메시지 소비#

kafka-console-consumer.sh \
  --topic orders \
  --from-beginning \
  --bootstrap-server localhost:9092

이 실습의 목적은 단순히 명령어를 실행하는 것이 아닙니다.

다음 구조를 직접 확인하는 것이 핵심입니다.

Producer
   ↓
Topic
   ↓
Partition
   ↓
Consumer
   ↓
Offset

1.18 실습: 파티션 수에 따른 컨슈머 병렬 처리 확인#

3개의 파티션을 가진 토픽을 만들었다면 컨슈머 그룹에 여러 컨슈머를 연결해 볼 수 있습니다.

orders
├── Partition 0 ──→ Consumer 1
├── Partition 1 ──→ Consumer 2
└── Partition 2 ──→ Consumer 3

컨슈머를 하나 더 추가해도 파티션이 3개라면 4번째 컨슈머가 독립적인 파티션을 하나 더 배정받을 수는 없습니다.

이 실습을 통해 다음 관계를 확인할 수 있습니다.

Partition 수
      ↓
컨슈머 그룹의 병렬성
      ↓
처리량

단, 실제 처리량은 컨슈머 애플리케이션과 브로커의 하드웨어, 네트워크, 메시지 크기 등에 따라 달라집니다.

1.19 실무에서 흔히 발생하는 파티션 설계 실수#

파티션을 무조건 많이 만드는 경우#

파티션이 많으면 무조건 빠를 것이라고 생각하는 것은 위험합니다.

파티션에는 관리 비용이 발생하기 때문입니다.

컨슈머 수만 늘리는 경우#

파티션이 3개인데 컨슈머를 10개 실행한다고 해서 10배의 병렬 처리가 이루어지는 것은 아닙니다.

Partition = 3
Consumer = 10

실제 동시에 처리 가능한 파티션
→ 최대 3개

키를 잘못 선택하는 경우#

특정 키에 데이터가 지나치게 몰리면 하나의 파티션에 부하가 집중될 수 있습니다.

Partition 0 → 90%
Partition 1 → 5%
Partition 2 → 5%

이러한 현상을 파티션 핫스팟으로 볼 수 있습니다.

따라서 키의 분포도 중요합니다.

순서 요구사항을 무시하는 경우#

전체 이벤트 순서가 필요하지 않은데 무조건 하나의 파티션으로 구성하면 병렬 처리 능력을 불필요하게 제한할 수 있습니다.

반대로 특정 엔터티의 순서가 반드시 필요한 시스템에서 키 설계를 잘못하면 이벤트 순서를 유지하기 어려워질 수 있습니다.

1.20 Kafka 토픽과 파티션 설계 체크리스트#

실무에서 새로운 토픽을 만들 때 다음 질문을 먼저 확인해 보세요.

토픽 설계#

  • 이 데이터는 어떤 도메인에 속하는가?
  • 어떤 서비스가 이 데이터를 소비하는가?
  • 다른 서비스에서도 재사용할 가능성이 있는가?
  • 얼마나 오래 보관해야 하는가?
  • 데이터 삭제 정책은 무엇인가?

파티션 설계#

  • 초당 몇 개의 메시지가 발생하는가?
  • 메시지 하나의 평균 크기는 얼마인가?
  • 컨슈머를 몇 개까지 병렬 실행할 것인가?
  • 특정 키에 데이터가 몰릴 가능성이 있는가?
  • 메시지 순서가 중요한가?
  • 향후 처리량 증가를 어느 정도 예상하는가?

운영 설계#

  • replication factor는 얼마로 할 것인가?
  • 브로커는 몇 대인가?
  • 디스크 용량은 충분한가?
  • 장애 발생 시 복구 전략은 무엇인가?
  • 모니터링할 지표는 무엇인가?

1.21 핵심 정리#

Kafka에서 토픽은 데이터를 논리적으로 분류하는 단위이고, 파티션은 데이터를 분할하여 저장하고 병렬 처리하는 핵심 단위입니다.

전체 구조를 하나의 그림으로 정리하면 다음과 같습니다.

                 Kafka Cluster
                      │
        ┌─────────────┴─────────────┐
        │                           │
     orders                      payments
        │                           │
   ┌────┼────┐                  ┌───┴───┐
   │    │    │                  │       │
  P0   P1   P2                 P0      P1
   │    │    │
   └────┼────┘
        │
  Consumer Group
   ┌────┼────┐
   │    │    │
  C1   C2   C3

이번 장에서 기억해야 할 핵심은 다음과 같습니다.

  • 토픽은 데이터를 논리적으로 분류하는 단위입니다.
  • 파티션은 Kafka의 병렬 처리와 확장성을 결정하는 핵심 단위입니다.
  • 메시지 순서는 기본적으로 파티션 내부에서 보장됩니다.
  • 동일한 키를 사용하면 관련 메시지를 같은 파티션에 배치하는 설계를 할 수 있습니다.
  • 컨슈머 그룹의 병렬성은 파티션 수와 밀접한 관계가 있습니다.
  • 파티션을 많이 만든다고 처리량이 무조건 증가하는 것은 아닙니다.
  • retention 정책을 이용하면 데이터를 일정 기간 또는 크기 기준으로 보존할 수 있습니다.
  • 파티션 수, 복제 계수, 브로커 수는 함께 고려해야 합니다.
  • 실무에서는 처리량, 순서, 키 분포, 저장 공간, 컨슈머 병렬성을 함께 고려해야 합니다.

Kafka를 제대로 설계하려면 단순히 "토픽을 만들고 메시지를 넣는 것"을 넘어 어떤 데이터를 어떤 기준으로 분리하고, 어떻게 병렬 처리하며, 얼마나 오래 보관할 것인지를 결정해야 합니다.

다음 단계에서는 Kafka의 실제 데이터 흐름을 담당하는 프로듀서와 컨슈머를 살펴보면서 메시지가 Kafka에 들어오고 다시 애플리케이션으로 전달되는 전체 과정을 이해해 보겠습니다.

1.22 자체 점검 문제#

  1. 토픽과 파티션의 차이를 설명해 보세요.
  2. Kafka가 데이터를 파티션으로 분할하는 이유는 무엇인가요?
  3. Kafka에서 메시지 순서는 어느 범위까지 보장되나요?
  4. 파티션 키는 어떤 역할을 하나요?
  5. 동일한 키를 가진 메시지를 같은 파티션에 배치하는 것이 유용한 사례를 설명해 보세요.
  6. 파티션 수보다 컨슈머 수가 많을 때 어떤 현상이 발생하나요?
  7. 파티션 수를 무조건 많이 설정하면 안 되는 이유는 무엇인가요?
  8. retention.ms와 retention.bytes의 차이를 설명해 보세요.
  9. replication factor가 필요한 이유는 무엇인가요?
  10. 주문 시스템을 Kafka로 구축한다면 토픽과 파티션을 어떻게 설계할지 설명해 보세요.
  11. 사용자 ID를 파티션 키로 사용할 때 발생할 수 있는 장점과 문제점을 설명해 보세요.
  12. 파티션 수를 변경할 때 데이터 분배 측면에서 주의해야 할 점은 무엇인가요?

이 페이지의 목차