서비스 모니터링

목적

갑자기 발생할 수 있는 문제에 즉각적인 대응이 어려우며, 시스템 장애에 대한 예측 역시 불가능하다. 문제발생을 예방하고 대비하기 위함.

• 시간을 기준으로 측정되는 주요 메트릭을 최소화하여 고가용성을 달성
• 사용량을 추적하여, 배포에 앞서 세운 가설을 검증하고 개선
  -애자일에서는 "검증된 학습을 적용한다"고 한다.

주요 벤더들이 이야기하는 모니터링의 목표와 메트릭

구글이 이야기하는 모니터링의 목표

• 장기적인 트렌드 분석
  • 데이터베이스가 얼마만큼의 용량을 차지하며, 얼마나 빨리 용량이 증가하는가?
  • DAU(일간 활성 사용자수)는 얼마나 빨리 증가하는가?
• 시간의 경과 및 실험 그룹 간의 비교
  • 어떤 데이터베이스를 썼을 때 쿼리가 빠른가?
  • 캐시용 노드를 추가했을 때, 캐시 적중률이 얼마나 향상되는가?
  • 지난주보다 사이트가 얼마나 느려졌는가?
• 경고
  -인프라의 어떤 부분이 고장났는가? 혹은 고장날 수 있는가?

매트릭

메트릭이란 시간에 따라 측정한 결과값이다. 보다 넓은 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미하기도 한다.

예를 들어 시간당 CPU사용률, 연간 순매출과 같이 시간이라는 차원이 함께 적용되어야 한다. 시간이 아닌 다른 차원을 기준으로 삼을 수도 있다.

---

구분

어떠한 서비스가 제대로 작동되는지 확인하려면 서비스 또는 시스템과 관련한 모든 변수들을 모니터링해야 한다.

하지만 모든 메트릭을 실시간으로 보는것은 불가능하고, 너무 많은 메트릭을 모니터링하다 보면 중요한 신호들을 반견하기도 어렵다.

그래서 모니터링을 할 때에는 단계를 구분해서 계층적으로 할 필요가 있다.

블랙박스 모니터링과 화이트박스 모니터링

블랙박스와 화이트박스의 구분은 박스를 기준으로 관찰자가 밖에서 바라보느냐, 안에서 바라보느냐의 차이 이다. 여기서 박스는 애플리케이션이 될 수도 있고, 쿠버네티스 시스템이 될 수도 있다.

블랙박스 모니터링은 CPU/메모리/스토리지 등 인프라 수준의 모니터링에 유용하다.

화이트박스 모니터링은 시스템 내부의 측정 기준에 따라 모니터링하는 것을 의미한다. 예를 들면 HTTP요청, 500에러 발생 횟수, 레이턴시 등이 이에 해당한다.

계층에 따른 모니터링 구분

논리적인 리소스의 집합이 하나의 상위 계층을 만든다.

• 쿠버네티스
  • 노드 > 클러스터 컴포넌트 > 파드
• ECS
  • 클러스터 > 서비스 > 태스크
• EC2: 인스턴스에 대한 메트릭.
• Lambda: 함수에 대한 메트릭.

Proxy 서버의 메트릭

애플리케이션 서버의 앞단에 캐시 서버 혹은 인증서버 로드 밸런서와 같은 Proxy 서버가 존재한다면, 이는 애플리케이션 서버와는 별도로 모니터링해야 한다. 애플리케이션서버가 각 노드의 컴퓨팅 자원을 모니터링하는 데에 중점을 두었다면, Proxy서버는 요청 그 자체와 연관된 메트릭을 위주로 모니터링해야 한다.

HTTP 요청/응답 관련 모니터링 대상은 쿠버네티스의 경우 인그레스, aws 에서는 로드밸런서(ALB)를 중점으로 보아야 한다.

---

모니터링 데이터 수집 방식

Push

데이터를 가진 곳에서 필요한 곳으로 보내준다.

Nagios, Zabbix

메트릭은 중앙에서 정의되고 할당된 에이전트에 푸시된다.
수집된 데이터는 에이전트가 중앙 서버로 보낸다.

Pull

데이터가 필요한 곳에서 가진 곳에 접속하여 데이터를 긁어간다.

Prometheus, Datadog, Collectd

에이전트 자체에 메트릭 정보가 포함되어 있다.
에이전트는 메트릭을 수집하며, 중앙 시스템으로 데이터 전송을 위한 정보가 보통 에이전트에 포함되어있다.
수집된 데이터는 중앙서버가 에이전트에서 긁어간다.

