study/devops

서비스 모니터링 : 모니터링 목표

FYE 2023. 2. 23. 13:20

모니터링의 목표

 

CI/CD 파이프라인의 마지막은 스테이지 운영이다. 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링하는 과정으로 대표될 수 있다.

어떤 지표를 수집하고, 어떤 메트릭을 기준으로 삼아야 할까?

 

 

메트릭이란?

모니터링 대상 시스템의 상태를 측정하고 분석하기 위한 수치적인 값이다. 메트릭은 대게 시간에 따라 측정되며, 시계열 데이터로 저장된다.

예를 들어, 시간당 CPU 사용률, 연간 순매출과 같이 시간이라는 차원이 함께 적용되어야 합니다.

시간이 아닌 다른 차원(서비스 별 매출 같은)을 기준으로 삼을 수도 있다.

 

 

 

 

https://learn.microsoft.com/ko-kr/power-bi/collaborate-share/service-modern-usage-metrics

 

 

모니터링의 목표

모니터링을 통해 얻고자 하는것은 다음과 같다.

 

서비스 모니터링의 목표는 시스템 및 서비스의 상태를 지속적으로 추적하고, 잠재적인 문제를 신속하게 감지하고 조치함으로써 시스템 가용성과 신뢰성을 최대화하는 것이다. 이를 통해서 서비스 다운타임 및 장애를 최소화하고, 사용자 경험을 개선할 수 있다.

 

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

 

참고 레퍼런스 - 검증된 학습

https://www.boldare.com/blog/lean-startup-validated-learning/

 

Validated Learning - Lean Startup Validation Examples

Validated learning is a part of progress that is generated by trying the idea and measuring the effect. What is lean startup validation and why is it important?

www.boldare.com

 

 

검증된 학습은 제품 또는 서비스를 개발하면서 적극적으로 수행하는 학습 프로세스이다.

이 프로세스는 실험과 검증을 통해 제품 또는 서비스의 hypothesis를 검증하고, 이를 통해 새로운 인사이트를 얻으며

다음 개발 단계에 반영하여 제품 또는 서비스를 지속적으로 개선하는 것을 목적으로 한다.

 

또한 검증된 학습은 애자일의 핵심 원칙 중 하나인 지속적인 개선과 함께 작동한다. 검증된 학습을 통해 팀은 신속하게 가설을 검증하고, 실패를 허용하며 그에 따라 제품 또는 서비스를 빠르게 개선할 수 있다. 이를 통해 빠른 시간 안에 고객의 요구사항을 충족시키는 제품 또는 서비스를 개발할 수 있다.

 

검증된 학습은 빠른 실패와 학습을 통해 제품 또는 서비스를 지속적으로 개선함으로써, 고객의 요구사항을 충족시키고 경쟁력을 유지하는데 중요한 역할을 한다.

 

 

 

 

 

 

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

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

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

 

 

마이크로소프트에서 어떤 메트릭을 보나요/

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

 

 

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

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

 

 

 

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

이번 유닛에서는 단일 노드에서 측정과 함께, 쿠버네티스 클러스터 상에서의 모니터링 과정을 살펴봅니다.

 

 

모니터링 구분

어떠한 서비스가 제대로 작동되는지를 확인하려면, 서비스 또는 시스템과 관련한 모든 변수들을 모니터링해야 합니다.
우리가 서비스 모니터링을 위해 날씨나 데이터센터의 전력 공급에 신경쓰지 않는다. 한편 반대로, 발생하는 모든 메트륵을 모니터링 하지도 않는다.
모든 메트릭을 실시간으로 보는 것은 불가능할 뿐더러, 너무 많은 메트릭을 모니터링 하다보면 정말 중요한 신호를 발견하기도 어렵습니다.
따라서 모니터링을 할 때에는 단계를 구분해서 계층적으로 할 필요가 있다.

 

 

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

