시스템 모니터링

메트릭이란?

메트릭은 시간에 따라 측정한 결과값. 보다 넓은 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미하기도 한다.
예를 들어, 시간당 CPU 사용률, 연간 순매출과 같이 시간이라는 차원이 함께 적용되어야 한다. 시간이 아닌 다른 차원(예를 들어, 서비스 별 매출)을 기준으로 삼을 수도 있다.

모니터링의 목표

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

📌 구글이 이야기하는 모니터링의 목표
https://sre.google/sre-book/monitoring-distributed-systems/
📌 마이크로소프트 Azure 서비스의 주요 메트릭
https://learn.microsoft.com/ko-kr/azure/data-explorer/using-metrics

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

• 블랙박스 모니터링

  블랙박스 모니터링은 시스템을 외부에서 관찰하고 분석하는 방식이다. 모니터링 대상에 대한 내부 동작 및 상태에 대한 세부 정보를 알지 못하고, 외부에서 입력을 주고 결과를 관찰하는 방식으로 동작한다. 일반적으로 시스템의 동작을 실제 사용자의 관점에서 모니터링하며, 주로 외부에서 수집된 데이터를 기반으로 분석한다.

  장점 : 외부 관점에서 시스템을 모니터링하므로, 시스템의 동작을 실제 사용자의 관점에서 평가할 수 있다. 내부 구현 세부 정보에 의존하지 않으므로 다양한 시스템에 대한 모니터링이 가능하다.

  한계 : 내부 동작 및 세부 정보에 대한 가시성이 제한되므로, 세밀한 디버깅 및 문제 해결이 어려울 수 있다. 또한 시스템 내부에서 발생하는 성능 저하 또는 문제에 대한 원인 파악이 어려울 수 있다.

• 화이트박스 모니터링:

  화이트박스 모니터링은 시스템 내부 동작 및 구성에 대한 세부 정보를 알고 있으며, 모니터링 대상에 대한 내부 상태 및 성능을 직접 측정하고 분석하는 방식이다. 주로 내부 로그, 메트릭, 상태 정보 등을 수집하고 분석하여 시스템의 동작 및 성능을 평가한다.

  장점: 내부 동작 및 세부 정보에 대한 가시성이 높으므로, 시스템의 내부 동작을 세밀하게 모니터링하고 문제를 진단할 수 있습니다. 성능 저하나 오류의 원인 파악이 상대적으로 용이하다.

  한계: 내부 구성에 대한 세부 정보가 필요하므로, 해당 정보에 접근하고 수집해야 합니다. 모니터링 대상 시스템에 대한 지식과 이해도가 높은 팀 또는 전문가의 참여가 필요할 수 있다.

SRE 관련 메트릭

어떤 서비스(웹사이트)가 온전히 사용자에게 전달될 수 있도록 가용성을 극대화하는 기술/문화를 특별히 “사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)”라고 한다.

구글의 SRE 조직에서 정의한 "네 가지 황금 시그널(The Four Golden Signals)"

• 대기 시간 (Latency)
  대기 시간은 서비스가 요청에 응답하는 데 걸리는 시간을 나타낸다. 핵심은 지속 시간뿐만 아니라 성공적인 요청의 대기 시간과, 실패한 요청의 대기 시간을 구별하는 데에도 중점을 두어야 한다.

• 트래픽 (Traffic)
  트래픽은 서비스에 대한 수요 측정이다. 대표적인 예로는, 초당 HTTP 요청 수가 있다.

• 오류 (Errors)
  오류는 실패한 요청/전체 요청 의 비율로 측정된다. 대부분의 경우 이러한 실패는 명시적이지만(예: HTTP 500 오류) 암시적일 수도 있다(예: "결과 없음"이라는 메시지를 본문으로 전달하는 HTTP 200 응답).

