Kubernetes 환경에서의 Kafka: 디스크 I/O가 많은 데이터 서비스의 성능 교훈

(dev.to)

Kafka 클러스터를 EC2에서 E/EKS로 이전하는 과정에서 발생한 예상치 못한 디스크 I/O 증가와 지연 시간 문제를 다룹니다. 문제의 원인이 Kafka 설정이 아닌, cgroup v2 및 새로운 리눅스 커널의 메모리 회수(reclaim) 메커니즘 변화에 있음을 심층적으로 분석합니다.

이 글의 핵심 포인트

1EC2에서 EKS(Strimzi)로 Kafka 이전 시 예상치 못한 디스크 읽기 및 지연 시간 발생
2초기 가설인 '컨슈머 랙(Consumer Lag)'은 문제의 근본 원인이 아님이 확인됨
3문제의 핵심은 Kafka 설정이 아닌 OS 환경 변화(cgroup v1 → v2, Amazon Linux 2023)에 있음
4커널의 `vmscan` 이벤트(메모리 압박에 의한 강제 회수)가 디스크 I/O를 유발하는 핵심 지표로 식별됨
5인프라 추상화 수준이 높아질수록 애플리케이션 하위 스택의 메모리 관리 메커니즘에 대한 이해가 필수적임

이 글에 대한 공공지능 분석

왜 중요한가

클라우드 네이티브로의 전환(EC2 → EKS)은 운영 효율성을 높여주지만, 인프라 추상화 계층의 변화가 애플리케이션의 성능 프로파일을 완전히 바꿀 수 있음을 경고합니다. 특히 데이터 집약적인 서비스에서 '운영 편의성'과 '성능 예측 가능성' 사이의 트레이드오프를 이해하는 것은 매우 중요합니다.

배경과 맥락

Kafka는 자체 버퍼링 대신 OS의 페이지 캐시(Page Cache)를 적극 활용하는 구조입니다. 따라서 인프라 환경이 바뀌어 커널의 메모리 관리 방식(cgroup v2 등)이 변경되면, 애플리케이션 코드를 수정하지 않아도 디스크 I/O가 급증하고 서비스 지연이 발생할 수 있는 기술적 배경이 존재합니다.

업계 영향

Kubernetes 도입을 추진하는 많은 기업이 단순히 '관리형 서비스'라는 이유로 성능 저하를 간과할 위험이 있습니다. 이는 서비스 SLA(Service Level Agreement) 위반으로 이어질 수 있으며, 인프라 엔지니어들에게 단순한 모니터링을 넘어 커널 레벨의 관측성(Observability) 확보가 필수적임을 시사합니다.

한국 시장 시사점

대규모 트래픽을 처리하는 한국의 IT 유니콘 및 스타트업들은 클라우드 네이티브 전환 시 '인프라의 불변성'을 맹신해서는 안 됩니다. EKS와 같은 관리형 서비스 도입 시, 애플리케이션 메트릭뿐만 아니라 커널 및 컨테이너 런타임의 리소스 관리 메커니즘을 검증하는 심층적인 성능 테스트 프로세스를 구축해야 합니다.

이 글에 대한 큐레이터 의견

스타트업 창업자와 CTO 관점에서 이번 사례는 '기술적 부채의 전이'를 보여주는 전형적인 사례입니다. EC2에서의 운영 공수(Operational Toil)를 줄이기 위해 EKS를 선택했지만, 그 대가로 '커널 레벨의 복잡성'이라는 새로운 형태의 기술적 난제를 떠안게 된 것입니다. 이는 단순한 인프라 교체가 아니라, 시스템의 동작 원리 자체를 재검증해야 하는 고난도 작업임을 의미합니다.

실행 가능한 인사이트를 드리자면, 인프라 아키텍처를 변경할 때는 반드시 '데이터 경로(Data Path)'의 변화를 추적해야 합니다. 단순히 CPU나 메모리 사용량 같은 상위 레벨의 지표만 볼 것이 아니라, eBPF와 같은 도구를 활용해 시스템 콜이나 커널의 메모리 회수 동작을 관찰할 수 있는 역량을 팀 내에 보유해야 합니다. 인프라 추상화가 높아질수록, 보이지 않는 곳에서 발생하는 성능 저하를 찾아내는 'Deep Observability' 능력이 기업의 기술적 경쟁력이 될 것입니다.

원문 보기 →