CI/CD 파이프라인의 마지막 Stage는 운영이다. 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링하는 과정으로 대표될 수 있다. 그렇다면 어떤 지표를 수집하고, 어떤 메트릭을 기준으로 삼아야 할까?
메트릭이란?
메트릭은 시간에 따라 측정한 결과값이다. 보다 넓은 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미하기도 한다.
예를 들어, 시간당 CPU 사용률, 연간 순매출과 같이 시간이라는 차원이 함께 적용되어야 한다. 시간이 다른 차원을 기준으로 삼을 수도 있다.
모니터링을 통해 얻는 것은 다음과 같다.
주요 메트릭은 노드에 따라 다르게 측정할 수 있다.
어떠한 서비스가 제대로 작동되는지 확인하려면, 서비스 또는 시스템과 관련한 모든 변수들을 모니터링해야 한다.
하지만 모든 메트릭을 실시간으로 보는 것은 불가능할뿐더러, 너무 많은 메트릭을 모니터링하다 보면, 정말 중요한 신호를 발견하기도 어렵다.
따라서 모니터링을 할 때에는 단계를 구분해서 계층적으로 할 필요가 있다.
블랙박스와 화이트박스의 구분은 박스를 기준으로 관찰자가 밖에서 바라보느냐, 안에서 바라보느냐의 차이이다. 박스는 애플리케이션이 될 수도 있고, 쿠버네티스 시스템이 될 수도 있다.
블랙박스 모니터링은 CPU/메모리/스토리지 등 인프라 수준의 모니터링에 유용하다. 쿠버네티스 시스템의 경우, 클러스터 정상 작동여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링하는 것도 블랙박스 모니터링에 해당한다. 그러나, 애플리케이션이 왜 오류를 내는지는 알 수 없다.
화이트박스 모니터링은 시스템 내부의 측정 기준에 따라 모니터링하는 것을 의미한다. 예를 들면, HTTP 요청, 500 에러의 발생 횟수, 레이턴시 등이 이에 해당한다. 단순히 현상만 바라보는 것이 아닌, 현상이 발생한 근거를 알 수 있는 모니터링 방식이다.
논리적인 리소스의 집합이 하나의 상위 계층을 만든다. 오케스트레이션 툴이나, AWS의 서비스가 제공하는 계층을 이해하면, 어떤 것을 모니터링해야 하는지 보다 쉽게 파악이 가능하다.
애플리케이션 서버의 압단에 캐시 서버 혹은 인증서버, 로드 밸런서와 같은 Proxy 서버가 존재한다면, 이는 애플리케이션 서버와는 별도로 모니터링해야 한다. 애플리케이션 서버가 각 노드의 컴퓨팅 자원을 모니터링하는 데에 중점을 뒀다면, Proxy 서버, 그중에서도 HTTP 라우팅을 다루고 있는 서버는 요청 그 자체와 연관된 메트릭을 위주로 모니터링해야 gksek.
HTTP 요청/응답 관련 모니터링 대상은 쿠버네티스의 경우 인그레스, AWS 생태계에서는 ALB를 중점으로 보아야 한다.