• 포화 수준 (Saturation)
  포화는 서비스 또는 시스템 리소스를 “얼마나 가득 채워서 사용하는가”로 설명할 수 있다. 전형적인 예로는 과도한 CPU 자원 사용이 있다. CPU 자원이 부족하면, 스로틀링을 초래하고 결과적으로 응용 프로그램의 성능을 저하시킨다.

발표 과제

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

---

AWS Lambda는 인프라 리소스를 관리하므로 CPU 사용량과 같은 일반적인 시스템 지표를 캡처할 수 없다(컴퓨팅 유닛 관련 메트릭). 대신 Lambda는 함수가 사용될 때 함수의 성능과 효율성을 보고한다(요청/응답, 스케일링 관련 메트릭). 람다 모니터링과 관련된 메트릭으로는 실행시간, 호출 횟수, 에러 및 성공률 등이 있다. 람다 함수를 모니터링할 때 다음과 같은 메트릭을 활용하여 다양한 질문을 할 수 있다.

1. 실행 시간 (Duration): 람다 함수의 실행에 걸리는 시간을 모니터링할 수 있습니다. 이를 통해 함수의 성능과 응답 시간에 대한 질문을 할 수 있습니다. 예를 들어, "어떤 시간대에 람다 함수의 실행이 가장 오래 걸렸나요?" 또는 "특정 이벤트에 대한 람다 함수의 평균 실행 시간은 어떻게 되나요?"와 같은 질문이 나올 수 있습니다.
2. 호출 횟수 (Invocation Count): 람다 함수가 호출된 횟수를 모니터링할 수 있습니다. 이를 통해 함수의 사용 빈도에 대한 질문을 할 수 있습니다. 예를 들어, "지난 주에 람다 함수가 얼마나 자주 호출되었나요?" 또는 "특정 이벤트 유형에 대한 람다 함수의 호출 횟수는 어떻게 되나요?"와 같은 질문이 있을 수 있습니다.
3. 오류 및 예외 (Errors and Exceptions): 람다 함수의 실행 중 발생한 오류와 예외를 모니터링할 수 있습니다. 이를 통해 함수의 안정성과 오류 처리에 대한 질문을 할 수 있습니다. 예를 들어, "최근에 람다 함수에서 발생한 가장 일반적인 오류는 무엇인가요?" 또는 "특정 유형의 예외가 발생할 때 람다 함수가 어떻게 반응하나요?"와 같은 질문이 있을 수 있습니다.
4. 메모리 사용량 (Memory Usage): 람다 함수가 사용하는 메모리 양을 모니터링할 수 있습니다. 이를 통해 함수의 성능과 메모리 요구 사항에 대한 질문을 할 수 있습니다. 예를 들어, "람다 함수의 실행 시간과 메모리 사용량 사이에는 어떤 상관 관계가 있나요?" 또는 "특정 이벤트 유형에 대한 람다 함수의 평균 메모리 사용량은 어떻게 되나요?"와 같은 질문이 있을 수 있습니다.
5. 리소스 사용량 (Resource Usage): 람다 함수가 사용하는 다른 리소스(예: 네트워크, 데이터베이스 연결 등)의 사용량을 모니터링할 수 있습니다. 이를 통해 함수의 리소스 활용과 최적화에 대한 질문을 할 수 있습니다. 예를 들어, "람다 함수가 사용하는 데이터베이스 연결 수는 얼마나 되나요?" 또는 "특정 이벤트 유형에 대한 람다 함수의 네트워크 사용량은 어떻게 되나요?"와 같은 질문이 있을 수 있습니다.

이 외에도 람다 함수에 따라 다양한 메트릭을 모니터링할 수 있으며, 이러한 메트릭들을 활용하여 함수의 성능, 안정성, 리소스 사용 등에 대한 다양한 질문을 할 수 있습니다.

