카테고리 없음

[대규모 설계 시스템 기초 2] - 지표 모니터링 및 경보 시스템

계범 2025. 7. 27. 18:17

지표 모니터링 및 경보 시스템이란

 

  • 지표(Metrics): 시스템이나 애플리케이션의 상태를 수치화한 데이터 (예: HTTP 요청 지연시간, CPU 사용률, 오류율 등)
  • 모니터링 시스템: 지표를 수집·저장·시각화하여 운영자가 시스템 상태를 실시간으로 파악할 수 있도록 해주는 플랫폼
  • 경보(Alerting) 시스템: 미리 정의한 임계값(threshold)이나 이상 탐지(anomaly detection) 기준을 넘어설 때 운영자에게 알림을 보내는 메커니즘

 

개략적 요구사항 및 가정

  • 대규모 인프라 모니터링
    • 일간 능동 사용자 수 1억명
    • 서버 풀 1000개. 서버 수 100개. 서버 당 100개의 운영 지표를 수집한다고 치면 모니터링 해야하는 지표 수는 1000만
    • 데이터 보관 기간 1년
    • 원본 데이터 보관 일주일. 그 뒤는 1분단위 데이터로 변환 후 30일 보관. 1시간 단위 데이터로 1년간 보관.
  • 모니터링 지표
    • cpu 사용률
    • 요청 수
    • 메모리 사용량
    • 메시지 큐 내 메시지 수
  • 비기능 요구사항
    • 규모 확장성
    • 낮은 응답 지연
    • 안정성
    • 유연성

 

기본적 구현 사항

  • 데이터 수집 : 여러 출처로부터 지표 데이터 수집
  • 데이터 전송 : 지표 데이터 -> 지표 모니터링 시스템 전송
  • 데이터 저장소 : 데이터를 정리하고 저장
  • 경보 : 밀려오는 데이터를 분석하고, 이상 징후 감지, 경보를 발생. 다양한 통신 채널로 경보 발송
  • 시각화 : 데이터를 차트나 그래프 등으로 제공

 

데이터 모델

지표 데이터는 통상 시계열 데이터 형태로 기록.

값 집합에 타임스탬프가 붙은 형태로 기록한다는 뜻.

시계열 각각에는 고유한 이름이 붙고, 선택적으로 레이블을 붙이기도 함.

 

사례1)

운영환경 서버 인스턴스 i163의 20:00 시점의 cpu 부하 파악하고 싶다.

 

metric_name cpu.load
labels host:i631,env:prod
timestamp 1613707265
value 0.29

 

 

사례2)

지난 10분간 us-west 지역에 위치한 모든 웹 서버의 cpu 부하 평균값

 

cpu.load host=webserver01, region=us-west 1613707265 50

cpu.load host=webserver01, region=us-west 1613707265 62

cpu.load host=webserver02, region=us-west 1613707265 63

cpu.load host=webserver02, region=us-west 1613707265 53

...

cpu.load host=webserver01, region=us-west 1613707265 76

cpu.load host=webserver01, region=us-west 1613707265 83

 

해당 데이터들의 마지막에 기록된 cpu 부하 수치의 평균을 구하면 됨.

 

데이터 접근 패턴

해당 로그 시스템은 당연히 압도적으로 쓰기 빈도수가 높다.

반면 읽기 부하는 일시적으로 치솟았다 사라지는(spike) 편이라고 봐야한다.

시각화나 경보 시스템은 데이터베이스에 대해 읽기 연산을 발생시킨다.

 

언제나 많은 양의 쓰기 연산 부하를 감당해야하고, 읽기 연산의 부하는 일시적으로 급증하였다가 곧 사라지곤 한다는 것.

 

데이터 저장소 시스템

관계형 데이터베이스는 시계열 데이터를 대상으로 통상적으로 수행하는 연산에 최적화되어있지 않음.

 

nosql은 카산드라나 빅테이블은 시계열 데이터 처리에 사용될 수 있다.

하지만 효과적으로 저장하고 질의하기 위해선 확장이 용이한 스키마 설계를 해야하고 그러려면 nosql 데이터베이스의 내부 구조에 대한 해박한 지식이 필요.

 

시계열 데이터베이스로 가장 인기 있는 것은 influxDB 그리고 프로메테우스이다.

