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

1단계: 설계 범위

1. 개략적 요구사항

• 대규모 인프라를 모니터링
  • 일간 활성 사용자수(DAU, Daily Active Users)는 1억 명
  • 서버 풀 1,000개, 풀당 서버 수 100개.
  • 데이터 보관 기간 1년
  • 수집한 데이터를 보관하는 기간은 일주일, 그 뒤에는 1분 단위 데이터로 변환 후에 30일간 보관, 그 뒤에는 1시간 단위 데이터로 변환한 뒤에 1년간 보관
• 모니터링할 지표
  • CPU 사용률
  • 요청 수
  • 메모리 사용량
  • 메세지 큐 내의 메세지 수

2. 비기능 요구사항

• 규모 확장성: 늘어나는 지표 수와 경보의 양에 맞게 확장될 수 있어야 한다.
• 낮은 응답 지연:대시보드와 경보를 신속하게 처리할 수 있도록, 질의에 대한 낮은 응답 지연 보장
• 안정성: 높은 안정성을 제공하여 중요 경보를 놓치지 않도록 해야 한다.
• 유연성: 기술은 계속 변화하므로, 신기술을 통합할 수 있도록 변경 가능한 파이프라인을 이용해 구축

2단계: 개략적 설계안

1. 기본적 사항

지표 모니터링 및 경보시스템은 일반적으로 다섯 가지 컴포넌트를 이용한다.

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

2. 데이터 모델

• 지표 데이터는 통상 시계열(time series) 데이터 형태로 기록한다.
• 값 집합에 타임스탬프가 붙은 형태로 기록한다. 
• 시계열 각각에는 고유한 이름이 붙고 선택적으로 레이블을 붙이기도 한다.

사례1

서버 인스턴스 i631의 20:00 시점의 CPU 부하를 알고 싶다.

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

사례2

지난 10분간 us-west 지역에 위치한 모든 웹 서버의 CPU 부하 평균값은 얼마인가?

 

지표 이름이 CPU.load이고 레이블에 포함된 지역 이름이 us-west인 데이터 저장소에서 가져온다.

 

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

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

CPU.load host=webserver01, region=us-west 1613707265 43

...

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

 

각 행의 마지막에 기록된 CPU부하 수치의 평균을 구하면 된다.

이름	자료형
지표 이름	문자열
태그/레이블 집합	<키:값> 쌍의 리스트
지표 값 및 그 타임스탬프의 배열	<값, 타임스탬프> 쌍의 배열

3. 데이터 접근 패턴

• 해당 시스템에 대한 쓰기 부하가 막대하다.
• 시점을 막론하고 많은 시계열 데이터가 기록될 수 있다.
• 개략적 요구사항에서 보면 매일 천만 개 운영지표가 기록되기 때문에 지표 발생 빈도가 높고 트래픽은 단연 쓰기가 압도적이다.
• 읽기 부하는 일시적으로 치솟았다 사라지는 편이다.

4. 데이터 저장소 시스템

데이터 저장소 시스템이 본 설계안의 핵심이다.

• 범용 데이터베이스
  • 이론적으로는 시계열 데이터를 처리할 수 있지만 부하 규모에 맞추려면 전문가 수준의 튜닝이 필요하다.
  • 시계열 데이터를 대상으로 수행하는 연산에 최적화 되어 있지 않다.
  • 많은 양의 쓰기 연사이 지속적으로 발생하는 환경에서는 좋은 성능을 보여주기 어렵다.
• NoSQL
  • 시계열 데이터를 효율적으로 처리할 수 있다고 알려진 카산드라, 빅테이블 등이 있다.
  • 효과적으로 저장하고 질의하기 위해서는 확장이 용이한 스키마 설계가 필요한데 그러기 위해서는 해박한 지식이 필요하다.
  • 기업에 필요한 규모를 지원하는 시계열 데이터베이스가 있기 때문에 매력적인 방안이 아니다.
• OpenTSDB
  • 분산 시계열 데이터베이스이지만 하둡과 HBase에 기반하고 있어 하둡/HBase 클러스터를 구성하고 운영해야한다.
• X(구 트위터)는 MetricsDB를 사용, 아마존은 타임스트림이라는 제품을 출시
• 가장 인기 있는 InfluxDB와 프로메테우스 이다.
  • 다량의 시계열 데이터를 저장하고 빠른 실시간 분석을 지원하는 것이 특징이다.

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

• InfluxDB는 레이블 기반의 신속한 데이터 질의를 지원하기 위해 레이블별로 인덱스를 구축한다.
• 레이블을 이용할 때 데이터베이스 과부하를 피하는 지침도 제공한다.
• 핵심은 각 레이블이 가질 수 있는 가짓수(cardinality)가 낮아야 한다는 것이다.
• 해당 기능은 데이터 시각화에 특히 중요하며, 범용 데이터베이스로 구축하기 매우 까다롭다.

