Apache Kafka 동작 원리 – 대용량 메시지 처리 구조

[랜덤 I/O vs 순차 I/O 성능 비교]
HDD 랜덤 읽기:   ~100 IOPS      (느림)
HDD 순차 읽기:   ~200 MB/s      (빠름)
RAM 랜덤 접근:   ~100,000 IOPS  (매우 빠름)
RAM 순차 접근:   ~10,000 MB/s   (극한)

→ Kafka의 순차 디스크 I/O는 RAM 랜덤 접근보다 빠른 경우도 존재

┌─────────────────────────────────────────────────────────┐
│                    Kafka Cluster                        │
│                                                         │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐            │
│  │ Broker 1 │   │ Broker 2 │   │ Broker 3 │            │
│  │          │   │          │   │          │            │
│  │ Topic A  │   │ Topic A  │   │ Topic A  │            │
│  │  P0(L)   │   │  P1(L)   │   │  P2(L)   │ ← 리더     │
│  │  P1(F)   │   │  P2(F)   │   │  P0(F)   │ ← 팔로워   │
│  └──────────┘   └──────────┘   └──────────┘            │
│       ↑               ↑               ↑                │
│  ZooKeeper / KRaft (메타데이터 관리)                     │
└─────────────────────────────────────────────────────────┘
         ↑                              ↓
  [Producers]                    [Consumer Groups]
  APP1, APP2, APP3              Group A, Group B

[토픽과 파티션 구조]

Topic: order-events (파티션 3개)
┌─────────────────────────────────────────────┐
│ Partition 0: [msg0][msg1][msg4][msg7]...    │  → Broker 1
│ Partition 1: [msg2][msg5][msg8][msg11]...   │  → Broker 2
│ Partition 2: [msg3][msg6][msg9][msg12]...   │  → Broker 3
└─────────────────────────────────────────────┘
       ↑                              ↑
   오프셋 0부터 순차 증가        파티션 내 순서 보장
  (파티션 간 순서는 미보장)

// 파티션 키를 지정한 메시지 전송
// orderId를 키로 사용 → 같은 주문 이벤트는 항상 같은 파티션
kafkaTemplate.send("order-events", order.getId(), orderEvent);
// hash("ORD-001") % 3 = 1 → 항상 Partition 1로 전달

[Kafka 디스크 디렉터리 구조]

/kafka-logs/
└── order-events-0/          ← 토픽명-파티션번호
    ├── 00000000000000000000.log    ← 실제 메시지 데이터
    ├── 00000000000000000000.index  ← 오프셋 → 파일 위치 인덱스
    ├── 00000000000000000000.timeindex ← 타임스탬프 인덱스
    ├── 00000000000001048576.log    ← 두 번째 세그먼트 (1MB 이후)
    ├── 00000000000001048576.index
    └── leader-epoch-checkpoint

[메시지 레코드 구조]
┌──────────────────────────────────────────┐
│ Offset          : 8 bytes (오프셋 번호)   │
│ Message Size    : 4 bytes                │
│ CRC             : 4 bytes (무결성 체크)   │
│ Magic Byte      : 1 byte  (포맷 버전)     │
│ Attributes      : 1 byte  (압축 방식 등)  │
│ Timestamp       : 8 bytes                │
│ Key Length      : 4 bytes                │
│ Key             : N bytes                │
│ Value Length    : 4 bytes                │
│ Value           : N bytes (실제 메시지)   │
└──────────────────────────────────────────┘

[.index 파일 구조 (희소 인덱스)]
오프셋 0     → 파일 위치 0 byte
오프셋 100   → 파일 위치 4,823 byte
오프셋 200   → 파일 위치 9,611 byte
...
(매 메시지가 아닌 일정 간격으로만 기록 → 희소 인덱스)

# server.properties / 토픽 설정
# 시간 기반 보존: 7일 (기본값)
log.retention.hours=168

# 크기 기반 보존: 파티션당 최대 1GB
log.retention.bytes=1073741824

# 두 조건 중 먼저 만족하는 쪽 적용
# 오래된 세그먼트부터 순서대로 삭제

# 압축(Compaction) 정책: 같은 키의 최신 메시지만 유지
log.cleanup.policy=compact
# 예: 사용자 프로필 업데이트 → 최신 상태만 보존 (이벤트 소싱에 활용)

[일반 파일 전송 경로 (4-copy)]

① 디스크 → 커널 페이지 캐시      (DMA 복사)
② 커널 페이지 캐시 → 사용자 버퍼  (CPU 복사) ← 컨텍스트 전환 1
③ 사용자 버퍼 → 소켓 버퍼        (CPU 복사) ← 컨텍스트 전환 2
④ 소켓 버퍼 → NIC 버퍼           (DMA 복사)

총 CPU 복사: 2회 / 컨텍스트 스위칭: 2회
→ 대용량 처리 시 CPU 병목 발생

[Zero-Copy 전송 경로 (2-copy)]

① 디스크 → 커널 페이지 캐시      (DMA 복사)
② 커널 페이지 캐시 → NIC 버퍼    (DMA 복사) ← sendfile() 시스템 콜

총 CPU 복사: 0회 / 컨텍스트 스위칭: 최소화
→ CPU 사용량 대폭 절감, 처리량 2~4배 향상

