개발 중인 서비스의 모니터링을 위해, 모니터링 기능을 구현하게 됐다.
모니터링 기능을 제공하기 위한 데이터 수집 오픈소스를 찾다보니 아래 3가지 방안 중 선택을 하게 됐다.
시각화는 따로 구현할 예정이라, 시각화 도구는 고려 대상에서 제외됐다.
선택의 주요 고려 요소
- 모니터링 중앙 서버 구성 후, 추후 다른 서비스를 추가 수집할 때의 편의성
- 구성된 리소스 부족시 확장 방안
- 중앙서버의 네트워크 Throughput 부족
- 저장 공간 부족
- Cpu/Mem 부족
- HA 구성을 위한 개발/운영 편의성
모니터링 아키텍쳐 구현 방안
1번 방안 - Telegraf + InfluxDB + Kapacitor
- 수집: Telegraf
- 저장: InfluxDB
- 알람: Kapacitor
Telegraf가 수집 대상 서버에 설치되어 InfluxDB로 데이터가 전송/저장된다.
2번 방안 - Prometheus + AlertManager + Thanos
- 수집: Prometheus Exporter
- 저장: Prometheus 서버의 로컬 파일
- 알람: AlertManager (plugin)
- 이중화: Thanos
Prometheus Exporter가 Agent 역할을 수행하여 데이터를 수집하고, 중앙 저장소인 Prometheus로 데이터를 보내준다. Prometheus는 해당 데이터를 일정시간 메모리에서 보유하고 있다가 로컬 파일 형태로 저장한다.
3번 방안 - Prometheus + MetricBeat + Elasticsearch
- 수집: Prometheus
- 저장: MetricBeat + Elasticsearch
- 알람: ?
2번 방안이 Develop되어, 데이터 저장이 로컬 파일이 아닌 Elasticsearch로 저장되는 방식이다.
위 3가지 방안 중, 결과적으로 2번 방안을 선택하게 됐다.
각 방안별 제외 이유는 다음과 같다.
방안별 제외 이유
1번 - Telegraf + InfluxDB + Kapacitor
기능 개요
- push 기반 시스템. Application server가 직접 api를 호출하여 수집 서버에 데이터를 넣어줘야함,
- 각 서비스 서버의 데이터 수집 옵션을 수정, 배포해주어야함.
- metric value들을 모두 DB로 관리하여 오버헤드 존재하나 이벤트 로깅에 강점이 있음
- 이벤트 로깅에 강점이 있다는게 무슨말이지...?
- 확장이 쉬움
- 많은 노드에서 동시에 스토리지와 쿼리를 처리하는 분산 스토리지 클러스터 구조
- 처음 구성이 어렵고, 구성 후 수평적 확장은 쉬움.
제외 이유
- Agent 수집 방식 - Push
Telegraf는 수집 대상 서버의 에이전트가 중앙 서버로 수집 데이터를 보내주는 방식이다.
이 방식의 경우, 아래의 이슈들이 존재한다.
- 중앙서버에서 수집이 불가능할 때에도 계속 데이터를 보내주게 된다.
- Kafka를 통해 해결이 가능한 것으로 추정되나 근본적인 해결은 아니며, 아키텍쳐가 복잡해져 운영 난이도가 증가한다.
- 중앙 서버에서의 변경 발생시, 모든 Agent에서 설정 변경이 요구된다.
- 엔서블 등을 통해 자동화하여 관리해야하는데, 이 역시 운영 난이도/복잡성이 증가한다.
- 라이센스 문제
- InfluxDB Opensource 버전의 HA 구성 이슈
- HA를 위해 클러스터링 구조를 제공해주고 있으나, 클러스터링 기능은 Enterprise 버전에서부터 제공
- 오픈 소스 버전의 HA구성을 지원해주는 써드파트앱은 찾지 못함.
- InfluxDB 클러스터를 구성했다 하더라도, Alert를 해주는 Kapacitor가 클러스터 구조에서의 Alert 기능을 제공해주지 않음. (이거도 유료버전써야 해줌)
InfluxDB는 Cloud, Open Source, Enterprise 버전의 지원 범위
https://www.influxdata.com/products/editions/
3번 - Prometheus + MetricBeat + Elasticsearch
기능 개요
- Prometheus를 통해 데이터를 수집하나, 데이터 저장소를 Elasticsearch로 하여 데이터 노드를 분리할 수 있고, 노드별 확장성의 이슈에서 더 자유로울 수 있다.
제외 이유
- Elastic 진영의 라이센스 전환 이슈
- 각 라이센스에 대해서 뎁쓰가 깊어서, 사용 적법성을 따지기가 쉽지않았고 모든게 추정이다.
- SSPL1.0 라이센스(무료)와 Elastic License(무료+부분유료) 중 선택해야함
- SSPL1.0 사용시 as a service로 사용되면 연계된 소프트웨어의 모든 소스 공개 의무
- Elastic License 사용시 제품을 관리형으로 사용 불가
- Elasticsearch를 백엔드로 사용하여 SaaS Application 빌드에는 문제없으나, 클라우드 업계의 무임승차를 중요문제로 취급한 이상 추후 잠재적 문제에 대한 불안감..
- 무료 버전의 제한된 기능이 구체적으로 어느선에서 제한적일지 현재는 판단이 어렵다. 일정 중간에 무료버전의 한계로 인해 다 갈아엎어야하는 상황이 걱정된다.
Elastic License의 요금제별 지원범위
https://www.elastic.co/kr/subscriptions
Elastic의 라이센스 전환 FAQ
https://www.elastic.co/kr/pricing/faq/licensing
2번 - Prometheus + Thanos + AlertManager 선택 이유
2번 방안을 선택하게 된 이유는 이 시리즈의 다음 포스트로 작성됐다.