백엔드 데이터 인프라 104편 — Kafka Hardware · OS (CPU·메모리·디스크·튜닝)

2026-05-17•백엔드 데이터 인프라

백엔드 데이터 인프라 104편. Kafka Hardware·OS 권장 — CPU·메모리·디스크 사양, OS tuning (file descriptor·vm.max_map_count·socket buffer), RAID vs JBOD, SSD vs HDD, JVM·flush policy, 클라우드 instance 가이드까지 풀어쓴 학습 노트. Part 5-5 마무리.

이 글은 백엔드 데이터 인프라 시리즈 130편 중 104편이에요. Part 5-5 Operations 의 마지막 글. 99~103편 으로 운영 도구·모니터링·multi-tenancy·multi-DC 를 잡았다면, 이번 104편은 물리 환경 — Hardware · OS tuning.

Hardware · OS가 어렵게 느껴지는 이유

이 영역은 개발자가 직접 만지는 일이 드물어요. SRE(서비스 운영 엔지니어)·DevOps(개발·운영 통합) 담당의 몫인데, 모르고 넘어가면 운영 사고로 돌아옵니다.

첫째, OS 기본값이 부적합해요. file descriptor(열린 파일 핸들 수)·vm.max_map_count(프로세스당 메모리 매핑 한계) 같은 기본값이 Kafka 규모에는 늘 부족합니다.

둘째, 클라우드 시대로 오면서 기준이 바뀌었어요. AWS EC2(가상 서버)·EBS(블록 스토리지)·MSK(Managed Kafka) 같은 환경에서는 RAID(디스크 다중화)·HDD vs SSD 같은 결정 방식도 달라집니다.

셋째, JVM(자바 가상 머신) 튜닝의 함정. heap 크기와 GC(가비지 컬렉션) 정책이 성능과 안정성을 가릅니다.

이 글에서 추천 사양 + OS 필수 tuning + JVM 가이드 까지.

1. Hardware 권장

CPU

8~16 core per broker (운영 환경)
I/O 가 bottleneck 인 경우가 많아 극단적 고성능 CPU 불필요
Compression·SSL/TLS 활성 시 CPU 사용 ↑

Memory

필요 메모리 ≈ write_throughput × 30초 (buffer)
+ JVM heap (보통 6~16GB)
+ OS pagecache (가능한 한 많이)

권장:

소규모 = 32GB (heap 6GB + cache 26GB)
중간 = 64GB (heap 12GB + cache 52GB)
대규모 = 128GB+ (heap 16GB + cache 100GB+)

여기서 시험 함정이 하나 있어요 — JVM heap 을 너무 크게 잡으면 OS pagecache(커널이 잡아두는 파일 캐시) 가 작아짐. Kafka 의 성능 핵심이 pagecache 라 heap ≤ 16GB 가 권장. 그 이상은 pagecache 양보.

Disk

SATA 7200rpm 다중 디스크 (가성비) 또는 NVMe SSD(PCIe 직결 고성능 SSD) (성능)
디스크 수가 많을수록 처리량 ↑
Sequential I/O(연속 영역 읽고 쓰기) 성능 결정적 (84편)

HDD vs SSD

	HDD	SSD
Sequential read/write	좋음	매우 좋음
Random I/O	매우 느림	빠름
비용	낮음	높음
수명	길음	쓰기 횟수 한계
Kafka 적합도	충분 (sequential 이라)	추가 latency 이득

Kafka 는 sequential 이라 HDD 로도 충분. SSD 는 p99 latency 결정적 환경.

Network

10 Gbps NIC(네트워크 인터페이스 카드) 이상 (운영 환경)
bandwidth 가 디스크 throughput 와 함께 bottleneck

2. OS — Linux 권장

Kafka 는 Unix 계열 에서 잘 작동. Linux 가 대부분.

Linux (CentOS·Ubuntu·Amazon Linux 등) — 표준
Solaris — 검증됨
Windows — 비권장 (몇 가지 이슈)

3. OS Tuning — 필수 3가지

(1) File Descriptor Limit

Kafka 는 log segment + connection 마다 file descriptor 사용. 기본 OS limit (보통 1024) = 즉시 부족.

확인

$ ulimit -n
1024

변경 (Linux)

/etc/security/limits.conf:

kafka soft nofile 100000
kafka hard nofile 100000

systemd 서비스라면:

# /etc/systemd/system/kafka.service.d/override.conf
[Service]
LimitNOFILE=100000

권장 = 최소 100,000. 큰 broker = 500,000+.

(2) vm.max_map_count — Memory Map 한계

Kafka 는 각 log segment 의 index 파일을 mmap(메모리 매핑 시스템 콜)으로 매핑해요. 한 segment 가 map area 2개를 차지합니다.

