Devops Day 60 (5.31) 서비스 모니터링_모니터링의 목표와 측정 항목

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

모니터링의 목표 :

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

2. 사용량을 추적하여, 배포에 앞서 세운 가설을 검증하고 개선

- 애자일에서는 “검증된 학습(Validated learning)을 적용한다”라고 합니다.
- Validated learning : https://www.boldare.com/blog/lean-startup-validated-learning/

 

주요 벤더들이 이야기하는 모니터링의 목표와 메트릭
구글이 이야기하는 모니터링의 목표는 다음과 같습니다.

 

장기적인 트렌드 분석 (Analyzing long-term trends)

- 데이터베이스가 얼마만큼의 용량을 차지하며, 얼마나 빨리 용량이 증가하는가?

- DAU(일간 활성 사용자수)는 얼마나 빨리 증가하는가?

시간의 경과 및 실험 그룹 간의 비교 (Comparing over time or experiment groups)

- 어떤 데이터베이스를 썼을 때 쿼리가 빠른가?

- 캐시용 노드를 추가했을 때, 캐시 적중률(hit rate)이 얼마나 향상되는가?

- 지난주보다 사이트가 얼마나 느려졌는가?

경고 (Alerting)

- 인프라의 어떤 부분이 고장 났는가? 혹은 고장 날 수 있는가?
참고 : https://sre.google/sre-book/monitoring-distributed-systems/

 

마이크로소프트에서는 어떤 메트릭을 볼까요? Azure 서비스에서 측정하는 메트릭의 주요 예는 다음과 같습니다.

·         캐시 사용률

·         CPU, Memory

·         인스턴스의 개수

·         연결 유지

레퍼런스: https://docs.microsoft.com/ko-kr/azure/data-explorer/using-metrics

 

메트릭은
- 단일 노드일 경우 리눅스를 통해 측정할 수 있습니다.
- 클러스터 형태, 즉 여러 대의 노드로 구성되어 있는 경우, AWS 콘솔(CloudWatch 등)을 통해 이미 제공되고 있는 경우가 많습니다.

 

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

블랙박스 모니터링과 화이트박스 모니터링
블랙박스와 화이트박스의 구분은 박스를 기준으로 관찰자가 밖에서 바라보느냐, 안에서 바라보느냐의 차이입니다. 박스는 애플리케이션이 될 수도 있고, 쿠버네티스 시스템이 될 수도 있습니다.
블랙박스 모니터링은 CPU/메모리/스토리지 등 인프라 수준의 모니터링에 유용합니다. 쿠버네티스 시스템의 경우, 클러스터 정상 작동 여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링하는 것도 블랙박스 모니터링에 해당합니다. 그러나, 애플리케이션이 왜 오류를 내는지는 알 수 없습니다.
화이트박스 모니터링은 시스템 내부의 측정 기준에 따라 모니터링하는 것을 의미합니다. 예를 들면, HTTP 요청, 500 에러의 발생 횟수, 레이턴시 등이 이에 해당합니다.

계층에 따른 모니터링 구분
논리적인 리소스의 집합이 하나의 상위 계층을 만듭니다. 파드나, 컨테이너 안에 포함된 애플리케이션의 메트릭은 별도로 다룹니다.
쿠버네티스 : 노드 > 클러스터 컴포넌트 > 파드
ECS : 클러스터 > 서비스 > 태스크
EC2 : 인스턴스에 대한 메트릭만 볼 수 있습니다.
Lambda: 함수에 대한 메트릭만 볼 수 있습니다.

Proxy 서버의 메트릭
애플리케이션 서버(WAS)의 앞단에 캐시 서버 혹은 인증 서버, 로드 밸런서와 같은 Proxy 서버가 존재한다면, 이는 애플리케이션 서버와는 별도로 모니터링해야 합니다. 애플리케이션 서버가 각 노드의 컴퓨팅 자원을 모니터링하는 데에 중점을 두었다면, Proxy 서버, 그중에서도 HTTP 라우팅을 다루고 있는 서버는 요청 그 자체와 연관된 메트릭을 위주로 모니터링해야 합니다.
HTTP 요청/응답 관련 모니터링 대상은 쿠버네티스의 경우 인그레스, AWS 생태계에서는 Application Load Balancer를 중점으로 보아야 합니다.

 

