Monitoring
모니터링(Moritoring)
CI/CD 파이프라인의 마지막 단계인 운영은 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링하는 과정으로 대표된다.
여기서 모니터링이란 어떤 대상을 감시, 관찰한다는 뜻으로 모니터링의 목적은 지속적인 감시, 감찰을 통해 대상의 상태나 가용성, 변화 등을 확인하고 대비하는 것이다.
즉, 어떤 대상의 상태나 상황을 지속적으로 감시, 관찰하여 예기치 못한 상황과 오류를 대비하고 극복한다. 라고 할 수 있다.
IT 서비스에서는 서비스가 어떤 환경에서 운영되든 모니터링이 중요하다.
특히 클라우드 플랫폼은 확장성과 유연성을 가졌기 떄문에 지속적인 모니터링을 통해 수집된 데이터를 기반으로 시스템 규모의 확장과 축소를 빠르게 결정해야하기 때문에 더욱 더 중요해진다.
그렇다면 모니터링을 통해 어떤 지표를 수집하고, 어떤 메트릭을 기준으로 삼아야 할 지 알아보겠다.
Metric(메트릭)
메트릭은 시간에 따라 측정한 결과값이다.
보다 넓은 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미하기도 한다.
서비스를 운영함에 있어 CPU사용량, 시간당 데이터 처리량, 분당 네트워크 속도 등의 것을 보고, 현재 파이프라인에서 알맞게 잘 돌아가고 있는지, 만약 문제가 있다면 어떻게 대처해야 하는지에 대한 의사결정이 필요하다.
여기서 메트릭이 이런 데이터들을 시각화해서 보여주는 것이라고 이해했다.
모니터링 목표
앞서 말했듯, 우리는 모니터링을 통해 시간을 기준으로 측정되는 주요 메트릭을 최소화하여 고가용성을 달성하고, 사용량을 추적하여 배포에 앞서 세운 가설을 검증하고 개선하는 것을 목표로 한다.
구글의 모니터링 목표
- 장기적인 트렌드 분석 (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, 메모리, 대역폭 등 대부분의 리소스 모니터링이 포함되어 인프라 수준의 모니터링에 유용하다.
쿠버네티스 시스템의 경우, 클러스터 정상 작동 여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링 하는 것이 블랙박스 모니터링에 해당된다.
하지만 애플리케이션이 왜 오류를 내는지는 알 수 없다.
화이트박스 모니터링
화이트박스 모니터링은 로그, JVM의 프로파일링과 같은 인터페이스류, 또는 내부 통계 정보를 내보내주는 HTTP 핸들러를 포함한 시스템 내부의 측정 기준에 따라 모니터링하는 것을 의미한다.
쿼리 수행이나 HTTP 요청 응답에 대한 자세한 수치를 제공하며, 예를 들어 HTTP 요청, 500 에러의 발생 횟수, 레이턴시 등이 이에 해당한다.
화이트박스 모니터링을 통해 단순히 현상만 바라보는 것이 아닌, 현상이 발생한 근거를 알 수 있는 모니터링 방식이다.
계층에 따른 모니터링 구분
논리적인 리소스의 집합은 하나의 계층을 만들게 된다.
컨테이너 오케스트레이션 툴, AWS 서비스의 계층 등에 따라 모니터링하는 메트릭이 다르다.
- 쿠버네티스: 노드 > 클러스터 컴포넌트 > 파드
- ECS: 클러스터 > 서비스 > 테스크
- EC2: 인스턴스의 메트릭
- Lambda: 함수의 메트릭
Proxy 서버의 메트릭
애플리케이션 서버(WAS)의 앞단에 캐시 서버 혹은 인증 서버, 로드밸런서와 같은 Proxy 서버가 존재한다면 애플리케이션 서버와는 별도로 모니터링 해야 한다.
애플리케이션 서버가 각 노드의 컴퓨팅 자원을 모니터링하는 데 중점을 두었다면, Proxy 서버, 그 중에서도 HTTP 라우팅을 다루고 있는 서버는 요청 그 자체와 연관된 메트릭을 위주로 모니터링해야 한다.
HTTP 요청/응답 관련 모니터링 대상은 쿠버네티스의 경우 인그레스, AWS 생테계에서는 Application Load Balancer를 중점으로 보아야 한다.