metrics-collection

네이버 TV (새 탭에서 열림)

네이버의 서비스 운영 환경에서 효율적인 지표 수집을 위해 Telegraf를 활용하여 커스텀 Exporter를 개발한 경험과 그 노하우를 공유합니다. 다양한 오픈소스 솔루션의 벤치마크 결과를 바탕으로 Telegraf의 유연성과 확장성을 검증하였으며, 이를 통해 기존 지표 수집 시스템의 한계를 극복하고 운영 효율을 개선한 구체적인 사례를 제시합니다. 최종적으로는 커스텀 지표 수집이 필요한 엔지니어들에게 실무적인 적용 가이드와 최적화 옵션을 제안합니다. **오픈소스 기반 Exporter 도입 배경과 벤치마크** * 서비스 규모가 확장됨에 따라 표준 지표만으로는 파악하기 어려운 비즈니스 로직 및 특정 인프라 상태를 모니터링해야 하는 필요성이 증가했습니다. * 기존의 파편화된 수집 방식을 개선하기 위해 여러 오픈소스 기반 Exporter들의 성능, 유지보수 편의성, 확장성을 비교 분석하는 벤치마크 테스트를 수행했습니다. * 다양한 환경에 유연하게 대응하면서도 시스템 리소스 점유율이 낮은 최적의 솔루션을 찾는 과정이 수반되었습니다. **Telegraf의 구조와 선정 이유** * Telegraf는 플러그인 기반 아키텍처를 가진 에이전트로, 데이터 수집(Input), 처리(Processor), 집계(Aggregator), 전송(Output)의 전 과정을 설정 파일만으로 손쉽게 구성할 수 있습니다. * Go 언어로 작성되어 별도의 런타임 없이 단일 바이너리로 실행 가능하며, 메모리 사용량이 적어 사이드카(Sidecar) 형태로 배포하기에 적합합니다. * 이미 풍부한 커뮤니티 플러그인을 보유하고 있어 새로운 커스텀 지표를 추가하거나 데이터 형식을 변환할 때 개발 공수를 획기적으로 줄일 수 있습니다. **Telegraf 적용 후 개선점** * 여러 대의 서버와 서비스에서 발생하는 지표 수집 방식을 Telegraf로 표준화하여 관리 포인트가 단일화되었습니다. * 필요에 따라 지표를 가공하거나 필터링하는 기능을 활용하여 모니터링 시스템(Prometheus, InfluxDB 등)으로 전달되는 데이터의 양을 최적화했습니다. * 커스텀 Exporter 개발 시 반복되는 통신 로직이나 버퍼링 로직을 직접 구현할 필요 없이 Telegraf의 기능을 활용함으로써 개발 생산성이 향상되었습니다. **성능 최적화를 위한 주요 설정 옵션** * `flush_interval`: 지표를 수집하여 목적지로 전송하는 주기를 조절함으로써 네트워크 트래픽과 실시간성 사이의 균형을 맞춥니다. * `metric_batch_size` 및 `metric_buffer_limit`: 한 번에 전송할 지표의 양과 일시적인 장애 시 보관할 버퍼 크기를 설정하여 데이터 유실을 방지합니다. * `precision`: 지표의 타임스탬프 정밀도를 설정하여 저장소 용량을 효율적으로 관리하고 쿼리 성능을 개선합니다. 오픈소스 기반의 모니터링 환경을 구축하려는 엔지니어에게 Telegraf는 매우 강력한 도구입니다. 단순히 지표를 수집하는 것을 넘어, 전처리와 집계 과정을 표준화하고 싶다면 Telegraf의 플러그인 아키텍처를 적극 활용해 보기를 권장합니다. 특히 대규모 인프라에서 커스텀 Exporter 개발 시 발생하는 중복 코드를 줄이고 운영 안정성을 확보하는 데 큰 도움이 될 것입니다.

쿠버네티스 상태 메트 (새 탭에서 열림)

Datadog은 대규모 Kubernetes 환경에서 오픈소스 도구인 kube-state-metrics(KSM)를 운영하며 겪은 확장성 문제를 해결하기 위해 오픈소스 커뮤니티에 직접 기여하여 성능을 대폭 개선했습니다. 기존 KSM은 수천 개의 노드와 수만 개의 포드가 있는 환경에서 지표 수집 시간이 수십 초에 달하고 데이터 용량이 비대해지는 성능 저하 문제를 안고 있었습니다. 이를 해결하기 위해 KSM v2 개발 과정에 참여하여 지표 생성 프로세스를 최적화함으로써 수집 속도를 15배 향상하고 대규모 클러스터에서도 고해상도 데이터를 안정적으로 확보할 수 있게 되었습니다. **KSM의 작동 원리와 기존의 한계** * KSM은 Kubernetes API 서버를 리스닝하며 객체의 상태 지표를 생성하는 서비스로, 인포머(Informer) 패턴을 사용해 클러스터 수준의 메타데이터를 OpenMetrics 형식으로 노출합니다. * Datadog 에이전트는 15초마다 `/metrics` 엔드포인트를 크롤링하여 데이터를 수집하며, 필요에 따라 `label_joins` 설정을 통해 메타데이터를 결합해 지표의 가독성을 높입니다. * 하지만 기존 구조에서는 쿼리 시점에 대량의 데이터가 한꺼번에 덤프되고, 지표 생성 과정에 개입할 수 있는 훅(hook)이 부족하여 성능 확장에 제약이 있었습니다. **대규모 환경에서의 확장성 병목 현상** * 리소스당 지표 생성량을 분석한 결과 노드는 약 9개, 포드는 약 40개의 지표를 생성하며, 수만 개의 포드가 있는 환경에서는 매 수집 주기마다 수백만 개의 지표를 처리해야 합니다. * 이로 인해 네트워크 호출 시간이 수십 초로 늘어나고 데이터 크기가 수십 메가바이트에 달하게 되어, 지표의 정밀도를 낮추거나 수집 주기를 강제로 늦춰야 하는 상황이 발생했습니다. * Datadog은 이를 해결하기 위해 포드, 노드, 기타 리소스별로 KSM 배포를 물리적으로 분리하는 전략을 사용했으나 이는 임시방편에 불과했습니다. **오픈소스 기여를 통한 성능 최적화** * Datadog 팀은 내부적인 수정을 넘어 KSM v2.0.0의 메인 커뮤니티와 협력하여 지표 생성 로직과 빌더(Builder) 구조를 근본적으로 개선했습니다. * 결과적으로 지표 수집 프로세스 소요 시간을 기존 대비 15배 단축하는 성과를 거두었으며, 이는 대규모 인프라 운영의 핵심적인 전환점이 되었습니다. * 이러한 경험은 오픈소스 커뮤니티에 기여하는 것이 개별 기업의 인프라 문제를 해결함과 동시에 기술적 생태계 전체의 성능을 끌어올리는 가장 효과적인 방법임을 시사합니다. **실용적인 결론 및 추천** 대규모 Kubernetes 클러스터를 운영 중이라면 KSM v2 이상의 버전을 채택하여 최적화된 지표 수집 성능을 확보하는 것이 필수적입니다. 또한 단일 KSM 배포에서 성능 저하가 발생할 경우, 본문에서 언급된 것처럼 리소스 유형별(Collectors)로 배포를 분리하여 부하를 분산하는 전략을 검토해 보시기 바랍니다.