[DevOps] 모니터링

모니터링의 목표

CI/CD 파이프라인 마지막 Stage는 운영이다. 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링하는 과정으로 대표된다. 그렇다면 어떤 지표를 수집하고, 어떤 메트릭을 기준으로 삼아야 하지?

메트릭?

메트릭은 시간에 따라 측정한 결과값이다. 

예를 들어서 시간당 CPU 사용률, 연간 순매출처럼 시간이라는 차원이 함께 적용되어야 한다. 시간이 아닌 다른 차원(예를 들어, 서비스 별 매출)을 기준으로 삼을 수도 있다.

모니터링의 목표

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

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

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

구글이 이야기하는 모니터링의 목표는 다음과 같다.

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

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

메트릭을 사용하여 Azure Data Explorer 성능, 상태 및 모니터링 - Azure Data Explorer

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

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

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

Google - Site Reliability Engineering

앞서 살펴본 바와 같이 주요 메트릭은,

단일 노드일 경우 리눅스를 통해 측정할 수 있다. 클러스터 형태, 즉 여러 대의 노드로 구성되어 있는 경우, AWS 콘솔(CloudWatch 등)을 통해 이미 제공되고 있는 경우가 많다. 이번 유닛에서는 단일 노드에서의 측정과 함께, 쿠버네티스 클러스터 상에서의 모니터링 과정을 살펴본다.

모니터링 구분

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

하지만 우리가 서비스 모니터링을 위해 날씨나 데이터센터의 전력 공급에 신경 쓰지 않는다. 반대로, 발생하는 모든 메트릭을 모니터링하지 않는다. 모든 메트릭을 실시간으로 보는 것은 불가능하고, 너무 많은 메트릭을 모니터링하다 보면, 중요한 신호를 발견하기도 어렵다.

따라서 모니터링할 때에는 단계를 구분해서 계층적으로 해야 한다.

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

블랙박스와 화이트박스의 구분은 박스를 기준으로 관찰자가 밖에서 바라보느냐, 안에서 바라보느냐의 차이다. 박스는 애플리케이션이 될 수도 있고, 쿠버네티스 시스템이 될 수도 있다.

• 블랙박스 모니터링은 CPU/메모리/스토리지 등 인프라 수준의 모니터링에 유용하다. 쿠버네티스 시스템의 경우, 클러스터 정상 작동 여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링하는 것도 블랙박스 모니터링에 해당한다.
• 그러나, 애플리케이션 로직과 관련된 문제나 애플리케이션 내부 로직에 대한 세부적인 모니터링을 할 때는 화이트박스 모니터링이 더 효과적이다.

---

이렇게 서비스의 건강과 성능을 파악하고 개선하기 위해 모니터링은 필수적이다. 주요 메트릭을 잘 파악하고 적절한 도구와 전략을 사용하면 서비스의 품질을 획기적으로 향상시킬 수 있다.