블랙박스 모니터링은 시스템이나 서비스를 외부에서 관찰하는 방법이다.

→ 시스템 내부의 동작 방식에 대한 세부 정부를 알지 못하고, 시스템의 출력물 또는 결과물만을 관찰한다.

→ 이를 통해 시스템이 예상한 대로 작동하는지 확인할 수 있다.

 

 ex) 웹 사이트가 브라우저에서 로드되는 속도를 측정하는 것은 블랙바스 모니터링의 예이다.

이 방법은 테스트 대상 시스템 내부의 코드나 로직 등에 대한 이해가 없어도 쉽게 적용할 수 있다.

 

화이트박스 모니터링은 시스템 내부의 동작 방식을 자세히 파악하고, 시스템의 내부의 동작 방식을 자세히 파악하고, 시스템의 내부 상태를 모니터링하는 방법이다.

시스템의 코드나 로직, 데이터 흐름 등을 분석하여 시스템의 상태를 추적하고, 문제가 발생한 경우에도 쉽게 원인을 파악할 수 있다.

 

ex) 코드 레벨에서 성능을 분석하거나, 시스템 로그를 분석하여 오류를 발견하는 것은 화이트 박스 모니터링의 예이다. 

→ 이 방법은 시스템의 내부  동작 방식에 대한 이해가 필요하지만, 세부적인 문제를 파악하고 해결할 수 있는 장점이 있다.

 

블랙박스와 화이트박스의 구분은 박스를 기준으로 관찰자가 밖에서 바라보느냐, 안에서 바라보느냐의 차이이다.

박스는 애플리케이션이 될 수도 있고, 쿠버네티스 시스템이 될 수도 있다.

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

쿠버네티스 시스템의 경우, 클러스터 정상 작동 여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링하는 것도 블랙박스 모니터링에 해당된다.

그러나, 애플리케이션이 왜 오류를 내는지는 알 수 없다.

 

화이트박스 모니터링은 시스템 내부의 측정 기준에 따라 모니터링하는 것을 의미한다.

예를 들면, HTTP 요청, 500 에러의 발생 횟수, 레이턴시 등이 이에 해당된다.

단순히 현상만 바라보는 것이 아닌 현상이 발생한 근거를 알 수 있는 모니터링 방식이다.

 

두 가지 모니터링 방법 모두 장단점이 있고, 모니터링 대상 시스템의 특성에 따라 적절한 방법을 선택해서 사용해야한다.

일반적으로는 블랙박스 모니터링과 화이트박스 모니터링을 함께 사용하여 시스템의 상태를 종합적으로 모니터링하는 경우가 많다.

 

 

 

계층에 따른 모니터링 구분

서비스 모니터링에서는 모니터링 대상을 계층적으로 분류하여 각 계층별로 어떤 메트릭을 수집해야 하는지 파악하는 것이 중요하다.

일반적으로 클라우드 환경에서는 하드웨어 레벨부터 애플리케이션 레벨까지 계층을 구분하여 모니터링한다.

 

예를 들어, 쿠버네티스와 ECS 같은 컨테이너 오케스트레이션 툴은 다음과 같은 계층으로 구성됩니다.

 

  • 노드(Node): 물리적인 서버나 가상 머신 등의 호스트 시스템
  • 클러스터 컴포넌트(Cluster Component): 쿠버네티스의 경우, 마스터, etcd, API서버, 스케줄러, 컨트롤러 매니저 등의 컨트롤 플레인 컴포넌트
  • 파드(Pod): 컨테이너 실행하는 가장 작은 배포 단위

 

이러한 계층에서 각각의 메트릭을 수집하여 서비스의 상태를 파악할 수 있다. 예를들어, 노드 레벨에서는 CPU, 메모리, 디스크 사용량 등의 하드웨어 리소스 사용량을 모니터링하고, 클러스터 컴포넌트 레벨에서는 API 서버나 스케줄러의 상태를 모니터링한다.

