Chapter 5

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

  • 5.1 문제 이해 및 설계 범위 확정
  • 5.2 개략적 설계안 제시
  • 5.3 상세 설계
  • 5.4 마무리

지표 모니터링 및 경보 시스템은 서버 CPU 사용률, 요청 지연시간, 에러율 같은 운영 지표를 수집하고, 이상이 감지되면 알림을 보내는 시스템이야. Datadog, Prometheus + Grafana 같은 도구가 하는 일을 밑바닥부터 설계해 보는 거지.

모니터링 시스템이 다루는 지표는 크게 세 종류야.

  • 인프라 지표 — CPU, 메모리, 디스크 사용률 등
  • 애플리케이션 지표 — 요청 수, 지연시간(p99), 에러율 등
  • 비즈니스 지표 — DAU, 매출, 전환율 등

핵심 기능은 두 가지지.

  • 지표 수집 및 저장 — 수십만 대의 서버에서 초당 수백만 건의 지표 데이터를 수집하고 저장
  • 경보(Alert) — 사전에 정의한 조건(임계값 초과 등)이 충족되면 슬랙, 이메일, PagerDuty 등으로 알림 발송

비기능 요구사항은 확장성(지표 소스가 늘어나도 처리 가능), 낮은 지연시간(실시간에 가까운 모니터링), 내구성(데이터 유실 방지)이야.

전체 흐름은 수집 → 전송 → 저장 → 질의 → 시각화 → 경보 이 파이프라인이야.

모니터링 지표는 본질적으로 시계열(time-series) 데이터야. 각 데이터 포인트는 (지표 이름, 태그, 타임스탬프, 값) 형태지.

예시: cpu.usage host=server01 region=us-east 1640000000 78.5

특징은 이래.

  • 쓰기가 압도적으로 많아. 수만 대의 서버가 계속 지표를 보내거든
  • 최근 데이터가 자주 조회돼. "최근 1시간 CPU 사용률" 같은 질의가 대부분이지
  • 오래된 데이터는 정밀도를 낮춰도 돼. 1개월 전 데이터를 초 단위로 볼 필요는 없으니 1분 또는 1시간 평균으로 다운샘플링하면 되고

일반적인 RDBMS로 시계열 데이터를 저장하면 성능이 나오지 않아. 시계열에 최적화된 DB가 따로 있지 — InfluxDB, Prometheus, TimescaleDB 등.

시계열 DB의 핵심 최적화를 보면:

  • 시간 기반 파티셔닝 — 최근 데이터와 오래된 데이터를 분리
  • 높은 쓰기 처리량 — 배치 쓰기, 압축 등
  • 시간 범위 쿼리 최적화 — 특정 시간 범위의 데이터를 빠르게 조회
  • 자동 다운샘플링 — 오래된 데이터의 정밀도를 자동으로 낮춤

지표 수집에는 두 가지 방식이 있어.

Pull 모델 — 모니터링 서버가 각 대상 서버를 주기적으로 폴링해서 지표를 가져와. Prometheus가 이 방식이지. 장점은 모니터링 대상이 수집 시스템을 몰라도 되고, 수집 주기를 중앙에서 제어할 수 있어. 단점은 대상 서버가 많으면 폴링 부하가 커지지.

Push 모델 — 각 서버에 설치된 에이전트가 지표를 수집 서버로 보내. 장점은 서버가 자기 지표를 능동적으로 전송하니까, 방화벽 뒤의 서버도 문제없어. 단점은 에이전트를 모든 서버에 설치해야 하고, 수집 서버의 주소를 알아야 하지.

어느 모델이든 대규모에서는 지표 데이터가 엄청나니 카프카 같은 메시지 큐를 중간에 두는 게 일반적이야. 수집기가 카프카에 넣고, 저장 서비스가 카프카에서 꺼내서 시계열 DB에 저장하는 구조. 이러면 수집과 저장이 분리되어 각각 독립적으로 확장 가능하지.

초 단위로 들어오는 원시 데이터를 전부 저장하면 스토리지 비용이 어마어마해. 보통 여러 단계로 집계하지.

  • 원시 데이터 → 7일 보관
  • 1분 단위 집계 → 30일 보관
  • 1시간 단위 집계 → 1년 보관

집계는 쓰기 시점에 할 수도 있고, 질의 시점에 할 수도 있어. 쓰기 시점 집계는 저장 공간을 아끼지만 원시 데이터를 잃지. 질의 시점 집계는 원시 데이터를 유지하지만 질의가 느려질 수 있고. 실전에서는 둘을 조합하는 경우가 많아.

대시보드나 경보 시스템이 사용하는 질의 인터페이스가 있어야 해. "지난 1시간 동안 region=us-east인 서버들의 평균 CPU 사용률" 같은 질의를 처리하지.

캐싱이 중요해 — 대시보드에서 같은 쿼리를 여러 사람이 동시에 조회하니까. 질의 결과를 캐시하면 시계열 DB 부하를 크게 줄일 수 있어.

경보의 구조는 이래.

규칙 관리 — 경보 규칙을 설정 파일이나 DB에 저장해. 예: "CPU 사용률이 90% 이상으로 5분 이상 유지되면 경보".

경보 평가 — 규칙 평가 서비스가 주기적으로 시계열 DB를 질의해서 조건을 확인해. 조건이 충족되면 경보 이벤트를 생성하지.

알림 전송 — 경보 이벤트를 슬랙, 이메일, PagerDuty 등으로 전송해. 여기서 중요한 건 중복 방지와 알림 피로(alert fatigue) 관리야.

중복 방지는 같은 경보를 여러 번 보내지 않는 거야. 경보 상태(firing, resolved)를 관리해서 이미 firing 중인 경보는 다시 보내지 않지.

알림 피로는 경보가 너무 많으면 사람이 무감각해지는 문제야. 경보 억제(suppression), 그룹핑, 심각도 분류 등으로 관리하지.

Grafana 같은 대시보드 도구가 질의 서비스의 API를 호출해서 차트를 그려. 시스템 설계에서 시각화 레이어는 보통 깊이 다루지 않지만, 질의 API가 대시보드 도구와 호환되는 형식으로 데이터를 반환해야 한다는 점은 짚고 넘어가야 해.

모니터링 시스템은 모든 대규모 서비스의 눈과 귀야. 장애를 빠르게 감지하고, 시스템의 건강 상태를 한눈에 파악하게 해주지. 시계열 DB가 핵심 기술이고, 카프카로 수집과 저장을 분리하는 패턴은 6장(광고 클릭 이벤트 집계)에서도 그대로 등장해.

정리

5장 읽고 기억할 거 세 가지:

  1. 모니터링 지표는 시계열 데이터이고, 시계열 DB가 이를 효율적으로 처리해. 시간 기반 파티셔닝, 다운샘플링, 높은 쓰기 처리량이 핵심이지.
  2. 수집과 저장 사이에 카프카를 두면 두 계층을 독립적으로 확장할 수 있어. Pull/Push 방식 모두 대규모에서는 이 패턴이 필요하지.
  3. 경보 시스템은 규칙 평가, 중복 방지, 알림 피로 관리가 핵심이야. 경보가 너무 많으면 없는 것만 못하니까 억제와 그룹핑이 중요하지.