[ Monitoring ] 인프라 모니터링 파이프라인 설계하기 #3

지난번에는 대략적으로 로깅까지 알아보았던 기록을 남겨뒀는데요, 

이번에는 지난번에 미처 못다룬 로그수집뿐만아니라 제가 어떤것에 중점을 두고 설계했는지,최종 아키텍처에 대해 이야기해보겠습니다.

 

로그모니터링 시스템

WHY ?

• 버그 및 장애 발생 시 해당 로그를 분석하여 원인을 빠르게 파악 및 해결
• 이슈 발생 시, 당시 사용자의 행동(데이터 요청 등) 확인
• 보안 이슈 또는 시스템의 취약점 파악
• 사용자의 요청과 응답 사이의 시간이 기록되어 성능 저하 발생 지점 파악
• 비즈니스 의사 결정에 로그 데이터 활용 가능

오픈소스 로그 모니터링 스택으로는 ELK(Elasticsearch, Logstash, Kibana) 스택과 PLG(Promtail, Loki, Grafana) 스택이 있다.

 

Elasticsearch는 데이터 검색 엔진, Logstash는 데이터 처리 파이프라인 툴, Kibana는 데이터 시각화 대시보드 툴인데요. 여기에 추가로, Beats라고 하는 경량 데이터 수집 툴을 함께 사용하기도 합니다.

앞서 ELK 스택이 널리 쓰이고 있는 로그 모니터링 스택 중 하나라고 했는데요. 사람들이 ELK 스택을 많이 사용하는 이유는 아래와 같습니다.

• 오픈소스 툴로 구성되어 있기 때문에 별도의 비용 없이 무료로 구축 가능
• 다양한 데이터 소스(서비스, 시스템)로부터 발생한 로그와 이벤트 데이터를 쉽게 수집 가능
• Kibana에서 실시간 데이터를 활용한 대시보드 구축 가능

 

• Beats의 역할
  • 데이터 수집 대상으로부터 발생하는 로그 데이터 수집
  • 수집한 데이터를 미리 지정된 대상에게 전달
• Logstash의 역할
  • Input: 다양한 데이터 소스로부터 로그 데이터 수집 (Beats도 데이터 소스 중 하나)
  • Filter: 수집한 로그 데이터 필터링 (다양한 플러그인을 사용하여 데이터 가공 등을 수행)
  • Output: 로그 데이터를 다양한 데이터 소스로 전달 (Elasticsearch도 데이터 소스에 해당)
• Elasticsearch의 역할
  • 전달받은 로그 데이터 저장 ()
  • Store
  • 저장된 로그 데이터를 API로 검색 가능 ()
  • Search
• Kibana의 역할
  • Elasticsearch에 저장된 데이터를 사용자가 시각화 가능
  • Elasticsearch에 저장된 데이터를 사용자가 쉽게 검색하고 필터링 가능

PLG

• Promtail의 역할
  • 로컬에서 발생하는 로그 수집
  • 수집한 로그를 Loki로 전달
• Loki의 역할
  • 로그 저장 요청을 받으면 처리 후 해당 로그 저장
  • 로그 조회 요청을 받으면 쿼리 이용하여 해당 로그 전달
  • Loki는 Elasticsearch처럼 실제 로그 데이터를 인덱싱하는 방식이 아닌, 로그의 메타데이터를 인덱싱하도록 설계되었기 때문
  • Elasticsearch의 쿼리 언어만큼 성숙하지 않음
  • 단순한 검색 쿼리만 지원
  • 로그 데이터의 메타데이터만으로 검색
• Grafana의 역할
  • Loki에 저장되어있는 로그 활용하여 사용자가 시각화 가능

종합해보면, 복잡한 쿼리나 필터링 기능이 필요하고 다양한 데이터 소스의 로그를 모니터링한다면 ELK 스택을, 복잡하지 않은 쿼리로도 로그 모니터링이 가능한 상황이면서 비용을 절약하고 싶다면 PLG 스택을 선택할 수 있겠습니다.🔍

 