또한 파드 레벨에서는 CPU, 메모리 사용량, 네트워크 트래픽 등의 애플리케이션 레벨의 메트릭을 수집하여 모니터링한다.

 

 

 

Proxy 서버의 메트릭

애플리케이션 서버 (WAS) 앞단에 위치한 Proxy서버는 캐시,인증, 로드 밸런싱 등의 역할을 수행합니다.

이 Proxy 서버는 애플리케이션 서버와는 별개로 모니터링이 필요합니다.

 

특히, HTTP 라우팅을 다루는 Proxy 서버는 요청과 관련된 메트릭을 모니터링해야 합니다.

이는 쿠버네티스의 경우 인그레스, AWS에서는 Application Load Balancer와 같은 Proxy 서버를 중점적으로 모니터링해야 합니다.

 

따라서, Proxy 서버의 모니터링 대상은 HTTP 요청 및 응답과 관련된 메트릭이며, 이를 위해 적절한 도구를 사용하여 인그레스나 로드 밸런서의 상태, 네트워크 지연 시간, 응답 속도 등을 측정하고 모니터링해야 한다.

 

 

프록시(Proxy)란 인터넷 상에서 클라이언트와 서버 사이에서 중계기로서 동작하는 서버를 말한다.
클라이언트가 서버에 직접 요청을 보내는 대신, 프록시 서버를 거쳐 요청을 보내고 응답을 받게 된다.

사용하는 이유? - 캐싱을 이용해서 반복적인 대한 응답 속도를 높일 수 있고, 보안을 강화하기 위해 요청을 필터링하거나 인증을 수행할 수도 있습니다. 또한, 로드 밸런싱을 통해 여러 서버에 요청을 분산시키는 등의 기능도 가능하다.

ex) 회사에서 직원들이 인터넷에 접속할 때 프록시 서버를 이용하도록 설정해 놓으면, 직원들이 인터넷을 사용할 때 프록시 서버를 거쳐 요청을 보내므로, 회사에서는 인터넷 사용에 대한 모니터링이나 보안 강화 등의 목적을 달성할 수 있다.

 

 

 

 

 

계층별 메트릭과 메트릭 구분

메트릭 한눈에 보기

 

쿠버네티스에서는 CPU 사용량, 메모리 사용량, 네트워크 in/out, 디스크 사용량 등의 컴퓨터 유닛 관련 메트릭과 요청 개수, 요청 대기 시간, 에러율 등의 요청/응답 관련 메트릭 그리고 디플로이먼트 상황 등의 스케일링 관련 메트릭을 모니터링한다.

 

ECS에서는 CPU 사용량, 메모리 사용량, 네트워크 in/out 등의 컴퓨팅 유닛 관련 메트릭과 서비스 개수, 작업 개수, 컨테이너 인스턴스 개수 등의 스케일링 관련 메트릭을 모니터링한다. 그리고 요청/응답 관련 메트릭은 ALB와 사용해서 분석한다.

 

EC2에서는 CPU 사용량, 네트워크 in/out, 디스크 읽기/쓰기, 작업 개수 등의 컴퓨팅 유닛 관련 메트릭을 모니터링합니다.

요청/응답 관련 메트릭은 상태 검사 실패 횟수를 모니터링합니다. 스케일링 관련 메트릭은 해당 사항이 없다.

 

ALB에서는 대상 응답 시간, 요청 개수, 응답 코드 개수, 대상 연결 오류, 거부된 연결 개수 합계, 대상 TLS 협상 오류, 클라이언트 TLS 협상 오류, 활성 연결 개수, 새 연결 개수, 처리된 바이트 등의 요청/응답 관련 메트릭을 모니터링한다.

스케일링 관려 메트릭은 해당 사항이 없다.

 

 

 

 

 

메트릭을 이용한 질문 예제

- 원하는 파드의 개수 중 실제로 실행중인 파드는 몇 개인가요?

