IT STUDY LOG
[서비스 모니터링] 01. 모니터링의 목표와 측정 항목 본문
# 학습 목표
- 서비스 및 계층별 메트릭을 이해할 수 있다.
- 주요 메트릭이 어떤 범주(컴퓨팅 유닛 관련, 요청/응답 관련, 스케일링 관련)에 속하는지 이해할 수 있다.
- 서비스 별 "키 메트릭"(Key metric, 핵심 지표)이 무엇인지 이해할 수 있다.
- 사이트 신뢰성 엔지니어링(SRE)에서 필요로 하는 주요 메트릭과, 모니터링 패턴을 이해할 수 있다.
# 학습 내용
1. 모니터링의 목표
- CI/CD 파이프라인의 마지막 Stage는 운영으로 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링하는 과정으로 대표
메트릭이란?
- 메트릭은 시간에 따라 측정한 결과값으로 보다 넓은 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미
(ex) 시간당 CPU 사용률 / 연간 순매출과 같이 시간이라는 차원이 함께 적용되어야 하며시간이 아닌 다른 차원(예를 들어, 서비스 별 매출)을 기준으로 삼을 수도 있음
모니터링의 목표
- 시간을 기준으로 측정되는 주요 메트릭을 최소화하여 고가용성을 달성
- 사용량을 추적하여, 배포에 앞서 세운 가설을 검증하고 개선
- 애자일에서 말하는 “검증된 학습(Validated learning)을 적용”
주요 벤더들이 이야기하는 모니터링의 목표와 메트릭
| 구글 | 마이크로소프트 (Azure) |
| 장기적인 트렌드 분석 (Analyzing long-term trends) - 데이터베이스가 얼마만큼의 용량을 차지하며, 얼마나 빨리 용량이 증가하는가? - DAU(일간 활성 사용자수)는 얼마나 빨리 증가하는가? 시간의 경과 및 실험 그룹 간의 비교 (Comparing over time or experiment groups) - 어떤 데이터베이스를 썼을 때 쿼리가 빠른가? - 캐시용 노드를 추가했을 때, 캐시 적중률(hit rate)이 얼마나 향상되는가? - 지난주보다 사이트가 얼마나 느려졌는가? 경고 (Alerting) - 인프라의 어떤 부분이 고장 났는가? 혹은 고장 날 수 있는가? |
- 캐시 사용률 - CPU, Memory - 인스턴스의 개수 - 연결 유지 |
주요 메트릭 측정 방법
- 단일 노드의 경우 : 리눅스를 통해 측정 가능
- 클러스터 형태의 경우(여러 대의 노드일 경우) : AWS 콘솔(CloudWatch 등)을 통해 제공
2. 모니터링 구분
- 어떠한 서비스가 제대로 작동되는지를 확인하려면, 서비스 또는 시스템과 관련한 모든 변수들을 모니터링해야 함
- 하지만 메트릭을 실시간으로 보는 것은 불가능할뿐더러, 너무 많은 메트릭을 모니터링하다 보면, 정말 중요한 신호를 발견하기도 어려우므로 모니터링을 할 때에는 단계를 구분해서 계층적으로 할 필요
블랙박스 모니터링과 화이트박스 모니터링
- 박스 : 애플리케이션이나 쿠버네티스 시스템 등
| 블랙박스 모니터링 | 화이트박스 모니터링 |
| - CPU/메모리/스토리지 등 인프라 수준의 모니터링에 유용 - 쿠버네티스 시스템의 경우, 클러스터 정상 작동 여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링하는 것 - 애플리케이션이 왜 오류를 내는 지 알 수 없다는 단점 |
- 시스템 내부의 측정 기준에 따라 모니터링하는 것을 의미 - 단순히 현상만 바라보는 것이 아닌, 현상이 발생한 근거를 알 수 있는 모니터링 방식 (ex) HTTP 요청, 500 에러의 발생 횟수, 레이턴시 등이 이에 해당 |
계층에 따른 모니터링 구분
- 논리적인 리소스의 집합이 하나의 상위 계층을 만듦
- 앞서 공부했던 컨테이너 오케스트레이션 툴이나, AWS의 서비스가 제공하는 계층을 이해하면, 어떤 것을 모니터링해야 하는지 보다 쉽게 파악이 가능 (왼쪽으로 갈수록 상위 계층)
- 파드나, 컨테이너 안에 포함된 애플리케이션의 메트릭은 별도로 다룸
- 쿠버네티스
- 노드 > 클러스터 컴포넌트 > 파드
- ECS
- 클러스터 > 서비스 > 태스크
- EC2: 인스턴스에 대한 메트릭만 볼 수 있음
- Lambda: 함수에 대한 메트릭만 볼 수 있음
Proxy 서버의 메트릭
- 애플리케이션 서버(WAS)의 앞단에 캐시 서버 혹은 인증 서버, 로드 밸런서와 같은 Proxy 서버가 존재한다면 애플리케이션 서버와는 별도로 모니터링해야 함
> 애플리케이션 서버 : 각 노드의 컴퓨팅 자원을 모니터링하는 데에 중점
> Proxy 서버, 그중에서도 HTTP 라우팅을 다루고 있는 서버 : 요청 그 자체와 연관된 메트릭을 위주로 모니터링
- HTTP 요청/응답 관련 모니터링 대상은 쿠버네티스의 경우 인그레스, AWS 생태계에서는 Application Load Balancer를 중점으로 확인
3. 계층별 메트릭과 메트릭 구분
메트릭 한눈에 보기
| 컴퓨팅 유닛 관련 메트릭 | 요청/응답 관련 메트릭 | 스케일링 관련 메트릭 | |
| k8s | - CPU 사용량 (utilization) - 메모리 사용량 - 네트워크 in/out - 디스크 사용량 (노드 및 파드 별) |
- etcd latency - ingress - 요청 개수 - 요청 latency - 에러율 |
- 디플로이먼트 상황 |
| ECS | - CPU 사용량 - 메모리 사용량 - 네트워크 in/out (클러스터 및 서비스 별) |
해당 사항 없음 (ALB와 사용하여 분석해야 함) | - 서비스 개수 - (원하는/실행 중인/보류 중인) 작업 개수 - 컨테이너 인스턴스 개수 |
| EC2 | - CPU 사용량 - 네트워크 in/out - 네트워크 패킷 in/out - 디스크 읽기/쓰기 (바이트), 작업 개수 - CPU 크레딧 사용량, 밸런스 |
- 상태 검사 실패 횟수 | 해당 사항 없음 |
| Lambda | 해당 사항 없음 | - 호출 개수 - 실행 시간 - 에러 개수 및 성공률 - throttles - async delivery failures - IteratorAge |
- 동시 실행 횟수 |
| ALB | 해당 사항 없음 | - 대상 응답 시간 - 요청 개수 - 응답 코드 개수 (2xx, 4xx, 5xx) - 대상 연결 오류 - 거부된 연결 개수 합계 - 대상 TLS 협상 오류 - 클라이언트 TLS 협상 오류 - 활성 연결 개수 - 새 연결 개수 - 처리된 바이트 - 사용된 Load Balancer 용량 단위 |
해당 사항 없음 |
클러스터
서비스
태스크
EC2
Lambda
레퍼런스
- 레퍼런스 문서에서 how many, how much, how long 관련 키워드 검색
- Datadog은 최근에 주목받는 상용 모니터링 툴
4. 사이트 신뢰성 엔지니어링 (SRE) 관련 메트릭
사이트 신뢰성 엔지니어링(SRE) 관련 메트릭
- CPU 및 메모리, 사용량 등을 파악하는 것 외에도 네트워크 요청에 따른 응답 상태, 요청의 횟수나 시간 등도 중요한 지표가 될 수 있음
- 이를 통해 어떤 서비스(웹사이트)가 온전히 사용자에게 전달될 수 있도록 가용성을 극대화하는 기술/문화를 특별히 “사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)”라고 칭함
- 조직마다 각기 상황이 다르고 아키텍처 중 특별한 메트릭을 사용할 수도 있으나 일반적인 주요 측정항목 존재
구글의 SRE 조직에서 정의한 “네 가지 황금 시그널(The Four Golden Signals)”로 SRE 모니터링의 주요 측정 항목
- 구글은 분산 환경에서 한정된 항목만을 측정할 수 있다면, 이 네 가지에 집중할 것을 권장
- 대기 시간 (Latency) : 대기 시간은 서비스가 요청에 응답하는 데 걸리는 시간을 나타내며, 핵심은 지속 시간뿐만 아니라 성공적인 요청의 대기 시간과, 실패한 요청의 대기 시간을 구별하는 데에도 중점을 두어야 함
- 트래픽 (Traffic) : 트래픽은 서비스에 대한 수요 측정입니다. 대표적인 예로는, 초당 HTTP 요청 수가 있음
- 오류 (Errors) : 오류는 실패한 요청/전체 요청 의 비율로 측정됨. 대부분의 경우 이러한 실패는 명시적이지만(예: HTTP 500 오류) 암시적일 수도 있음(예: "결과 없음"이라는 메시지를 본문으로 전달하는 HTTP 200 응답).
- 포화 수준 (Saturation) : 포화는 서비스 또는 시스템 리소스를 “얼마나 가득 채워서 사용하는가”로 설명 가능. 전형적인 예로는 과도한 CPU 자원 사용이 있으며, CPU 자원이 부족하면 스로틀링을 초래하고 결과적으로 응용 프로그램의 성능을 저하시킴
주요 모니터링 패턴
- 대표적인 모니터링 패턴으로는 USE 패턴, RED 패턴이 존재하며 그밖에 다른 패턴 역시 유사하고 대기 시간, 트래픽, 오류 및 포화도를 측정하기 위한 SRE 요구와 크게 다르지 않음
USE 패턴
- USE 패턴은 모든 리소스에 대한 사용률(Utilization), 포화도(Saturation), 오류(Errors)를 체크하는 패턴
RED 패턴
- RED 패턴은 비율(Rate), 오류(Errors) 및 기간(Duration)을 주요 메트릭으로 정의하는 패턴
'devops bootcamp 4 > DevOps 인프라 관리' 카테고리의 다른 글
| [서비스 모니터링] 03. Prometheus + Grafana (0) | 2023.06.02 |
|---|---|
| [서비스 모니터링] 02. 쿠버네티스 클러스터 모니터링 (0) | 2023.06.02 |
| [컨테이너 오케스트레이션] 04. 쿠버네티스 네트워크 (0) | 2023.05.22 |
| [컨테이너 오케스트레이션] 03. 쿠버네티스 구성 요소 (0) | 2023.05.22 |
| [컨테이너 오케스트레이션] 02. 쿠버네티스 워크로드 (0) | 2023.05.18 |