특징과 차이점

Push 방식은 중앙집중형이기에, 중앙 모니터링 시스템이 데이터 수집 항목, 수집할 서버를 모두 관리하고 있다. 반면 Pull방식은 분산형으로, 중앙시스템은 에이전트가 보내주는 데이터를 긁어갈 수만 있으며, 어떤 에디터를 수집할지 중앙에서 변경할 수 없다.

• 수집 대상이 Auto-scaling 등으로 가변적일 경우, Push 방식이 Pull 방식보다 유리하다.
  만약 새로운 수집 Host가 추가될 경우, Push방식에서는 Host가 Data-Backend로 수집데이터를 보내주기에, 전송된 데이터를 받기만 하면된다. 하지만 Pull 방식에선 Data-Backend가 수집 Host로 접속하여 데이터를 긁어가야 하기에, 중앙서버에서 pull해갈 Host/Service의 목록들을 관리하여야 한다.

• 수집 대상의 유연성 측면에서는 Pull 방식이 Push 방식보다 유리하다.
  Pull 방식에서 중앙서버는 데이터를 수동적으로 긁어가기만 하기에, Pull system에서 Data-Backend는 언제든지 새로운 데이터(unplanned metrics)들을 수용할 수 있으며 모든 메트릭을 요청할 수 있도록 구현되어있다. 하지만 Push 방식에선 메트릭을 중앙에서 정의하고 에이전트로 푸시하는 구조이며, 새로운 메트릭 수용을 위해서는 중앙 서버에서 해당 변경사항을 반영해줘야한다.

• 보안 측면에서는 Push가 Pull보다 유리하다
  Pull방식은 수집 대상 서버에서 중앙 폴러가 접근할 수 있는 포트, IP 등을 수신 대기해야 한다.

• HA 측면에서 Pull이 Push 방식보다 유리하다.
  Data-Backend에서 장애가 발생하더라도, Pull 방식에선 수집 Host에 영향이 없으나 Push 방식에선 데이터 전송 재시도 등 Host에 영향이 생긴다.

서비스 수준 관련 용어

서비스를 운영하는 데에 있어서 사용자에게 필요한 적정 수준을 정의하고 제공하기 위해 서비스 제공자와 사용자는 서로 서비스 수준 협약을 맺는다.(SLA) 하지만 고객과의 약속이라는 것은 좋은 서비스를 제공했다라는 기준을 명확하게 명시하지 않으면 안된다.

SRE엔지니어는 척도를 통한 목표를 이해하고, 실제로 목표를 세우는 방법을 알아야 한다.

SLI (서비스 수준 척도, Service Level Indicator)

서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정한 값

• 응답속도: 요청에 대한 응답이 리턴되기까지의 시간
• 에러율: 전체 요청 수 대비 에러
• 처리량: 초당 처리할 수 있는 요청 수
• 가용성: 서비스가 사용 가능한 상태로 존재하는 시간의 비율
• 내구성: 데이터 저장이 중요한 목적인 서비스의 경우 중요!

SLO (서비스 수준 목표, Service Level Objectives)

SLI에 의해 측정된 서비스 수준의 목표 값, 또는 일정 범위의 값을 의미한다. 즉, SLO는 다음과 같이 표현된다.
SLLI ≤ 목표치
최소값 ≤ SLI ≤ 최댓값

구글의 SRE조직에서 정의한 네가지 황금 시그널

대기시간

대기 시간은 서비스가 요청에 응답하는 데 걸리는 시간을 나타낸다. 핵심은 지속 시간뿐만 아니라 성공적인 요청의 대기 시간과, 실패한 요청의 대기 시간을 구별하는 데에도 중점을 두어야 한다.

트래픽

트래픽은 서비스에 대한 수요 측정입니다. 대표적인 예로는, 초당 HTTP 요청 수가 있다.

오류

오류는 실패한 요청/전체 요청 의 비율로 측정된다. 대부분의 경우 이러한 실패는 명시적이지만(예: HTTP 500 오류) 암시적일 수도 있다(예: "결과 없음"이라는 메시지를 본문으로 전달하는 HTTP 200 응답).

포화 수준

포화는 서비스 또는 시스템 리소스를 “얼마나 가득 채워서 사용하는가”로 설명할 수 있다. 전형적인 예로는 과도한 CPU 자원 사용이 있습니다. CPU 자원이 부족하면, 스로틀링을 초래하고 결과적으로 응용 프로그램의 성능을 저하시킨다.