컨테이너 서비스 운영의 현실 📊

24시간 안정성을 위한 모니터링과 장애 대응

🚨 새벽 3시, 장애 알림이 울렸다면?

실제 상황 재현

금요일 밤 11시

💬 슬랙 알림: "웹사이트 응답 없음"
📱 카카오톡: "고객이 주문을 못 한다고 연락 왔어요!"
📧 이메일: "CloudWatch ALARM: CPU 사용률 100%"

이런 상황, 경험해보셨나요?

오늘은 이런 일이 생기기 전에 미리 준비하는 방법과, 생겼을 때 빠르게 해결하는 방법을 알려드릴게요.

---

📈 모니터링이 뭐길래 이렇게 중요할까?

모니터링 = 건강검진 + 응급실

건강검진 역할:

• 평소 서비스 상태 체크
• 문제 징후 미리 발견
• 예방 조치 가능

응급실 역할:

• 장애 발생 즉시 알림
• 원인 파악 도구 제공
• 복구 시간 단축

모니터링 없이 운영한다면?

 

❌ 고객이 먼저 문제를 발견
❌ 원인 파악에 몇 시간 소요
❌ 매출 손실과 신뢰도 하락
❌ 개발팀 야근과 스트레스

vs 모니터링 있을 때:

 

✅ 문제 발생 1분 내 알림
✅ 원인 파악 10분 내 완료
✅ 자동 복구 또는 빠른 대응
✅ 고객은 모르게 해결

---

🎯 꼭 모니터링해야 할 핵심 지표들

💻 인프라 지표 (서버 건강 상태)

1. CPU 사용률

 

🟢 정상: 50% 이하
🟡 주의: 50-70%
🔴 위험: 70% 이상

실제 사례:
"CPU 90% 지속 → 응답 속도 10초 → 고객 이탈"

2. 메모리 사용률

 

🟢 정상: 70% 이하
🟡 주의: 70-85%
🔴 위험: 85% 이상

주의사항:
메모리 부족 시 컨테이너가 갑자기 종료될 수 있음

3. 네트워크 I/O

 

모니터링 포인트:
- 인바운드 트래픽 급증
- 아웃바운드 트래픽 이상
- 패킷 손실률

실제 사례:
"DDoS 공격으로 트래픽 1000배 증가 감지"

🌐 애플리케이션 지표 (서비스 품질)

1. 응답 시간 (Response Time)

🟢 우수: 200ms 이하
🟡 보통: 200ms - 1초
🟠 느림: 1-3초
🔴 매우 느림: 3초 이상

고객 이탈률:
- 1초 지연 → 7% 이탈
- 3초 지연 → 40% 이탈

2. 에러율 (Error Rate)

🟢 정상: 0.1% 이하
🟡 주의: 0.1-1%
🔴 위험: 1% 이상

5xx 에러 vs 4xx 에러:
- 5xx: 서버 문제 (우리 책임)
- 4xx: 클라이언트 문제 (보통 정상)

3. 처리량 (Throughput)

측정 단위:
- 초당 요청 수 (RPS)
- 분당 처리 건수 (TPM)
- 동시 접속자 수

패턴 분석:
평일 vs 주말, 낮 vs 밤 패턴 파악

🏗️ 컨테이너 특화 지표

1. 컨테이너 상태

 

Running: 정상 실행 중
Pending: 시작 대기 중
Failed: 실행 실패
Stopped: 정지됨

알림 기준:
Failed 상태 5분 이상 지속

2. 오토스케일링 상태

스케일 아웃 빈도
스케일 인 적정성
리소스 활용률

최적화 기준:
평균 CPU 50-70% 유지

---

🛠️ AWS 네이티브 모니터링 구축하기

📊 CloudWatch 기본 설정

1. 대시보드 만들기

AWS 콘솔 → CloudWatch → 대시보드

추가할 위젯:
1. ECS 클러스터 CPU/메모리
2. ALB 응답 시간/에러율
3. RDS 커넥션/CPU
4. 커스텀 메트릭 (비즈니스 지표)

2. 필수 알람 설정

 

🚨 즉시 알림 (Critical):
- CPU 80% 이상 5분 지속
- 메모리 85% 이상 5분 지속
- 5xx 에러율 5% 이상
- 응답 시간 5초 이상

⚠️ 주의 알림 (Warning):
- CPU 70% 이상 10분 지속
- 디스크 사용률 80% 이상
- 컨테이너 재시작 빈발

3. 실제 알람 설정 예시