계층별 메트릭과 메트릭 구분
메트릭 한 눈에 보기 :

메트릭을 이용한 질문 예제 :
원하는 파드(태스크)의 개수 중 실제로 실행 중인 파드(태스크)는 몇 개인가요?
Pending 상태인 파드(태스크)는 몇 개인가요?
파드 요청을 처리할 수 있을 만큼의 충분한 리소스가 있나요?

 

레퍼런스 :

• Key Metrics for AWS Monitoring | Datadog (datadoghq.com)
• Top ELB Health and Performance Metrics | Datadog (datadoghq.com)
• https://www.datadoghq.com/blog/ec2-monitoring/
• https://www.datadoghq.com/blog/aws-fargate-metrics/

Key metrics for monitoring AWS Fargate

Key metrics for EC2 monitoring

Top ELB performance metrics

Key metrics for AWS monitoring

 

사이트 신뢰성 엔지니어링 (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)을 주요 메트릭으로 정의하는 패턴입니다.

 

첫 번째 발표

[C171] 람다를 모니터링하려는 경우, 메트릭을 활용해 어떤 질문이 나올 수 있을까요? 레퍼런스(Lambda 키 메트릭)를 읽고, 어떤 질문을 해결할 수 있는지 알아봅시다. (힌트: 레퍼런스 문서에서 how many, how much, how long으로 검색해 보세요.)

 

AWS 람다 함수는 다른 서비스의 이벤트에 응답하여 호출됩니다. 서비스가 함수를 처음 호출할 때, 함수의 런타임과 핸들러 메서드가 초기화됩니다.

1. 람다를 모니터링하는 하나의 메트릭은 람다 함수의 동시성을 모니터링하는 것입니다. 우리는 몇 개의 새로운 인스턴스/요청이 처리되고 더 많은 요청이 처리될 것인지, 함수가 제한에 도달하고 스로틀링될 때까지 이벤트를 처리하는 데 얼마나 걸리는지에 대해 질문할 수 있습니다. 함수의 동시성을 모니터링하는 것은 사용자가 예약된 또는 프로비저닝된 동시성을 구성할 수 있도록 합니다.

 

2. 또 다른 주목해야 할 메트릭은 실행 시간(duration)과 청구 실행 시간(billed duration)입니다. 람다 함수는 함수가 실행될 수 있는 시간을 제한하고(15분), 함수를 종료하고 타임아웃 오류를 발생시킵니다. 따라서 각 함수의 실행 시간을 모니터링하고 임계값을 조사하는 것이 중요합니다. 실행 시간을 모니터링함으로써 코드를 최적화하거나 실행 시간에 영향을 주는 타사 서비스를 최적화할 수 있습니다. 또한, 청구 실행 시간은 실행 시간을 100ms 단위로 반올림한 것입니다. AWS 람다의 가격은 청구 실행 시간과 함수의 메모리 크기에 기반합니다. 따라서 실행 시간이 일정한 경우, 실행 시간을 줄이기 위해 메모리를 추가할 수 있습니다. 우리는 각 함수의 실행 시간이 얼마나 오래 처리되는지 파악하여 최적의 조치 방안을 결정할 수 있습니다.

 

3. 메모리 크기와 최대 메모리 사용량은 AWS 람다에서 주목해야 할 메트릭입니다. 메모리는 함수의 실행 시간에 영향을 주므로 중요합니다. 충분한 메모리가 없으면 실행 시간이 느려지고 이는 비용을 증가시킬 수 있습니다. 반대로, 함수가 설정된 메모리의 일부만 사용한다면, 할당된 메모리 양을 조정하여 비용을 줄일 수 있습니다. 이를 위해 함수에서 얼마나 많은 메모리가 필요한지, 최적의 사용을 위해 메모리를 효율적으로 할당하는 방법에 대해 질문할 수 있습니다.

 