broker 의 partition 100개 × segment 평균 10개 = 1000 segment
× 2 map area = 2000 map area

기본 Linux vm.max_map_count=65535 = partition·segment 폭증 시 부족.

확인

$ cat /proc/sys/vm/max_map_count
65535

변경

# 임시
$ sudo sysctl -w vm.max_map_count=262144

# 영구 (/etc/sysctl.conf)
vm.max_map_count = 262144

권장 = 최소 262,144. 대규모 = 1,000,000.

여기서 정말 중요한 자리 — 이 limit 도달 시 broker 가 OutOfMemoryError(Map failed) 로 크래시. 미리 늘려두기.

(3) Socket Buffer

WAN·고대역폭 환경 (102편 datacenters 참고):

# 임시
$ sudo sysctl -w net.core.rmem_max=16777216
$ sudo sysctl -w net.core.wmem_max=16777216

# 영구
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216

Kafka 측 socket.send.buffer.bytes·socket.receive.buffer.bytes 와 함께.

4. Filesystem 선택

XFS — 권장

큰 파일 처리 최적화
Kafka workload 에 가장 좋음 (Confluent 권장)
대부분 Linux distro 지원

ext4 — 무난

대부분 환경 기본
Kafka 에도 충분
운영 부담 ↓

비권장

NFS(네트워크 파일 시스템) — 절대 X (분산 lock·일관성 이슈)
EBS gp2/gp3 = OK (AWS), EFS(AWS 공유 파일 스토리지) = X

5. RAID vs JBOD

RAID

디스크 장애 자동 복구
Rebuild 부하 큼 (사실상 broker 마비)
Write throughput 감소
Kafka 의 Replication 이 이미 redundancy 제공

JBOD (Just a Bunch of Disks)

log.dirs=/disk1/kafka,/disk2/kafka,/disk3/kafka

각 디스크가 독립 partition data
Kafka 가 partition 을 round-robin 배치
디스크 한 개 죽으면 그 partition 만 영향
Replication 으로 회복

Confluent·Linkedin 등 대부분 JBOD 권장. RAID 의 redundancy 가 Kafka replication 과 중복.

6. JVM Tuning

Heap 크기

export KAFKA_HEAP_OPTS="-Xms6g -Xmx6g"

권장:

소규모 = 4~6GB
중간 = 8~12GB
대규모 = 12~16GB

16GB 이상 비추 — pagecache 양보가 더 이득.

GC — G1GC 권장

export KAFKA_JVM_PERFORMANCE_OPTS="\
    -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 \
    -XX:InitiatingHeapOccupancyPercent=35 \
    -XX:+ExplicitGCInvokesConcurrent \
    -Djava.awt.headless=true \
    -XX:+UseStringDeduplication"

G1GC(저지연 가비지 컬렉터)가 Kafka workload 에 가장 적합. CMS(구형 동시 마크-스윕)는 deprecated.

GC Logging

export KAFKA_GC_LOG_OPTS="\
    -Xlog:gc*:file=/var/log/kafka/gc.log:time,tags:filecount=10,filesize=100M"

운영 환경 GC 로그 필수. GC pause 분석.

7. Application vs OS Flush

84편 persistence 에서 본 내용. Kafka 권장 = 기본값 (OS pagecache 의존).

# 기본값 그대로 (변경 X)
# log.flush.interval.messages=Long.MAX_VALUE
# log.flush.interval.ms=Long.MAX_VALUE

이유:

Replication 이 fsync(디스크 강제 동기화) 보다 강력한 보장
fsync 강제 = 성능 100~1000배 하강
OS pagecache + Kafka background flush = 충분

극도로 단단한 보장이 필요한 경우만 (예: 단일 broker + 디스크 손실 안 됨) 명시 fsync.

8. 클라우드 환경 권장

AWS

m5d / r5d / i3 instance (NVMe SSD 로컬)
EBS 사용 시 = gp3 또는 io2
운영 환경 = 3 AZ(가용 영역) 분산 + rack-aware
가장 간편 = AWS MSK (Managed)

GCP

n2-highmem-8 / 16 + Local SSD
또는 Confluent Cloud (Managed)

Azure

Dsv3·Esv3 series + Premium SSD
또는 Azure Event Hubs (Kafka API 지원)

대부분의 신규 도입 = Managed Kafka 권장. 운영 부담 극도로 감소.

9. Sizing — 시작 사양

소규모 (TPS(초당 트랜잭션) < 10K)

3 broker
8 vCPU, 32 GB RAM each
1 TB SSD each
10 Gbps network

중간 (TPS 10K~100K)

