about me
20'S LIFE IN SYDNEY and BUSAN
CI/CD 파이프라인의 마지막 Stage는 운영
서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링하는 과정으로 대표될 수 있습니다. 그렇다면 어떤 지표를 수집하고, 어떤 메트릭을 기준으로 삼아야 할까요?
메트릭이란?
메트릭은 시간에 따라 측정한 결과값입니다. 보다 넓은 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미하기도 합니다.
예를 들어, 시간당 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
인스턴스의 갯수
연결 유지
모니터링 구분
어떠한 서비스가 제대로 작동되는지를 확인하려면, 서비스 또는 시스템과 관련한 모든 변수들을 모니터링해야 합니다.
한편 반대로, 발생하는 모든 메트릭을 모니터링 하지도 않습니다. 모든 메트릭을 실시간으로 보는 것은 불가능할 뿐더러, 너무 많은 메트릭을 모니터링 하다보면, 정말 중요한 신호를 발견하기도 어렵습니다.
따라서 모니터링을 할 때에는 단계를 구분해서 계층적으로 할 필요가 있습니다.
블랙박스 모니터링과 화이트박스 모니터링
블랙박스와 화이트박스의 구분은 박스를 기준으로 관찰자가 밖에서 바라보느냐, 안에서 바라보느냐의 차이입니다.
박스는 애플리케이션이 될 수도 있고, 쿠버네티스 시스템이 될 수도 있습니다.
블랙박스 모니터링은 CPU/메모리/스토리지 등 인프라 수준의 모니터링에 유용합니다.
쿠버네티스 시스템의 경우, 클러스터 정상 작동 여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링하는 것도 블랙박스 모니터링에 해당합니다. 그러나, 애플리케이션이 왜 오류를 내는지는 알 수 없습니다.
화이트박스 모니터링은 시스템 내부의 측정 기준에 따라 모니터링하는 것을 의미합니다.
예를 들면, HTTP 요청, 500 에러의 발생 횟수, 레이턴시 등이 이에 해당합니다. 단순히 현상만 바라보는 것이 아닌, 현상이 발생한 근거를 알 수 있는 모니터링 방식입니다.
계층에 따른 모니터링 구분
논리적인 리소스의 집합이 하나의 상위 계층을 만듭니다. 앞서 공부했던 컨테이너 오케스트레이션 툴이나, AWS의 서비스가 제공하는 계층을 이해하면, 어떤 것을 모니터링해야 하는지 보다 쉽게 파악이 가능합니다. (왼쪽으로 갈 수록 상위 계층입니다)
파드나, 컨테이너 안에 포함된 애플리케이션의 메트릭은 별도로 다룹니다.
쿠버네티스
노드 > 클러스터 컴포넌트 > 파드
ECS
- 클러스터 > 서비스 > 태스크
EC2: 인스턴스에 대한 메트릭만 볼 수 있습니다.
Lambda: 함수에 대한 메트릭만 볼 수 있습니다.
Proxy 서버의 메트릭
애플리케이션 서버(WAS)의 앞단에 캐시 서버 혹은 인증 서버, 로드 밸런서와 같은 Proxy 서버가 존재한다면, 이는 애플리케이션 서버와는 별도로 모니터링해야 합니다.
애플리케이션 서버가 각 노드의 컴퓨팅 자원을 모니터링하는 데에 중점을 두었다면, Proxy 서버, 그 중에서도 HTTP 라우팅을 다루고 있는 서버는 요청 그 자체와 연관된 메트릭을 위주로 모니터링해야 합니다.
HTTP 요청/응답 관련 모니터링 대상은 쿠버네티스의 경우 인그레스, AWS 생태계에서는 Application Load Balancer를 중점으로 보아야 합니다.
사이트 신뢰성 엔지니어링 (SRE) 관련 메트릭
CPU 및 메모리, 사용량 등을 파악하는 것 외에도 네트워크 요청에 따른 응답 상태, 요청의 횟수나 시간 등도 중요한 지표가 될 수 있습니다.
이를 통해 어떤 서비스(웹사이트)가 온전히 사용자에게 전달될 수 있도록 가용성을 극대화 하는 기술/문화를 특별히 “사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)”라고 부릅니다.
조직마다 각기 상황이 다르고 아키텍처 중 특별한 메트릭을 사용할 수도 있겠지만, 여기서는 일반적인 주요 측정항목에 대해서 설명합니다. 아래는 구글의 SRE 조직에서 정의한 “네가지 황금 시그널(The Four Golden Signals)”로 SRE 모니터링의 주요 측정 항목입니다.
구글은 분산 환경에서 한정된 항목만을 측정할 수 있다면, 이 네가지에 집중할 것을 권장합니다.
대기 시간 (Latency)
대기 시간은 서비스가 요청에 응답하는 데 걸리는 시간을 나타냅니다. 핵심은 지속 시간뿐만 아니라 성공적인 요청의 대기 시간과, 실패한 요청의 대기 시간을 구별하는 데에도 중점을 두어야 합니다.
트래픽 (Traffic)
트래픽은 서비스에 대한 수요 측정입니다. 대표적인 예로는, 초당 HTTP 요청 수가 있습니다.
오류 (Errors)
오류는 실패한 요청/전체 요청 의 비율로 측정됩니다. 대부분의 경우 이러한 실패는 명시적이지만(예: HTTP 500 오류) 암시적일 수도 있습니다(예: "결과 없음"이라는 메시지를 본문으로 전달하는 HTTP 200 응답).
포화 수준 (Saturation)
포화는 서비스 또는 시스템 리소스를 “얼마나 가득 채워서 사용하는가”로 설명할 수 있습니다. 전형적인 예로는 과도한 CPU 자원 사용이 있습니다. CPU 자원이 부족하면, 스로틀링을 초래하고 결과적으로 응용 프로그램의 성능을 저하시킵니다.
주요 모니터링 패턴
시간이 지남에 따라 다양한 모니터링 방법이 개발되었습니다. 대표적으로 USE 패턴, RED 패턴이 있으며, 그밖에 다른 패턴 역시 유사하며 대기 시간, 트래픽, 오류 및 포화도를 측정하기 위한 SRE 요구와 크게 다르지 않습니다.
USE 패턴
USE 패턴은 모든 리소스에 대한 사용률(Utilization), 포화도(Saturation), 오류(Errors)를 체크하는 패턴을 의미합니다.
RED 패턴
RED 패턴은 비율(Rate), 오류(Errors) 및 기간(Duration)을 주요 메트릭으로 정의하는 패턴입니다.
댓글