4. 주의해야 할 오류 메트릭은 두 가지 유형이 있습니다. 하나는 호출 오류(invocation error)이고, 다른 하나는 함수 오류(function error)입니다. 호출 오류는 적절한 권한이 없는 서비스 또는 계정의 실행 제한에 도달한 경우 등을 포함할 수 있습니다. 함수 오류는 코드에 문제가 있거나 함수가 타임아웃된 경우 등을 의미합니다. 오류 횟수를 모니터링함으로써 어떤 함수가 문제를 일으키고 있는지 파악하는 데 도움을 줄 수 있습니다.

 

5. 반복자 연령(metric)은 배치의 마지막 레코드가 스트림에 기록된 시간과 람다가 해당 배치를 수신한 시간 사이의 시간입니다. 함수에서 반복자 연령이 증가하는 것을 관찰한다면, 함수가 데이터 배치를 처리하는 데 너무 오래 걸리고 처리되지 않은 이벤트들이 쌓이는 큰 지연을 초래하고 있다는 의미입니다. 반복자 연령이 증가할 수 있는 요인으로는 함수의 실행 시간이 길어지는 경우, 스트림에 충분한 샤드가 없는 경우, 호출 오류 및 충분하지 않은 배치 크기 등이 있습니다. 따라서 오류의 수와 함수를 최적화하기 위해 할당해야 할 메모리의 양에 대해 스스로 질문해야 합니다.

 

6. 함수 호출 모니터링은 애플리케이션 활동을 이해하고 함수의 전반적인 성능을 평가하는 데 도움이 되므로 중요합니다. 지연 시간을 개선하거나 더 많은 리소스를 할당하여 호출을 개선할 수 있습니다. 얼마나 많은 리소스가 필요한지를 평가하여 지연 시간 또는 함수를 개선할 수 있습니다.

7. DLQ(Dead Letter Queue) 또는 데드 레터 오류는 처리되지 못한 이벤트(처리되지 못하고 실패한 이벤트)를 처리하는 데 사용됩니다. 해당 메트릭을 사용하면 람다가 이벤트를 DLQ로 보내지 못한 횟수를 모니터링할 수 있으며, 이를 통해 함수 권한이나 다운스트림 서비스의 쓰로틀링과 같은 문제의 원인을 찾을 수 있습니다.

 

8. 동시 실행(concurrent executions) 메트릭은 함수가 동시에 여러 프로세스를 실행할 수 있는 경우를 의미합니다. 함수가 풀 내의 모든 동시성을 사용하고 있는지를 모니터링하고, 임계값에 도달하면 경고를 받을 수 있습니다.

 

9. 예약되지 않은 동시 실행(unreserved concurrent executions)은 함수가 더 무거운 작업량 동안 남은 동시성 풀을 고갈시킬 때 모니터링하는 데 사용되는 메트릭입니다. 그래프에서의 증가는 한 함수가 사용 가능한 동시성 중 대부분을 사용하고 있다는 것을 나타낼 수 있습니다. 이는 함수로 너무 많은 요청을 보내는 경우일 수 있으며, 이를 방지하기 위해 해당 함수를 위해 동시성을 예약할 수 있습니다.

 

10. 타임아웃(throttles)은 람다가 풀이 고갈되어 모든 들어오는 요청을 거부하는 것입니다. 타임아웃은 함수의 효율성을 모니터링하는 데 사용될 수 있으며, 그래프에서의 증가는 함수가 처리할 수 있는 요청보다 더 많은 요청이 있고 함수에 충분한 용량이 없는 것을 나타낼 수 있습니다. 이를 방지하기 위해 예약된 동시성을 할당하거나 처리할 요청의 수를 제한할 수 있습니다.

 

11. 할당된 예약된 동시성 수준을 초과하는 경우 함수의 과다 동시성 넘침 호출(metric)이 발생합니다. 이런 경우 함수는 예약된 동시성이 아닌 동시성에서 실행되며, Cold Start가 발생할 가능성이 높아집니다.

 