5. 개략적 설계안

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

 

3단계: 상세 설계

1. 지표수집

1) 풀 VS 푸시 모델

 

풀 모델

• 실행 중인 애플리케이션에서 주기적으로 지표 데이터를 가져오는 지표 수집기가 흐름의 중심이다.
• 지표 수집기는 데이터를 가져올 서비스 목록을 알아야 한다.
• 서버가 수시로 추가/삭제되는 대규모 운영 환경에는 적용하기 어렵다.
  • etcd나 아파치 주키퍼 같은 서비스 탐색 기술을 활용하면 해결할 수 있다.
• 수천 대 서버가 만들어 내는 지표 데이터를 수집하려면 서버 한대로는 부족하다.
• 지표 수집기 서버를 여러 대 둘 때 흔히 빚어지는 문제는 데이터를 중복해서 가져온다.
  • 해당 문제를 해결하기 위해 중재 메커니즘이 존재하는데 안전 해시링이 있다.

푸시 모델

• 푸시 모델은 지표 출처에 해당하는 서버, 즉 웹 서버나 데이터베이스 서버 같은 서버가 직접 지표를 수집기에 전송하는 모델이다.
• 푸시 모델의 경우, 모니터링 대상 서버에 통상 수집 에이전트라고 부르는 소프트웨어를 설치한다.
  • 수집 에이전트는 장비에서 실행되는 서비스가 생상하는 지표 데이터를 받아 모은 다음 주기적으로 수집기에 전달한다.
• 데이터 집계는 수집기에 보내는 데이터의 양을 줄이는 효과적인 방법이다.
• 지표 수집기가 밀려드는 지표 데이터를 제때 처리하지 못하는 일을 방지하려면, 지표 수집기 클러스터 자체도 자동 확장이 가능하도록 구성해야하고 앞에 로드밸런서를 두는 것이 바람직하다.

풀 모델 VS 푸시 모델 장단점 비교

• 풀 모델은 프로메테우스
• 푸시 모델은 아마존 클라우드와치, 그래파이트 등이 있다.

 

디버깅 - 풀모델

상태  진단 - 풀모델

생존 기간이 짧은 프로세스 - 푸시 모델

복잡한 네트워크 구성 - 푸시 모델

성능 - 풀은 TCP / 푸시는 UDP

데이터 신빙성 - 풀 모델은 수집한 데이터는 믿을 수 있다 / 푸시는 아무나 보낼 수 있어 문제가 있지만 인증을 강화하면 해결할 수 있다.

 

풀 모델과 푸시 모델 가운데 무엇이 나은지 논쟁은 정답이 없다.

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

지표 수집기는 지표 데이터를 카프카와 같은 큐 시스템에 전송한다.
(풀/ 푸시 모델 가운데 무엇을 채택할지 여부는 관계 없다.)

 

아파치 스톰이나 플링크, 스파크 같은 스트림 처리 서비스가 해당 데이터를 받아 시계열 데이터베이스에 저장한다.

 

스트림 처리 서비스가 해당 데이터를 받아 저장하면 좋은 장점

• 카프카는 고도로 안정적이고 규모 확장성이 뛰어난 분산 메세지 플랫폼
• 데이터 수집 컴포넌트와 처리 컴포넌트 사이의 결합도를 낮출 수 있다.
• 데이터 베이스에 장애가 생겨도 소실되지 않는다.
  (카프카에 보관해 두면 된다.)

카프카를 통한 규모 확장

카프카에 내장된 파티션 메커니즘을 사용하면 시스템의 규모를 다양한 방법으로 확장할 수 있다.

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

 

카프카의 대안

• 카프카 시스템 구축은 쉽지 않다.
• 큐 없이도 대규모 데이터 처리가 가능한 모니터링 시스템이 있다.
  (ex. 페이스북의 메모리 기반 시계열 데이터베이스 시스템 고릴라) 
• 이러한 시스템을 쓴다면 카프카 같은 메세지 큐가 없어도 같은 수준의 안전성을 제공할 수 있다.

3. 데이터 집계 지점

• 수집 에이전트가 집계하는 방안
  • 클라이언트에 설치된 수집 에이전트는 복잡한 집계 로직은 지원하기 어렵다. 
• 데이터 수집 파이프라인에서 집계하는 방안
  • 데이터를 저장소에 기록하기 전에 집계할 수 있으려면 플링크 같은 스트림 프로세싱 엔진이 필요
  • 기록되는 양이 엄청나게 줄어들겠지만, 원본 데이터를 보관하지 않기 때문에 정밀도나 유연성 측면에서 손해를 보게 된다.
