모니터링의 중요성 (Feat. Node.js 핵심 지표)

본 게시글은 네이버 김성근 테크리더님의 ‘웹 서비스 성능 최적화 및 시스템 안정성’ 특강을 듣고 요약한 내용입니다.

모니터링의 중요성

• 측정할 수 없으면 개선할 수 없다

• 모니터링이 필요한 이유
1. 장애 조기 탐지: 사용자가 알기 전에 문제 발견
2. 용량 계획: 트래픽 패턴 분석으로 스케일링 계획
3. 성능 최적화: 병목 지점 파악 및 개선

• 모니터링이 없다면? → 대응 시작까지 30분 이상
1. 사용자가 장애 신고
2. CS팀이 개발팀에 전달
3. 개발팀이 원인 파악 시작

• 모니터링 적용 시 → 대응 시작까지 1분 이내
1. 이상 징후 자동 감지
2. 담당자에게 알림 발송
3. 대시보드로 즉시 상황 파악

• MTTR(Mean Time To Recovery)를 줄이는 것이 목표
• 모니터링은 빠른 감지와 대응의 시작점

백분위수(Percentile)란?

• 백분위수(Percentile):
• 전체 데이터를 순서대로 나열했을 때, 특정 비율 이하에 해당하는 값
• P99 = 100개 중 99번째로 빠른 응답시간

• P50:
• 중앙값 (Median)
• 요청의 50%가 이 시간 이내에 응답
• 일반적인 사용자 경험. 대부분의 요청이 이 정도 속도.

• P95:
• 상위 5% 제외
• 요청의 95%가 이 시간 이내에 응답
• 대부분의 사용자 경험을 대표. SLA 기준으로 자주 사용.

• P99:
• 상위 1% 제외
• 요청의 99%가 이 시간 이내에 응답
• 최악의 경우 감지. 숨겨진 성능 문제 발견에 유용.

왜 평균(Average)이 아닌 백분위수인가?

• 평균의 문제점
• 극단값(Outlier)에 의해 왜곡됨
• 실제 사용자 경험을 대표하지 못함
• 성능 저하를 숨길 수 있음

• 예시
• 서버 A가 응답이 90, 100, 98, 105ms 라면
• 평균: 100ms
• P99: 105ms
• 서버 B가 응답이 50, 50, 50, 50, 300ms 라면
• 평균: 100ms
• P99: 300ms
• 평균은 같지만 서버 B는 20%의 사용자가 6배 느린 경험을 한다!

• 하루 100만 요청이면 P99 = 1만 명이 겪는 최악의 경험

• Tip: P50과 P99 차이가 크다면 일부 요청에서 성능 문제가 발생하고 있다는 신호

• 따라서 평균 대신 P50, P95, P99를 함께 모니터링하여 전체적인 성능 분포를 파악하자.

Node.js 서버 핵심 모니터링 지표

1. Event Loop Lag

• 이벤트 루프가 작업을 처리하는 데 걸리는 지연 시간

• 경고: 100ms 초과 시 응답 지연 발생

• 원인: CPU 집약 작업, 동기 코드

2. Heap Memory

• V8 힙 메모리 사용량 (heapUsed, heapTotal)

• 경고: heapTotal의 80% 초과 시

• 위험: 메모리 누수 시 OOM 크래시

3. CPU Usage

• 프로세스 CPU 사용률

• 경고: 70% 지속 시 스케일 아웃 고려

• 참고: 싱글 스레드 특성 고려

4. Active Handles

• 열린 연결, 타이머, 파일 핸들 수

• 경고: 지속적으로 증가하면 누수

• 확인: DB, HTTP 연결 정리 여부

5. GC (Garbage Collection)

• GC 빈도와 소요 시간, 너무 자주/길면 성능 저하

6. HTTP Requests

• 요청 수, 응답시간(P50/P95/P99), 에러율

7. 외부 의존성

• DB, Redis, 외부 API 응답시간 및 에러율

알람(Alert) 설정 전략

• 효과적인 알람은 적시에 적절한 정보를 전달한다

1. CRITICAL
• 즉시 대응 필요
• 예제
• 서비스 다운
• 에러율 5% 초과
• P99 응답시간 5초 초과
• 알림: 전화, SMS, 슬랙 멘션

