머신과 어플리케이션의 모니터링 아키텍쳐 선택

Hansu Kim·2022년 4월 12일
0

개발 중인 서비스의 모니터링을 위해, 모니터링 기능을 구현하게 됐다.
모니터링 기능을 제공하기 위한 데이터 수집 오픈소스를 찾다보니 아래 3가지 방안 중 선택을 하게 됐다.
시각화는 따로 구현할 예정이라, 시각화 도구는 고려 대상에서 제외됐다.

선택의 주요 고려 요소

  1. 모니터링 중앙 서버 구성 후, 추후 다른 서비스를 추가 수집할 때의 편의성
  2. 구성된 리소스 부족시 확장 방안
    • 중앙서버의 네트워크 Throughput 부족
    • 저장 공간 부족
    • Cpu/Mem 부족
  3. 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번 방안을 선택하게 된 이유는 이 시리즈의 다음 포스트로 작성됐다.

0개의 댓글