모니터링의 목표와 측정 항목

---

목표

CI/CD 파이프라인 중 가장 마지막 단계인 운영에 있어 필요한 측정 항목(metric)과 AWS의 대표적인 모니터링 도구인 CloudWatch를 좀 더 잘 다룰 수 있게 연습합니다. 또한, 쿠버네티스 환경에서 사용하는 Prometheus와 Grafana 조합을 살펴봅니다.

 

 

 

---

모니터링 목표

- 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링 함 
   => 어떤 지표를 수집하고, 어떤 메트릭을 기준으로 삼아야 할까??

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

- 사용량을 추적하여, 배포에 앞서 세운 가설을 검증하고 개선
   => 애자일에서는 "검증된 학습 (Validated learning) 을 적용한다." 고 함
          https://www.boldare.com/blog/lean-startup-validated-learning/

💡메트릭이란?

시간에 따라 측정한 결과값 => 비즈니스 개념을 나타내는 수치 측정을 의미
ex) 시간당 CPU 사용률, 연간 순매출과 같이 시간이라는 차원이 함께 적용 되어야 함 
       시간이 아닌 다른 차원 (서비스 별 매출 등)을 기준으로 삼을 수도 있음

 

 

 

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

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

- 장기적 트렌드 분석 (Analyzing long-term trends)
   => 데이터베이스가 얼만큼의 용량을 차지하며 얼마나 빨리 증가하는가?
   => DAU (일간 활성 사용자수) 는 얼마나 빨리 증가하는가?

- 시간의 경과 및 실험 그룹간의 비교 (Comparing over time or experiment groups)
   => 어떤 데이터 베이스를 썼을 때 쿼리가 빠른가?
   => 캐시용 노드를 추가했을 때, 캐시 적중률(hit rate)이 얼마나 향상 되는가?
   => 지난 주 보다 사이트가 얼마나 느려졌는가?

- 경고 (Alerting)
   => 인프라의 어떤 부분이 고장났는가? 혹은 고장날 수 있는가? (예지보전 활용)

참고링크

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

 

 

* 마이크로소프트 에서 모니터링 하는 메트릭

- 캐시 사용률
- CPU, Memory
- 인스턴스 개수
- 연결 유지

참고링크

https://docs.microsoft.com/ko-kr/azure/data-explorer/using-metrics

 

 

---

주요 메트릭

• 단일 노드일 경우 리눅스를 통해 측정할 수 있음
• 클러스터의 형태, 즉 여러대의 노드로 구성되어 있는 경우 AWS 콘솔(Cloud Watch 등)을 통해 이미 제공되고 있음

 

 

 

---

모니터링 구분

- 어떤 서비스가 제대로 작동되는지를 확인하려면 서비스 또는 시스템과 관련한 모든 변수들을 모니터링 해야함
- 모든 메트릭을 실시간으로 보는 것은 불가능함 -> 중요 신호를 발견하기 어려움 

 

 

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

구분 기준 : 관찰자가 밖에서 바라보느냐, 안에서 바라보는냐의 차이
                  => 박스는 어플리케이션 or 쿠버네티스 시스템 등이 될 수 있다.

- 블랙박스 모니터링
   => CPU/메모리/스토리지 등 인프라 수준의 모니터링에 유용
   => 쿠버네티스 시스템의 경우, 클러스터 정상 작동 여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링하는 것도 해당

- 화이트박스 모니터링
   => 시스템 내부의 측정 기준에 따라 모니터링 하는 것
   => HTTP 요청, 500 에러의 발생 회수, 레이턴시 등이 해당함
   => 단순 현상만 바라보는 것이 아닌 발생 근거를 알 수 있는 모니터링 방식

 

 

 

계층에 따른 모니터링 구분

논리적 리소스 집합 -> 하나의 상위 계층을 만듦
파드나, 컨테이너 안에 포함된 어플리케이션의 메트릭은 별도로 다룸
(왼쪽으로 갈 수 록 상위 계층)

- 쿠버네티스
   => 노드 > 클러스터 컴포넌트 > 파드
