GitHub About Docs Tech-Log

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시간 단위)

참고자료

Last updated