알람 이름: ECS-CPU-High
메트릭: AWS/ECS CPUUtilization
조건: 평균 > 80% for 2 periods of 5 minutes
액션: SNS 토픽으로 슬랙/이메일 전송

💡 꿀팁:
알람 설명에 대응 방법까지 적어두세요!
"CPU 높음 → 스케일 아웃 또는 인스턴스 타입 업그레이드"

📱 알림 채널 구성

1. 슬랙 연동

SNS → Lambda → Slack Webhook

장점:
- 실시간 알림
- 팀 전체 공유
- 쓰레드로 대응 과정 기록

예시 메시지:
🚨 [CRITICAL] ECS CPU 85%
클러스터: production-cluster
시간: 2024-01-15 14:30
대응: @oncall-engineer

2. 이메일 + SMS

Critical 알람: SMS (즉시)
Warning 알람: 이메일 (배치)
정기 리포트: 이메일 (일/주간)

📈 로그 관리

1. CloudWatch Logs 설정

ECS 태스크 정의에서:
logDriver: awslogs
options:
  awslogs-group: /ecs/my-app
  awslogs-region: ap-northeast-2
  awslogs-stream-prefix: ecs

2. 로그 레벨 전략

DEBUG: 개발 환경만
INFO: 주요 비즈니스 로직
WARN: 경고성 이벤트
ERROR: 에러 발생
FATAL: 시스템 중단급 오류

실제 예시:
INFO: "사용자 12345 로그인 성공"
ERROR: "데이터베이스 연결 실패: timeout"

---

🔍 고급 모니터링: Prometheus + Grafana

AWS CloudWatch만으로 부족할 때

CloudWatch 한계:

• 커스텀 메트릭 비용 부담
• 복잡한 쿼리 어려움
• 실시간성 부족

Prometheus 장점:

• 무료 오픈소스
• 강력한 쿼리 언어 (PromQL)
• 마이크로서비스 모니터링 특화

🚀 Prometheus 구축하기

1. EKS에서 설정 (권장)

 

bash

# Helm으로 Prometheus 설치
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack

# 접속 확인
kubectl port-forward svc/prometheus-grafana 3000:80

2. ECS에서 설정 (복잡하지만 가능)

 

Prometheus 서버를 별도 ECS 서비스로 구성
각 애플리케이션에서 메트릭 엔드포인트 제공
Service Discovery로 자동 모니터링 대상 발견

📊 Grafana 대시보드 구성

1. 필수 대시보드들

 

🖥️ 인프라 대시보드:
- 클러스터 전체 리소스 현황
- 노드별 상태
- 네트워크 트래픽

📱 애플리케이션 대시보드:
- 서비스별 응답 시간
- 에러율 트렌드
- 사용자 세션 수

💰 비즈니스 대시보드:
- 일매출/시간당 매출
- 신규 가입자 수
- 주요 기능 사용률

2. 알림 규칙 (AlertManager)

 

yaml

groups:
- name: critical-alerts
  rules:
  - alert: HighCPU
    expr: cpu_usage_percent > 80
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "CPU 사용률이 높습니다"
      description: "{{ $labels.container }}의 CPU가 {{ $value }}%입니다"

---

🆘 장애 대응 실전 매뉴얼

📋 장애 대응 체크리스트

1단계: 즉시 확인 (1분 내)

□ 서비스 접속 확인 (외부에서)
□ CloudWatch/Grafana 대시보드 확인
□ 최근 배포나 변경사항 확인
□ 팀에 상황 공유 (슬랙)

2단계: 원인 파악 (5분 내)

□ CPU/메모리 사용률 체크
□ 에러 로그 확인
□ 네트워크 상태 점검
□ 외부 서비스 (DB, API) 상태 확인

3단계: 임시 조치 (10분 내)

□ 스케일 아웃으로 부하 분산
□ 문제되는 컨테이너 재시작
□ 트래픽 일부 다른 환경으로 우회
□ 고객 공지 (필요시)

4단계: 근본 해결 (30분 내)

 

□ 코드 수정 또는 설정 변경
□ 새 버전 배포
□ 서비스 정상화 확인
□ 고객 공지 업데이트

🔧 자주 발생하는 장애와 해결법

 

1. CPU 100% 사용률

📊 증상:
- 응답 속도 급격히 느려짐
- CloudWatch에서 CPU 100% 표시

🔍 원인:
- 무한 루프 코드
- 예상보다 많은 트래픽
- 리소스 부족

