Design Metrics Monitoring System
요구 사항
섹션 제목: “요구 사항”- 시스템 운영 지표 수집(CPU / 메모리 / 디스크 / 초당 요청 수 등)
- 일간 사용자 1억 명
- 1000개 서버 풀 / 풀마다 100대 서버
- 지표 데이터 1년간 보관
- 7일 뒤 데이터 -> 1분 단위 데이터로 압축 / 30일 뒤 데이터 -> 1시간 단위 데이터로 압축
- 경보 채널 지원: 이메일 / 전화 등 지원
기본적 사항
섹션 제목: “기본적 사항”지표 모니터링 및 경보 시스템을 지원하기 위해선 일반적으로 다섯 가지 컴포넌트를 필요로 한다.
- 데이터 수집: 여러 출처로부터 지표 데이터 수집
- 데이터 전송: 지표 데이터를 지표 모니터링 시스템으로 전송
- 데이터 저장소: 전송되어 오는 데이터를 정리하고 저장
- 경보: 밀려오는 데이터를 분석하고 이상 징후 감지 및 경보 발생
- 시각화: 데이터를 차트나 그래프 등으로 시각적으로 제공
데이터 모델
섹션 제목: “데이터 모델”지표 데이터는 통상 시계열 데이터 형태로 기록한다.(값 집합에 타임스탬프가 붙은 형태로 기록)
| 필드 | 설명 | 예시 |
|---|---|---|
| metric_name | 지표 이름 | cpu.load |
| labels | 태그/레이블 집합 | host:i631,env:prod |
| value | 지표 값 | 0.59 |
데이터 저장소 시스템
섹션 제목: “데이터 저장소 시스템”지표 저장을 위해 MySQL 같은 RDBMS를 사용할 수 있지만 다음과 같은 이유로 사용하기 어렵다.
- 이론적으론 시계열 데이터 처리가 가능하나 부하 감당이 어려움
- 관계형 데이터베이스는 통상적으로 시계열 데이터 대상 연산에 최적화되어 있지 않음
그렇다면 NoSQL 데이터베이스도 고려해볼 수 있지만 마찬가지로 다음과 같은 이유로 사용하기 어렵다.
- 시계열 데이터를 효과적으로 저장하고 질의하기 위해선 확장에 용이한 스키마 설계 필요
- 그러기 위해선 NoSQL 내부 구조에 대한 깊은 이해 필요
위 선택지가 아닌 시계열 데이터에 최적화된 저장소 시스템이 많이 나와있기 때문에, 이를 사용하는 것이 좋다.
시계열 데이터베이스로는 InfluxDB, OpenTSDB, Prometheus 등이 존재하며, 시계열 데이터 처리에 특화된 기능을 제공한다.
- 시계열 데이터 분석에 적합하며 쉬운 질의 인터페이스 제공
- 데이터 보관 기간 설정 및 데이터 집계 기능 제공
- 다량의 시계열 데이터를 저장하고 빠른 실시간 분석 가능
개략적 설계
섹션 제목: “개략적 설계”지표 모니터링 시스템은 다음과 같은 구조로 설계할 수 있다.
[지표 출처] --> [지표 수집기] --> [시계열 데이터베이스] <--> [질의 시스템] <--> [시각화 시스템] | | v [경보 시스템] | ---------------------------------------------------- | | | | v v v v [이메일] [단문 메시지] [페이지듀티] [HTTPS 서비스 엔드포인트]- 지표 출처: 지표 데이터가 만들어지는 곳(애플리케이션 서버 / SQL 데이터베이스 / 메시지 큐 등)
- 지표 수집기: 지표 데이터를 수집하고 시계열 데이터에 기록
- 시계열 데이터베이스: 지표 데이터를 시계열 데이터 형태로 보관
- 질의 서비스: 시계열 데이터베이스에 보관된 데이터를 질의
- 경보 시스템: 경보 대상에 알림 전송
- 시각화 시스템: 지표를 다양한 형태의 차트로 시각화
지표 수집 방법
섹션 제목: “지표 수집 방법”지표를 수집 데이터는 약소실되어도 아주 심각한 문제가 아니기 때문에, 지표를 보내는 클라이언트는 데이터 전송의 성공 여부를 확인하지 않아도 된다.
데이터를 전송하는 방법으론 크게 풀 모델과 푸시 모델로 나눌 수 있다.
- 풀 모델: 지표 수집기가 주기적으로 실행 중인 서비스에서 지표 데이터를 수집
- 지표 수집기는 데이터를 가져올 서비스 목록을 알아야 하기 때문에 서버가 추가되거나 제거될 때 이를 감지할 수 있어야 함
- 지표 데이터를 생성하는 서버가 일정 대수 이상이 되면 여러 대의 지표 수집기 서버 필요
- 여러 대의 지표 수집기 서버가 데이터를 중복해서 수집하지 않도록 주의(안정 해시 링을 통해 중복 수집 방지 가능)
- 지표 대상 서비스는 제공할 엔드포인트를 제공해야 함
- 대표적으로 프로메테우스가 풀 모델을 사용
- 푸시 모델: 지표 데이터를 생성하는 서비스에서 지표 수집기로 지표 데이터를 전송
- 모니터링 대상 서버에 수집 에이전트 설치 필요
- 간단한 카운터 지표의 경우 수집기에 보내기 전 에이전트가 자체적으로 집계 작업을 하여 데이터 양을 줄일 수 있음
- 대표적으로 클라우드와치 / 그래파이트가 푸시 모델을 사용
두 모델을 장/단점을 비교한 표는 다음과 같다.
| 풀 모델 | 푸시 모델 | |
|---|---|---|
| 손쉬운 디버깅 | 지표 대상 서버에 수집 엔드 포인트를 강제하여 언제든 지표 데이터 확인 가능하여 디버깅 용이 | |
| 상태 진단 | 지표 대상 서버가 풀 요청에 응답하지 않으면 서버 장애 발생으로 진단 가능 | 지표 수집기에서 지표를 받지 못하면 네트워크 장애인지 서버 장애인지 확인 불가 |
| 생존 기간이 짧은 프로세스 | 생명 주기가 짧은 작업인 경우 지표를 끌어가기도 전에 작업 종료 가능성 존재(푸시 게이트웨이를 통해 해결 가능) | |
| 복잡한 네트워크 구성 | 수집기 서버가 지표 대상 서버의 수집 엔드 포인트에 접근 가능하도록 구성 필요 | 지표 수집기가 로드밸런서 및 자동 규모 확장 클러스터인 경우 어디서 오는 지표든 수집 가능 |
| 성능 | TCP 사용 | UDP 사용으로 오버헤드가 적음 |
| 데이터 신빙성 | 지정된 지표 대상 서버 가져오기 때문에 데이터 신빙성이 높음 | 아무나 지표 수집기에 데이터를 보낼 수 있음(인증 강제로 문제 해결 가능) |
카프카를 사용한 지표 수집
섹션 제목: “카프카를 사용한 지표 수집”시계열 데이터베이스에 장애가 생기면 데이터 손실이 발생할 가능성이 존재하지만, 카프카와 같은 큐 시스템을 두어 문제를 해소할 수 있다.
[지표 출처] --> [지표 수집기] --> [카프카] --> [소비자] --> [시계열 데이터베이스] <--> ...장애 문제 해소 이외에도 데이터 수집 컴포넌트와 처리 컴포넌트 사이 결합도를 낮춘다는 이점이 있으며, 카프카의 파티션 메커니즘을 사용해 규모를 더 안정적으로 확장할 수 있다.
- 지표 이름에 따라 해당 파티션에 배치되도록 설정
- 중요 지표가 먼저 처리될 수 있도록 지표를 분류하고 우선순위 지정 가능
데이터 집계 지점
섹션 제목: “데이터 집계 지점”지표 집계는 다양항 지점에서 실행 가능하다.
- 수집 에이전트가 집계: 클라이언트에 설치된 수집 에이전트가 지표를 집계하여 전송
- 복잡한 집계 로직은 어려우며, 분 단위 집계 후 데이터를 전송하는 정도 가능
- 전송량을 줄여 네트워크 부하를 줄일 수 있음
- 데이터 수집 파이프라인에서 집계: 데이터를 저장소에 기록하기 전에 계산하여 데이터베이스에 계산 결과 기록
- 데이터베이스게 기록되는 데이터 양을 줄일 수 있음
- 늦게 도착하는 지표 데이터의 처리가 어려움
- 원본 데이터를 보관하지 않아 정밀도나 유연성 측면에서 손해
- 질의 시에 집계: 데이터 날것 그대로 보관 후 질의할 때 집계
- 데이터 손실 없이 데이터를 보관할 수 있음
- 질의를 처리하는 순간에 집계를 실행하기 때문에 질의 시간이 길어질 수 있음
저장 용량 최적화
섹션 제목: “저장 용량 최적화”지표 모니터링 시스템에 저장할 데이터의 양은 매우 크기 때문에 저장 용량을 최적화하는 것이 중요하다.
- 데이터 인코딩 및 압축: 데이터를 인코딩하고 압축하여 크기를 줄이는 방법, 시계열 데이터베이스는 대부분 이 기능을 가지고 있음
- 다운샘플링: 데이터의 해상도를 낮춰 저장하는 방법(최초: 초 단위 보관 -> 7일 뒤: 1분 단위 -> 30일 뒤: 1시간 단위)