• 질의 시에 집계하는 방안
  • 데이터를 날것 그대로 보관한 다음 질의할 때 필요한 시간에 맞게 집계한다.
  • 데이터 손실 문제는 없으나 질의 처리하는 순간에 전체 데이터 세트를 대상으로 집계 결과를 계산해야 하므로 속도는 느리다.

4. 질의 서비스

질의 서비스는 질의 서버 클러스터 형태로 구현되며, 시각화 또는 경보 시스템에서 접수된 요청을 시계열 데이터베이스를 통해 처리하는 역할을 담당한다.

 

클라이언트와 시계열 데이터베이스 사이의 결합도를 낮출 수 있다.

 

캐시 계층

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

 

질의 서비스를 두면 곤란한 경우

• 상용 시각화 및 경보 시스템은 시장에서 널리 사용되는 시계열 데이터베이스와의 연동을 처리하는 강력한 플러그인을 이미 갖추고 있는 경우가 많다.
• 별도 캐시를 도입할 필요가 없는 시계열 데이터베이스가 있다는 것도 고려 사항이다.

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

• 프로메테우스나 InfluxDB 같은 널리 사용되는 지표 모니터링 시스템들은 SQL이 아닌 독자 질의어를 제공한다.
• 시계열 데이터는 SQL로는 질의하기가 까다롭다.

4. 저장소 계층

시계열 데이터베이스는 신중하게 선택할 것

• 페이스북에서 내놓은 연구에 따르면 데이터 저장소에 대한 질의의 85%는 지난 26시간 내에 수집된 데이터를 대상으로 한다.
• 해당 사실을 활용하는 시계열 데이터베이스를 고르면 성능 측면에서 이득을 볼 수 있다.

저장 용량 최적화

지표 모니터링 시스템에 저장할 데이터의 양은 막대하다.

해당 문제를 공략하는 몇 가지 전략

 

1) 데이터 인코딩 및 압축

• 데이터를 인코딩하고 압축하면 크기를 상당히 줄일 수 있다.

2) 다운 샘플링

• 데이터의 해상도를 낮춰 저장소 요구량을 줄이는 기법이다.
• 설계안에 요구된 데이터 보관 기간은 1년이므로, 낡은 데이터는 해상도를 줄인다.
  • 7일 이내 데이터: 샘플링을 적용하지 않는다.
  • 30일 이내 데이터: 1분 해상도로 낮춰 보관한다.
  • 1년 이내 데이터: 1시간 해상도로 낮춰 보관한다.

3) 냉동저장소

• 잘 사용되지 않는 비활성 상태 데이터를 보관하는 곳이다.
• 내동 저장에 드는 비용은 일반 저장소에 비해 훨씬 낮다.

5. 경보 시스템

1. 설정 파일을 가져와 캐시 서버에 보관한다.
   YAML을 널리 사용한다.
2. 경보 관리자는 경보 설정 내역을 캐시에서 가져온다.
3. 설정된 규칙에 근거하여 경보 관리자는 지정된 시간마다 질의 서비스를 호출한다.
   
   • 질의 결과가 설정된 임계값을 위반하면 경보 이벤트를 생성한다.
4. 경보 저장소는 카산드라 같은 형태의 키-값 저장소다.
5. 경보 이벤트를 카프카에 전달한다.
6. 경보 소비자는 카프카에서 경보 이벤트를 읽는다.
7. 경보 소비자는 다양한 채널로 알림을 전송한다.

경보 시스템 - 만들 것인가 구매할 것인가

• 기업이 필요로 하는 규모를 바로 지원 가능한 경보 시스템은 시장에 많다.
• 유명 시계열 데이터베이스와 통홥되어 있고 다양한 알림 채널을 지원한다.
• 경보 시스템을 밑바닥 부터 구현하겠다는 아이디어는 수용하기 어렵다.

6. 시각화 시스템

• 지표 대시보드에는 지표를 다양한 시간 범위로 표시한다.
• 경보 대시보드에는 다양한 경보의 상태를 표시한다.
• 품질 좋은 시각화 시스템은 구현하기 어렵기 댸문에 그라파나 같은 사용품을 구입해서 사용하는 주장이 바람직하다.

4단계: 마무리

집중적으로 살펴본 컴포넌트

• 지표 데이터 수집 모델: 풀 모델 vs 푸시 모델
• 카프카를 활용한 규모 확장 방안
• 최적 시계열 데이터베이스의 선정
• 다운샘플리을 통한 데이터 크기 절감
• 경보/시각화 시스템: 구현할 것인가 구입할 것인가