⚡ 해결:
1. 즉시 스케일 아웃 (컨테이너 개수 2배)
2. 코드 리뷰로 성능 병목 찾기
3. 인스턴스 타입 업그레이드

 

2. 메모리 부족 (OOM)

📊 증상:
- 컨테이너가 갑자기 종료됨
- "Container killed" 로그

🔍 원인:
- 메모리 리크
- 대용량 파일 처리
- 설정된 메모리 한계 초과

⚡ 해결:
1. 메모리 한계 즉시 증가
2. 메모리 사용 패턴 분석
3. 코드 최적화 (캐시, 가비지 컬렉션)

 

3. 데이터베이스 연결 실패

📊 증상:
- "Connection timeout" 에러
- 5xx 에러율 급증

🔍 원인:
- DB 서버 과부하
- 커넥션 풀 부족
- 네트워크 이슈

⚡ 해결:
1. 읽기 전용 쿼리는 읽기 복제본으로 우회
2. 커넥션 풀 설정 조정
3. 불필요한 DB 쿼리 최적화

📞 에스컬레이션 프로세스

레벨 1: 당직자 (5분 대응)

권한: 스케일링, 재시작
책임: 즉시 대응, 상황 공유
에스컬레이션: 15분 내 해결 안 되면 레벨 2

레벨 2: 팀 리더 (15분 대응)

권한: 설정 변경, 롤백
책임: 원인 파악, 근본 해결
에스컬레이션: 30분 내 해결 안 되면 레벨 3

레벨 3: 아키텍트/CTO (30분 대응)

권한: 인프라 변경, 외부 업체 연락
책임: 전체적 판단, 비즈니스 의사결정

---

📊 성능 최적화를 위한 모니터링

🎯 성능 지표 수집

1. 애플리케이션 성능 모니터링 (APM)

도구 선택:
- AWS X-Ray (AWS 네이티브)
- New Relic (상용)
- Datadog (상용)
- Jaeger (오픈소스)

측정 항목:
- 함수별 실행 시간
- 데이터베이스 쿼리 성능
- 외부 API 호출 시간
- 메모리 사용 패턴

2. 사용자 경험 모니터링 (RUM)

프론트엔드 지표:
- 페이지 로딩 시간
- 첫 화면 렌더링 시간
- 사용자 인터랙션 지연
- JavaScript 에러율

도구:
- Google Analytics
- CloudWatch RUM
- Lighthouse CI

📈 성능 개선 프로세스

1. 베이스라인 설정

현재 성능 측정:
□ 평균 응답 시간: ___ms
□ 95% 응답 시간: ___ms  
□ 에러율: ___%
□ 처리량: ___RPS

목표 설정:
□ 응답 시간 20% 개선
□ 에러율 50% 감소
□ 처리량 2배 증가

2. 병목 지점 식별

분석 순서:
1. 가장 느린 API 엔드포인트
2. 가장 많이 호출되는 함수
3. 가장 무거운 데이터베이스 쿼리
4. 가장 큰 메모리 사용 컴포넌트

3. 우선순위 결정

개선 우선순위 매트릭스:
높은 영향 + 쉬운 구현 = 최우선
높은 영향 + 어려운 구현 = 2순위
낮은 영향 + 쉬운 구현 = 3순위
낮은 영향 + 어려운 구현 = 후순위

---

🔮 예측적 모니터링과 자동화

📊 트렌드 분석

1. 용량 계획 (Capacity Planning)

분석 지표:
- 월별 트래픽 증가율
- 리소스 사용률 트렌드
- 피크 시간대 패턴

예측 모델:
- 선형 회귀: 안정적 성장
- 지수 성장: 급성장 서비스
- 계절성 모델: 이벤트/쇼핑몰

결과 활용:
"3개월 후 현재 인프라 한계 도달 예상"
"블랙프라이데이 대비 서버 3배 증설 필요"

2. 이상 탐지 (Anomaly Detection)

AWS CloudWatch Anomaly Detection:
- 기계학습으로 정상 패턴 학습
- 예상 범위 벗어날 때 자동 알림
- 트래픽 급증/급감 조기 감지

활용 사례:
"평소보다 에러율 10배 증가 감지"
"새벽 시간 비정상적 트래픽 패턴"

🤖 자동 복구 시스템

1. 자동 스케일링 고도화

ECS Service Auto Scaling:
- CPU 기반 스케일링
- 메모리 기반 스케일링  
- 커스텀 메트릭 기반 스케일링

Target Tracking 정책:
평균 CPU 50% 유지
응답 시간 200ms 이하 유지
활성 커넥션 수 1000개 이하 유지

