DevOps에서 모니터링(Monitoring) 정의 및 분류

모니터링의 목표

Observability -> Monitoring -> Analysis

1. 시간 기준으로 측정되는 주요 메트릭을 최소화, 고가용성 달성

2. 사용량 추적을 통해 이전에 세운 가설을 검증, 개선

* 메트릭(Metric)

메트릭은 시간에 따라 측정한 결과값이다. 큰 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미하기도 한다. 간단한 예로는 연간 순매출, 시간당 CPU 사용률 등 시간 개념과 함께 적용된다. 시간외에도 다른 기준으로 삼을 수 있다.

모니터링 메트릭 및 목표 by 구글

1. 장기적인 트렌드 분석

• 데이터베이스의 예상 용량, 용량의 증가 속도 확인
• DAU(일간 활성 사용자수)의 증가 속도

2. 시간의 경과 및 실험 그룹 간의 비교

• DB별 쿼리 속도 확인
• 캐시용 노드 추가 시, 캐시 적중률(hit rate) 확인

3. 경고

• 인프라 예상 문제 및 문제 발생 확인

https://sre.google/sre-book/monitoring-distributed-systems/

Google - Site Reliability Engineering

---

+ 주요 메트릭

• 단일 노드인 경우 리눅스를 통해서 측정 가능하다.
• 클러스터 형태, 여러 대의 노드로 구성된 경우, AWS 콘솔을 통해 미리 제공되고 있는 경우가 많다.

---

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

블랙과 화이트의 구분은 관찰자가 박스 밖에서 보는지, 안에서 보는지에 따라 결정된다. 여기서 '박스'의 의미는 어플리케이션, 쿠버네티스 시스템 등 정하기 나름이다.

https://grafana.com/

블랙박스 모니터링

CPU/메모리/스토리지 등 인프라 수준의 모니터링에 유용하다. 쿠버네티스의 경우, 클러스터 정상 작동 여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링하는 것도 블랙박스 모니터링에 해당한다. 단, 어플리케이션의 문제는 파악할 수 없다.

화이트박스 모니터링

시스템 내부의 측정 기준에 따라 모니터링하는 것을 의미한다. HTTP 요청, 500 에러 발생 횟수, 레이턴시 등이 해당한다. 현상만 파악하는 것이 아닌, 현상이 발생한 근거를 확인하기 위한 방식이다.

---

계층에 따른 모니터링

논리적인 리소스의 집합은 하나의 계층을 만들게된다. 컨테이너 오케스트레이션 툴, AWS 서비스의 계층에 따라서 모니터링하는 메트릭은 다르다.

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

---

Proxy 서버 메트릭

어플리케이션 서버(WAS) 앞단의 캐시 서버, 인증 서버, 로드 밸런서와 같은 Proxy 서버가 존재할 경우에는 어플리케이션 서버와는 별도로 모니터링을 진행해야 한다.

WAS가 각 노드의 컴퓨팅 자원을 모니터링하지만, Proxy 서버는 요청에 관련된 메트릭을 위주로 모니터링해야한다.

HTTP 요청/응답 모니터링 대상

• k8s : Ingress
• AWS : ALB(Application Load Balancer)

---

사이트 신뢰성 엔지니어링(SRE)

네트워크 요청에 따른 응답상태, 요청 횟수, 시간 등이 중요한 지표가 될 수 있다. 이를 활용하여 어떤 서비스가 온전히 사용자에게 전달될 수 있도록 가용성을 극대화하는 것을 '사이트 신뢰성 엔지니어링(Site Reliability Engineering)' 이라고 한다.

구글의 SRE가 정의한 4가지 황금 시그널 (SRE 모니터링의 주요 측정 항목)

1. 대기시간(Latency)

서비스가 요청에 응답하는데 걸리는 시간으로, 지속 시간 외에도 성공적인 요청의 대기 시간, 실패한 요청의 대기 시간을 구별하는 데에도 중점을 둔다.

2. 트래픽(Traffic)

서비스 수요를 측정하기 위함이다. 대표적으로 초당 'HTTP 요청 수'가 있다.

3. 오류(Errors)

오류는 실패 요청/ 전체 요청 의 비율로 결정된다. 실패는 명시적인 실패(HTTP 500 오류)가 있지만, 암시적인 실패(결과없음을 전달하는 HTTP 200 응답)도 있다.

4. 포화수준(Saturation)

서비스, 시스템 리소스를 '얼마나 가득 채워서 사용하는가'로 설명할 수 있다. 전형적인 예로 과도한 CPU 자원 사용이 있다. CPU 자원이 부족하면 응용 프로그램의 성능을 저하시킨다.

https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals

Google - Site Reliability Engineering

---

주요 모니터링 패턴

지금까지 다양한 모니터링 방법이 개발되어왔다. 대표적으로 USE와 RED 패턴이 있고, 그 외에는 대체로 대기 시간, 트래픽, 오류 및 포화도를 확인하는 SRE와 비슷하다.

USE 패턴

모든 리소스에 대한 사용률(Utilization), 포화도(Saturation), 오류(Errors)를 체크하는 패턴이다.

RED 패턴

비율(Rate), 오류(Errors), 기간(Duration)을 주요 메트릭으로 체크한다.