참고 : https://maily.so/newslettertodevops/posts/vpzl9mxdzk9

🔭[Monitoring 특집] PLG 스택과 ELK 스택 비교

 

 

사실 로깅은 그렇게 많이는 고려하지 못했어서, 이어서는 아키텍처 설계 방안에 대해 이야기하겠습니다.

설계 진행에 앞서, 저만의 가상 조건를 확실히 정의하고 설계 범위를 확장하고자 했습니다.

아키텍처 설계

1단계 : 문제 이해 및 설계 범위 고려해보기 

• 시스템의 고객은 누구일지?
  • 회사 내부 사용할 시스템 설계
• 어떤 지표를 수집해야 할 지?
  • 시스템 운영 지표 수집
    • cpu부하, 메모리 사용률, 디스크 상용량 같은 저수준의 운영체제 사용률 지표일 수 있고,
    • 서버가 처리하는 초당 요청수나 웹 서버 프로세스 개수같은 고차원적 개념에 관계된 지표일 수 있다.
• 모니터링 할 인프라 규모는?
  • 일간 능동 사용자 수는 5천명 (DAU)
  • 1000개의 서버 풀이 있고
  • 풀마다 100개의 서버 하드웨어를 유지하고 있다.
• 지표 데이터 보관 기간은?
  • 1년동안 보관
  • 새로 수집한 데이터는 7일동안 보관하는것
  • 7일 뒤에는 1분단위 데이터로 만들어서 30일간 보관
  • 그 후에는 1시간 단위데이터로 만들어서 보관
• 경보 채널
  • 이메일, 전화, 웹훅 ( HTTP 프로토콜을 지원하는 엔드포인트 ) 등을 지원한다.

 

상기의 내용들은 대규모 시스템 설계2 를 참고했습니다.

핵심적인 키워드는 

• 유연하게 변경가능한가?
• 안정적인가?
• 낮은 응답지연을 가지고있는가?
• 확장성이있는가?

이라고 생각했고, 인프라 지표 그 자체에 관심을 두었기 때문에, 로그에는 초점을 맞추지 않았습니다. 

 

2단계 : 시스템 구축을 위한 기본적인 사항에 대한 고민  

| 여기부터는 일부 구어체로 적겠습니다. 

대규모시스템설계2

데이터 모델)

• 시계열 데이터 형태로 기록한다.
• 레이블을 붙이기도 한다.
• 각 행의 데이터 형식은 행 프로토콜을 따르고있다.
  • 시장공개 많은 모니터링 소프트웨어가 이 공통형식을 준수한다.

저장소 )

• 시계열 데이터베이스를 대상으로 하는 저장소 시스템은 시장에 많다.
• 가장 인기있는 시계열 데이터베이스는 InfluxDB, 프로메테우스 이다.
• 다량의 시계열 데이터를 저장하고, 빠른 실시간 분석을 지원하는것이 특징이다.
• 메모리캐시와 디스크 저장소를 사용한다.
• 영속성 요건과 높은 성능 요구사항도 잘 만족한다.

 

중요한것은 지표데이터는 본질적으로 시계열 데이터이므로,

Influx DB 와 같은 시계열 데이터베이스에 저장할 수 있다는 것을 설명해야만 한다. 

좋은 시계열 데이터베이스는 막대한 양의 시계열 데이터베이스를 레이블(어떤 데이터베이스에서는 태그라고 부르기도 한다.) 기준으로 집계하고 , 분석하는 기능을 제공한다.

• influx DB는 레이블 기반의 신속한 데이터 질의를 지원하기 위해 레이블별로 인덱스를 구축한다.
• 레이블을 이용할 때 데이터베이스의 과부하를 피하는 지침도 제공한다.
• 핵심은 각 레이블이 가질 수 있는 값의 가짓수가 낮아야한다는 것이다.
• 이 기능은 데이터 시각화에 매우 중요하며, 범용 데이터베이스로 구축하기에는 매우까다롭다.