2. WARNING
• 주의 관찰 필요
• 예제
• 에러율 1% 초과
• P95 응답시간 2초 초과
• CPU/Memory 80% 초과
• 알림: 슬랙 채널 알림

3. INFO
• 참고 정보
• 예제
• 배포 완료
• 스케일 아웃/인
• 설정 변경
• 알림: 슬랙 채널 기록

좋은 알람의 조건

• Actionable: 받으면 무엇을 해야 하는지 명확

• Low Noise: 오탐(False Positive)이 적음

• Timely: 문제 발생 후 즉시 발송

피해야 할 알람

• Alert Fatigue: 너무 많은 알람은 무시됨

• Flapping: 경계값에서 반복 발생

• No Context: 원인 파악이 어려운 알람

효과적인 대시보드 구성

• USE Method (리소스 관점) → 서버, DB, 캐시 등 인프라 모니터링에 적합
• Utilization - 사용률 (CPU, Memory %)
• Saturation - 포화도 (큐 길이, 대기 수)
• Errors - 에러 (실패 횟수, 에러 로그)

• RED Method (서비스 관점) → API, 마이크로서비스 모니터링에 적합
• Rate - 요청 수 (RPS, 초당 요청)
• Errors - 에러율 (%, 4xx/5xx)
• Duration - 응답시간 (P50/P95/P99)

장애 대응 프로세스

1. 감지
• 모니터링 알람 수신
• 증상 확인
• 영향 범위 파악

2. 대응
• 담당자 소집
• 원인 분석
• 임시 조치 실행

3. 복구
• 서비스 정상화 확인
• 모니터링 지표 안정화
• 사용자 공지

4. 회고
• 타임라인 정리
• 근본 원인 분석
• 재발 방지책 수립

핵심 원칙

1. 복구 우선: 원인 분석보다 서비스 복구가 먼저

2. 커뮤니케이션: 진행 상황 실시간 공유

3. 기록: 모든 조치와 시간을 기록

회고 필수 항목

• 장애 요약 (What happend)

• 타임라인 (언제 무엇을)

• 영향 범위 (사용자, 매출 등)

• 근본 원인 (5 Whys)

• Actions Items (담당자, 기한)

실전 모니터링 체크리스트

• 모니터링은 한 번 설정하고 끝이 아님. 서비스 변화에 따라 지속적으로 개선

필수 모니터링 지표

• 응답시간 (P50, P95, P99 모두 측정)

• 에러율 (4xx, 5xx 비율 분리)

• 처리량 RPS (초당 요청 수, 트래픽 추이)

• 가용성 (Uptime %, Helath Check)

• 리소스 사용량 (CPU, Memory, Disk, Network)

알람 임계치 권장값

• 에러율 (Warn: 1% / Crit: 5%)

• P95 응답시간 (Warn: 1s / Crit: 3s)

• CPU 사용률 (Warn: 70% / Crit: 90%)

• Memory 사용률 (Warn: 80% / Crit: 95%)

• Event Loop Lag (Warn: 50ms / Crit: 100ms)

• 서비스 특성에 따라 조절 필요!

운영 체크리스트

• 대시보드가 구성되어 있는가?

• Critical 알람이 설정되어 있는가?

• 알람 수신자가 지정되어 있는가?

• 로그가 중앙에서 수집되는가?

• 장애 대응 프로세스 문서화가 되어있는가?

• 런북(Runbook)이 준비되어 있는가?

• 정기적으로 모니터링을 점검하는가?

정리

• 백분위수: 평균 대신 P50, P95, P99로 실제 사용자 경험 측정

• USE / RED Method: 리소스는 USE, 서비스는 RED로 체계적 모니터링

• 효과적인 알람: Actionable하고 Low Noise한 알람만 설정

• Node.js 핵심 모니터링 지표
1. Event Loop Lag: 100ms 이하
2. Heap Memory: 80% 이하
3. SSR 응답시간: P95 200ms 이하
4. 에러율: 1% 이하
5. Active Handles: 누수 없음

• 모니터링의 목표: 빠른 감지 → 빠른 대응 → MTTR 최소화