들어가며
안녕하세요, 코인원 Platform Engineer 허민입니다. 인프라 플랫폼을 운영하면서 서버, 네트워크, Application의 상태를 모니터링 하는 것은 매우 중요한 일입니다. 의사가 아픈 사람에게 청진기나 엑스레이를 사용하여 증상을 파악하는 것처럼 엔지니어도 인프라 플랫폼의 상태를 파악하고, 나아가서는 추이 분석을 통해 장애를 대비하기 위한 모니터링 구성을 지속적으로 해야 합니다.
모니터링 시스템은 불과 몇 년 전만 해도 zabbix나 cacti 외에는 별다른 선택지가 없었습니다. 최근에는 new relic이나 datadog의 상용 솔루션은 물론이고 오픈소스 형태의 많은 프로젝트가 생겨났습니다.
코인원은 베어메탈이나 클라우드는 물론이고 컨테이너 환경(특히 kubernetes)을 도입하며 다양한 인프라 플랫폼을 아우를 수 있는 모니터링 시스템 구축을 필요로 했습니다. 이 일환으로 Prometheus와 Grafana의 조합으로 통합 모니터링 시스템 구축을 검토하게 되었습니다.
이번 글에서는 모니터링 시스템을 구축하면서 겪었던 다양한 경험과 실무에서의 적용까지 이야기해보려고 합니다.
왜 Prometheus인가?
코인원에서는 올해 초 코인원코어라는 차세대 거래 엔진 프로젝트를 진행하면서 기반 인프라 환경을 kubernetes로 구축하게 되었습니다. 그러면서 kubernetes의 리소스를 모니터링 하는 것과 기존의 시스템도 통합할 수 있는 솔루션을 필요로 했습니다.
리서치를 해보니 kubernetes 모니터링 솔루션은 선택지가 그렇게 많지는 않았는데, 그중에서 Prometheus가 사실상의 표준 모니터링 솔루션으로 자리 잡고 있었습니다.
kubernetes 리소스 모니터링 솔루션에 대한 자료는 kubernetes 공식 문서를 참고 했습니다.
Prometheus를 도입했을 때의 장점은 아래와 같습니다.
1) kubernetes 환경에서 간편하게 설치
저희는 kubernetes 안의 모든 어플리케이션을 helm을 이용해 관리하고 있었습니다. Prometheus 역시 helm을 이용해서 설치했습니다.
실제로 설치부터 helm chart를 이용해 간단히 설치를 했고, 각종 metric도 별다른 설정 없이 손쉽게 수집이 가능했습니다.
helm chart는 https://github.com/helm/charts/tree/master/stable/prometheus를 사용했습니다.
위의 helm chart를 이용해서 설치를 진행하면 alertmanager, kube-state-metrics, node-exporter, pushgateway, server에 대한 pod가 일괄로 생성됩니다.
helm chart에서 저희가 수정한 부분은 server에서 data가 저장되는 Persistent Volume의 사이즈와 data의 저장 주기를 늘려주는 것 뿐이었습니다.
2) 다양한 metric exporter의 제공
또한 Linux나 Windows 등의 OS metric 뿐만 아니라 각종 Third-party exporter를 제공하고 있어서, 향후에는 다양한 플랫폼을 모니터링 할 수 있는 솔루션으로도 발전시킬 수 있다고 판단이 되었습니다.
Third-party exporter에 대한 자세한 내용은 https://prometheus.io/docs/instrumenting/exporters/ 참고하시기 바랍니다.
3) 장기간의 데이터 유지와 추이 확인
그 밖의 장점으로는 metric의 수집을 server에서 pull 방식으로 수집하고 있어서 Agent node에 특별한 부하를 유발시키지 않는다는 점, 데이터 저장소가 시계열 데이터(time-series) 저장소로 구성이 되어 있어서 많은 양의 변경 내용을 빠르게 검색할 수 있다는 점을 들 수 있습니다.
더불어 grafana에서 prometheus의 db를 손쉽게 연결할 수 있어서 상황에 맞는 대시보드를 손쉽게 제작할 수 있습니다.
Prometheus 도입 이후 문제점은 없었나?
아래는 저희가 약 3개월 정도의 Prometheus를 운영한 내용입니다. AWS m5.2xlarge 인스턴스에 pod를 올렸고 특별히 리소스 제한은 주지 않았습니다.
가급적 필요한 정보만 선택하도록 대시보드를 만들기는 했지만, Prometheus가 리소스를 많이 사용하지 않았다는 것을 알 수 있습니다. 특히 metric을 가져오는 주기가 1분 단위이고, Pod의 수가 280개 정도인 상황에서도 데이터양은 크게 늘지 않았습니다.
다만, 위에서도 언급한 데이터 보관 주기를 처음에는 지정하지 않아서 기본값 15d로 운영이 되었고, 15일이 지난 metric 데이터는 자동으로 삭제가 되는 문제가 있었습니다.
또한 helm으로 설치를 하다 보니 재설치를 진행했을 때, persistent volume도 같이 삭제되어 metric 데이터를 모두 유실한 적도 있었습니다. 이를 방지하기 위해서 아래와 같이 Reclaim Policy를 Retain으로 변경하여, helm chart 삭제 후에도 persistent volume은 유지되게 하였습니다.
아직 3개월 정도의 시간밖에 운영을 하진 않았지만, Prometheus로 kubernetes 환경의 모니터링을 하기에는 큰 부족함은 없었습니다. 특히 grafana의 연동으로 누구든 시스템의 현황을 손쉽게 확인할 수 있었습니다.
또한, metric 데이터가 쌓이면서 서비스의 리소스 사용량과 임계치 설정으로 시스템 운영의 최적화 및 이상징후 탐지가 가능했습니다.
마무리하며
지금까지 코인원의 Prometheus 도입 배경과 실제 사용기에 관해 이야기를 해보았습니다. 확실히 container 서비스 환경과 kubernetes는 서비스의 도입을 쉽고 빠르게 해주는 장점이 있습니다.
다만, 이렇게 빠르게 도입되는 서비스에 대해서 안정적인 운영을 하기 위해서는 Prometheus와 같은 모니터링 솔루션은 반드시 구축되어야 하며, 이를 사용하는 방법도 조직 내에 지속해서 학습이 되어야 한다고 봅니다.
그럼 다음 편에서는 실제로 metric 데이터를 활용하는 방법에 대해 소개하도록 하겠습니다.
허민, Platform Engineer
가입하기