지표 데이터 수집

풀 vs 푸시 모델

풀 - 프로메테우스

주기적으로 데이터를 가져오는 것

대규모 데이터를 수집하려면, 지표 수집 서버가 여러대여야하는데 이때 데이터 중복 문제가있기 때문에 해시링을 통해 해결한다.

 

푸시 - 클라우드워치, 그래파이트

서버가 지표수집기에 데이터를 전송하는것

밀려드는 대규모데이터를 처리하기 위해서는 앞에 로드밸런서를 두는것이 바람직함

이때 클러스터 크기는 수집기 서버 cpu 부하에 따라 자동으로 늘어나거나 줄어들도록

비교

이 두모델의 장단점을 비교할 수 있는 능력을 보이는것이 중요하다.

 

지표 전송 파이프라인 부분

• 풀/푸쉬 관계없이
• 엄청난양의 데이터를 받아 처리해야함
• 자동 규모 확장 가능하게 해서 충분히 수집할 수 있또록 해야함
• 하지만 시계열 데이터베이스에 장애가 생기면 데이터손실이 발생할 가능성이 있어서 카프카와 같은 큐를 두면 그런 문제를 해소할 수 있따.
  • 카프카
    • 고도 안정적, 규모 확장성이 뛰어난 분산 메시지 플랫폼
    • 데이터 수집 컴포넌트와 처리 컴포넌트 사이의 결합도를 낮춘다.
    • 데이터베이스에 장애 생겨도 데이터 소실 안됨, 카프카에 보관해서 가능하다. 
    • 카프카에 내장된 파티션 메커니즘을 사용하면 시스템의 규모를 다양한방법으로 확장할 수 있다.
    • 그러면 지표 수집기는 지표 데이터를 카프카같은 큐에 전송
    • 스트림 처리 서비스 ( 아파치 스톰,플링크, 스파크 )가 시계열 데이터베이스에 저장함

질의

• 프로메테우스나 influxDB 같은 널리 사용되는 지표 모니터링 시스템들은 sql 이 아닌 독자 질의어를 제공한다.
• 시계열데이터는 sql 로는 질의하기가 까다롭기 때문

저장소 계층

저장 용량 최적화

• 데이터 인코딩 및 압축
• 다운샘플링

 

---

위 내용을 참고하며, influx DB를 쓸지 프로메테우스를 사용할지, 혹은 pull/push 중 어떤것을 선택해야할 지에대한 고민을 했습니다.

또한, 카프카를 이용해 대규모 데이터를 처리하는 방안을 마련할 수 있었습니다. 

 

3단계 : 본격적인 설계와 조건 설립 

위에서 진행했던 문제 이해 및 설계 범위 고려해보기 를 통해 아래와 같은 사항을 명확히 결정할 수 있었습니다. 

(조건은 큰 변경없음)

 

조건 ) 

• 시스템의 고객은 누구일지?
  • 사내 사용자 (관리자)
• 어떤 지표를 수집해야 할 지?
  • 클라우드 인프라의 시스템 운영 지표 수집
    • cpu부하, 메모리 사용률, 디스크 상용량 같은 저수준의 운영체제 사용률 지표일 수 있고,
    • 서버가 처리하는 초당 요청수나 웹 서버 프로세스 개수같은 고차원적 개념에 관계된 지표일 수 있다.
• 모니터링 할 인프라 규모는?
• 일간 능동 사용자 수는 5천명 (DAU)
• 1000개의 서버 풀이 있고
• 풀마다 100개의 서버 하드웨어를 유지하고 있다.
• 경보 채널
  • 이메일, 전화, 웹훅 ( HTTP 프로토콜을 지원하는 엔드포인트 ) 등을 지원한다.

사용자 세션 길이가 간접적으로 중요한 이유

