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