Select a result to preview

[CloudNeta] EKS 워크샵 스터디 (5) - EKS 디버깅 마스터 가이드 (3)

#devlog #kubernetes #cloudneta

이번 게시글에서는 EKS 워크샵 스터디 제 5주차 내용을 작성합니다.

이 글은 3부로 나누어집니다.

  1. 5주차 - EKS 디버깅 마스터 가이드 (1)
  2. 5주차 - EKS 디버깅 마스터 가이드 (2)
  3. 5주차 - EKS 디버깅 마스터 가이드 (3) (현재 보고계신 글)

IX. 옵저버빌리티 아키텍처

Metrics / Logs / Traces 수집 → 분석 → 알림 파이프라인

flowchart LR
    A[Applications
메트릭/로그/트레이스]
    K[Kubernetes
이벤트/메트릭]
    N[Nodes
시스템 메트릭]

    ADOT[ADOT Collector
OpenTelemetry]
    CWA[CloudWatch Agent
Container Insights]
    PROM[Prometheus
kube-state-metrics]

    CWL[CloudWatch
Logs & Metrics]
    AMP[Amazon Managed
Prometheus]

    G[Grafana 대시보드]
    ALARM[CloudWatch Alarms]
    AM[Alertmanager]

    OUT[SNS / PagerDuty / Slack]

    A --> ADOT
    K --> CWA
    K --> PROM
    N --> CWA
    N --> PROM
    ADOT --> CWL
    CWA --> CWL
    PROM --> AMP
    CWL --> G
    AMP --> G
    CWL --> ALARM
    AMP --> AM
    ALARM --> OUT
    AM --> OUT

    style A fill:#4286f4,stroke:#2a6acf,color:#fff
    style K fill:#4286f4,stroke:#2a6acf,color:#fff
    style N fill:#4286f4,stroke:#2a6acf,color:#fff
    style ADOT fill:#fbbc04,stroke:#c99603,color:#000
    style CWA fill:#fbbc04,stroke:#c99603,color:#000
    style PROM fill:#fbbc04,stroke:#c99603,color:#000
    style CWL fill:#9333ea,stroke:#7623bf,color:#fff
    style AMP fill:#9333ea,stroke:#7623bf,color:#fff
    style G fill:#10b981,stroke:#0d8a63,color:#fff
    style ALARM fill:#ff9900,stroke:#cc7a00,color:#fff
    style AM fill:#ff9900,stroke:#cc7a00,color:#fff
    style OUT fill:#ff4444,stroke:#cc3636,color:#fff

Container Insights & Application Signals

영역 내용
Enhanced 모니터링 CloudWatch Agent가 노드/Pod/컨테이너 메트릭 자동 수집 — CPU, 메모리, 네트워크, 디스크 I/O. Fluent Bit으로 로그 수집 통합
Application Signals ADOT 기반 분산 추적 자동화 — X-Ray 트레이스 + CloudWatch 메트릭 통합. 서비스 맵 · 레이턴시 · 에러율 자동 계산
SLI/SLO 기반 알림 가용성 99.9% SLO / 레이턴시 P99 · 에러율 기반 SLI 측정 / Error Budget 소진율로 알림 트리거

Container Insights 설정 및 핵심 PromQL

# Container Insights Add-on 설치
aws eks create-addon --cluster-name $CLUSTER \
  --addon-name amazon-cloudwatch-observability

# CPU Throttling 감지 (25% 이상 → 성능 저하)
sum(rate(container_cpu_cfs_throttled_periods_total{namespace="prod"}[5m]))
/ sum(rate(container_cpu_cfs_periods_total{namespace="prod"}[5m])) > 0.25

# OOMKilled 감지
kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} > 0

# Node 메모리 85% 초과 경고
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 85

인시던트 디텍팅 4가지 패턴

