[시스템 디자인] 05. 지표 모니터링 및 경보 시스템

시스템 디자인 시리즈의 글입니다.

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

1. 문제 이해 및 설계 범위 확정

기능 요구사항

• 대규모 인프라를 모니터링해야함
  • DAU 100m
  • 서버풀 1,000개 x 풀당 서버수 100개 x 서버당 100개 운영지표 수집 = 지표 10m
  • 데이터보관기간 1년
  • 그대로보관 7일 → 1분단위 30일 보관 → 1시간단위 1년 보관 (해상도resolution을 낮춰감)
• 모니터링할 지표
  • CPU 사용률
  • request 수
  • 메모리사용량
  • 메세지 큐 내의 메세지 수

비기능 요구사항

• 규모확장성
• 낮은 응답지연
• 안정성
• 유연성

2. 개략적 설계안 제시 및 동의

기본적 사항

• 데이터 수집
• 데이터 전송
• 데이터 저장소
• 경보
• 시각화

데이터 모델

지표데이터 = 시계열(tiem series) 데이터

• metric name
• tag/label
• timestamp
• value

데이터 접근 패턴

• 쓰기 : 매우 많음
• 읽기: spiky한 편. (일시적으로 치솟는형태)

데이터 저장소 시스템

• 지표모니터링시스템의 핵심.
• 직접 설계하거나 RDB같은 범용 저장 시스템을 사용하는것은 추천X
• NoSQL의 경우, 시계열데이터를 처리하려면 확장이 용이한 스키마를 설계해야하는데 NoSQL 내부에 대한 깊은 이해 필요. → 비추천
• 시계열데이터에 최적화된 저장소 시스템이 시장에 많이 나와있음.
  • 시계열 데이터 분석에 적합
  • 질의 인터페이스를 갖추고있음
  • OpenTSDB : 하둡/HBase기반 (복잡)
  • InfluxDB, 프로메테우스
    • 가장 인기있는 시계열 데이터베이스
    • 다량의 시계열 데이터 저장
    • 빠른 실시간 분석 지원
    • 메모리캐시 + 디스크 저장소 함꼐 사용
    • 용속성 + 높은 성능.
  • 레이블기준으로 집계, 분석하는 기능 제공

개략적 설계안

• 지표출처 : 지표가 만들어지는곳.
• 지표 수집기: 지표데이터 수집 후 시계열 데이터를 기록
• 시계열 데이터베이스 : 지표데이터를 시계열 데이터 형태로 보관
• 질의서비스 : 시계열 데이터베이스에 보관된 데이터에 질의하고 결과를 가져옴
• 경보시스템 : 경보를 받아야하는 대상에 경보알림 전송
• 시가고하 시스템 : 지표를 다양한 형태의 그래프 / 차트로 시각화

3. 상세설계

지표수집

• 때때로 데이터가 소실되어도 ㅇㅋ
• 클라이언트는 성공적으로 데이터가 전송되었는지 신경 안써도됨

풀(pull) 모델

• 실행중인 애플리케이션에서 지표수집기가 주기적으로 지표데이터를 땡겨옴
• 지표수집기는 땡겨올 서비스의 엔드포인트정보를 알아야함
• 따라서 서버가 수시로 추가/삭제되는 대규모 운영환경에서는 어려움
• etcd나 아파치 주키퍼같은 서비스탐색기술에서 엔드포인트 정보를 받아와야함
• 클라에서는 지표수집기가 땡겨올 api 뚫어둬야함 (ex. /metrics )
• 여러서버가 같은 출처에서 데이터를 중복해서 가져올 가능성이 존재. → 안정해시링 구조 사용해야함
• 프로메테우스가 풀모델

푸시(push)모델

• 지표출처에 해당하는 서버가 직접 지표를 수집기에 전송
• 수집에이전트(agent) 소프트웨어 설치
• 지표데이터를 모아 주기적으로 수집기에 전달
• 에이전트가 직접 데이터 집계(aggregation)을 하기도함
• 일시적 문제가 생기면 버퍼에 보관했다가 재전송할수있음
• autoscaling서버에서는 서버가 추가/삭제시 데이터 일부 소실될수도있음
• 지표수집기 클러스터도 스케일링되므로 앞에 로드밸런서를 두는게 좋음
• 클라우드와치, 그라파이트가 푸쉬모델

풀모델 vs 푸시모델

• 손쉬운 디버깅 : pull
• 상태진단 : pull
• lifecycle짧은 프로세스 : push
• 방화벽등 복잡한 네트워크 구성 : push
• 성능 : push (UDP사용)
• 데이터신빙성 : pull

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

• 지표수집기는 트래픽 높은 서비스이므로 규모확장이 가능해야함.
• 데이터베이스에 장애가생기면 데이터손실 발생가능
• 큐(카프카)를 두면 해당 문제를 해소할 수 있음
  • 데이터 수집 컴포넌트와 처리 컴포넌트 사이 결합도를 낮춤
  • 데이터베이스 장애가생겨도 데이터가 손실되지않음
  • 파티션 메커니즘을 사용해 시스템 규모를 다양한 방법으로 확장 가능

데이터 집계 지점

• 수집 에이전트가 집계
• 데이터 수집 파이프라인에서 집계
  • 스트림 프로세싱 엔진 필요
  • 늦게도착하는 지표 데이터는 누락됨
  • 원본데이터를 보관하지 않아 정밀도, 유연성 손해
• 질의 시에 집계
  • 데이터손실문제가 없음
  • 질의 처리 순간에 계산해야해서 속도가 느림

질의 서비스

• 질의서버 클러스터 형태로 구현
• 접수된 요청을 시계열 데이터베이스를 통해 처리
• 클라-시계열DB간 결합도를 낮춤
• 시계열DB를 자유롭게 교체 가능
• 질의결과를 캐시하면 성능을 높일수있음
• SQL말고 독자 질의어를 제공

저장소 계층

• 시계열 DB 신중하게 선택
  • 85% 질의는 26시간 내 수집된 데이터 대상.
  • 이를 잘 활용하는 DB를 골라야 성능면에서 이득
• 저장용량 최적화
  • 데이터 인코딩 및 압축
  • 다운샘플링
  • 냉동저장소

경보시스템

• 경보설정을 캐시서버에 보관
• 설정을 캐시에서 가져옴
• 지정되 ㄴ시간마다 질의해 threshold를 넘으면 경보이벤트 생성
  • 경보필터링, 병합, 중복제거
  • 접근제어
  • 재시도
• 경보이벤트 카프카 전달
• 경보소비자는 이벤트를 처리 (alert)

경보시스템은 밑바닥부터 구현하기보다는 시장에 성숙된 시스템을 구매해서 쓰는걸 추천

시각화시스템

• 데이터계층 위에 만들어짐
• 대시보드에서 다양한 시간범위로 지표 표시
• 경보상태 표시 마찬가지로 상용품을 쓰는것을 추천