- Pending 상태인 파드는 몇 개인가요?

- 파드 요청을 처리할 수 있을 만큼의 충분한 리소스가 있나요?

 

 

 

Action Items

  • Q. 람다를 모니터링 하려는 경우, 메트릭을 활용해 어떤 질문이 나올 수 있을까요? 레퍼런스(Lambda 키 메트릭)를 읽고, 어떤 질문을 해결할 수 있는지 알아봅시다.
    • 힌트: 레퍼런스 문서에서 how many, how much, how long 으로 검색해보세요. 
      • How many requests did my Lambda function receive?
      • How much time did my Lambda function take to execute?
      • How long did my Lambda function run?
      • How much memory did my Lambda function consume?
      • How many invocations of my Lambda function were throttled?
      • How many errors did my Lambda function encounter?
      • How many retries did my Lambda function attempt?

 

    • Q. 쿠버네티스에 어떤 파드가 Pending 상태에 머물러있다면, 어떤 계층부터 살펴보아야 할까요? 이 경우는 파드가 Running 상태인데 잘 작동하지 않는 경우랑은 어떻게 다른가요? (서비스는 연결되어 있다고 가정합니다)
    • → 파드가 pending 상태로 멈춰 있는 경우는 노드에 스케줄 될 수 없음을 의미한다. 일반적으로 이것은 어떤 유형의 리소스가 부족하거나 스케줄링을 방해하는 다른 요인 때문이다.
    • 리소스가 부족한 경우: 사용자 클러스터의 CPU나 메모리가 고갈되었을 수 있다. → 파드를 삭제하거나, 리소스 요청을 조정하거나, 클러스터에 노드를 추가해야 한다.
    • hostPort를 사용하고 있는 경우: 파드를 hostPort에 바인딩할 때, 파드가 스케줄링될 수 있는 장소 수 제한이 존재한다. 대부분의 경우 hostPort는 불필요하므로 파드를 노출하기 위해서는 서비스 오브젝트 사용을 고려해 본다. hostPort가 꼭 필요하다면 클러스터의 노드 수 만큼만 파드를 스케줄링할 수 있다.

 

 

https://kubernetes.io/ko/docs/tasks/debug/debug-application/debug-pods/

 

파드 디버깅하기

이 가이드는 쿠버네티스에 배포되었지만 제대로 동작하지 않는 애플리케이션을 디버깅하는 방법을 소개한다. 이 가이드는 클러스터 디버깅에 대한 것은 아니다. 클러스터 디버깅에 대해서는

kubernetes.io

 

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

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

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

 

사이트 신뢰성 엔지니어링(SRE)은 사용자에게 원활한 서비스를 제공하기 위한 기술/문화를 말합니다.

이를 위해 각종 메트릭을 모니터링하고 분석하여 서비스의 가용성을 극대화합니다.

 

SRE에서 중요한 측정항목은 CPU, 메모리 등의 시스템 자원 사용량 뿐만 아니라, 네트워크 요청에 대한 응답 상태, 요청의 횟수 및 처리시간등이 있다. 이러한 측정 항목들을 통해 사용자에게 온전한 서비스를 제공하기 위해 각종 이슈를 신속하게 파악하고 대처할 수 있다.

 

 

  1. Latency(지연 시간): 사용자의 요청에 대한 응답 시간을 측정하여 처리 속도를 파악합니다.
  2. Traffic(트래픽): 서비스에 접속한 사용자 수나 요청 횟수 등을 측정하여 부하 상황을 파악합니다.
  3. Errors(오류): 사용자에게 제공되는 서비스에서 발생한 오류 횟수 및 오류 처리 상황을 파악합니다.
  4. Saturation(과부하): 시스템 자원의 사용량 및 한계치를 측정하여 과부하 상황을 파악합니다.

 

 

저작자표시 비영리 동일조건 (새창열림)