DevOps/SRE 관점에서 알아야 할 모니터링 개념 정리

운영 환경을 관리하다 보면 단순히 "알람이 울린다" 수준을 넘어, 어떤 알람이 의미 있고 어떤 알람이 노이즈인지 구분하는 것이 중요하다. 특히 잘못 설계된 모니터링은 오히려 장애 대응 능력을 떨어뜨릴 수 있다.

이번 글에서는 운영 현장에서 자주 등장하는 False Positive, Flapping, Alert Fatigue 등의 개념을 정리해본다.

---

False Positive

False Positive는 실제로는 문제가 없지만 시스템이 장애로 잘못 판단하는 경우를 의미한다.

예를 들어 서비스는 정상적으로 동작하고 있지만 일시적인 네트워크 지연으로 헬스체크가 실패하여 장애 알람이 발생하는 경우가 있다.

서비스 정상
↓
헬스체크 실패
↓
장애 알람 발생
↓
실제 서비스 영향 없음

반대로 실제 장애가 발생했지만 탐지하지 못하는 경우는 False Negative라고 한다.

운영에서는 False Negative가 더 위험하지만, False Positive가 많아질 경우 운영자가 알람을 신뢰하지 않게 되는 문제가 발생한다.

---

Flapping

Flapping은 시스템 상태가 정상과 비정상 사이를 짧은 시간 동안 반복적으로 오가는 현상을 의미한다.

정상
↓
장애
↓
정상
↓
장애
↓
정상

대표적인 원인은 다음과 같다.

• 네트워크 지연
• CPU 스파이크
• GC Pause
• 과도하게 민감한 헬스체크
• 외부 API 응답 지연
• Autoscaling 중 일시적인 응답 실패

예를 들어 Kubernetes에서 Readiness Probe가 너무 민감하게 설정된 경우 다음과 같은 현상이 발생할 수 있다.

Ready
NotReady
Ready
NotReady
Ready

이러한 상태를 Readiness Flapping이라고 부른다.

---

Noisy Alert

Noisy Alert는 실제 운영 가치가 거의 없는 알람을 의미한다.

예를 들어 CPU 사용률이 90%를 넘었다는 이유만으로 알람이 발생하지만 실제 서비스에는 아무런 영향이 없는 경우가 있다.

CPU 92%
↓
경고 발생
↓
서비스 정상

또는 배치 서버처럼 원래 CPU 사용률이 높은 시스템에 동일한 기준을 적용하는 경우도 있다.

Noisy Alert가 많아질수록 운영자는 중요한 알람과 중요하지 않은 알람을 구분하기 어려워진다.

---

Alert Fatigue

Alert Fatigue는 알람 피로도를 의미한다.

지속적으로 의미 없는 알람이 발생하면 운영자는 점차 알람을 무시하게 된다.

09:00 장애
09:05 복구
09:10 장애
09:15 복구
09:20 장애

처음에는 확인하던 운영자도 나중에는

또 가짜 알람이겠지

라고 생각하게 된다.

문제는 진짜 장애가 발생했을 때도 같은 방식으로 대응하게 된다는 점이다.

따라서 Alert Fatigue는 운영 조직의 장애 대응 능력을 크게 저하시킬 수 있다.

---

Hysteresis

Hysteresis는 장애 진입 조건과 복구 조건을 다르게 설정하는 기법이다.

예를 들어 다음과 같은 기준이 있다고 가정해보자.

CPU 80% 이상 → 장애
CPU 79% 이하 → 정상

CPU 사용률이 79~80% 사이를 반복하면 상태가 계속 바뀌게 된다.

이를 방지하기 위해 다음과 같이 설정한다.

CPU 80% 이상 → 장애 진입

CPU 60% 이하 → 정상 복귀

그러면 60~80% 구간에서는 현재 상태를 유지하게 된다.

에어컨 온도 조절도 대표적인 Hysteresis 사례이다.

---

Debounce

Debounce는 짧은 변화를 무시하고 일정 시간 지속되는 경우에만 상태를 변경하는 방식이다.

예를 들어 CPU 사용률이 순간적으로 상승하는 경우를 생각해보자.

CPU 95%
지속 시간 2초

이 정도는 무시한다.

반면

CPU 95%
지속 시간 5분

이면 경고를 발생시킨다.

즉, 순간적인 스파이크에 의해 알람이 발생하지 않도록 하는 기법이다.

---

Health Check Tuning

Health Check Tuning은 헬스체크 민감도를 적절하게 조정하는 작업이다.

예를 들어 다음 설정은 매우 공격적이다.

periodSeconds: 5
timeoutSeconds: 1
failureThreshold: 1

한 번만 실패해도 장애로 판단한다.

반면 아래 설정은 훨씬 안정적이다.

periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 3

이 경우 30초 동안 연속 실패해야 장애로 간주된다.

튜닝의 목표는 단순하다.

실제 장애는 빠르게 탐지하고
가짜 장애는 최소화한다.

---

MTTD (Mean Time To Detect)

장애 발생 후 탐지하기까지 걸리는 평균 시간이다.

14:00 장애 발생
14:20 장애 발견

MTTD = 20분

모니터링 품질을 평가할 때 중요한 지표다.

---

MTTR (Mean Time To Recovery)

장애 발생 후 복구 완료까지 걸리는 평균 시간이다.

14:00 장애 발생
14:20 발견
14:40 복구 완료

MTTR = 40분

운영 조직의 복구 능력을 나타내는 대표적인 지표다.

---

SLO (Service Level Objective)

서비스가 달성해야 하는 목표 수준이다.

예시

가용성 99.9%

또는

95% 요청이 500ms 이하

처럼 정의할 수 있다.

---

SLA (Service Level Agreement)

고객과 계약한 서비스 수준이다.

예시

가용성 99.9% 미만 시 보상

SLO는 내부 목표이고 SLA는 외부 약속이라고 볼 수 있다.

---

Error Budget

SLO에서 허용된 실패 범위를 의미한다.

예를 들어 SLO가 다음과 같다면

99.9% 가용성

한 달 동안 허용 가능한 실패율은

0.1%

이다.

이 허용 범위를 Error Budget이라고 한다.

Google SRE에서 매우 중요하게 다루는 개념이다.

---

Symptom Alert vs Cause Alert

Symptom Alert

사용자가 실제로 영향을 받는 증상을 감지한다.

예시

• HTTP 5xx 증가
• 응답 시간 증가
• 로그인 실패 증가
• 결제 실패 증가

운영 관점에서 가장 중요한 알람이다.

---

Cause Alert

문제의 원인을 감지한다.

예시

• CPU 95%
• 메모리 부족
• 디스크 Full
• DB Connection Pool 고갈

원인을 빠르게 파악하는 데 도움이 된다.

---

마무리

운영 환경에서 좋은 모니터링은 "알람을 많이 발생시키는 것"이 아니다.

진짜 중요한 목표는 다음과 같다.

사람이 즉시 대응해야 하는 알람만 울리는 것

False Positive가 많아지면 Noisy Alert가 되고, Noisy Alert는 Alert Fatigue를 유발한다. 결국 Flapping과 같은 현상이 반복되면서 운영자는 알람을 신뢰하지 않게 된다.

따라서 모니터링 시스템은 단순히 감시하는 도구가 아니라, 신뢰할 수 있는 의사결정 도구가 되어야 한다.