프로메테우스, 데이터독과 유사한 모니터링/알람 시스템 설계 1. 초기 설계안

이번 글에서는 모니터링/알람 시스템이 무엇인지 알아보고, 직접 시스템 설계를 한다는 가정하에 요구사항을 구체화하고 초기 설계안에 대해 설명하고자 합니다.

해당 내용은 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2의 5장 지표 모니터링 및 경보시스템 참고하여 작성되었습니다.

 

목차

 

1. 서론

1.1. 지표 모니터링 및 경보 시스템의 중요성

1.2. 대규모 시스템에서의 역할 및 가치

1.3. 대표적인 지표 모니터링/알람 시스템

 

2. 설계에 앞서 아키텍처 이해와 문제 범위 정하기

2.1. 요구사항 구체화

2.2. 요구사항 정리

 

3. 5가지 컴포넌트 / 데이터와 데이터베이스 선택 / 개략적인 설계안

3.1. 5가지 컴포넌트

3.2. 데이터 모델

3.3. 데이터 접근 패턴

3.4. 데이터 저장소 시스템

3.5. 개략적 설계안

 

4. 마치며

 

---

1. 서론

1.1. 지표 모니터링/알람 시스템의 중요성

사이드 프로젝트와 실제 고객이 존재하는 운영 중인 서비스는 차이가 큽니다. 운영 중인 서비스는 실시간으로 운영되며, 이는 서비스가 중단 없이 계속해서 사용자의 요청에 응답해야 함을 의미합니다. 이러한 서비스의 특성상, 예상치 못한 문제가 발생할 수 있는데, 이때 모니터링 시스템이 없다면 문제의 원인을 신속하게 파악하고 대응하기 어렵습니다. 모니터링은 이처럼 서비스의 상태를 실시간으로 확인하고, 문제가 발생했을 때 빠르게 알림을 받아 적절한 조치를 취할 수 있게 해 줍니다.

 

1.2. 대규모 시스템에서의 역할 및 가치

대규모 시스템에서 모니터링의 중요성은 더욱 증가합니다. 수많은 서버와 서비스가 상호 작용하는 복잡한 환경에서는, 한 곳에서 발생한 작은 문제가 전체 시스템에 영향을 미칠 수 있습니다. 이러한 환경에서 모니터링 시스템은 실시간으로 시스템 전반의 상태를 감시하고, 장애가 발생하면 즉각적인 경보를 통해 관리자에게 알리는 중요한 역할을 수행합니다. 이는 장애로 인한 서비스 중단 시간을 최소화하고, 시스템의 안정성과 가용성을 높이는 데 결정적인 요소가 됩니다.

 

1.3. 대표적인 지표 모니터링/알람 시스템

회사 상황에 따라 사용되는 모니터링/알람 시스템은 다양합니다.

대표적으로 그라파나, 프로메테우스, 데이터독, 뉴렐릭, 와탭랩스, 제니퍼소프트, 스카우터 등 등 많은 시스템이 있습니다.

데이터독 https://www.datadoghq.com/blog/slo-monitoring-tracking/ 이미지 중

 

Grafana - wiki image

 

와탭랩스 - https://www.whatap.io/ko/blog/55/

---

2. 설계에 앞서 아키텍처 이해와 문제 범위 정하기

모니터링 시스템을 설계하기 위해서는 먼저 시스템 아키텍처를 깊이 이해하고, 어떤 문제들을 해결하려고 하는지 명확한 설계 범위를 정의하는 것이 중요합니다. 이 과정에서는 마치 가상 면접의 형식을 빌려, 다양한 질문과 답변을 통해 설계를 구체화합니다.

 

2.1 요구사항 구체화

시스템 사용 대상

