Fundamentals

이 도메인이 묻는 것

Fundamentals는 2장 아키텍처, 7장 스토리지·리텐션·컴팩션, 8장 스키마와 직렬화의 범위입니다. 개발자 관점의 "이 데이터가 어떻게 저장되고 언제 사라지는가"가 핵심입니다. 브로커를 직접 운영하는 절차(파티션 재할당, 롤링 업그레이드 등)는 CCAAK 쪽 비중이 크지만, CLI 워크플로의 순서는 CCDAK에서도 list order 유형으로 나올 수 있습니다.

핵심 개념 (1) 파티션과 복제

순서 보장의 단위는 파티션입니다

토픽은 여러 파티션으로 나뉘고, 각 파티션은 append-only 로그입니다. 오프셋은 파티션 안에서만 의미가 있고, 토픽 전역 오프셋은 존재하지 않습니다. 같은 키를 가진 레코드는 같은 파티션으로 가므로, 순서를 보장하려면 키를 지정해야 합니다.

파티션 수는 늘릴 수만 있고 줄일 수 없습니다. 그리고 늘리면 murmur2(key) % numPartitions의 분모가 바뀌므로 기존 키의 파티션 배치가 달라져 순서 보장이 깨집니다. 또한 파티션 수 증가는 그 토픽을 구독하는 컨슈머 그룹의 리밸런스를 유발합니다.

ISR과 내구성 계산

각 파티션에는 리더 하나와 팔로워가 있고, 리더를 충분히 따라잡은 레플리카의 집합을 ISR(In-Sync Replicas)이라고 합니다. 팔로워가 replica.lag.time.max.ms(브로커 기본 30000) 동안 리더를 따라잡지 못하면 ISR에서 빠집니다.

acks=all은 "모든 레플리카"가 아니라 "현재 ISR의 모든 멤버"의 응답을 기다립니다. 그래서 ISR이 1로 줄어든 상태에서는 acks=all도 사실상 acks=1이 됩니다. 이 구멍을 막는 것이 min.insync.replicas입니다.

오프셋 4종

인터랙티브 그림으로 네 지점이 어떻게 벌어지는지 보려면 1장 오프셋 절과 2장을 보세요. consumer lag = high watermark − committed offset이며, LEO에서 빼는 것이 아닙니다. 이 정의는 Observability 도메인에서도 다시 나옵니다.

핵심 개념 (2) 메시지 크기 — 5개 설정이 정합해야 합니다

이 도메인에서 가장 자주 나오는 matching 문항이 "설정 ↔ 소속"입니다. 메시지 크기 관련 설정은 다섯 개이고, 각각 다른 컴포넌트에 있습니다. 하나만 올리면 다른 곳에서 막힙니다.

핵심 개념 (3) 리텐션과 컴팩션

디스크 용량 산정

필요 디스크 = 일일 유입량 × 보관 일수 × 복제 계수 × (1 − 압축률) × 여유 계수

예) 200GB/일, 7일 보관, RF=3, 압축률 60%, 여유 30%
  = 200 × 7 × 3 × 0.4 × 1.3
  = 2184 GB  → 브로커 3대면 대당 약 730GB

계산 문항으로 나올 수 있습니다. 복제 계수를 곱하는 것을 잊지 않는 것이 핵심이고, 압축은 프로듀서가 압축한 배치를 브로커가 그대로 저장하므로 (토픽 compression.type=producer가 기본값) 디스크에서도 압축 효과가 유지됩니다.

핵심 개념 (4) 스키마 호환성과 배포 순서

Schema Registry는 Apache Kafka 본체가 아니라 Confluent 컴포넌트이지만 CCDAK 출제 범위입니다. 이 절의 두 표가 이 도메인 최고의 가성비 산출물입니다.

wire format과 subject 전략

[0x00]  [4바이트 schema id]  [Avro/Protobuf 페이로드]
  1B          4B                  나머지
  ↑           ↑
magic byte   빅엔디안 정수. 컨슈머는 이 id 로 레지스트리에서 스키마를 조회