다량의 시계열 데이터를 저장하고 빠른 실시간 분석을 지원하는 것이 특징.

두 제품 모두 메모리 캐시와 디스크 저장소를 함께 사용.

영속성 요건과 높은 성능 요구사항도 잘 만족한다.

 

8CPU 코어와 32GB 램을 갖춘 influxDB 서버 한대로 초당 250,000회의 쓰기 연산 처리가 가능하다.

이력서에 언급하지 않았다면 면접관도 대체적으로 내부 구조까지 질문하지는 않을것..

 

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

핵심은 각 레이블이 가질 수 있는 값의 가짓수(cardinality)가 낮아야한다.

 

개략적 설계안

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

 

상세 설계

지표 수집

카운터나 cpu 사용량 같은 지표를 수집할 때는 때로 데이터가 소실되어도 아주 심각한 문제는 아님.

 

풀 vs 푸시 모델

풀모델

이 접근법에서 지표 수집기는 데이터를 가져올 서비스 목록을 알아야 함.

'지표 수집기' 서버 안에 모든 서비스 엔드포인트의 DNS/IP 정보를 담은 파일을 두면 가장 간단하다.

하지만 이 방안은 서버가 수시로 추가/삭제되는 대규모 운영 환경에서 적용하긴 어려움.

 

etcd나 아파치 주키퍼 같은 서비스 탐색 기술을 활용하면 이 문제는 해결 가능.

각 서비스는 자신의 가용성 관련 정보를 서비스 탐색 서비스(SDS)에 기록하고, SDS는 서비스 엔드포인트 목록에 변화가 생길 때마다 지표 수집기에 통보하는 것이다.

SDS에는 언제 어디서 지표를 수집하면 되는지에 관한 설정 정보를 기록한다.

 

수집 흐름

1) 지표 수집기는 SDS에서 서비스 엔드포인트 설정 메타데이터 목록을 가져온다. 각 메타데이터에는 지표 수집 주기, IP 주소, 타임 아웃, 재시도 인자 등이 기록되어 있다.

 

2) 지표 수집기는 사전에 합의된 http 엔드포인트에서 ( /metics 같은 ) 지표 데이터를 가져온다.

이런 엔트포인트를 수집기에 노출하기 위해서, 통상 서비스에 특정 클라이언트 라이브러리를 추가한다.

 

3) 지표 수집기는 서비스 엔드포인트 목록의 변화를 통지 받기 위한 변경 이벤트 알림 콜백을 서비스 탐색 컴포넌트에 등록할 수 있다. 그렇게 하는 대신 주기적으로 서비스 탐색 컴포넌트에서 엔드포인트 목록을 다시 가져와도 된다.

 

수천대 서버가 만들어 내는 지표 데이터를 수집하려면 지표 수집기 서버 1대로는 부족하다.

지표 수집기 서버 풀을 만들어야 지표 데이터 규모를 감당할 수 있다.

여러 수집기 서버가 같은 출처에서 데이터를 중복해서 가져올 가능성이 생기니, 모종의 중재 메커니즘이 필요하다.

 

이 메커니즘을 구현하는 한가지 방안은 안정 해시 링이다.

해시 링 구간마다 해당 구간에 속한 서버로부터 생산되는 지표의 수집을 담당하는 수집기 서버를 지정하는 것이다.

이렇게 하면 특정 서버의 지표 데이터는 항상 하나의 수집 서버가 처리함을 보장할 수 있다.

 

푸시 모델

푸시 모델은 지표 출저에 해당하는 서버, 즉 웹 서버나 데이터베이스 서버 같은 서버가 직접 지표를 수집기에 전송하는 모델이다.

푸시 모델의 경우, 모니터링 대상 서버에 통장 수집 에이전트라고 부르는 소프트웨어를 설치한다.

수집 에이전트는 해당 장비에서 실행되는 서비스가 생산하는 지표 데이터를 받아 모은 다음 주기적으로 수집기에 전달한다.

간단한 카운터 지표의 경우, 수집기에 보내기 전에 에이전트가 직접 데이터 집계 등의 작업을 처리할 수도 있다.

 

데이터 집계는 수집기에 보내는 데이터의 양을 줄이는 효과적인 방법이다.