출처 : https://www.datadoghq.com/blog/key-metrics-for-monitoring-aws-lambda/#key-aws-lambda-metrics-to-monitor

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

  ---

  파드가 Pending 상태로 멈춰 있는 경우는, 노드에 스케줄 될 수 없음을 의미한다. 일반적으로 이것은 어떤 유형의 리소스가 부족하거나 스케줄링을 방해하는 다른 요인 때문이다. 파드가 Running 상태인데 잘 작동하지 않는 경우라면, 파드 상세(예: 로컬 머신에 있는 mypod.yaml 파일)에 에러가 있었는데 파드 생성 시에 에러가 조용히 지나쳐진 경우일 수 있다. 종종 파드 상세의 들여쓰기가 잘못되었거나, 키 이름에 오타가 있어서 해당 키가 무시되는 일이 있을 수 있다. 쿠버네티스에서 파드가 Pending 상태에 머물러 있다면, 다음과 같은 계층 순서로 살펴보아야 합니다:
  1. 노드 상태 (Node Status): 파드가 실행되어야 할 노드의 상태를 확인해야 합니다. 노드가 정상적으로 동작하고 있는지, 리소스(CPU, 메모리 등)가 충분한지, 네트워크 연결이 원활한지 등을 확인해야 합니다. 노드에 문제가 있을 경우 파드가 Pending 상태에 머무를 수 있습니다.
  2. 리소스 요구 사항 (Resource Requirements): 파드가 필요로 하는 리소스(CPU, 메모리 등)의 요구 사항을 확인해야 합니다. 파드의 요구 사항이 노드의 가용 리소스보다 큰 경우, 파드는 Pending 상태에 머무를 수 있습니다. 이 경우 리소스를 충분히 할당할 수 있는지 확인해야 합니다.
  3. 스케줄러 (Scheduler): 쿠버네티스 스케줄러가 파드를 어떤 노드에 할당할지 결정하는지 확인해야 합니다. 스케줄러는 노드의 상태와 리소스 사용량, 파드의 요구 사항 등을 고려하여 적절한 노드에 파드를 할당합니다. 스케줄러 설정에 문제가 있거나 사용 가능한 노드가 없는 경우, 파드는 Pending 상태에 머무를 수 있습니다.
  4. 스토리지 볼륨 (Storage Volume): 파드가 사용하는 스토리지 볼륨이 정상적으로 마운트되었는지 확인해야 합니다. 스토리지 볼륨에 접근할 수 없거나 문제가 있는 경우, 파드는 Pending 상태에 머무를 수 있습니다.
  5. 이미지 (Container Image): 파드에 사용된 컨테이너 이미지가 올바르게 다운로드되었는지 확인해야 합니다. 이미지 다운로드에 실패하거나 사용할 수 없는 경우, 파드는 Pending 상태에 머무를 수 있습니다.
  6. 네트워크 (Networking): 파드가 정상적으로 네트워크에 접근할 수 있는지 확인해야 합니다. 파드의 네트워크 설정, 서비스 연결, 네트워크 정책 등을 확인하여 문제가 있는지 파악해야 합니다.

파드가 Running 상태에 있지만 제대로 작동하지 않는 경우, 다음과 같은 차이점이 있을 수 있습니다:

1. 컨테이너 문제: 파드 내부에 실행되는 컨테이너의 문제로 인해 컨테이너가 작동하지 않을 수 있습니다. 이 경우 파드는 Running 상태에 있을 수 있지만, 컨테이너의 로그 또는 이벤트를 확인하여 문제를 파악해야 합니다.
2. 애플리케이션 구성 문제: 파드 내부에서 실행되는 애플리케이션의 구성 문제로 인해 애플리케이션이 제대로 작동하지 않을 수 있습니다. 예를 들어, 잘못된 환경 변수, 설정 파일 오류 등이 있을 수 있습니다. 이 경우 파드는 Running 상태에 있지만, 애플리케이션 로그 및 구성 파일을 확인하여 문제를 해결해야 합니다.

이 두 가지 상황 모두 파드가 Running 상태에 있지만 제대로 작동하지 않는 차이가 있으며, 문제의 원인과 해결 방법을 찾기 위해 해당 계층들을 살펴보아야 한다.

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