[Cloud Computing] Monitoring & Observability
Monitoring & Observability
계기판을 보는 것과, 차가 왜 이상한지 스스로 진단하는 것의 차이. 모니터링과 옵저버빌리티를 각각 충분히 뜯어본 뒤, 마지막에 둘의 진짜 차이를 정리한다.
| Category | Level | Reads | Status |
|---|---|---|---|
| Cloud Computing · SRE | 초급 ~ 중급 | 약 17분 | VERIFIED |
모니터링이란?
모니터링은 미리 정해둔 지표(Metric)를 수집하고, 정상 범위를 벗어나면 알려주는 활동이다.
자동차 계기판을 떠올리면 된다. 속도계, 온도계, 연료계 — 미리 뭘 볼지 정해뒀고, 바늘이 빨간 구역에 들어가면 경고등이 켜진다. 모니터링도 똑같다. "CPU 사용률", "응답 시간", "에러율" 처럼 우리가 미리 중요하다고 정한 값들을 계속 지켜보다가, 임계치를 넘으면 알림을 보낸다.
지표가 미리 정한 기준값(예: CPU 90% 이상)을 넘으면 알림을 발생시키는 방식. 모니터링의 가장 기본적인 동작 원리다.
모니터링의 장단점
- 구축이 비교적 간단하고, 결과를 직관적으로 이해하기 쉬움
- "이 지표가 위험하면 알려줘"라는 명확한 규칙 기반 대응 가능
- 대시보드 하나로 시스템 전체 상태를 한눈에 파악
- 리소스 사용량이 상대적으로 적음(정해진 지표만 수집)
- 미리 정해둔 지표만 볼 수 있음 — 예상 못 한 문제는 놓침
- "무언가 잘못됐다"는 알지만 "왜"는 알기 어려움
- MSA처럼 서비스가 많아지면 지표만으로 원인 추적이 힘들어짐
- 임계치 설정을 잘못하면 알림 피로(너무 잦은 알림)가 생김
AWS 서비스 & 오픈소스
AWSAmazon CloudWatch — AWS 리소스의 지표·로그·알람을 통합 수집하는 완전관리형 모니터링 서비스. EC2, RDS, Lambda 등 거의 모든 AWS 서비스가 기본 연동된다.
OPEN SOURCE| 도구 | 특징 |
|---|---|
| Prometheus | 메트릭 수집·저장의 사실상 표준. Kubernetes 생태계와 강하게 결합 |
| Grafana | Prometheus 등의 데이터를 시각화하는 대시보드 도구(수집 자체는 안 함) |
| Zabbix / Nagios | 전통적인 서버·네트워크 모니터링 도구, 온프레미스 환경에서 여전히 널리 쓰임 |
| Datadog | 모니터링에서 시작해 옵저버빌리티 전반으로 확장한 상용 SaaS |
시간에 따라 변하는 숫자 하나(예: CPU 사용률 73%). 모니터링의 가장 기본 재료이며, 뒤에서 볼 옵저버빌리티의 "세 기둥" 중 하나이기도 하다.
실무에 적용되는 방식
CPU, 메모리, 요청 수, 에러율 같은 핵심 지표를 한 화면에 모아두고 상시 확인한다.
임계치를 넘으면 Slack, 이메일, 온콜 시스템(PagerDuty 등)으로 자동 알림을 보낸다.
서비스가 살아있는지 주기적으로 핑을 보내 확인하고, 실패하면 자동으로 재시작하거나 알린다.
옵저버빌리티란?
옵저버빌리티(Observability)는 시스템 내부에서 무슨 일이 일어나는지, 외부에서 관찰한 데이터만으로 추론할 수 있는 능력이다.
다시 자동차에 비유하면 — 모니터링이 "미리 달아둔 계기판을 보는 것"이라면, 옵저버빌리티는 정비사가 처음 보는 이상 증상이 생겼을 때, 엔진 소리·진동·각종 센서 로그를 조합해서 "왜" 이런 일이 생겼는지 스스로 진단해내는 능력에 가깝다. 미리 준비한 계기판이 없어도, 시스템이 충분히 "관찰 가능"하다면 원인을 파헤칠 수 있다.
이 용어는 원래 제어이론에서 왔다 — "시스템의 외부 출력만으로 내부 상태를 얼마나 잘 알아낼 수 있는가"를 뜻하는 수학적 개념이었는데, 소프트웨어 업계가 그대로 가져다 썼다.
데이터가 가질 수 있는 고유한 값의 다양성. 옵저버빌리티는 사용자ID, 요청ID처럼 매우 다양한(High Cardinality) 값 기준으로도 자유롭게 파고들 수 있어야 한다 — 이게 전통 모니터링과의 큰 차이다.
옵저버빌리티의 세 기둥
Trace(분산 트레이싱)가 특히 핵심이다. 하나의 요청이 여러 마이크로서비스를 거쳐갈 때, 그 요청이 지나간 전체 경로와 각 구간에서 걸린 시간을 하나로 이어서 보여준다. "어느 서비스에서 느려졌는지"를 로그를 일일이 뒤지지 않고 바로 찾을 수 있다.
하나의 요청이 여러 서비스를 거치는 과정을 하나의 흐름(Trace)으로 엮어 추적하는 기법. 각 서비스를 거친 구간을 Span이라 부른다.
옵저버빌리티의 장단점
- 예상하지 못했던 문제의 원인도 사후에 파고들어 찾아낼 수 있음
- MSA·분산 시스템처럼 복잡한 환경에서 특히 강력함
- 미리 정한 질문뿐 아니라, 그때그때 임의의 질문을 데이터에 던질 수 있음
- 모든 요청에 Trace를 심어야 해서 계측(Instrumentation) 작업이 필요함
- 데이터량이 훨씬 많아 저장·처리 비용이 큼
- 도입·학습 난이도가 모니터링보다 높음
AWS 서비스 & 오픈소스
AWSAWS X-Ray — 분산 트레이싱 전용 서비스. 요청이 Lambda, API Gateway, DynamoDB 등을 거치는 경로를 시각화해서 병목을 찾아준다. CloudWatch와 함께 쓰면 메트릭·로그·트레이스를 아우르는 옵저버빌리티가 완성된다.
OPEN SOURCE| 도구 | 특징 |
|---|---|
| OpenTelemetry | 메트릭·로그·트레이스 수집을 표준화하는 CNCF 프로젝트. 특정 벤더에 종속되지 않게 계측 코드를 통일 |
| Jaeger / Zipkin | 분산 트레이싱 전용 오픈소스 도구, Trace 시각화에 특화 |
| Grafana LGTM 스택 | Loki(로그)·Grafana(시각화)·Tempo(트레이스)·Mimir(메트릭)를 조합한 올인원 스택 |
| Honeycomb | High Cardinality 데이터 탐색에 특화된 옵저버빌리티 SaaS 선구자 |
실무에 적용되는 방식
대표적인 흐름은 이렇다. 사용자 요청 하나가 여러 서비스를 거치며 각 서비스가 Trace ID를 이어받아 로그를 남기고, 이 모든 걸 하나로 묶어서 "이 요청은 A→B→C를 거쳤고, C에서 800ms가 걸려서 전체가 느려졌다"는 식으로 원인을 정확히 짚어낸다. 장애 발생 시 담당 엔지니어가 "왜"라는 질문을 데이터에 직접 던지며 파고들 수 있다는 게 핵심이다.
그래서, 진짜 차이가 뭔가
이제 둘을 나란히 놓고 보면 차이가 선명해진다.
| 구분 | Monitoring | Observability |
|---|---|---|
| 기본 질문 | "이 지표가 정상 범위인가?" | "왜 이런 일이 일어났나?" |
| 다루는 문제 | 미리 알고 있는 문제(Known Unknowns) | 예상 못 한 문제까지(Unknown Unknowns) |
| 데이터 관점 | 미리 정한 지표 위주 | Metrics + Logs + Traces를 자유롭게 결합 |
| 탐색 방식 | 정해진 대시보드를 확인 | 임의의 질문을 즉석에서 데이터에 던짐 |
| 적합한 환경 | 비교적 단순한 시스템 | MSA 등 복잡하게 얽힌 분산 시스템 |