데이터 전송 트래픽의 양이 막대하여 수집기가 오류를 반환하면,

에이전트는 내부의 소규모 버퍼에 일시적으로 보관한 다음 나중에 재전송할 수도 있을 것이다.

 

만일 에이전트가 위치한 서버 클러스터가 자동 규모 확장이 가능하도록 설정되어 있다면

서버가 동적으로 추가되거나 삭제되는 과정에서 해당 데이터는 소실할 수도 있음.

 

지표 수집기 클러스터 자체도 자동 규모 확장이 가능하도록 구성하고 앞에 로드밸런서를 두는 것이 바람직함.

지표 수집기 서버 cpu 부하에 따라 자동으로 오토 스케일링 되도록 설정.

 

항목 Push 모델 Pull 모델
설정 복잡도 클라이언트 라이브러리와 Push Gateway 설정 필요 서버에 타깃 목록(서비스 디스커버리)만 등록하면 됨
방화벽·네트워크 클라이언트 → 서버 단방향 연결 (방화벽 허용이 비교적 간단) 수집기 → 클라이언트 양방향 연결 (많은 포트를 열어야 할 수 있음)
장애 복원력 네트워크 장애 시 데이터 손실 우려 (버퍼링 로직 필요) 장애 시 다음 스크랩 주기에 재시도 가능
보안 인증·암호화 구현이 자유롭지만, 전송 지점이 많아 관리 포인트 증가 한 곳에서 인증·TLS 설정 가능
확장성 고빈도 푸시 트래픽으로 수집 서버 부하 증가 가능 스크랩 주기·병렬 요청 수로 부하 제어 쉬움
임시·단발성 지표 애초에 푸시 트리거 가능 (예: 배치 작업 완료 이벤트) 대상 서버가 항상 가동 중이어야 스크랩 가능
디버깅   서버에 /metrics를 통해 확인 가능

 

선택 기준

 

  • Pull
    • 마이크로서비스가 많고 동적 서비스 디스커버리(쿠버네티스 등)를 활용할 때
    • 실시간 모니터링·알림을 위한 안정적 스크랩 주기가 중요할 때
  • Push
    • 단명(batch) 프로세스나 Lambda 함수처럼 항상 노출된 엔드포인트가 없는 경우
    • 방화벽으로 들어오는 트래픽을 최소화해야 할 때

 

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

시계열 데이터베이스에 장애가 생기면 데이터 손실의 가능성이 있으므로,

앞단에 카프카와 같은 스트림 처리 서비스를 두는 것이 좋음.

( 데이터 보관, 결합도 낮춤 )

카프카를 통한 규모 확장

  • 대역폭 요구사항에 따라 파티션의 수 설정
  • 지표 이름에 따라 어느 파티션에 배치할지 결정하면 소비자는 지표 이름에 따라 데이터 집계 가능
  • 태그/레이블에 따라 지표 데이터를 더욱 세분화한 파티션으로 나눈다
  • 중요 지표가 먼저 처리될 수 있도록 지표를 분류하고 우선순위를 지정한다.

 

카프카 대안

상용 규모의 카프카 시스템 구축은 쉽지 않음.

큐 없이도 대규모 데이터 처리가 가능한 모니터링 시스템이 있음.

페이스북의 메모리 기반 시계열 데이터베이스 시스템 고릴라가 주요 사례..

(깊게는 안보겠음..)

 

데이터 집계 지점

관점 구현 위치 핵심 기능 장점 단점
1. 수집 에이전트 애플리케이션 프로세스 1차 집계·버킷 계산 전송량 절감, 즉시성, 맥락 보존 서비스 부하, 설정 편차, 신뢰성 리스크
2. 데이터 수집 파이프라인 중간 데몬/Collector 처리해주는스트림 프로세싱 엔진 이벤트 수집 → 주기별 합산 오프로딩, 중앙관리, 재시도 운영 복잡도, SPOF(분산 쓰면 아님), 반영 지연
3. 질의 시 집계 TSDB + 대시보드/쿼리 엔진 원시 샘플 → 쿼리 시점 집계 유연성·정확성·복잡분석 지원 쿼리 성능 부담, 반복 비용, 저장소 요구

 