2. 자동 복구 액션

Lambda 기반 자동 대응:
- 컨테이너 재시작
- 장애 인스턴스 교체
- 트래픽 우회
- 긴급 공지 발송

예시 시나리오:
"5xx 에러 5% 초과 → 자동으로 이전 버전 롤백"
"DB 커넥션 실패 → 읽기 전용 모드 전환"

---

📋 운영 체크리스트 - 일/주/월 루틴

📅 일일 체크 (10분)

□ 전날 알림 리뷰
□ 주요 지표 트렌드 확인
□ 에러 로그 스팟 체크
□ 사용자 피드백 확인
□ 백업 상태 점검

📅 주간 리뷰 (30분)

□ 성능 지표 주간 리포트 작성
□ 용량 사용률 트렌드 분석
□ 알림 임계값 적정성 검토
□ 비용 사용량 체크
□ 보안 이벤트 리뷰

📅 월간 최적화 (2시간)

□ 대시보드 개선점 도출
□ 알림 룰 튜닝
□ 성능 개선 계획 수립
□ 장애 대응 프로세스 개선
□ 팀 교육 및 지식 공유

---

💡 운영 노하우와 팁

🎯 효율적인 모니터링을 위한 꿀팁

1. 알림 피로도 방지

❌ 잘못된 예:
- 모든 지표에 알림 설정
- 임계값 너무 민감하게 설정
- 중요도 구분 없이 동일한 채널

✅ 올바른 예:
- Critical vs Warning 구분
- 시간대별 임계값 차등 적용
- 알림 묶음 처리 (5분간 동일 알림 1개만)

2. 의미있는 메트릭 선택

비즈니스 연관성 고려:
- 기술 지표: CPU, 메모리
- 사용자 지표: 응답시간, 에러율
- 비즈니스 지표: 주문 수, 매출

예시:
"CPU 80%보다 주문 완료율 95% 미달이 더 중요"

3. 문서화의 중요성

Runbook 작성:
- 각 알림별 대응 방법
- 장애 시나리오별 체크리스트
- 담당자 연락처
- 외부 업체 정보

예시:
"DB 연결 실패 시: 1) RDS 상태 확인 2) 커넥션 풀 재시작 3) 30분 내 복구 안 되면 DBA 연락"

🔄 지속적 개선

1. 포스트모템 (사후 분석)

장애 발생 후 반드시 수행:
- 타임라인 정리
- 근본 원인 분석
- 재발 방지 액션 아이템
- 프로세스 개선점

템플릿:
- 사건 요약
- 발생 시간 및 영향 범위
- 대응 과정
- 학습한 점
- 개선 계획

2. 성능 벤치마킹

정기적 성능 테스트:
- 부하 테스트 (예상 트래픽 2배)
- 스트레스 테스트 (시스템 한계 확인)
- 장애 복구 테스트 (Chaos Engineering)

도구:
- JMeter (오픈소스)
- Artillery (Node.js)
- AWS Load Testing Solution

---

🎉 마무리: 안정적인 서비스 운영을 위한 로드맵

🚀 단계별 구축 계획

1단계: 기본 모니터링 (1주)

✅ CloudWatch 기본 대시보드
✅ CPU/메모리 알림 설정
✅ 슬랙 연동
✅ 기본 로그 수집

2단계: 고도화 (1개월)

✅ 애플리케이션 레벨 메트릭
✅ 사용자 경험 모니터링
✅ 자동 스케일링 정교화
✅ 장애 대응 프로세스 문서화

3단계: 예측/자동화 (3개월)

✅ Prometheus + Grafana 구축
✅ 이상 탐지 시스템
✅ 자동 복구 로직
✅ 성능 최적화 사이클

💡 성공하는 운영팀의 특징

반응적 → 예방적 사고전환

• 문제 발생 후 대응 → 문제 발생 전 예방
• 수동 모니터링 → 자동 감지
• 개별 지표 → 전체적 맥락

지속적 학습과 개선

• 매 장애마다 학습
• 업계 베스트 프랙티스 적용
• 새로운 도구와 기법 실험

팀워크와 소통

• 투명한 정보 공유
• 명확한 역할 분담
• 효과적인 에스컬레이션

🔮 미래를 위한 준비

AI/ML 기반 운영

• 자동 이상 탐지
• 예측적 스케일링
• 인텔리전트 알림

옵저버빌리티 진화

• 메트릭 + 로그 + 트레이스 통합
• 분산 시스템 가시성
• 비즈니스 메트릭 연동