• 질문: 고객은 누구인가요? 회사 내부용 시스템인가요? 데이터독 같은 SaaS 제품인가요?
• 답변: 우리는 주로 회사 내부용 시스템을 설계하고 있습니다. 이는 우리의 특정 요구사항에 맞춰진, 맞춤형 모니터링 솔루션을 구축하는 것을 목표로 합니다.

수집 지표

• 질문: 어떤 지표를 수집해야 하나요?
• 답변: 우리는 시스템 운영 지표에 초점을 맞춥니다. 이에는 CPU 부하, 메모리 사용률, 디스크 사용량과 같은 운영 체제 지표와, 서버가 처리하는 RPS, 웹 서버 프로세스 개수 등이 포함됩니다. 사업 지표는 수집하지 않습니다.

모니터링 규모

• 질문: 모니터링할 인프라의 규모는 어떻게 됩니까?
• 답변: DAU가 1억 명이며, 1000개의 서버 풀을 관리하고 있습니다. 각 풀에는 약 100개의 소프트웨어 컴포넌트가 있습니다.

데이터 저장 기간

• 질문: 지표 데이터는 얼마나 오래 유지해야 하나요?
• 답변: 모든 지표 데이터는 최소 1년 동안 보관합니다.

데이터 해상도(resolution)

• 질문: 데이터 장기 보관 전용 저장소로 옮길 때 지표의 해상도를 낮추어도 되나요?
• 답변: 네, 초기 7일은 최고 해상도로 데이터를 보관하며, 이후에는 30일 간격으로 1분 단위 데이터로 압축하여 보관합니다. 30일 후에는 1시간 단위로 데이터를 압축합니다.

알람 채널 지원

• 질문: 어떤 알람 채널을 지원해야 하나요?
• 답변: 시스템은 이메일, 전화, 페이저듀티, 웹훅 등 다양한 알람 채널을 지원해야 합니다.

로그 수집 가능

• 질문: 에러 로그나 엑세스 로그 등에 대한 수집 기능도 제공해야 하나요?
• 답변: 아니요, 현재는 시스템 운영 지표에 중점을 두고 있으므로, 로그 수집 기능은 포함하지 않습니다.

분산 추적

• 질문: 분산 시스템 추적 기능도 제공해야 하나요?
• 답변: 아니요, 초기 버전에서는 분산 시스템 추적 기능을 제공하지 않습니다. 우리의 주된 목표는 기본적인 모니터링 및 경보 기능에 집중하는 것입니다.

2.2 요구사항 정리

기능 요구사항

• 대규모 인프라를 모니터
• DAU 1억 명, 서버 풀은 100개, 풀당 서버 수 100개, 서버당 100개의 운영 지표 수집 => 천만 개 수준
• 데이터 보관 1년
• 수집한 raw 데이터 보관 1주일, 그 뒤 데이터 해상도는 1분 단위 변환 후 30일 보관, 그 뒤에는 1시간 단위 1년 보관
• 모니터링 지표 예: CPU 사용률, 요청 수, 메모리 사용량, 메시지 큐 내의 메시지 수

비기능 요구사항

• 규모 확장성: 늘어나는 지표 수와 경보의 양에 맞게 지표 확장 되어야 함
• 낮은 응답: 대시보드와 알람을 신속하게 처리하도록 query에 대한 낮은 응답 지연 보장
• 안정성, 유연성,..

고려하지 않아도 되는 요구사항

• 로그 모니터링: ELK 스택,...
• 분산 시스템 추적: 분산 시스템 내부를 어떻게 흘러 다니는지 추적

---

3. 5가지 컴포넌트 / 데이터와 데이터베이스 선택 / 개략적인 설계안

3.1. 5가지 컴포넌트

모니터링/알람 시스템은 크게 5가지 컴포넌트가 필요합니다.