질의 서비스

사용자가 대시보드나 API를 통해 지표를 조회(쿼리)할 때, 시계열 데이터베이스(TSDB)나 메트릭 저장소로부터 데이터를 읽어와 집계·가공한 결과를 반환해 주는 “백엔드 서비스”

이런 질의 처리 전담 서비스를 두면 클라이언트(시각화 또는 경보 시스템)와 시계열 데이터베이스 사이의 결합도를 낮출 수 있음.

 

캐시 계층

질의 결과를 저장할 때 캐시 서버를 도입하면 시계열 데이터베이스에 대한 질의 부하를 낮추고 질의 서비스의 성능을 높일 수 있음.

 

시계열 데이터베이스 질의어

프로메테우스나 InfluxDB 같은 널리 사용되는 지표 모니터링 시스템들은 SQL이 아닌 독자 질의어를 제공.

(SQL로 짜기 어려운 것들이 많기 때문)

 

저장소 계층 상세

페이스북에서 내놓은 연구 논문에 따르면 운영 데이터 저장소에 대한 질의의 85%는 지난 26시간 내에 수집된 데이터를 대상으로 한다.

이 사실을 잘 활용하는 시계열 데이터베이스를 고르면 성능 측면에서 큰 이득을 볼 수 있음.

 

더보기

아래는 “최근 데이터(예: 마지막 26시간 이내)에 대한 조회가 대부분을 차지한다”는 패턴을 적극 활용해 **핫 데이터(hot data)**를 메모리나 빠른 스토리지에 올려두고, 콜드 데이터(cold data)는 저비용 디스크 계층에 보관하는 구조를 갖춘 대표적인 시계열 데이터베이스들입니다.

  • Gorilla
    • Facebook에서 연구·발표한 인메모리 시계열 DB
    • 지난 26시간 분량의 데이터를 메모리에 유지하고, 디스크 기반 영속 스토어를 캐시로 활용
    • 시계열 데이터 전용 XOR·델타-오브-델타 압축으로 메모리 사용량을 12배 이상 절감 VLDB
  • Beringei
    • Facebook이 오픈소스로 공개한 고성능 TSDB 엔진
    • 최근 24시간 분량의 데이터를 전부 메모리에 상주시켜 초당 백만 건 이상의 쓰기와 수십 마이크로초 수준의 읽기 지연 보장 Engineering at Meta
  • Prometheus
    • “헤드 블록(head block)”이라 불리는 최근 1–3시간 분량의 샘플을 메모리에 유지
    • WAL(Write‑Ahead Log)과 mmap된 청크를 이용해 메모리 사용을 최적화하고, 2시간 주기로 디스크 블록을 생성·압축 저장 Grafana LabsPrometheus
  • InfluxDB
    • 쓰기 시 WAL과 캐시(Cache)에 먼저 기록해, Cache + TSM 파일을 병합 조회
    • 인메모리 캐시는 메모리 한도를 넘어가면 자동 스냅샷 후 디스크로 플러시, 재시작 시 WAL로 복구
    • InfluxDB 3 Enterprise는 “Last Value Cache”로 최근 값만 별도 메모리 캐시해 조회 성능 가속 InfluxDataInfluxData
  • TimescaleDB
    • PostgreSQL 기반 하이퍼테이블 위에서 동작
    • Continuous aggregates(연속 집계) + Real-time aggregates로, 미리 계산된 집계와 최신 원시 데이터를 결합해 즉시성 있는 결과 제공 TigerData
  • VictoriaMetrics
    • 인메모리 버퍼와 페이지 캐시(page cache)를 활용해, 최근에 인제스트된 데이터에 대해 수 밀리초 내 응답
    • 오래된 블록은 디스크에 머무르되, 필요 시 메모리로 로드해 쿼리 성능을 유지 VictoriaMetrics
  • M3DB
    • 버퍼(buffer), 인메모리 캐시, 디스크 파일셋(fileset) 계층을 두어, 최근 읽힌 블록을 메모리에 일정 기간 보관하는 정책 제공
    • recently_read 캐시 정책으로, 디스크에서 읽은 블록을 configurable duration 동안 메모리에 유지 M3
  • QuestDB
    • 컬럼 지향(+Parquet) 스토리지와 SIMD 최적화를 통해, 인메모리 파티션과 디스크 파티션을 활용
    • 실시간(high‑throughput) 쓰기 및 저지연 SQL 쿼리를 위해 최근 데이터가 메모리에 머무르도록 설계 GitHub

