Prometheus 모니터링 실무 적용기 1탄

코인원이 베어메탈과 클라우드, 쿠버네티스가 섞인 인프라를 하나로 모니터링하기 위해 Prometheus 와 Grafana 조합을 도입한 기록이다. 차세대 거래 엔진 프로젝트를 쿠버네티스로 구축하면서 기존 시스템까지 아우를 솔루션이 필요했고, 3개월 운영하며 겪은 데이터 보관 주기와 볼륨 삭제 사고도 함께 적는다.

핵심 포인트

도입 배경은 차세대 거래 엔진을 쿠버네티스로 구축하면서 쿠버네티스 리소스와 기존 시스템을 함께 볼 솔루션이 필요해진 것이다.
쿠버네티스 모니터링은 선택지가 많지 않았고 Prometheus 가 사실상 표준으로 자리 잡고 있었다.
helm chart 로 설치하면 alertmanager, kube-state-metrics, node-exporter, pushgateway, server pod 가 한 번에 생성된다. 손댄 것은 저장 볼륨 크기와 데이터 보관 주기뿐이었다.
metric 을 서버가 pull 방식으로 가져가 에이전트 노드에 부하를 주지 않고, 시계열 저장소라 많은 변경 내용을 빠르게 검색할 수 있다.
3개월 운영 결과 Pod 280개, 수집 주기 1분 환경에서 m5.2xlarge 인스턴스로 충분했고 데이터양도 크게 늘지 않았다.

상세 정리

몇 년 전만 해도 zabbix 나 cacti 외에 선택지가 없었지만 지금은 New Relic, Datadog 같은 상용과 오픈소스 프로젝트가 많아졌다는 배경을 먼저 짚는다.
코인원은 쿠버네티스 안의 모든 애플리케이션을 helm 으로 관리하고 있어 Prometheus 도 같은 방식으로 설치했다.
설치 후 별다른 설정 없이 각종 metric 이 수집됐다.
OS metric 외에 third-party exporter 가 다양해 앞으로 여러 플랫폼으로 확장할 수 있다고 봤다.
Grafana 에서 Prometheus 를 데이터소스로 바로 연결할 수 있어 상황에 맞는 대시보드를 쉽게 만들었다.
첫 번째 사고는 데이터 보관 주기를 지정하지 않아 기본값 15일로 운영된 것이다. 15일이 지난 metric 이 자동 삭제됐다.
두 번째 사고는 helm 으로 재설치할 때 persistent volume 까지 함께 삭제돼 metric 데이터를 전부 잃은 것이다.
대응으로 Reclaim Policy 를 Retain 으로 바꿔 helm chart 를 지워도 볼륨은 남도록 했다.
metric 이 쌓이면서 서비스별 리소스 사용량 파악과 임계치 설정, 이상징후 탐지가 가능해졌다.
저자는 컨테이너와 쿠버네티스가 서비스 도입을 빠르게 해주는 만큼 안정적 운영을 위한 모니터링 구축은 필수이며, 사용법이 조직에 계속 학습돼야 한다고 정리한다.