12. 예약된 동시성 활용률 모니터링을 통해 함수가 예약된 동시성을 효율적으로 사용하고 있는지 확인할 수 있습니다. 사용 가능한 예약된 동시성을 모두 사용하는 함수는 활용 임계값에 도달할 수 있으며, 이 경우 추가 동시성이 필요할 수 있습니다.

AWS Lambda는 함수의 활용 및 성능 메트릭을 자동으로 추적합니다. 이러한 데이터를 모니터링하면 함수를 최적화하고 비용을 관리할 수 있습니다.

참조 : https://www.datadoghq.com/blog/key-metrics-for-monitoring-aws-lambda/

Key metrics for monitoring AWS Lambda

 

[C172] 쿠버네티스에 어떤 파드가 Pending 상태에 머물러있다면, 어떤 계층부터 살펴보아야 할까요? 이 경우는 파드가 Running 상태인데 잘 작동하지 않는 경우랑은 어떻게 다른가요? (서비스는 연결되어 있다고 가정합니다)

 

쿠버네티스에서 파드가 Pending 상태에 머무르는 경우, 다음과 같은 계층을 순서대로 살펴보아야 합니다:

 

1. 노드 상태 확인: 파드가 배치될 노드의 상태를 확인합니다. 노드가 Ready 상태여야 파드가 실행될 수 있습니다. 노드가 Unreachable 상태인 경우 네트워크 문제나 노드 자체의 문제가 있을 수 있습니다.

 

2. 자원 할당 확인: 파드가 필요로 하는 자원(CPU, 메모리)이 충분히 할당되었는지 확인합니다. 다른 파드나 노드 리소스 사용량이 과도하게 높아서 자원이 부족한 경우 파드는 Pending 상태에 머무를 수 있습니다.

 

3. 스케줄링 제약 확인: 파드의 스케줄링 제약 조건이 충족되는지 확인합니다. 예를 들어, 파드가 특정 노드 셀렉터와 일치하는 노드에만 스케줄되어야 하는 경우 해당 노드가 존재하지 않거나 사용 가능한 노드가 없을 경우 파드는 Pending 상태에 머무를 수 있습니다.

 

4. Persistent Volume (PV) 및 Persistent Volume Claim (PVC) 확인: 파드가 PVC를 요청한 경우 해당 PVC가 적절한 PV와 바인딩되지 않으면 파드는 Pending 상태에 머무를 수 있습니다.

 

파드가 Running 상태이지만 제대로 작동하지 않는 경우는 다른 시나리오입니다. 이 경우, 파드는 실행 중이지만 애플리케이션 내부의 문제로 인해 올바른 작동을 수행하지 못할 수 있습니다. 이러한 경우에는 다음 단계를 고려할 수 있습니다:

 

1. 컨테이너 로그 확인: 파드의 컨테이너 로그를 확인하여 어떤 문제가 발생했는지 파악합니다. 로그에는 애플리케이션의 오류 메시지 또는 예외 정보 등이 포함될 수 있습니다.

 

2. 리소스 사용량 확인: 파드의 컨테이너가 필요로 하는 리소스(CPU, 메모리)를 충분히 할당받았는지 확인합니다. 리소스 부족으로 인해 컨테이너가 예상대로 작동하지 않을 수 있습니다.

 

3. 애플리케이션 구성 확인: 애플리케이션 구성 파일 또는 환경 변수를 확인하여 올바른 구성이 이루어졌는지 확인합니다. 예를 들어, 데이터베이스 연결 정보, 외부 서비스의 엔드포인트 등이 올바르게 설정되어야 합니다.

 

이렇게 보면, Pending 상태와 Running 상태에서의 문제는 약간 다른 측면을 고려해야 합니다. Pending 상태는 파드가 시작되지 못하는 것을 나타내며, 주로 클러스터의 자원 또는 스케줄링과 관련된 문제에 의해 발생할 수 있습니다. 반면, Running 상태에서의 문제는 파드가 시작되었지만 내부적인 애플리케이션 문제로 인해 정상적으로 작동하지 않는 경우입니다.