패턴 방식 장점 한계 도구
임계값 기반 미리 정의한 값 초과 시 알림 구현 간단, 예측 가능 False Positive 많음 CloudWatch Alarms, PrometheusRule
이상 탐지 ML 기반 정상 패턴 학습 동적 환경에 적합 학습 기간 2주 필요 CloudWatch Anomaly Detection
복합 알람 여러 알람 AND/OR 조합 False Positive 대폭 감소 설정 복잡도 높음 CloudWatch Composite Alarms
로그 메트릭 필터 로그 패턴 → 메트릭 변환 커스텀 이벤트 탐지 실시간성 제한 CloudWatch Metric Filters

인시던트 디텍팅 성숙도 모델

레벨 명칭 MTTD 구현
L1 기본 < 30분 수동 모니터링
L2 표준 < 10분 임계값 + 로그 필터
L3 고급 < 5분 이상 탐지 + 복합 알람
L4 자동화 < 1분 자동 감지 + 자동 복구

알림 최적화 & Alert Fatigue 방지

전략 내용
Alert Fatigue 방지 알림이 너무 많으면 운영팀이 알림을 무시. P3/P4 → Slack 채널만 / P1/P2만 PagerDuty. 주기적 알림 규칙 리뷰 필수
Composite Alarm 활용 여러 시그널 조합으로 실제 인시던트만 감지. "에러율 증가 AND 지연시간 증가" = 서비스 장애 / "에러율 증가 AND Pod 재시작" = 앱 크래시

권장 알림 채널 매트릭스

심각도 알림 채널 응답 SLA 예시
P1 Critical PagerDuty + Phone 15분 서비스 전체 다운
P2 High Slack DM + PagerDuty 30분 부분 장애, 성능 저하
P3 Medium Slack 채널 4시간 Pod 재시작, 리소스 경고
P4 Low Email / Jira 다음 영업일 디스크 증가, 인증서 만료

X. Top 10 에러 빠른 참조표

사고 발생 시 바로 찾아볼 수 있는 요약표를 정리해 보았습니다.

# 에러 / 증상 원인 핵심 명령어
1 CrashLoopBackOff 앱 크래시, 설정 오류, OOM kubectl logs <pod> --previous
2 ImagePullBackOff 이미지 미존재, 인증 실패 kubectl describe pod → Events
3 Pending (노드 부족) 리소스 부족, Taint 불일치 kubectl describe pod → FailedScheduling
4 OOMKilled 메모리 limits 초과 kubectl describe pod → Last State
5 Service Endpoints <none> Selector / Label 불일치 kubectl get endpoints <svc>
6 DNS 해석 실패 CoreDNS OOM, ndots:5 kubectl logs -n kube-system -l k8s-app=kube-dns
7 PVC Pending AZ 불일치, CSI 권한 kubectl describe pvc → Events
8 EBS Attach 실패 볼륨 제한 초과, Detach 지연 kubectl describe pod → FailedAttachVolume
9 GPU not found Driver 미설치, Device Plugin kubectl get clusterpolicy -A
10 NCCL Timeout SG 차단, EFA 미설치 kubectl logs <pod> | grep NCCL

XI. 핵심 교훈 5가지

1. 체계적 디버깅 — 계층별 접근

Pod → Node → 네트워크 → 스토리지 순서로 레이어별 진단.
kubectl describe와 Events가 항상 출발점.

2. 선제적 옵저버빌리티 — 문제 전에 감지

Container Insights + Prometheus + ADOT 3종 세트.
Composite Alarm으로 False Positive 제거.

3. Auto Mode의 트레이드오프 이해

편의성 vs 커스터마이징. GPU · 고성능 스토리지 · Custom CNI가 필요하면 하이브리드 구성 필수.

4. GPU / AI 워크로드는 별도 디버깅 스킬

XID 에러 코드 숙지, vLLM 파라미터 이해, NCCL 네트워크 요구사항.
devicePlugin=false는 Auto Mode 필수 설정.

5. 운영 자동화 — Alert → Auto-Remediation

알림 피로 방지 + EventBridge Lambda 자동 복구.
MTTD를 30분 → 5분 → 1분으로 단축.