1. 자원 사용량 증가
   • 장기 세션이 많을수록 서버, 네트워크, 스토리지 등 인프라 자원의 부하가 증가합니다.
   • 예를 들어, 세션이 길어질수록 CPU 사용량이 지속적으로 높아질 가능성이 있어 이를 추적하고 분석해야 할 수 있습니다.
2. 시스템 안정성 평가
   • 긴 세션 동안 발생하는 메모리 누수나 CPU 과부하와 같은 문제를 감지해야 합니다.
   • 이는 시스템 운영 상태를 안정적으로 유지하기 위한 중요한 지표입니다.
3. 데이터 저장 및 처리량 증가
   • 사용자 세션이 길면, 해당 세션 동안 생성되는 메트릭 데이터와 로그의 양이 증가합니다.
   • 이러한 데이터를 저장하고 처리할 수 있는 파이프라인의 성능을 보장해야 합니다.

1. 데이터 수집

• Node Exporter:서버의 CPU, 메모리, 디스크 I/O, 네트워크 상태 등 메트릭 수집.
• cAdvisor:컨테이너 환경에서 리소스 사용량 수집 (Docker, Kubernetes).
• SNMP Exporter:네트워크 장비(라우터, 스위치)의 SNMP 데이터를 Prometheus로 가져옴.
  • 서버/네트워크 리소스: Prometheus Node Exporter, SNMP Exporter.
  • 컨테이너: cAdvisor.
  • 로그: Fluentd.

참고 : https://yjkim97.tistory.com/53

2. 데이터 전송

• Prometheus Pull Mechanism:Prometheus 자체의 pull 기반 메트릭 수집 방식. 수집 주기와 Exporter 설정을 통해 데이터 가져옴.
• Kafka:대규모 데이터 스트림 처리를 위한 메시지 브로커. 높은 내구성과 확장성 제공.
  • Prometheus 자체 Pull 방식.
  • Kafka나 Fluentd로 추가적인 스트림 처리.
• 풀/푸쉬 관계없이
• 엄청난양의 데이터를 받아 처리해야함
• 자동 규모 확장 가능하게 해서 충분히 수집할 수 있도록 해야함
• 하지만 시계열 데이터베이스에 장애가 생기면 데이터손실이 발생할 가능성이 있어서 카프카와 같은 큐를 두면 그런 문제를 해소할 수 있다.
  • 카프카
    • 고도 안정적, 규모 확장성이 뛰어난 분산 메시지 플랫폼
    • 데이터 수집 컴포넌트와 처리 컴포넌트 사이의 결합도를 낮춘다.
    • 데이터베이스에 장애 생겨도 데이터 소실 안됨, 카프카에 보관해서

3. 데이터 저장

• Prometheus TSDB:Prometheus 기본 시계열 데이터베이스. 온프레미스에서는 빠르고 간단히 설정 가능.
• Thanos:
• Prometheus 데이터를 장기 저장하며, 클러스터링 및 중앙화된 쿼리 지원.

참고 ) 

https://static.toss.im/slash21/pdf/[토스_SLASH 21] 토스의 서버 인프라 모니터링_이재성.pdf

https://toss.im/slash-21/sessions/1-2

https://blog.shik.kr/tsdb-for-prometheus-and-why-thanos

 

 

(프로메테우스 단점 생각해서 타노스가 필요하다고 생각했다.)

 

로컬 디스크만 써도 저렇게 좋으면 타노스가 왜 필요할까?

사실 프로메테우스 서버 하나에서도 초당 백만개의 데이터를 집어넣을 수 있고, 말이 로컬 디스크지 EBS, Ceph을 마운트하면 내부적으로 복제를 하니까 꽤나 persistent하다. 그럼에도 불구하고 Thanos가 왜 필요한가…? 가 할 수 있다. Thanos가 처음 나올 때 글에 모티베이션이 잘 설명되어 있다 .