1. 데이터 수집(data collection): 여러 출처로부터 지표 데이터를 수집
2. 데이터 전송(data transmission): 지표 데이터를 지표 모니터링 시스템으로 전송
3. 데이터 저장소(data storage): 전송되어 오는 데이터를 정리/저장
4. 경보(alerting): 수집되는 데이터를 분석 / 이상 징후를 감지 /  경보 발생(다양한 채널로)
5. 시각화(visualization): 데이터를 차트나 그래프 등으로 제공한다

3.2. 데이터 모델

수집되는 지표 데이터는 보통 시계열(time series) 데이터로 기록됩니다.

 

3.2.1. 시계열 데이터 예시

인스턴스 i631의 20:00 시점의 CPU 부하 확인을 하고 싶은 경우

System Design Interview - 그림 5.3

 

labels - host:1631,env:prod
timestamp - 1613707265
value - 0.29

 

 

3.2.2. line protocol

지난 10분간 us-west region(지역)에 위치한 모든 웹 서버의 CPU 부하 평균값이 얼마인지 알고 싶은 경우 아래 데이터와 같이 raw 형태로 가지고 있고 평균을 구하면 됩니다.

CPU. load host=webserver01, region=us-west 1613707265 48
CPU. load host=webserver01, region=us-west 1613707265 62
CPU. load host=webserver02, region=us-west 1613707265 43
CPU. load host=webserver02, region=us-west 1613707265 53
...
CPU. load host=webserver03, region=us-west 1613707265 71
CPU. load host=webserver01, region=us-west 1613707265 78

 

위 형태의 형식을 lline protocol이라고 합니다.. 프로메테우스나 OpenTSDB 가 위 형태로 데이터를 관리하고 있습니다.

// OpenTSDB Line Protocol 
// https://docs.tdengine.com/develop/insert-data/opentsdb-telnet/

<metric> <timestamp> <value> <tagk_1>=<tagv_1>[ <tagk_n>=<tagv_n>]

meters.current 1648432611249 10.3 location=California.SanFrancisco groupid=2
meters.current 1648432611250 12.6 location=California.SanFrancisco groupid=2
meters.current 1648432611249 10.8 location=California.LosAngeles groupid=3
...
meters.current 1648432611250 11.3 location=California.LosAngeles groupid=3
meters.voltage 1648432611249 219 location=California.SanFrancisco groupid=2
meters.voltage 1648432611250 218 location=California.SanFrancisco groupid=2

 

 

3.3. 데이터 접근 패턴

모니터링/알람 시스템 특징으로는 읽기보다는 쓰기 부하가 더 크게 발생합니다. 매일 천만 개 이상의 운영 지표가 저장됩니다.

읽기 <<< 쓰기

물론 읽기 연산의 급증으로 부하가 몰릴 수 있겠지만 전체적인 관점에서 많은 양의 쓰기 연산의 데이터 접근 패턴을 보입니다.

 

3.4. 데이터 저장소 시스템

그렇다면 위와 같은 패턴에 맞는 데이터 저장소는 어떤 것을 선택해야 할까요?

 

- RDB

- NoSQL

- 시계열 데이터베이스

- 직접 설계/개발(파일 시스템,...)

 

3.4.1. RDB

일반적인 RDB는 시계열 데이터 연상에 최적화되어있지 않습니다. 지수 이동 평균(exponential moving average) 값에 대한 쿼리를 날리고 싶다면 상당히 복잡합니다.. 또한 태그/레이블 관련 쿼리를 지원하려면 태그마다 인덱스를 생성해야 하는데 이 또한 문제입니다.

또한 많은 양의 쓰기 연산이 지속적으로 발생하게 될 텐데 RDB가 완벽히 적합하지 않고 가능하더라도 많은 튜닝이 필요하고 성능이 안 나올 수 있습니다.

 

3.4.2. NoSQL

시계열 데이터를 효율적으로 처리할 수 있다는 NoSQL 중 카산드라(Casandra), 빅테이블(Bigtable)은 시계열 데이터 처리에 사용될 수 있습니다..  모니터링/알람 시스템 시계열 데이터는 고정되어있지 않고 확장 용이한 스키마 설계가 필요한데 NoSQL 내부 구조에 대한 깊은 지식이 필요하므로 좋은 선택이 아닐 수 있습니다.

 