5~10 broker
16 vCPU, 64 GB RAM each
2~4 TB SSD each
10~25 Gbps network

대규모 (TPS 100K~1M+)

10~50+ broker
32+ vCPU, 128+ GB RAM each
NVMe SSD multiple
25~100 Gbps network

10. Capacity Planning

기본 공식:

storage ≈ peak_messages_per_sec × avg_message_size × retention_seconds × replication_factor
       × 1.2 (overhead for index, etc.)

memory (pagecache) ≈ peak_write_throughput × 30 seconds
network ≈ peak_throughput × replication_factor × 1.5

예제 — TPS 10K, message 1KB, retention 7일, RF(복제 계수) 3:

storage ≈ 10000 × 1KB × 604800 × 3 × 1.2 ≈ 22 TB
       broker 5대로 = 4.4 TB per broker
memory ≈ 10000 × 1KB × 30s ≈ 300MB pagecache (per cluster)
       broker 5대로 = ~60MB each
network ≈ 10MB/s × 3 × 1.5 ≈ 45 MB/s
       broker 5대로 = 9 MB/s each = 충분히 1 Gbps

한계·실무 함정

1. File descriptor 부족

운영 시작 후 수일 안에 OOM. 반드시 100K+ 설정.

2. vm.max_map_count 부족

대량 partition·segment 환경에서 broker crash. 미리 늘림.

3. JVM heap 너무 큼

pagecache 양보 → 성능 하강. 16GB 이하 권장.

4. RAID rebuild 부하

운영 중 디스크 교체 시 broker 사실상 마비. JBOD 권장.

5. NFS 사용

분산 lock·일관성 이슈로 데이터 손상 위험. 절대 X.

6. Cloud 인스턴스 burstable

t-series (AWS) 같은 burstable CPU = 지속 부하 환경 부적합. m·r·c 계열 등 fixed performance.

Part 5-5 Operations 마무리

6편 (99~104) 으로 Kafka 운영의 모든 영역 정리:

99 Basic — Topic·Partition·Reassignment·Rolling Restart
100 Monitoring — JMX 메트릭 30가지·Prometheus·Grafana
101 Multi-tenancy — Naming·Quota·ACL 분리
102 Multi-Datacenter — Local + Mirror vs Stretched
103 Geo-Replication — MirrorMaker 2 깊이
104 Hardware/OS — CPU·메모리·디스크·OS tuning

Kafka 운영자 = 이 6편 + 1~5편 설정 의 조합. 기본값 + 운영 함정 회피 가 대부분.

시험 직전 한 번 더 — Kafka Hardware/OS 함정 압축 노트

Hardware — 8~16 core CPU, 32~128GB RAM, NVMe SSD 또는 HDD JBOD, 10Gbps+ NIC
JVM heap 16GB 이하 — 이상은 pagecache 양보가 더 이득
OS = Linux (XFS 권장), Solaris 검증됨, Windows 비권장
File descriptor = 최소 100,000 (/etc/security/limits.conf)
vm.max_map_count = 최소 262,144 (기본 65535 부족)
부족 시 = OutOfMemoryError(Map failed) crash
Socket buffer = WAN 환경 net.core.rmem_max=16777216 등
Filesystem — XFS 권장, ext4 OK, NFS·EFS 절대 X
RAID vs JBOD — JBOD 권장, replication 이 redundancy 제공
JVM Heap = -Xms6g -Xmx6g (소규모) ~ -Xmx16g (최대)
G1GC 권장 (CMS deprecated)
GC pause 모니터링 = KAFKA_GC_LOG_OPTS
Flush Policy = 기본값 (OS pagecache 의존) 강력 권장
fsync 강제 = 성능 100~1000배 하강
클라우드 — AWS m5d/r5d/i3 + EBS gp3 / AWS MSK 권장
GCP = n2-highmem + Local SSD / Confluent Cloud
Azure = Dsv3 / Event Hubs
신규 도입 = Managed Kafka 권장
Sizing — 소규모 3 broker / 중간 5~10 / 대규모 10~50+
Capacity Planning — storage = TPS × size × retention × RF × 1.2
함정 — file descriptor 부족 = 수일 안에 OOM
함정 — vm.max_map_count 부족 = broker crash
함정 — JVM heap 너무 큼 = pagecache 양보
함정 — RAID rebuild = broker 마비
함정 — NFS = 데이터 손상
함정 — Burstable CPU instance = 지속 부하 부적합
Part 5-5 Operations 6편 종합 — basic·monitoring·multi-tenancy·datacenters·geo-replication·hardware

공식 문서: Kafka Hardware and OS 에서 자세한 권장 사항을 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

다음 글:

※ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.