# 05.지표 모니터링 및 경보 시스템

지표 모니터링 및 경보 시스템은 인프라의 상태를 선명하게 볼 수 있도록 하여 높은 가용성과 안정성을 달성하는 데 중추적 역할

## 1단계: 문제 이해 및 설계 범위 확정

✅ **개략적 요구사항 및 가정**

대규모 인프라를 모니터링

* 일간 능동 사용자 수 1억명
* 서버 풀 1,000개, 풀당 서버 수 100개, 서버당 100개의 운영 지표를 수집한다고 치면 모니터링해야 하는 지표의 수는 천만개 수준
* 데이터 보관 기간은 1년
* 수집한 그대로 데이터를 보관하는 기간은 일주일, 그 뒤에는 1분 단위 데이터로 변환한 후 30일간 보관. 그 뒤에는 1시간 단위 데이터로 변환한 뒤 1년간 보관

모니터링할 지표

* CPU 사용률
* 요청 수
* 메모리 사용량
* 메시지 큐 내의 메시지 수

✅ **비기능 요구사항**

* 규모 확장성: 시스템은 늘어나는 지표 수와 경보의 양에 맞게 확장될 수 있어야 함.
* 낮은 응답 지연: 대시보드와 경보를 신속하게 처리할 수 있도록 질의에 대한 낮은 응답 지연을 보장
* 안정성: 높은 안정성을 제공하여 중요 경보를 놓치지 않도록
* 유연성: 기술은 계속 변화하므로, 미래의 신기술을 쉽게 통합할 수 있도록 유연하게 변경 가능한 파이프라인을 이용해 구축한 시스템

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

* 로그 모니터링
* 분산 시스템 추적

## 2단계: 개략적 설계안 제시 및 동의 구하기

### 기본적 사항

사용되는 컴포넌트

* 데이터 수집: 여러 출처로부터 지표 데이터를 수집
* 데이터 전송: 지표 데이터를 지표 모니터링 시스템으로 전송
* 데이터 저장소: 전송되어 오는 데이터를 정리하고 저장
* 경보: 밀려오는 데이터를 분석하고, 이상 징후를 감지하고, 경보를 발생
  * 이 시스템은 다양한 통신 채널로 경보를 발송
* 시각화: 데이터를 차트나 그래프 등으로 제공
  * 패턴, 추이, 문제점을 더 쉽게 파악하기 위한 도구

### 데이터 저장소 시스템

범용 데이터베이스는 이론적으로 시계열 데이터를 처리할 수 있지만, 이 설계안이 감당하려는 부하 규모에 맞추려면 전문가 수준의 튜닝이 필요

* Casandra, Bigtable 같은 시계열 데이터를 효율적으로 처리할 수 있다고 알려진 NoSQL DB들이 있지만,
* 시계열 데이터를 효과적으로 저장하고 질의하기 위해서는 확장이 용이한 스키마 설계가 필요한데, 내부 구조에 대한 해박한 지식이 필요

시계열 데이터에 최적화된 저장소 시스템은 시장이 만다.

* `OpenTSDB`:
  * 분산 시계열 데이터베이스
  * Hadoop, HBase에 기반하여 Hadoop/HBase 클러스터를 구성하고 운영해야 하므로 복잡
* `MetricsDB`:
  * X가 사용하는 시계열 데이터베이스
* `Timestream`:
  * 아마존이 출시한 제품

[DB-engines 조사 결과](https://db-engines.com/en/ranking/time+series+dbms) `InfluxDB`, `Prometheus`가 높은 인기

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

### 개략적 설계안

<figure><img src="https://3925856803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfJN93IwN0ptPSTmZ53eY%2Fuploads%2Fgit-blob-5d0915947a79277ec071c64c22201df4b051814d%2F5.6.png?alt=media" alt=""><figcaption></figcaption></figure>

* **지표 출처**: 지표 데이터가 만들어지는 곳으로, 애플리케이션 서버, SQL 데이터베이스, 메시지 큐 등
* **지표 수집기**: 지표 데이터를 수집하고, 시계열 데이터에 기록
* **시계열 데이터베이스**: 지표 데이터를 시계열 데이터 형태로 보관하는 저장소
  * 다량의 시계열 데이터를 분석하고 요약하는 데 적합하도록 설계된 질의 인터페이스 제공
* **질의 서비스**: 시계열 데이터베이스에 보관된 데이터를 질의하고 가져오는 과정을 지원
* **경보 시스템**: 경보를 받아야 하는 다양한 대상으로 경보 알림을 전송하는 역할
* **시각화 시스템**: 지표를 다양한 형태의 그래프/차트로 시각화 하는 기능을 제공

## 3단계: 상세 설계

### 지표 수집

<figure><img src="https://3925856803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfJN93IwN0ptPSTmZ53eY%2Fuploads%2Fgit-blob-946a6844a2cd15bc15b97ff55d06f65ac396d275%2F5.7.png?alt=media" alt=""><figcaption></figcaption></figure>

#### 풀 vs 푸시 모델

지표 데이터 수집 방법에는 두 가지 모델이 있다.

✅ **풀 모델**

HTTP 기반 풀 모델을 이용하는 지표 수집의 흐름

* 실행중인 애플리케이션에서 주기적으로 지표 데이터를 가져오는 `지표 수집기`가 흐름의 중심

<figure><img src="https://3925856803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfJN93IwN0ptPSTmZ53eY%2Fuploads%2Fgit-blob-4833e399a6e95ccfe30167d0488f82d29c811d49%2F5.8.png?alt=media" alt=""><figcaption></figcaption></figure>

**지표 수집기**는 데이터를 가져올 서비스 목록을 알아야 하는데, '지표 수집기' 서버 안에 모든 서비스의 엔드포인트의 DNS/IP 정보를 담은 파일을 두면 가장 간단

* 서버가 수시로 추가/삭제되는 대규모 운영 환경에서는 적응하기 어려움
* [etcd](https://etcd.io/), [Apache Zookeeper](https://zookeeper.apache.org/) 같은 서비스 탐색 기술 활용 시 해결 가능
* 각 서비스는 자신의 가용성 고나련 정보를 서비스 탐색 서비스(SDS, Service Descovery Service)에 기록하고, SDS는 서비스 엔드포인트 목록에 변화가 생길 떄마다 지표 수집기에 통보
  * SDS에는 언제 어디서 지표를 수집하면 될지에 관한 설정 정보를 기록
  * 지표 수집 주기, IP 주소, 타임아웃, 재시도 인자 등

수천 대 서버가 만들어 내는 지표 데이터를 수집하려면 지표 수집기 서버 한대로는 부족하고, 서버 풀을 만들어야 대량의 데이터 규모를 감당할 수 있다.

* 지표 수집기 서버를 여러 대 둘 때 흔히 빚어지는 문제는 데이터 중복 가능성인데, 서버 간에 모종의 중재 메커니즘이 필요
* 안정 해시 링(consistent hash ring)을 사용하여 구현 가능
* 즉, 해시 링 구간마다 해당 구간에 속한 서버로부터 생산되는 지표의 수집을 담당하는 수집기 서버를 지정

<figure><img src="https://3925856803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfJN93IwN0ptPSTmZ53eY%2Fuploads%2Fgit-blob-d31bd97cbdd8964a95cfd1924f6ef25e09e13f22%2F5.12.png?alt=media" alt=""><figcaption></figcaption></figure>

### 지표 전송 파이프라인 규모 확장

### 질의 서비스

### 저장소 계층

### 경보 시스템

### 시각화 시스템
