9장. Kafka 디스크 선택 가이드
Kafka는 데이터를 디스크에 저장하는 구조이기 때문에, 디스크의 성능과 구성은 Kafka 클러스터의 안정성과 성능에 큰 영향을 줍니다. 이 장에서는 Kafka 운영 시 디스크를 어떻게 선택하고 설계할지에 대한 가이드를 제공합니다.
9.1 디스크 성능 개념 이해
Kafka는 데이터를 파일 형태로 저장합니다. 이때 어떤 디스크를 쓰느냐에 따라 처리 속도와 안정성이 크게 달라집니다. 디스크 성능을 판단할 때 주로 아래 개념을 사용합니다.
| 용어 | 설명 |
|---|---|
| IOPS | 초당 몇 번 읽고 쓰기를 할 수 있는지 나타내는 수치입니다. 작은 메시지를 많이 처리할수록 중요합니다. |
| Throughput | 초당 얼마나 많은 데이터를 처리할 수 있는지를 나타냅니다. 큰 메시지를 빠르게 처리하려면 이 값이 중요합니다. |
| 블록 크기 | 한 번에 읽거나 쓰는 데이터의 최소 단위입니다. 일반적으로 4KB입니다. |
디스크 성능 계산 공식
IOPS = ceil((M × S) ÷ B)
Throughput = (M × S) ÷ 1024 ÷ 1024
- M: 초당 메시지 수
- S: 메시지 크기 (Bytes)
- B: 블록 크기 (Bytes)
예를 들어, 초당 5,000개의 메시지를 처리하고 메시지 크기가 1KB라면, 대략 5,000KB/s = 4.88MB/s의 Throughput이 필요합니다.
9.2 디스크 종류 및 성능 비교
Kafka를 EC2 환경에서 운영하는 경우, AWS의 EBS(Elastic Block Store) 볼륨 타입에 따라 디스크 성능이 달라집니다. 아래는 일반적인 EBS 디스크 성능 비교입니다.
| EBS 볼륨 타입 | IOPS(최대) | Throughput(최대) | 특징 |
|---|---|---|---|
| gp3 | 최대 16,000 | 최대 1,000MiB/s | 범용 SSD. 성능과 비용 균형이 좋음 |
| io2 | 최대 256,000 | 최대 4,000MiB/s | 고성능 SSD. 높은 IOPS가 필요한 워크로드에 적합 |
| st1 | 최대 500 | 최대 500MiB/s | 저렴한 HDD. 대용량 순차 작업에 적합 (보관용) |
| sc1 | 최대 250 | 최대 250MiB/s | 가장 저렴한 HDD. 접근이 거의 없는 장기 보관용 |
공식 성능 수치는 AWS 문서에서 확인 가능합니다: EBS 볼륨 성능 비교 표 (AWS)
9.3 Kafka 로그 저장 용량 계산법
Kafka는 수신한 메시지를 로그(segment 파일)로 저장하고, 설정에 따라 오래된 데이터를 삭제합니다. 다음 공식으로 필요한 디스크 용량을 계산할 수 있습니다.
계산 공식
총 저장 용량 = 하루 데이터량 × 보관일수 × replication.factor
브로커당 저장량 = 총 저장 용량 ÷ 브로커 수
운영 마진 포함 = 브로커당 저장량 × 1.2 ~ 1.3
예시
- 하루 트래픽: 1TB
- 보관일수: 7일
- replication.factor: 3
- 브로커 수: 3대
총 저장 용량 = 1TB × 7 × 3 = 21TB
브로커당 저장량 = 7TB
운영 마진 포함 = 약 9TB 추천
복제를 고려하면 디스크 사용량은 메시지 양보다 훨씬 많아질 수 있으므로 주의해야 합니다.
9.4 환경별 디스크 선택 기준
| Kafka 운영 환경 | 중요 요소 | 추천 디스크 |
|---|---|---|
| 메시지를 자주 보내는 경우 | IOPS | SATA SSD / NVMe SSD |
| 큰 메시지를 빠르게 처리해야 하는 경우 | Throughput | 고속 SSD / SAS SSD |
| 보관이 목적이고 조회는 거의 없는 경우 | 용량, 가격 | HDD |
| 실시간 처리 중심 | IOPS + Throughput | NVMe SSD |
9.5 설정과 함께 고려할 점
default.replication.factor가 클수록 같은 메시지가 여러 브로커에 저장되어 디스크 사용량이 증가합니다.log.retention.bytes를 설정하지 않으면 디스크가 가득 차도 데이터가 자동으로 삭제되지 않을 수 있습니다.log.segment.bytes값이 너무 작으면 파일이 수천 개 이상 생겨, 리눅스 시스템의 inode가 고갈될 수 있습니다. 일반적으로 1GB 이상으로 설정하는 것이 좋습니다.
9.6 Kafka 디스크 구성 주의사항
- 브로커 간 디스크 성능과 용량은 되도록 비슷하게 맞춰야 분산 처리에 문제가 없습니다.
- Kafka는 자체적으로 복제를 하기 때문에 RAID보다 JBOD 구성을 추천합니다.
- Kafka는 디스크 공간이 가득 차도 자동으로 데이터 삭제를 하지 않으므로, 모니터링 설정이 꼭 필요합니다.
- HDD는 순차 입출력은 괜찮지만, 랜덤 입출력에 약하므로 실시간 처리에는 부적합합니다.
9.7 JBOD와 디스크 전략
Kafka에서 JBOD(Just a Bunch of Disks)는 RAID 없이 각 디스크를 독립적으로 사용하는 방식입니다. log.dirs에 여러 디렉터리를 지정하면, Kafka는 파티션 데이터를 디스크마다 나눠 저장합니다.
📌 중복 저장이 아닌 분산 저장이므로, 디스크 하나가 고장 나면 그 디스크에 저장된 파티션만 영향을 받습니다. 복제(replication.factor ≥ 2)가 되어 있으면 다른 브로커의 복제본으로 복구됩니다.
💡 참고해 볼만한 실전 팁:
- 디스크 1개 IOPS가 낮아도 여러 개 구성하면 합산 IOPS 증가
- 500 IOPS × 10개 ≈ 5000 IOPS, 1000 IOPS × 5개도 동일 → 이론상 쓰기 성능은 비슷
- 하지만 디스크 개수가 많으면 병렬성 ↑, 장애 허용성 ↑, 운영 복잡도도 ↑
- 고성능 디스크는 관리가 쉽고 장애 확률 낮지만 가격이 비쌈
✅ 목적에 따라 ‘저렴한 디스크 여러 개(JBOD)’ vs ‘고성능 디스크 소수’ 전략을 선택합니다.
⚠️ 주의 사항
Kafka는 파티션 단위로 디스크를 분산하므로, 특정 토픽의 파티션 하나에 데이터가 몰릴 경우 해당 디스크 하나만 과도하게 부하될 수 있습니다.
즉, 전체 데이터가 디스크에 자동으로 균등 분산되는 것이 아니라, 파티션별 분산이라는 점을 고려해야 합니다.
→ 특정 파티션의 트래픽이 디스크 IOPS 한계를 초과하는 경우, 병목이 발생할 수 있습니다. 토픽 설계 시 파티션 수를 적절히 나누고, 파티션 부하 균형도 함께 고려해야 합니다.
9.8 파일 시스템
Kafka는 디스크에 데이터를 파일 형태로 저장하는 구조이지만, 특정 파일 시스템에 대한 하드 의존성은 없습니다.
운영 환경에서는 주로 다음 파일 시스템들이 사용됩니다:
| 파일 시스템 | 특징 |
|---|---|
| EXT4 | 리눅스 표준 파일 시스템으로 폭넓게 사용됩니다. 안정성이 높고 범용성이 뛰어납니다. |
| XFS | 대용량 데이터와 고속 쓰기 작업에 최적화된 파일 시스템으로, 대규모 저장소 환경에서 성능이 우수합니다. |
📊 파일 시스템 성능 비교
Kafka 클러스터에서 상당한 메시지 부하를 주어 다양한 파일 시스템 생성 및 마운트 옵션을 테스트한 결과,
Kafka의 주요 모니터링 지표인 Request Local Time(쓰기 작업 완료까지 걸리는 시간)에서 다음과 같은 결과가 관찰되었습니다:
- XFS는 로컬 시간이 훨씬 더 우수했습니다.
- XFS: 약 160ms
- EXT4(최적 구성 시): 약 250ms 이상
- XFS는 평균 대기 시간(Wait Time)도 더 짧았으며,
- 디스크 성능의 변동성(Variance)도 EXT4에 비해 훨씬 적었습니다.
이러한 결과로 Kafka와 같이 대량의 데이터를 지속적으로 처리하는 워크로드에서는 XFS가 더 안정적이고 일관된 성능을 제공하는 경향이 있음을 알 수 있습니다.
🔧 파일 시스템 마운트 설정: noatime 적용
Kafka는 파일의 atime(파일 마지막 읽은 시간) 정보를 사용하지 않습니다.
따라서 디스크를 마운트할 때 noatime 옵션을 설정하면 디스크에 불필요한 쓰기 작업을 줄여 성능을 더욱 최적화할 수 있습니다.