Project
KIM 수치예보 모델 실시간 데이터 파이프라인 구축
2026.03 ~ 현재·설계 / 개발 / 운영·한국전자기술연구원 (KETI)
Overview
기상 수치예보 모델 전환(GRIB2 → NetCDF)에 따른 실시간 데이터 파이프라인을 처음부터 설계·구축하고, 핵심 성능 병목을 근본 원인 분석을 통해 해결한 프로젝트.
Key Metrics
처리 속도 개선
17x
메모리 사용률
98% → 34~50%
일 처리 데이터
392파일 / 51GB
격자 해상도 향상
3.84배
Tech Stack
Apache KafkaPyArrowHDFSDockerDocker ComposenetCDF4numpyKafka ConnectPrometheusGrafanaAnsible
Details
파이프라인 설계 및 구축
- etc(지표면) / prs(기압면) 독립 파이프라인 설계로 장애 영향 범위 50% 감소 — 한쪽 장애 시 다른 쪽 무영향
- 일일 392개 파일, 51GB, 약 3.5억 행 데이터를 실시간 수집 / 파싱 / 변환 / 적재
- 격자 해상도 3.84배 향상 (470,162 → 1,806,336 격자점)
- etc: HDFS Parquet 적재 (45 컬럼 × 1,806,336행/파일)
- prs: NAS gzip 백업 (파일당 149~232MB, 월간 ~750~900GB)
Kafka 토픽 및 Consumer 설계
- 3개 토픽 설계: kim-etc-to-hadoop (파티션 10), kim-prs-to-gz (파티션 1), kim-etc-to-gz (파티션 1)
- etc Consumer: Docker Compose --scale 옵션으로 수평 확장 (최대 10개 병렬 처리)
- prs / etc 백업: NAS I/O 병목을 고려한 단일 파티션 설계
- 이벤트 기반 백업 트리거: HDFS 적재 완료 → 백업 토픽 발행 → 비동기 백업 처리
성능 최적화 — PySpark → PyArrow 전환
- 원인 분석: createDataFrame의 176MB 단일 task가 JVM Old Gen 압박 → GC thrashing → CommitFailedError → rebalance 연쇄 장애
- Spark Cluster 전환 검토 후 기각: createDataFrame은 Driver 측 작업이므로 클러스터로도 해결 불가, 메시지 분할도 직렬화 총량 동일
- 기존 GB2 파이프라인과 동일 구조이나, 격자 크기 3.8배 차이(47만 → 180만)로 KIM에서만 임계점 초과
- 파일당 처리 시간: ~4분 → ~14초 (17x 개선)
- 컨테이너당 메모리: 4GB JVM → ~400MB (JVM 제거)
- 호스트 메모리 사용률: 98% → 34~50% (OOM 해소, 약 51GB 메모리 확보)
- CommitFailedError, HDFS lease 만료 0건
- Docker 빌드 단계: eccodes C 소스 컴파일(~10단계) → pip install netCDF4(2단계), 80% 감소
트러블슈팅
- PySpark JVM GC thrashing: 원인 분석 후 PyArrow 전환으로 근본 해결
- Kafka Consumer CommitFailedError: max_poll_interval_ms 3분 → 10분 조정 후 PyArrow 전환으로 항구 해소
- Kafka Broker Direct Buffer OOM: MaxDirectMemorySize 설정 추가
- Connector Producer 메시지 크기 제한: producer.max.request.size 설정 추가
- RAID 1 디스크 고장: 서버 디스크 교체, CentOS 7 → Ubuntu 22.04 OS 전환, 클러스터 복구
- Docker 네트워크 방화벽 차단: ufw Docker 대역(172.16.0.0/12) 허용 설정
모니터링 체계 구축
- 기존 Elasticsearch + Burrow + Telegraf + srvstatus → Prometheus + Grafana로 모니터링 스택 전환
- Elasticsearch 메모리 과다 사용 및 운영 부담 해소
- Kafka Exporter: 토픽별 메시지 처리량 및 Consumer lag 메트릭 수집 (기존 Burrow 대체)
- Node Exporter: CPU, 메모리, 디스크 I/O 모니터링 (기존 Telegraf 대체)
- Ansible playbook을 활용한 Exporter 에이전트 자동 배포 — Hadoop 14대 + Kafka 3대, 총 17대 일괄 관리