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

시계열 데이터

시간에 따라 변화하는 데이터를 다루는 데이터 유형으로, 주로 시간 순서가 중요한 데이터

 

시계열 데이터 저장소

• 많은 양의 쓰기 연산 부하
• 읽기 연산의 부하는 잠시 급증하는 정도

1. 쓰기 연산이 항상 많은 경우

문제점

1. 관계형 데이터베이스 (RDBMS):
   • 트랜잭션 처리 오버헤드:
     • RDBMS는 ACID 특성을 보장하기 위해 쓰기 작업마다 트랜잭션을 처리합니다. 이로 인해 데이터 삽입 속도가 느림
   • 스키마 설계 제약:
     • 시계열 데이터는 빠르게 증가하기 때문에, 인덱스가 방대해지고 조인 연산이 많아지면 쓰기 성능이 저하
   • 확장성 부족:
     • 수평 확장(Sharding)이 어렵기 때문에, 데이터 양이 급격히 증가하면 확장 비용이 높음
2. NoSQL:
   • 쓰기 성능의 제약:
     • NoSQL(예: MongoDB, Cassandra)은 쓰기 성능이 좋지만, 대량의 쓰기 작업에서 인덱싱 비용이 높음
   • 디스크 I/O 증가:
     • 대량 쓰기 작업 시 디스크 I/O가 병목이 되어 성능 저하를 초래할 수도

2. 읽기가 특정 시간에 몰리는 경우

문제점

1. 관계형 데이터베이스 (RDBMS):
   • 읽기 병목:
     • 복잡한 질의
     • join
   • 인덱스 비효율성:
     • 대규모 시계열 데이터에서 시간 기반 쿼리(예: WHERE timestamp BETWEEN ...)는 범위 검색이 많아져 인덱스 성능이 저하될 수 있습니다.
     • 인덱스를  검색하려는 모든 값에 걸 수 없음
     • 튜닝 한계
2. NoSQL:
   • 읽기 쿼리 제약:
     • 시계열 데이터를 읽을 때, 복잡한 필터링 및 집계 작업이 필요하면 NoSQL 시스템에서는 추가적인 애플리케이션 레벨의 처리가 필요
   • 읽기 집중 시 과부하:
     • MongoDB와 같은 NoSQL 시스템은 읽기 요청이 급증할 경우, 캐싱 및 클러스터 확장이 충분하지 않으면 병목이 발생할 수도

 

시계열 데이터베이스(TSDB)(예: InfluxDB, TimescaleDB)는 쓰기/읽기 최적화, TTL, 시간 기반 쿼리 등 시계열 특화 기능으로 적합

시계열 데이터베이스(TSDB)가 적합한 이유

1. 쓰기 최적화:
   • TSDB는 쓰기 작업을 빠르게 처리하도록 설계
   • 압축 기술: 데이터 크기를 줄이고 저장 효율을 높임.
   • Batch Writing: 쓰기 작업을 배치 처리로 최적화.
2. 읽기 최적화:
   • 시간 기반 쿼리 최적화: 타임스탬프 기반 필터링 및 집계가 빠르게 동작.
   • 전용 인덱스: 시계열 데이터를 효율적으로 검색하도록 설계된 고유 인덱스 구조.
     • 레이블(태그) 별로 인덱스
3. 자동 데이터 관리:
   • Retention Policy(TTL): 오래된 데이터를 자동으로 삭제하여 저장 공간을 관리.
   • Downsampling: 오래된 데이터를 요약 데이터로 변환(예: 1초 단위 -> 1시간 평균).
4. 확장성:
   • TSDB는 수평 및 수직 확장이 용이하며, 대량의 데이터를 처리하는 데 최적화됨.
5. 예: InfluxDB, TimescaleDB, Prometheus, OpenTSDB

 

풀 vs 푸시

• 풀: 지표수집기가 주기적으로 지표를 요청하여 데이터를 가져옴
  • 서비스 디스커버리를 사용하여 수집해야 할 서버정보와 메타 데이터를 관리
  • 지표 수집기가 서비스 디스커버리로부터 목록을 확보하여 http로 데이터를 가져옴
  • 지표 수집기도 여러대(서버풀)준비해야 할텐데 여러 지표 수집기가 같은 서버를 찌르지 않도록 consistent hash ring 구조로 담당 서버를 지정하면 특정 서버 지표는 항상 하나의 수집 서버가 처리함을 보장할 수  있다.
  • 프로메테우스
• 푸시: 서버기 지표 수집기를 호출하여 데이터 전송
  • 푸시 모델의 지표 수집기가 밀려드는 지표 데이터를 제 때 처리하지 못하면 일시적으로 버퍼(메모리/디스크 등)에 저장하여 재전송할 수도 있겠지만 서버가 동적으로 추가/삭제되는 과정에서 데이터가 소실될 수 있다.
  • 따라서 지표 수집기 클러스터 자체도 자동 규모 확장이 가능하게 구성하고 그 앞에 로드밸러서를 두는게 좋다.

 

카프카를 통한 규모 확장

• 시계열 데이터 베이스 앞에 카프카를 두어 디비가 죽어도 데이터가 소실되지 않게 함
• 지표의 태그/레이블에 따라 토픽/파티션으로 세분화 가능

 

집계(통계화) 시점

• 데이터 저장 전에 집계한다면 스트림 프로세싱 엔진이 필요할거고 저장양이 줄긴하지만 원본데이터를 저장하지 않으니 유연성이 좋지 않다
• 저장하고 조회 시 집계한다면 전체 대상으로 계산해야해서 속도가 느리다

 

질의 서비스

• 캐시 고려
• 질의 서비스를 안두고 바로 시계열 디비와 연동하는 경우도 있음

 

저장소

• 저장 용량 최적화 필요
• 데이터 인코딩 및 압축
• 다운 샘플링: 기간별 해상도를 낮춰서 보관
  • 예를 들어 2주는 원본 한달이내 1분단위로 집계한 데이터 1년 이내 1시간으로 집계한 데이터 등..(해상도를 낮춘다고 표현)
• cold storage: 저장 위치를 아애 옮겨버림 nas 같은 곳으로..

 

경보 시스템

• 경보 규칙을 설정파일로 저장하고 캐시화
• 규칙에 따라 질의 서비스 호출해서 계산하고 설정 임계값을 위반하면 경보 이벤트 생성
• 경보 저장소: 키-값 저장소; 모든 경보의 상태 저장; 알림이 적어도 한번은 전달되도록 보장
• 경보 이벤트는 카프카로
• 해당 메세지를 읽어 다양한 채널로 알림 전송