• TopicNameStrategy (기본) — subject = {topic}-key / {topic}-value. 한 토픽에 한 종류의 레코드.
• RecordNameStrategy — subject = 레코드 풀네임. 한 토픽에 여러 종류의 레코드를 넣을 때. 같은 레코드 타입은 토픽이 달라도 스키마를 공유.
• TopicRecordNameStrategy — {topic}-{레코드 풀네임}. 위 둘의 절충.

핵심 개념 (5) 보안 프로토콜과 관리 CLI

security.protocol 4종

파티션 재할당 워크플로

# 1) 계획 생성 — 현재 배치와 제안 배치를 JSON 으로 출력한다
bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --topics-to-move-json-file topics.json \
  --broker-list "1,2,3" --generate

# 2) 실행 — 복제 대역폭을 제한해 프로덕션 영향을 줄인다
bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file plan.json --throttle 50000000 --execute

# 3) 확인 — 완료되면 스로틀이 해제된다. 반드시 verify 까지 해야 한다
bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file plan.json --verify

반드시 외워야 할 설정값

자주 나오는 함정

함정 1 — 리텐션 vs 컴팩션

함정 2 — high watermark vs LEO vs committed offset

함정 3 — TRANSITIVE vs 비-TRANSITIVE

함정 4 — retention.ms vs segment.ms

함정 5 — delete.retention.ms vs retention.ms

함정 6 — 크기 설정 3종의 소속

코드·설정 읽기 문제 대비

스니펫 1 — 이 토픽 설정의 문제

bin/kafka-topics.sh --create --topic user-profile-state \
  --bootstrap-server localhost:9092 \
  --partitions 6 --replication-factor 3 \
  --config retention.ms=86400000

스니펫 2 — 이 스키마 변경은 통과하는가

// v1
{ "type": "record", "name": "Order", "fields": [
    { "name": "orderId", "type": "string" },
    { "name": "amount",  "type": "long" } ]}

// v2 — couponCode 를 추가
{ "type": "record", "name": "Order", "fields": [
    { "name": "orderId",    "type": "string" },
    { "name": "amount",     "type": "long" },
    { "name": "couponCode", "type": "string" } ]}

스니펫 3 — 이 계산의 답

Topic: payments  Partition: 3
  Leader: 2   Replicas: 2,3,1   Isr: 2,3
  log-start-offset: 1200
  committed offset (group=billing): 8400
  high watermark: 9100
  LEO: 9350

이어서 볼 곳

• 2장 · 아키텍처와 핵심 개념 복제, ISR, 리더 선출, 오프셋 4종의 전체 설명. 기본개념
• 7장 · 스토리지·리텐션·컴팩션 세그먼트 물리 구조, 컴팩션 before/after, Tiered Storage. 기본개념
• 8장 · 스키마와 직렬화 호환성 매트릭스 전문, subject 전략, wire format. 기본개념
• 케이스 6 · RF=3인데 유실 min.insync.replicas를 1로 둔 결과. 실수 케이스
• 케이스 10 · 큰 메시지 무한 재시도 5개 설정 중 하나를 빼먹었을 때 무엇이 먼저 깨지는가. 실수 케이스
• 설정 치트시트 브로커·토픽 설정 전체 표와 프리셋 3종. 빠른참조

도메인 미니 퀴즈

공식 문서 출처

• Broker Configs — message.max.bytes, min.insync.replicas, replica.lag.time.max.ms, replica.fetch.max.bytes, offsets.retention.minutes, transaction.state.log.*
• Topic Configs — cleanup.policy, retention.ms, segment.bytes, segment.ms, delete.retention.ms, min.cleanable.dirty.ratio, max.message.bytes, compression.type, remote.storage.enable
• Replication — ISR, high watermark, unclean leader election
• Log Compaction — tombstone, 활성 세그먼트 제외, dirty ratio
• Expanding your cluster / Reassigning partitions — --generate / --execute / --verify
• Security — security.protocol 4종, 인증과 인가의 분리