3.4.3. 시계열 데이터 베이스

모니터링/알람 시스템에 맞는 최적화된 시계열 데이터베이스가 이미 많이 존재합니다.

시계열 데이터베이스는 레이블을 기준으로 집계하고 분석하는 기능을 제공하기 위해 레이블 별로 인덱스를 제공합니다.

 

OpenTSDB는 분산 시계열 데이터베이스지만 하둡, HBase 기반으로 클러스터 구성 운영이 약간 복잡하다. 트위터(X)의 MetricsDB나 AWS의 타임스트림이 있지만 InfluxDB와 프로메테우스가 인기가 많습니다.

다량의 시계열 데이터를 저장하고 빠른 실시간 분석을 지원한다 두 제품 모두 메모리 캐시와 디스크 저장소를 함께 활용하며, 영속성 요건과 높은 성능 요구사항도 만족합니다.

 

*8 CPU 코어, 32GB 램을 갖춘 InfluxDB 서버 한 대로 초당 250,000회의 쓰기 연산 처리가 가능하다고 합니다. (책 167p 중)

 

3.4.4. 직접 개발

회사 상황에 맞게 커스텀하여 직접 개발할 수 있습니다.

+a) 현재는 회사 내부 시스템으로 대략적인 설계안이지만, 만약 데이터독처럼 SaaS 서비스로 제공한다면 core 시스템이 별도 구축이 필요할 수 있습니다. 기존 시계열 데이터베이스를 활용할 수도 있겠지만 직접 개발할 수 있지 않을까요?

 

3.5. 개략적 설계안

 

• 지표 출처(metrics source): 지표 데이터가 만들어지는 곳으로 보통 애플리케이션, DB, 메시지 큐 등 
• 지표 수집기(metrics collector): 지표 데이터 수집하고 시계열 데이터 기록하는 역할
• 시계열 데이터베이스: 지표 데이터를 시계열 데이터 형태로 보관하는 저장소, 시계열 데이터 분석/요약하는데 적합하고 쿼리 인터페이스 제공
• 쿼리 서비스(query service): 시계열 데이터베이스에 보관된 데이터 쿼리하고 가져오는 과정 돕는 서비스, 좋은 시계열 데이터베이스 선택했다면 해당 서비스의 역할이 많지 않아도 않아도 되거나 없어도 된다.
• 경보 시스템(alerting sytstem): 경보를 받아야 하는 여러 대상으로 전송
• 시각화 시스템(visualization system): 지표를 다양한 형태의 그래프/차트로 시각화하는 기능 제공 / 대시보드까지

---

4. 마치며

모니터링 시스템은 서비스의 안정성과 사용자 경험 최적화를 위해 필수적입니다. 이 시스템은 실시간 문제 감지와 대응, 대규모 인프라 관리에 중요한 역할을 합니다. 설계 과정은 사용자 요구사항의 정의, 적합한 데이터 모델과 저장소의 선택, 그리고 데이터 수집부터 시각화까지의 주요 컴포넌트 구성을 포함합니다.

 

다음 글에서 개략적 설계안을 발전시키며 기술적 내용을 자세히 살펴보려 합니다.

지표 수집에 필요한 풀 vs 푸시 모델 비교부터 지표 전송 파이프라인 확장성을 위해 카프카 사용과 그 대안, 데이터 집계 방법, 쿼리 서비스의 캐시, 저장 용량 최적화를 위해 데이터 인코딩 및 압축 / 다운 샘플링 / cold 스토리지 등을 알아봅니다.

 

감사합니다.

---

Reference

- 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 - 5장 https://m.yes24.com/Goods/Detail/124138645

- OpenTSDB Line Protocol