이들 데이터베이스는 모두 “핫 데이터”를 메모리나 빠른 계층에 올려두고, “콜드 데이터”를 디스크나 오브젝트 스토리지에 장기 보관하는 티어드 스토리지(tiered storage) 구조를 갖추고 있어, 전체 데이터 볼륨 대비 성능과 비용 효율을 극대화합니다.

 

저장 용량 최적화

데이터 인코딩 및 압축을 통해 최적화를 할 수 있다.

대부분 이 기능을 내장하고 있음.

 

1610087371과 1610087381 간의 차이는 딱 10초만큼만 다른 값이며,

타임스탬프 하나를 온전히 표현하는 데는 32비트가 필요하지만 10을 표현하는데는 4비트면 충분하다.

 

이를 이용해 기준값과의 차이를 저장한다.

1610087371, 10, 10, 9, 11 과 같은 형태.

 

다운 샘플링

데이터의 해상도를 낮춰 저장소 요구량을 줄이는 기법.

본 설계안에 요구된 데이터 보관 기간은 1년이므로, 낡은 데이터는 해상도를 줄여도 된다.

 

  • 7일 이내 데이터: 샘플링 미적용
  • 30일 이내 데이터 : 1분 해상도로 낮춰 보관
  • 1년 이내 데이터 : 1시간 해상도로 낮춰 보관

저장 형태 (5분 간격 기준)

Interval Start Avg(Value) Max(Value) Min(Value)
2025-07-01 00:00:00 11.6 13 10
2025-07-01 00:05:00 14.4 16 13

 

 

  • Avg(Value) = 해당 5분 구간 내 값들의 산술평균
  • Max(Value) = 구간 내 최댓값
  • Min(Value) = 구간 내 최솟값

 

경보 시스템

경보 처리 흐름

1) 설정 파일을 가져와 캐시 서버에 보관.

경보 규칙은 디스크에 파일 형태로 보관하며, yaml 로 사용하여 대부분 저장.

 

2) 경보 관리자는 경보 설정 내역을 캐시에서 가져온다.

 

3) 설정된 규칙에 근거하여 경보 관리자는 지정된 시간마다 질의 서비스를 호출.

경보 관리자는 질의 결과가 임계값을 위반하면 경보 이벤트 생성.

 

그 외에도 경보 관리자는 다음과 같은 작업을 수행함.

  • 경보 필터링, 병합, 중복 제거 : 짧은 시간 내 같은 인스턴스에서 발생한 경보를 필터링, 병합, 중복 제거 처리 할 수 있음.
  • 접근 제어 : 경보 관리 작업은 반드시 특정한 개인만이 수행할 수 있도록 제한
  • 재시도 : 경보 상태를 확인하고 알림이 최소 한번은 전달됨을 보장

4) 경보 저장소는 카산드라 같은 형태의 키-값 저장소다.

모든 경보의 상태(비활성화, 응답 대기, 경보 발령, 문제 해결 등)가 여기 보관.

알림이 적어도 한 번 이상 전달되도록 보장되는 구실을 한다.

 

5) 경보 이벤트를 카프카에 전달

 

6) 경보 소비자는 카프카에서 경보 이벤트를 읽는다.

 

7) 경보 소비자는 읽은 경보 이벤트를 처리하여 이메일, 단문 메시지, http 서비스 엔드포인트 등의 다양한 채널로 알림을 전송.

 

경보 시스템은 이미 시장에 많고 잘 구현되어있으니, 이왕이면 구매해서 사용할 것.

 

시각화 시스템

지표를 시각화해서 보여주는 시스템.

현재 서버가 처리하고 있는 요청의 수, 메모리/cpu 사용률, 페이지 로드 시간, 트래픽 양, 로그인 현황 등의 지표 정보를 표시하는 대시보드 사례.

 

마찬가지로 상용화된 시스템을 이용하는 편이 좋음.

 

최종안

 

 

 

저작자표시 비영리 변경금지 (새창열림)