[AWS EKS] EKS Observability 2 - Monitoring과 Observability 개념, 기능, 차이점, 핵심 요소
AWS EKS Workshop Study 3기
이 글은 CloudNet@팀의 AWS EKS Workshop Study(AEWS) 3기 스터디 내용을 바탕으로 작성되었습니다.
AEWS는 CloudNet@의 '가시다'님께서 진행하는 스터디로, EKS를 학습하는 과정입니다.
EKS를 깊이 있게 이해할 기회를 주시고, 소중한 지식을 나눠주시는 가시다님께 다시 한번 감사드립니다.
이 글이 EKS를 학습하는 분들께 도움이 되길 바랍니다.
1. 개요
모니터링과 관측 가능성은 IT 시스템의 운영 상태를 분석하고 문제를 해결하는 데 중요한 개념입니다.
모니터링은 사전에 정의된 기준을 기반으로 시스템의 정상 작동 여부를 감시하는 역할을 하며,
관측 가능성은 외부 출력 데이터(로그, 메트릭, 트레이스)를 기반으로 시스템의 내부 상태를 분석하는 개념입니다.
이 두 개념은 단순한 시스템과 복잡한 분산 시스템에서 문제를 분석하는 접근 방식에서 큰 차이를 보입니다.
2. 모니터링(Monitoring)
2.1. 정의
모니터링은 사전에 정의된 메트릭을 기반으로 시스템의 상태를 감시하고, 문제가 발생할 경우 이를 탐지하여 경고하는 프로세스입니다.
- 목적: 시스템의 성능을 지속적으로 추적하여 장애 발생을 감지하고 조기에 대응하는 것
- 데이터 소스: CPU 사용량, 메모리 사용량, 응답 시간, 오류율 등 미리 정의된 메트릭
- 특징:
- IT 시스템의 운영 상태를 감시
- 특정 임계값(Threshold)을 초과하면 경고(Alert) 발생
- 단순한 시스템(예: 단일 서버 환경)에서 효과적
2.2. 주요 기능
| 기능 | 설명 |
|---|---|
| 메트릭 기반 감시 | CPU 사용량, 메모리 사용량, 네트워크 트래픽 등을 수집하여 이상 여부를 감시 |
| 정적 경고 시스템 | 특정 기준(예: CPU 사용률 90% 초과 시 경고)에 도달하면 알람 발생 |
| 대시보드 제공 | 운영자가 시스템 상태를 실시간으로 확인할 수 있도록 시각화 |
| 자동화된 대응 | 임계값 초과 시 자동으로 대응(예: 리소스 확장, 알림 전송) |
2.3. 예시
- 서버의 CPU 사용률이 90%를 초과하면 경고 발생
- 웹 애플리케이션의 응답 시간이 500ms를 초과하면 장애 감지
- 네트워크 트래픽이 특정 한도를 넘으면 자동 스케일링 수행
3. 관측 가능성(Observability)
3.1. 정의
관측 가능성은 로그(Log), 메트릭(Metric), 트레이스(Trace)를 활용하여 시스템의 내부 상태를 분석하고, 원인을 파악하는 개념입니다.
- 목적: 시스템의 내부 상태를 보다 깊이 있게 이해하고, 장애의 원인을 신속하게 분석하는 것
- 데이터 소스: 로그(Log), 메트릭(Metric), 트레이스(Trace) 등 다양한 데이터 활용
- 특징:
- 복잡한 분산 시스템(MSA, 클라우드 환경)에 필수적
- 단순 감지가 아니라 문제의 원인까지 추적 가능
- 예측하지 않은 문제도 해결 가능
3.2. 주요 기능
| 기능 | 설명 |
|---|---|
| 로그(Log) 수집 | 시스템 내 모든 이벤트 및 오류를 기록하여 디버깅 가능 |
| 트레이스(Trace) 분석 | 요청(Request)이 여러 마이크로서비스를 거칠 때 전체 흐름을 추적 |
| 메트릭(Metric) 기반 분석 | CPU, 메모리, 트래픽 등의 수치를 시간별로 분석 |
| 실시간 쿼리 및 분석 | 단순한 알람이 아니라, 문제의 원인을 찾기 위해 데이터를 직접 탐색 가능 |
3.3. 예시
- MSA(마이크로서비스 아키텍처) 환경에서 어떤 마이크로서비스에서 장애가 발생했는지 분석
- 웹사이트에서 사용자가 요청한 API가 실패했을 때, 로그와 트레이스를 통해 문제의 원인을 찾음
- 전체적인 애플리케이션 성능을 최적화하기 위해 데이터 흐름을 분석
4. 모니터링과 관측 가능성의 차이점
| 비교 항목 | 모니터링(Monitoring) | 관측 가능성(Observability) |
|---|---|---|
| 정의 | 특정 특정 메트릭 추적으로 문제 감지 | 외부 출력 데이터로 시스템 상태 이해 |
| 목표/목적 | 시스템의 이상 감지 및 알람 제공 | 시스템 내부 상태 분석 및 문제 원인 파악, 시스템 최적화 |
| 데이터 수집 | 미리 정의된 메트릭(CPU, 메모리 등) | 로그(Log), 메트릭(Metric), 트레이스(Trace), 이벤트 등 |
| 사용 사례 | 단순 시스템 감시 (예: 서버 다운 감지) | 복잡한 시스템 분석 (예: 특정 요청 지연 원인 분석) |
| 적용 대상/시스템 유형 | 단순 시스템, 온프레미스 서버, 잘 알려진 파라미터 | 클라우드, MSA, 분산 시스템, 다중 컴포넌트 |
| 상호작용 방식 | 정적 경고. 사전에 정의된 경고 (임계값(Threshold) 기반) | 동적 분석 (질문 기반) (문제 발생 시 새로운 쿼리 수행) |
5. 관측 가능성의 핵심 요소
| 비교 항목 | 메트릭 (Metrics) | 로그 (Logs) | 추적 (Tracing) |
|---|---|---|---|
| 정의 | 수치로 표현된 성능 데이터 | 시스템 이벤트 기록 | 요청이 시스템을 거치는 과정 추적 |
| 형태 | 숫자 (정량적 데이터) | 텍스트 (비정형 데이터) | 트랜잭션 흐름 데이터 |
| 예시 데이터 | CPU 사용률, 응답 시간, 요청 수 | 오류 메시지, 로그인 시도, API 호출 로그 | A 서비스 → B 서비스 → C 서비스 요청 흐름 |
| 주요 목적 | 시스템 성능 모니터링 및 알람 | 이벤트 분석 및 디버깅 | 서비스 간 호출 경로 및 병목 현상 분석 |
| 저장 방식 | 시계열 데이터베이스(TSDB) | 로그 파일 또는 로그 관리 시스템 | 분산 트레이싱 시스템 (Jaeger, Zipkin) |
| 활용 도구 | Prometheus, Grafana | ELK Stack, Loki | Jaeger, Zipkin |
5.1. 메트릭(Metric)
- 정의: 시스템 성능을 정량적으로 나타내는 수치 데이터
- 예시: CPU 사용률, 응답 시간, 트래픽 양
- 도구: Prometheus, Grafana
5.2. 로그(Log)
- 정의: 시스템이 수행한 이벤트를 기록한 데이터
- 예시: 오류 메시지, 사용자 로그인 이벤트, API 호출 로그
- 도구: ELK Stack(Elasticsearch, Logstash, Kibana), Loki
5.3. 추적/트레이스(Trace)
- 정의: 시스템 내에서 하나의 요청이 여러 서비스 간을 이동하는 경로를 추적하는 데이터
- 예시: 사용자의 요청이 A 서비스 → B 서비스 → C 서비스를 거치는 과정 추적
- 도구: Jaeger, Zipkin
6. 서비스 신뢰성 관리(SLI, SLO, SLA)
| 항목 | SLI(서비스 수준 지표) | SLO(서비스 수준 목표) | SLA(서비스 수준 계약) |
|---|---|---|---|
| 정의 | 서비스 성능을 측정하는 실제 값 | 유지해야 하는 성능 목표 | 고객과 맺은 공식 계약 |
| 목적 | 현재 서비스 상태를 모니터링 | 내부적으로 목표 설정 | 고객과의 계약 보장 |
| 예시 | 99.95%의 가용성 | 99.9% 이상의 가용성 목표 | 99.9% 미만이면 환불 제공 |
| 법적 구속력 | ❌ 없음 | ❌ 없음 | ✅ 있음 |
| 위반 시 결과 | 단순 데이터 측정 | 내부 경고 및 개선 조치 | 보상금 지급, 계약 위반 가능 |
7. 결론
모니터링은 사전에 정의된 지표를 활용하여 시스템의 이상을 감지하는 역할을 하며,
관측 가능성은 로그, 메트릭, 트레이스를 활용하여 더 깊이 있는 원인 분석 및 최적화를 수행하는 개념입니다.
특히 현대의 분산 시스템 환경에서는 관측 가능성(O11y)이 필수적이며,
OpenTelemetry와 같은 표준을 활용하여 로그, 메트릭, 트레이스를 통합 관리하는 것이 중요합니다.