• 1: 프로메테우스 서버 여러개를 하나의 뷰로 보고 싶다
  • 프로메테우스 서버 별로 수집하는 메트릭이 다른데 그라파나에서 그래프 하나에 그리고 싶을 수 있다.
  • HA를 위해 같은 역할을 하는 프로메테우스 두 개를 띄운다고 할 때, 살아있는 프로메테우스에만 쿼리하기가 좀 귀찮을 수 있다.
• 2: 로컬디스크의 limit 이상의 데이터를 저장하고 싶다
• 3: 다운 샘플링이 필요하다 (5분/한시간 등등)

https://hanhorang31.github.io/post/pkos2-4-monitoring/

 

https://medium.com/@dast04/theory-monitoring-with-prometheus-thanos-part-1-2-8bc500a9c6a8

 

프로메테우스의 페더레이션

참고 : https://wkdwoo.tistory.com/9

Prometheus Federation

 

4. 데이터 시각화

• Grafana:
• Prometheus, InfluxDB, Elasticsearch 등 다양한 데이터 소스와 연동 가능. 커스터마이징 가능한 대시보드.

Signoz는 분산 시스템의 성능 모니터링과 디버깅에 특화되어 있으며, OpenTelemetry 기반의 메트릭, 로그, 트레이스 수집 및 분석에 중점을 둡니다. Grafana는 다양한 데이터 소스를 시각화하고, 사용자 정의 가능한 대시보드를 통해 실시간 모니터링을 제공합니다. 시스템 모니터링부터 비즈니스 메트릭 시각화까지 다양한 사용 사례에 적합합니다.

 

출처: https://ls-altr.tistory.com/164 [동구멍폴로 IT:티스토리]

 

 

5. 로깅

이전 게시물 기반으로 고려함 

 

---

 

1차 최종 아키텍처 

위 내용들을 고려해서 아래와 같은 아키텍처를 설계했습니다. 

 

 

하지만, 주변 분들의 피드백을 요청하여 카프카가 다소 오버 엔지니어링 일 수 있다는 점을 피드백을 들을 수 있었습니다. 

때문에, 저 역시도 피드백과 가정했던 조건을 고려해보았을 때에는 Kafka를 제외하고 Thanos의 Federation만으로 충분히 부하를 처리할 수 있다는 것)은 현재 상황에서는 적합할 것이라는 판단을 하게 되었습니다.

 

그럼에도 불구하고, 아키텍처는 확장성과 사용자 증가를 고려하였을 때를 가정해야한다고 생각했기 때문에, 아래와 같이 상황을 나누었습니다.

---

최종 아키텍처 ( 고도화되지 않은 ver)

• 지표 수집 : 시스템 운영 지표 수집
  •  cpu부하, 메모리 사용률, k8s 노드 상태 등
• 로그 수집 : 시스템 로그, k8s 컨테이너 로그 등
• 모니터링 할 인프라 규모
  • 일간 능동 사용자 수 : 5천명
  • 10개의 서버 풀
  • 풀마다 10개의 서버 하드웨어 유지

 

• 지표 데이터 보관 기간 : 1년보관 (장기보관 가능)
• 확장성 및 고가용성 고려, 디스크 부하 방지 

 

최종 아키텍처 ( 고도화된 ver)

고도화의 필요성은 다음과 같다.

모니터링 할 인프라 규모 증가

ex ) 10만개의 서버

 

방안: 카프카 도임

• 데이터 처리량 증가 대응
• 장애 복원력
• 확장성 및 통합성 

 

---

 

혹시나 해당 아키텍처를 참고하시거나, 재 가공 하실 경우 출처 표기 부탁드립니다.

사실 이 아키텍처가 완벽한지 (?), 괜찮은지는 잘 모르겠지만

제가 생각한 바는 여기까지 입니다. 

다음 게시물 부터는 vm에 프로메테우스를 구축해서 수집해보겠습니다.

직접 구축해 지식을 체화하는 인재 !^^ ,,