- ECS
   => 클러스터 > 서비스 > 태스크
- EC2
   => 인스턴스에 대한 메트릭만 관찰 가능
- Lambda
   => 함수에 대한 메트릭만 관찰 가능

 

 

Proxy 서버의 메트릭

WAS 의 앞단에 캐시 서버 혹은 인증서버, 로드밸런서 같은 Proxy 서버가 존재한다면
어플리케이션 서버와는 별도로 모니터링을 해야함

가가 노드의 컴퓨팅 자원을 모니터링 하는데 중점을 주었다면, Proxy 서버, 그중에서도 HTTP 라우팅을 다루고 있는 서버는 요청 그 자체와 연관된 메트릭을 위주로 모니터릴ㅇ 해야함

HTTP 요청/응답 관련 모니터링 대상은 쿠버네티스의 경우 인그레스, AWS 생태계에서는 ALB를 중점으로 봐야함

 

 

---

Proxy 서버의 메트릭

	컴퓨팅 유닛 관련 메트릭	요청/응답 관련 메트릭	스케일링 관련 메트릭
k8s	- CPU 사용량 - 메모리 사용량 - 네트워크 in/out - 디스크 사용량 (노드 및 파드 별)	- etcd latency - ingress - 요청 개수 - 요청 latency - 에러율	- 디플로이먼트 상황
ECS	- CPU 사용량 - 메모리 사용량 - 네트워크 in/out	해당 사항 없음 (ALB와 사용하여 분석해야 함)	- 서비스 개수 - (원하는/실행 중인/ 보류중인)       작업개수 - 컨테이너 인스턴스 개수
EC2	- CPU 사용량 - 메모리 사용량 - 네트워크 in/out - 디스크 읽기/쓰기 (바이트),           작업 개수 - CPU 크레딧 사용량, 밸런스	- 상태 검사 실패 회수	해당 사항 없음
Lambda	해당 사항 없음	- 호출 개수 - 실행 시간 - 에러 개수 및 성공률 - throttles - async delivery failures - lteratorAge	- 동시 실행 회수
ALB	해당 사항 없음	- 대상 응답 시간 - 요청 개수 - 응답 코드 개수    (2xx, 4xx, 5xx) - 대상 연결 오류 - 거부된 연결 개수 합계 - 대상 TLS 협상 오류 - 클라이언트 TLS 협상 오류 - 활성 연결 개수 - 새 연결 개수 - 처리된 바이트 - 사용된 Load Balancer   용량 단위	해당 사항 없음

 

질문

Q. 메트릭을 이용한 질문 예제

• Q. 원하는 파드(태스크)의 개수 중 실제로 실행중인 파드(태스크)는 몇 개인가요?
• Q. Pending 상태인 파드(태스크)는 몇 개인가요?
• Q. 파드 요청을 처리할 수 있을 만큼의 충분한 리소스가 있나요?

 

Datadog

• AWS 키 메트릭

Key metrics for AWS monitoring

• ELB 키 메트릭

Top ELB performance metrics

• EC2 키 메트릭

Key metrics for EC2 monitoring

• AWS 키 메트릭

Key metrics for monitoring AWS Fargate

 

 

 

---

사이트 신뢰성 엔지니어링(SRE) 관련 메트릭

CPU 및 메모리, 사용량 등을 파악하는 것 외에도 네트워크 요청에 따른 응답 상태, 요청의 회수나 시간 등도 중요한 지표가 될 수 있음

SRE 란?
- 어떤 서비스가 온전히 사용자에게 전달될 수 있도록 가용성을 극대화 하는 기술/문화

 

* SRE 모니터링의 주요 측정 항목

참고 링크 : https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals

대기 시간 (Latency)	대기 시간은 서비스가 요청에 응답하는데 걸리는 시간을 나타냄 핵심은 지속 시간 뿐만 아니라 성공적인 요청의 대기 시간 및 실패한 요청의 대기 시간을 구별하는데 중점을 두어야함
트래픽 (Traffic)	트래픽 서비스에 대한 수요 측정 대표적인 예로는, 초당 HTTP 요청 수가 있음
오류 (Error)	실패한 요청/전체 요청의 비율로 측정 대부분의 경우 이러한 실패는 명시적이지만 (예 : HTTP 500 오류) 암시적일 수 있음 (예 : '결과 없음' 이라는 메시지를 본문으로 전달하는 HTTP 200 응답)
포화 수준 (Saturation)	포화는 서비스 또는 시스템 리소스를 "얼마나 가득 채워서 사용하는가" 로 설명함 (ex. 전형적인 예로는 과도한 CPU 자원 사용) CPU 자원이 부족하면, 스로틀링을 초래하고 결과적으로 응용 프로그램의 성능을 저하시킴

 

 

주요 모니터링 패턴

시간이 지남에 따라 다양한 모니터링 방법이 개발되었음
대표적으로 USE 패턴, RED 패턴이 있음, 그 밖에 다른 패턴 역시 유사하며
대기 시간, 트래픽, 오류 및 포화도를 측정하기 위한 SRE 요구와 크게 다르지 않음

• USE 패턴
  => 모든 리소스에 대한 사용률(Utilization), 포화도(Saturation), 오류(Errors) 를 체크하는 패턴을 의미함
• RED 패턴
  => 비율(Rate), 오류(Errors) 및 기간(Duration)을 주요 메트릭으로 정의하는 패턴임

 

---

발표

• Q. 람다를 모니터링 하려는 경우, 메트릭을 활용해 어떤 질문이 나올 수 있을까요? 레퍼런스(Lambda 키 메트릭)를 읽고, 어떤 질문을 해결할 수 있는지 알아봅시다. https://www.datadoghq.com/blog/key-metrics-for-monitoring-aws-lambda/ 
  • 힌트: 레퍼런스 문서에서 how many, how much, how long 으로 검색해보세요.

1. 람다 함수의 호출 빈도를 모니터링 할 수 있는가?
   => 람다 함수 내 View metrics in CloudWatch를 통해 해당 함수에 대한 메트릭을 확인할 수 있다. 
   => Metrics 섹션에서 Invocations 메트릭을 선택하여 람다함수의 호출 빈도를 확인할 수 있다.
         - Invocations 내에서 함수 호출 총 회수, 특정 기간 호출 회수 등의 정보를 확인할 수있다.  

2. 사용 시간에 대한 청구에 대한 메트릭은 어떻게 구성되어있는가?
   => 100ms를 반올림하여 실행시간을 측정하며 청구 기간과 함수의 메모리 크기를 기반으로 한다.
   => 함수 사용 기간과 메모리 크기를 조절하여 적절한 비용 관리를 할 수 있다.

3. 함수 실행 시간에 따른 로그를 확인할 수 있는가?
   => CloudWatch로그에서 함수 실행의 경과 시간(ms)을 확인할 수 있음

 

 

• Q. 쿠버네티스에 어떤 파드가 Pending 상태에 머물러있다면, 어떤 계층부터 살펴보아야 할까요? 이 경우는 파드가 Running 상태인데 잘 작동하지 않는 경우랑은 어떻게 다른가요? (서비스는 연결되어 있다고 가정합니다)
  (Pending 상태 - 해당 파드가 실행을 위해 필요한 모든 리소스(CPU 등)를 할당받지 못해 실행 대기 상태에 머물러 있다는 것)
  

1. 노드확인 - 노드의 유무 및 노드에 할당된 자원이 충분한가 등 상태를 확인한다.
2. 노드 선택을 위한 스케줄러 동작 확인
3. 파드가 요구하는 리소스 양 확인 - 가용 자원이 보다 적으면 Pending 될 수 있음
4. 파드 실행을 위한 이미지 유무 확인

* Running 상태인데 잘 작동하지 않는 경우
1. 어플리케이션의 구성이 제대로 되어있는지 확인 
2. 환경변수 설정 확인 
3. 스토리지 볼륨의 마운트 상태 확인