모니터링 vs 관측가능성, 그리고 SLI·SLO·SLA

728x90

들어가며

EKS와 같은 K8s 기반의 컨테이너 운영 환경에서의 서비스는 점점 더 복잡해지고 있습니다. 이렇게 복잡한 시스템이 안정적으로 운영되기 위해서는 모니터링(monitoring)과 관측가능성(observability)을 통해 서비스 장애를 빠르게 감지하고, 문제의 원인을 빠르게 파악하며 성능을 개선하기 위해 데이터 분석을 해야 합니다. 이 글에서는 모니터링과 관측가능성의 차이점, 주요 데이터 유형(메트릭, 로그, 트레이싱), 그리고 SLI, SLO, SLA 개념을 정리해보겠습니다.

모니터링과 관측가능성

	모니터링	관측가능성
정의	특정 메트릭을 추적하여 문제를 감지	외부의 출력 데이터를 통해 시스템의 상태를 이해
목표	문제 발생 시 감지 및 알람	문제 원을 진단하고 시스템을 최적화
데이터 소스	미리 정의된 매트릭(CPU, Mem등)	로그, 매트릭, 트레이스, 이벤트 등
유형	단순한 시스템	복잡한 분산 시스템, 다중 컴포넌트
방식	임계값 기반한 정적 경고	질문을 기반으로 한 동적 쿼리 및 분석

모니터링(monitoring)

Google의 SRE팀에서 모니터링을 시스템에 대한 실시간 정량 데이터 수집, 처리, 집계, 표시"로 정의하며, 쿼리 수, 오류 수, 처리 시간 등을 포함한다고 설명

모니터링은 미리 정한 기준(CPU 사용률, 메모리 사용량등)으로 시스템이 잘 작동하고 있는지 지속적으로 감시하여 문제가 생기면 알람을 보내는 역할을 합니다. 즉, 장애를 빨리 발견하고 대응하여 서비스 중단(다운타임)을 줄이기 위해 사용됩니다.

예시
- CPU 사용량이 90%가 넘으면 경고 알람을 발생
- 서버의 응답 속도가 너무 느려지면 알람을 발생

관측가능성(observability)

IBM에서는 관측 가능성을 복잡한 시스템의 내부 상태를 외부 출력 데이터로 이해하는 능력으로 정의

모니터링 보다 한 단게 더 나아가서, 단순히 숫자만 보는 것이 아니라 로그(기록), 매트릭(숫자 데이터), 트레이스(요청 흐름)등을 분석해서 문제가 왜 발생했는지 파악하는 행위 입니다. 주로 MSA와 같은 복잡한 분산 시스템에서 예상치 못한 문제를 해결하기 위해 구성됩니다. 또한, APM 대신 추적(trace) 이라고 부르며, 계측(instrumentation)과 텔레메트리(telemetry) 라는 용어를 범용적으로 사용함.

예시
- "서버가 느려졌네?" -> 단순 모니터링으로 확인
- "왜 느려진거지?" -> 로그, 트레이스를 분석해보니 데이터베이스 연결 문제 때문에 느려진것으로 확인!

데이터 유형

	Metric	Log	Tracing
정의	수치로 표현된 성능 관련 데이터	시스템의 이벤트를 기록	요청이 시스템을 거치는 과정
형태	숫자	텍스트	트랜잭션 흐름 데이터
목적	시스템 성능 모니터링 및 알람	이벤트 분석 및 디버깅	서비스 간 호출 경로 및 병목 현상 분석
저장 방식	시계열 데이터베이스(TSDB)	로그 파일 또는 로그 관리 시스템	분산 트레이싱 시스템(Jaeger, Zipkin)
활용 도구	Prometheus, Grafana(대시보드)	ELK Stack, Loki	Jaeger, Zipkin
예시	CPU 80%, 응답시간 200ms	"DB 연결 실패", "로그인 성공"	이 요청이 API → DB → 응답까지 800ms 걸림

metric 👉 CPU 80%와 같이 시스템 성능을 숫자로 측정

시스템의 성능, 상태, 사용량등을 실시간으로 숫자로 측정되는 정량적인 데이터입니다. 같은 시간에 따라 변화하는 데이터이며 빠르게 분석하고, 시각화(그래프, 대시보드)할 수 있습니다.

log 👉 DB Connectoin Failed와 같이 특정 이벤트를 기록

시스템에서 발생하는 이벤트들로 텍스트 형태로 저장되며 디버깅과 원인 분석에 사용됩니다. 사람이 읽을 수 있는 텍스트 데이터이며, 특정 시간에 어떤 일이 일어났는지 기록되어있는 것이 특징입니다.

tracing 👉 요청이 DB에서 500ms 걸림과 같이 요청이 시스템 내부에서 어떻게 처리되는지 추적

마이크로 서비스, 서버 간의 데이터 흐름을 시각적으로 보여줌으로서 사용자의 요청이 시스템 내부에서 어떻게 흐르는지 알 수 있습니다. 즉, 요청이 여러 서비스에서 어떻게 처리되는지 분석할 수 있으며, 느려진 성능 문제의 원인을 파악하는 데 도움을 주는데 이때, 각 요청마다 TraceID를 부여하여 요청이 어디를 지나갔는지 알 수 있습니다.

SLI, SLO, SLA

https://www.atlassian.com/ko/incident-management/kpis/sla-vs-slo-vs-sli

SLI

SLI (Service Level Indicator, 서비스 수준 지표)는 사용자가 서비스의 품질을 어떻게 경험하는지를 수치로 나타내어 서비스 품질을 측정하는 핵심 성능 지표입니다. 즉, 서비스가 얼마나 안정적으로 운영되고 있는지를 측정할 때 사용합니다.

예시
- 가용성: 서버가 99.5%의 시간동안 정상 작동함
- 응답 시간: API 요청 응답 시간이 평균 200ms 이하
- 에러율: 전체 요청 중 0.1% 이하가 실패

SLO

SLO (Service Level Objective, 서비스 수준 목표)는 서비스가 안정적으로 운영되기 위해 우리가 지켜야 하는 기준으로 운영팀과 비즈니스가 서비스 품질을 유지하기 위해 설정하는 SLI에 대한 목표 값입니다. 즉, 운영팀이 SLA를 충족시키기 위해 관리하는 내부 목표로 서비스의 신뢰성을 보장하고, 운영목표를 설정할 때 사용합니다.

예시
- 가용성 목표 : 우리 서비스는 99.95% 이상 가용성을 유지해야 한다.
- 응답 시간 목표 : API 응답 시간의 95%는 200ms 이하여야 한다.
- 에러율 목표 : 전체 요청 중 0.1% 이상이 실패하면 안된다.

SLA

SLA (Service Level Agreement, 서비스 수준 계약)은 SLO를 기반으로 고객과 맺는 공식적인 계약으로 SLA를 어길 경우, 고객에게 보상을 해야할 수도 있습니다. 즉, 고객과 계약을 맺거나 서비스 수준을 보장해야하는 경우에 사용되는 지표입니다.

예시
- 가용성 SLA : 99.9% 가용성을 보장하지 못한다면, 한달 요금의 10%를 환불한다.
- 응답시간 SLA : API 응답 시간이 500ms를 초과하면 서비스 요금 감면 적용한다.

참고

https://www.atlassian.com/ko/incident-management/kpis/sla-vs-slo-vs-sli

SLA, SLO, SLI 비교: 서비스 메트릭의 주요 차이점 | Atlassian

인시던트 관리에서 SLA, SLO, SLI 간의 차이를 이해하고 이 메트릭을 효과적으로 구현하는 방법을 알아보세요.

www.atlassian.com