// application.yml – 프로듀서 배치 설정
spring:
  kafka:
    producer:
      # 배치 최대 크기: 16KB (기본값, 높일수록 처리량 ↑ 지연 ↑)
      batch-size: 16384
      # 배치 대기 시간: 최대 10ms 기다렸다가 묶어서 전송
      # (0이면 즉시 전송, 지연 최소화 but 처리량 낮음)
      properties:
        linger.ms: 10
        # 프로듀서 메모리 버퍼 크기: 32MB
        buffer.memory: 33554432
        # 메시지 압축 방식: snappy (속도/압축률 균형)
        # none, gzip, snappy, lz4, zstd 선택 가능
        compression.type: snappy

[배치 + 압축 효과]

배치 없이 1,000개 메시지 전송:
  → 네트워크 요청 1,000회 × RTT = 높은 지연

배치로 1,000개 메시지 전송 (배치 크기 100):
  → 네트워크 요청 10회 × RTT = 지연 1/100

+ snappy 압축 적용:
  → 전송 데이터 크기 약 30~50% 감소
  → 네트워크 대역폭 절감 + 디스크 저장 공간 절감

[페이지 캐시 활용 흐름]

Producer 쓰기:
메시지 → 페이지 캐시 (즉시 반환) → 비동기 디스크 플러시

Consumer 읽기 (최신 메시지):
페이지 캐시 HIT → 디스크 접근 없이 메모리에서 직접 전달 ✅

Consumer 읽기 (오래된 메시지):
페이지 캐시 MISS → 디스크에서 로드 → 페이지 캐시 갱신

[복제 구조 – replication.factor=3]

Topic: order-events, Partition 0

Broker 1 (리더)  ← 프로듀서/컨슈머가 직접 통신
  [msg0][msg1][msg2][msg3]...

Broker 2 (팔로워)  ← 리더에서 복제
  [msg0][msg1][msg2][msg3]...

Broker 3 (팔로워)  ← 리더에서 복제
  [msg0][msg1][msg2][msg3]...

→ Broker 1 장애 발생 시:
  Broker 2 또는 3이 새 리더로 자동 선출
  → 서비스 중단 없이 처리 지속

[ISR과 acks 설정 비교]

acks=0: 브로커 응답 기다리지 않음
  → 처리량 최고 / 데이터 유실 위험 최고
  → 로그성 데이터 수집에 적합

acks=1: 리더만 저장 확인
  → 균형 (기본값)
  → 리더 장애 시 미복제 데이터 유실 가능

acks=all (또는 -1): ISR 전체 저장 확인
  → 처리량 낮음 / 데이터 유실 위험 없음
  → 금융·결제 등 중요 데이터에 필수

[ISR 이탈 기준]
replica.lag.time.max.ms=30000 (기본 30초)
→ 30초 동안 리더를 따라오지 못하면 ISR에서 제외
→ ISR에서 제외된 팔로워는 리더 선출 대상에서도 제외

[리더 선출 타임라인]

t=0s  : Broker 1(리더) 장애 감지
t=2s  : ZooKeeper/KRaft가 컨트롤러에 통보
t=3s  : 컨트롤러가 ISR에서 Broker 2를 새 리더로 선출
t=3s  : 메타데이터 업데이트 전파 (모든 브로커·클라이언트)
t=4s  : Broker 2가 새 리더로 읽기/쓰기 재개

→ 약 3~5초의 일시적 불가용 후 자동 복구 ✅

[ZooKeeper 의존 구조의 문제점]

운영 복잡성:
  → Kafka 클러스터 3대 + ZooKeeper 클러스터 3대 = 최소 6대 서버 필요
  → 두 시스템의 버전·설정을 각각 관리해야 함

확장성 한계:
  → ZooKeeper에 저장 가능한 메타데이터 크기 한계 존재
  → 파티션 수가 수십만 개를 넘으면 컨트롤러 재시작 시간이 수분~수십분

단일 장애점:
  → ZooKeeper 클러스터 장애 = Kafka 클러스터 전체 메타데이터 손실 위험

[KRaft 아키텍처]

KRaft 모드 클러스터 (3대로 구성)

┌──────────────────────────────────────────┐
│  Broker 1 (Controller + Broker 겸임)     │ ← Active Controller
│  Broker 2 (Controller + Broker 겸임)     │ ← Standby Controller
│  Broker 3 (Controller + Broker 겸임)     │ ← Standby Controller
└──────────────────────────────────────────┘
           ↑
  ZooKeeper 없이 Raft 프로토콜로
  내부 메타데이터 합의 처리

[KRaft의 개선 효과]
파티션 수 100만 개 시 컨트롤러 재시작:
  ZooKeeper 모드: 수십 분 소요
  KRaft 모드: 수 초 이내 완료 (약 10,000배 향상)

# server.properties (KRaft 모드)

# 노드 역할: broker + controller 겸임
process.roles=broker,controller

# 클러스터 고유 ID (kafka-storage.sh random-uuid 로 생성)
node.id=1

# 컨트롤러 쿼럼 구성 (node.id@host:port)
controller.quorum.voters=1@broker1:9093,2@broker2:9093,3@broker3:9093

# 리스너 설정
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
inter.broker.listener.name=PLAINTEXT
controller.listener.names=CONTROLLER

# 로그 디렉터리
log.dirs=/var/kafka/data

# KRaft 클러스터 초기화 (최초 1회만)
# 클러스터 고유 UUID 생성
KAFKA_CLUSTER_ID=$(kafka-storage.sh random-uuid)

# 각 브로커 스토리지 포맷
kafka-storage.sh format \
  --config /etc/kafka/server.properties \
  --cluster-id $KAFKA_CLUSTER_ID

# Kafka 브로커 시작 (ZooKeeper 없이 바로 실행)
kafka-server-start.sh /etc/kafka/server.properties