•
잘 설계된 지표 모니터링 및 경보 시스템은 인프라의 상태를 선명하게 볼 수 있도록 하여 높은 가용성과 안정성을 달성하는데 중추적 역할을 한다.
1단계: 문제 이해 및 설계 범위 확정
•
요구사항 가정
◦
회사 내부에서 사용할 시스템
◦
시스템 운영 지표를 수집한다. CPU 부하, 메모리 사용률, 디스크 사용량같은 저수준 지표부터 서버가 초당 처리하는 요청 수나 웹 서버 프로세스 개수같은 고차원적 개념 지표일 수 있다.
◦
일간 능동 사용자 수는 대략 1억명, 1000개의 서버 풀이 존재하며 풀마다 100개의 서버 하드웨어를 유지한다.
◦
지표 데이터는 1년 동안 보관한다.
◦
데이터를 장기 보관 전용 저장소로 옮길 때 지표의 해상도를 낮추어도 괜찮다.
◦
경보 채널로는 이메일, 전화, 페이저듀티, 웹훅 등을 지원한다.
◦
에러 로그나 액세스 로그 등에 대한 수집 기능은 지원하지 않는다.
◦
분산 시스템 추적 기능은 필요하지 않다.
개략적 요구사항 및 가정
•
대규모 인프라를 모니터링해야 한다.
◦
일간 능동 사용자 수 1억 명
◦
서버 풀 1,000개, 풀당 서버 수 100개, 서버당 대략 100개의 지표를 수집한다면 10,000,000 정도의 지표를 수집함
◦
데이터 보관 기간은 1년
◦
원본 데이터의 보관 기간은 일주일, 그 뒤에는 1분 단위 데이터 변환 후 30일 간 보관, 그 뒤에는 1시간 단위로 바꾸어 1년간 보관
•
모니터링할 데이터 예시
◦
CPU 사용률
◦
요청 수
◦
메모리 사용량
◦
메시지 큐 내의 메시지 수
비기능 요구사항
•
규모 확장성 : 시스템은 늘어나는 지표 수와 경보의 양에 맞게 확장될 수 있어야 한다.
•
낮은 응답 지연 : 대시보드와 경보를 신속하게 처리할 수 있도록 질의에 대한 낮은 응답 지연을 보장해야 한다.
•
안정성 : 높은 안정성을 제공하여 중요 경보를 놓치지 않도록 해야 한다.
•
유연성 : 기술은 계속 변화하므로 미래의 신기술을 쉽게 통합할 수 있도록 유연하게 변경 가능한 파이프라인을 이용해 구축한 시스템이어야 한다.
2단계: 개략적 설계안 제시 및 동의 구하기
기본적 사항
•
지표 모니터링 및 경보 시스템은 일반적으로 다섯 가지 컴포넌트를 사용한다.
◦
데이터 수집 : 여러 출처로부터 지표 데이터를 수집한다.
◦
데이터 전송 : 지표 데이터를 지표 모니터링 시스템으로 전송한다.
◦
데이터 저장소 : 전송되어 오는 데이터를 정리하고 저장한다.
◦
경보 : 밀려오는 데이터를 분석하고 이상 징후를 감지하여 경보를 발생시킨다. 이 시스템은 다양한 통신 채널로 경보를 발송할 수 있어야 한다.
◦
시각화 : 데이터를 차트나 그래프 등으로 제공한다. 엔지니어에게 데이터를 시각적으로 보여주면 패턴, 추이, 문제점을 더 쉽게 파악할 수 있어야 한다.
데이터 모델
•
지표 데이터는 통상 시계열 데이터 형태로 기록한다. 값 집합에 타임스탬프가 붙은 형태로 기록한다는 뜻이다.
•
시계열 각각에는 고유한 이름이 붙고 선택적으로 라벨을 붙이기도 한다.
데이터 저장소 시스템
•
쓰기 부하는 막중하다. 매일 천만 개의 운영 지표가 기록된다. 그러나 읽기 부하는 시각화나 경보 시 등 단기간에 집중적으로 발생한다.
•
이런 시계열 데이터를 처리하는 것에는 범용 데이터베이스를 추천하지 않는다. NoSQL 역시 시계열 데이터를 처리하는데 효과적이나 이미 시계열 데이터베이스가 존재하는 이상 사용할 이유는 해당 NoSQL에 해박하지 않은 이상 별로 없다.
•
가장 인기 있는 시계열 데이터베이스는 InfluxDB와 프로메테우스이다. 다량의 시계열 데이터를 저장하고 빠른 실시간 분석을 지원하는 것이 특징이다.
개략적 설계안
•
지표 출처 : 지표 데이터가 만들어지는 곳으로 애플리케이션 서버, SQL 데이터베이스, 메시지 큐 등 어떤 프로세스든 가능하다.
•
지표 수집기 : 지표 데이터를 수집하고 시계열 데이터에 기록하는 역할을 한다.
•
시계열 데이터베이스 : 지표 데이터를 시계열 데이터 형태로 보관하는 저장소다. 다량의 시계열 데이터를 분석하고 요악하는 데 적합하도록 설계된 질의 인터페이스를 제공한다.
•
질의 서비스 : 질의 서비스는 시계열 데이터베이스에 보관된 데이터를 질의하고 가져오는 과정을 돕는 서비스다.
•
경보 시스템 : 경보를 받아야 하는 대상에게 경보 알림을 전송하는 역할을 한다.
•
시각화 시스템 : 지표를 다양한 형태의 그래프/차트로 시각화하는 기능을 제공한다.
3단계: 상세 설계
지표 수집
•
풀 모델
◦
지표 수집기는 데이터를 가져올 서비스 목록을 가지고 지표를 수집한다.
◦
서버가 수시로 추가/삭제되는 경우, etcd나 아파치 주키퍼같은 서비스 탐색 기술을 사용하면 해결할 수 있다.
◦
보통 대용량 데이터를 처리하기 위해 지표 수집기 풀을 사용하며 이때 부하를 안정적으로 할당하기 위해 안정 해시 링을 사용한다.
•
푸시 모델
◦
모니터링 대상 서버에 통상 수집 에이전트라는 소프트웨어를 설치한다.
◦
수집 에이전트는 해당 장비에서 실행되는 서비스가 생산하는 지표 데이터를 받아 모은 다음 주기적으로 수집기에 전달한다.
•
장단점 비교
◦
디버깅 (풀 승)
▪
풀 모델이 더 낫다. 각 애플리케이션 서버로 하여금 /metircs 엔드포인트를 할당하므로 언제든지 지표 데이터를 볼 수 있다.
◦
상태 진단 (풀 승)
▪
애플리케이션 서버가 풀 요청에 응답하지 않으면 바로 장애가 발생했음을 알 수 있다. 풀 모델 쪽이 더 쉽다.
▪
반면 푸시는 지표 수집기가 지표를 받지 못한 이유가 네트워크 이슈인지, 장애 발생인지 확인 전에는 판단이 어렵다.
◦
생존 기간이 짧은 프로세스 (푸시 승)
▪
생명 주기가 짧은 배치 프로세스의 경우, 수집기가 지표를 풀링해 가기 전에 종료되어 버린다. 이런 경우 푸쉬 모델이 더 나을 수 있다.
◦
방화벽 등의 복잡한 네트워크 구성 (푸시 승)
▪
일반적으로 네트워크 구성은 푸시 모델이 더 쉽다.
◦
성능
▪
풀 모델은 일반적으로 TCP, 푸시 모델은 UDP를 사용한다.
▪
이는 푸시 모델의 지표 전송 지연이 더 낮다는 뜻인데, TCP 연결을 맺는데 드는 오버헤드가 지표 데이터를 전송하는 것에 비해 낮으므로 크게 상관없다는 반론도 있다.
◦
데이터 신빙성
▪
푸시의 경우 아무나 지표 수집기에 데이터를 보낼 수 있다는 문제가 있다.
지표 전송 파이프라인의 규모 확장
•
시계열 데이터베이스의 부하를 낮추기 위해 큐를 두어 데이터 손실와 부하를 해소할 수 있다.
•
카프카를 통한 규모 확장
◦
대역폭 요구사항에 따라 파티션의 수를 설정한다.
◦
지표 이름에 따라 어느 파티션에 배치할지 결정한 후, 소비자는 지표 이름에 따라 데이터를 집계한다.
◦
태그/레이블에 따라 지표 데이터를 더욱 세분화한 파티션으로 나눈다.
◦
중요 지표가 먼저 처리되도록 할 수 있다.
데이터 집계 지점
•
이는 다양한 지점에서 처리될 수 있다.
•
수집 에이전트에서 미리 처리하여 전송할 수도 있고 데이터 수집 파이프라인에서 가공할 수도 있다. 혹은 질의 시점에 데이터를 가공할 수도 있다.
•
각 사항의 장/단점을 고려하여 실정에 맞게끔 부하를 주는 것이 적절하다.
◦
수집 에이전트가 처리하는 방안
▪
복잡한 집계 로직이 어렵다. 애플리케이션 서버 특성상 지원하는 집계 기능에는 한계가 있다.
◦
데이터 수집 파이프라인에서 집계하는 방안
▪
플링크 같은 스트림 프로세싱 엔진을 이용해 집계하는 것으로, 데이터베이스에는 계산 결과만이 기록하여 부하가 줄어든다는 장점이 있다.
▪
하지만 이는 늦게 도착하는 지표 데이터의 처리가 어렵고 원본 데이터가 유실되어 정밀도나 유연성 측면에서는 손해를 볼 수 있다.
◦
질의 시에 집계하는 방안
▪
데이터 손실 문제는 없으나 질의를 처리하는 순간에 전체 데이터셋을 대상으로 집계 결과를 계산해야 하므로 속도는 느릴 것이다.
질의 서비스
•
질의 서비스는 질의 서버 클러스터 형태로 구현되며 시각화 또는 경보 시스템에서 접수된 요청을 시계열 데이터베이스를 통해 처리하는 역할을 담당한다.
•
이런 질의 처리 전담 서비스를 두면 클라이언트와 시계열 데이터베이스 사이의 결합도를 낮출 수 있다. 이를 통해 유연성을 꾀할 수 있다.
•
캐시 계층
◦
질의 결과를 저장할 캐시 서버를 도입하면 질의 부하를 낮추고 질의 성능을 높일 수 있다.
•
질의 서비스를 두면 곤란한 경우
◦
대부분의 상용 시각화 및 경보 시스템은 시계열 데이터베이스와 연동을 처리하는 강력한 플러그인을 이미 갖추고 있는 경우가 많다.
◦
별도 캐시를 도입할 필요가 없는 시계열 데이터베이스가 있다는 것도 고려할 사항이다.
•
시계열 데이터베이스 질의어
◦
프로메테우스나 InfluxDB 같은 널리 사용되는 지표 모니터링 시스템들은 SQL가 아닌 독자 질의어를 제공한다.
◦
시계열 데이터는 SQL로는 질의하기가 까다롭기 때문이다. 하지만 시계열 데이터베이스 분석에 최적화된 플럭스 언어는 훨씬 사용이 쉽다.
저장소 계층
•
시계열 데이터베이스는 신중하게 선택할 것
◦
운영 데이터 저장소에 대한 질의의 85%는 보통 지난 26시간 내에 수집된 데이터를 대상으로 한다.
◦
이 사실을 잘 활용하는 시계열 데이터베이스를 고르면 성능 측면에서 큰 이득을 볼 수 있다.
▪
데이터 저장 엔진의 설계에 관심 있는 경우 InfluxDB 저장소 엔진의 설계 문서를 참고하면 좋다.
•
저장 용량 최적화
◦
데이터 인코딩 및 압축
▪
데이터를 인코딩, 압축하면 크기를 상당히 줄일 수 있다. 좋은 시계열 데이터베이스는 보통 이 기능을 내장하고 있다.
◦
다운샘플링
▪
데이터의 해상도를 낮춰 저장소 요구량을 줄이는 기법이다.
▪
보관 기간이 1년이므로 낡은 데이터는 해상도를 줄여도 된다.
◦
냉동저장소
▪
잘 사용되지 않는 비활성 상태 데이터를 보관하는 곳이다.
경보 시스템
•
경보 처리 흐름은 다음과 같다.
1.
설정 파일을 가져와 캐시 서버에 보관한다. 경보 규칙은 디스크에 파일 상태로 보관하며 규칙을 정의하는 데는 YAML이 널리 사용된다.
2.
경보 관리자는 경보 설정 내역을 캐시에서 가져온다.
3.
설정된 규칙에 근거하여 경보 관리자는 지정된 시간마다 질의 서비스를 호출한다. 그리고 질의 결과가 설정된 임계값을 위반하면 경보 이벤트를 생성한다.
•
경보 필터링, 병합, 중복 제거: 가령 짧은 시간 동안 같은 인스턴스에서 발생한 경보는 다음과 같이 병합할 수 있다.
•
접근 제어 : 사람의 실수로 빚어지는 장애를 막고 시스템의 보안을 유지하려면 특정한 경보 관리 작업은 반드시 특정한 개인만이 수행할 수 있도록 제한해야 한다.
•
재시도 : 경보 관리자는 경보 상태를 확인하고 알림이 최소 한 번은 전달됨을 보장해야 한다.
4.
경보 저장소는 카산드라 같은 형태의 키-값 저장소다. 모든 경보의 상태가 여기 보관된다. 알림이 적어도 한 번 이상 전달되도록 보장하는 구실을 한다.
5.
경보 이벤트를 카프카에 전달한다.
6.
경보 소비자는 카프카에서 경보 이벤트를 읽는다.
7.
경보 소비자는 카프카에서 읽은 경보 이벤트를 처리하여 이메일, 단문 메시지, 페이저듀티, HTTP 서비스 엔드포인트 등 다양한 채널로 알림을 전송한다.
•
경보 시스템의 경우, 만들거나 구매할 수 있다. 따라서 상황에 적합하게 선택할 수 있도록 한다.
시각화 시스템
•
시각화 시스템은 데이터 계층 위에 만들어지는데 지표 대시보드에는 지표를 다양한 시간 범위로 표시하고 경보 대시보드에는 다양한 경보 상태를 표시한다.
•
품질 좋은 시각화 시스템을 직접 구현하는 것은 까다로우므로 그라파나와 같은 상용품을 구매해 사용하자 주장하는 것이 적합하다.
4단계: 마무리
•
다음과 같은 주요 컴포넌트와 기술을 살펴보았다.
◦
지표 데이터 수집 모델 : 풀 모델 vs 푸시 모델
◦
카프카를 활용한 규모 확장 방안
◦
최적 시계열 데이터베이스의 선정
◦
다운샘플링을 통한 데이터 크기 절감
◦
경보/시가고하 시스템 : 구현할 것인가 구매할 것인가
