Quartz 4

01_프로메테우스 기초 개념

14 min read

프로메테우스 기초 개념

📑 목차

1. 왜 프로메테우스가 필요한가?

핵심 질문

“서비스를 배포한 후에 뭔가 문제가 생기면, 어떻게 알아챌 것인가?”

💡 문제 상황 이해하기

📋 모니터링 없는 운영 환경

배포 후 현실

개발자: “드디어 완성! 쿠버네티스에 배포했어!”

배포 후 상황:

쿠버네티스 클러스터
├─ 마스터 노드: ??? (살았나? 죽었나?)
├─ 워커 노드 #1: ??? (CPU는 괜찮나?)
├─ 워커 노드 #2: ??? (메모리는?)
└─ 워커 노드 #3: ??? (디스크는?)

관리자: "서버가 잘 돌아가는지 어떻게 알지?" 😰
사용자: "사이트 느린데요?" 😡

🏭 공장 비유로 이해하기

쿠버네티스 클러스터 = 대형 자동차 공장
 
모니터링 없는 공장:
  상황: 기계들이 돌아가는지 일일이 눈으로 확인
  문제: 
    - 문제 생겨도 한참 뒤에 알아챔
    - "어? 이 기계 언제 고장났지?"
    - 생산 라인 전체 중단 위험
 
모니터링 있는 공장:
  상황: 중앙 관제실 화면에서 모든 기계 상태 실시간 확인
  장점:
    - 온도 높아지면 즉시 알람
    - "2번 라인 CPU 80% 넘었습니다!"
    - 사전 예방 조치 가능

🎯 쿠버네티스 환경의 특수성

📊 기존 서버 vs 쿠버네티스

구분기존 서버쿠버네티스
서버 수1~3대수십~수백대
변화 빈도거의 없음지속적 변화
모니터링 대상고정된 서버Pod, Service, Ingress 등
복잡도단순매우 복잡
장애 영향명확함연쇄 반응

💻 실제 시나리오

전형적인 장애 상황

  1. 오후 2시: 사용자 급증 → CPU 사용률 상승
  2. 오후 2시 30분: 일부 Pod에서 메모리 부족
  3. 오후 3시: Pod 재시작 → 로드밸런서 혼란
  4. 오후 3시 30분: 사용자 “사이트 안 열려요!”
  5. 오후 4시: 개발팀 비상 소집 🚨

문제: 오후 2시에 알았다면 30분 만에 해결 가능했던 문제

2. 메트릭의 개념과 중요성

메트릭(Metric) 정의

시스템의 상태를 숫자로 표현한 것. 시간의 흐름에 따른 변화를 추적할 수 있는 데이터.

💡 메트릭의 종류

📋 Resource 메트릭 (인프라 중심)

CPU 메트릭:
  - 사용률: 75%
  - 로드 평균: 2.5
  - 코어별 사용률: [80%, 70%, 90%, 60%]
 
메모리 메트릭:
  - 사용량: 4GB / 8GB (50%)
  - 캐시: 1.5GB
  - 스왑: 512MB
 
디스크 메트릭:
  - 사용률: 80%
  - I/O 대기시간: 15ms
  - 읽기/쓰기 속도: 100MB/s
 
네트워크 메트릭:
  - 트래픽: 초당 100MB
  - 패킷 손실률: 0.1%
  - 연결 수: 1,500개

📋 Application 메트릭 (비즈니스 중심)

성능 메트릭:
  - 응답 시간: 0.5초 (평균)
  - 처리량: 초당 1,000건 요청
  - 에러율: 0.01%
 
비즈니스 메트릭:
  - 동시 접속자: 500명
  - 주문 완료율: 98%
  - 결제 성공률: 99.5%
 
상태 메트릭:
  - HTTP 상태 코드: 200 (정상)
  - 서비스 가용성: 99.9%
  - 데이터베이스 연결: 활성

🔢 숫자로 표현하는 이유

❌ 주관적 표현의 문제

"서버가 좀 느린 것 같아요"
"가끔 에러가 나는 것 같아요"
"사용자가 많이 접속한 것 같아요"

문제점:
- 주관적이고 애매함
- 즉시 대응 불가
- 트렌드 파악 어려움

✅ 객관적 메트릭의 장점

"CPU 사용률 85%, 응답시간 3초"
"에러율 0.5%, 주로 /api/users 엔드포인트"
"동시 접속자 1,200명, 평소 대비 300% 증가"

장점:
- 객관적이고 명확함
- 즉시 대응 방향 결정 가능
- 과거 데이터와 비교 가능

📊 메트릭의 시계열 특성

💻 시계열 데이터의 예

시간         | CPU 사용률 | 메모리 사용률 | 응답시간
2024-12-02 14:00 | 45%    | 60%       | 0.3초
2024-12-02 14:15 | 52%    | 62%       | 0.4초
2024-12-02 14:30 | 78%    | 70%       | 0.8초
2024-12-02 14:45 | 95%    | 85%       | 2.1초  ← 문제 발생!
2024-12-02 15:00 | 98%    | 90%       | 5.2초  ← 심각!

패턴 발견:

  • 14:30부터 급격한 상승
  • CPU와 메모리 사용률이 동시 증가
  • 응답시간이 지수적으로 증가

3. 프로메테우스 핵심 특징

💡 시계열 데이터베이스 (Time-Series DB)

시계열 DB 특징

시간의 흐름에 따른 데이터 저장에 최적화된 데이터베이스

📊 일반 DB vs 시계열 DB

일반 관계형 DB (MySQL):
  구조: 테이블 + 행/열
  용도: 사용자, 주문, 상품 등 정적 데이터
  예시:
    users 테이블: [id, name, email]
    orders 테이블: [id, user_id, amount]
 
시계열 DB (Prometheus):
  구조: 메트릭 + 타임스탬프 + 값
  용도: CPU, 메모리 등 시간별 변화 데이터
  예시:
    cpu_usage{server="web1"} 75 @1701504000
    memory_usage{server="web1"} 4096 @1701504000

🎯 Pull 방식의 데이터 수집

📋 Pull vs Push 방식 비교

구분Pull (프로메테우스)Push (전통 방식)
수집 주체모니터링 서버가 데이터 요청각 서버가 데이터 전송
연결 방향Prometheus → 서버서버 → 모니터링 시스템
장점서버 죽어도 계속 시도실시간 전송
단점지연 가능서버 죽으면 데이터 손실

💻 Pull 방식 동작 원리

프로메테우스 수집 과정:
  1. 설정: 프로메테우스가 타겟 서버 목록 관리
  2. 스케줄: 15초마다 각 서버 방문 (기본값)
  3. 요청: HTTP GET /metrics 요청 전송
  4. 응답: 서버가 현재 메트릭 값 반환
  5. 저장: 시계열 DB에 타임스탬프와 함께 저장
 
예시:
  14:00:00 - http://server1:9100/metrics 방문
  14:00:15 - http://server1:9100/metrics 방문 (15초 후)
  14:00:30 - http://server1:9100/metrics 방문 (30초 후)

🔍 Service Discovery (자동 발견)

쿠버네티스 환경의 핵심 기능

새로운 Pod가 생성되거나 제거될 때 자동으로 모니터링 대상에 추가/제거

📋 동적 환경에서의 필요성

기존 환경 (고정 서버):
  - 서버 목록: web1, web2, web3
  - 변화: 거의 없음
  - 설정: 수동으로 서버 IP 입력
 
쿠버네티스 환경 (동적):
  - Pod 목록: 지속적 변화
  - 변화: 초/분 단위로 생성/삭제
  - 설정: 자동 발견 필수
 
Service Discovery 동작:
  1. 새 Pod 생성 → 프로메테우스가 자동 감지
  2. Pod에 annotation 확인
  3. /metrics 엔드포인트 확인
  4. 모니터링 대상에 자동 추가

📝 PromQL (Prometheus Query Language)

프로메테우스 전용 쿼리 언어

SQL처럼 메트릭 데이터를 조회하고 계산할 수 있는 언어

💻 PromQL 예시

# 기본 조회
cpu_usage
 
# 필터링
cpu_usage{server="web1"}
 
# 시간 범위
cpu_usage[5m]  # 최근 5분간 데이터
 
# 계산
rate(cpu_usage[5m])  # 최근 5분간 평균 증가율
 
# 집계
avg(cpu_usage) by (server)  # 서버별 평균
sum(cpu_usage)  # 전체 합계
 
# 복잡한 쿼리
rate(http_requests_total[5m]) * 60  # 분당 요청 수

4. 실무에서의 활용

💡 알람 시나리오

📋 단계별 알람 설정

1단계 - 주의 (Warning):
  조건: CPU 사용률 > 70%
  액션: Slack 채널 알림
  내용: "서버 부하 증가 중 - 확인 필요"
 
2단계 - 경고 (Critical):
  조건: CPU 사용률 > 85%
  액션: 전화 + SMS + 이메일
  내용: "긴급! 서버 부하 위험 수준"
 
3단계 - 재해 (Emergency):
  조건: CPU 사용률 > 95% AND 응답시간 > 5초
  액션: 자동 스케일링 + 담당자 즉시 호출
  내용: "시스템 장애 임박 - 즉시 대응 요망"

🎯 모니터링 대시보드

📊 계층별 대시보드 구성

경영진 대시보드:
  - 서비스 가용성: 99.9%
  - 사용자 만족도: 4.5/5
  - 수익 영향: $0 손실
  - 전체 상태: 정상
 
운영팀 대시보드:
  - 서버 상태: 12대 정상, 1대 주의
  - 네트워크: 정상
  - 디스크 사용률: 평균 65%
  - 알람 현황: 2건 해결 중
 
개발팀 대시보드:
  - API 응답 시간: 평균 0.3초
  - 에러율: 0.01%
  - 데이터베이스 성능: 정상
  - 최신 배포 상태: 성공

🔧 장애 대응 프로세스

📋 프로메테우스 기반 장애 대응

장애 감지 (0분):
  - 프로메테우스 알람 발생
  - "API 응답시간 3초 초과"
  - Slack #alerts 채널 즉시 알림
 
초기 대응 (5분):
  - 담당자가 Grafana 대시보드 확인
  - 영향 범위 파악: /api/users 엔드포인트
  - CPU/메모리/네트워크 상태 점검
 
원인 분석 (10분):
  - PromQL 쿼리로 상관관계 분석
  - 로그와 메트릭 교차 확인
  - 최근 배포 이력 확인
 
문제 해결 (20분):
  - 근본 원인 식별: DB 쿼리 성능 저하
  - 임시 조치: 캐싱 활성화
  - 근본 해결: 인덱스 추가
 
사후 처리 (30분):
  - 서비스 정상화 확인
  - 알람 해제
  - 장애 보고서 작성

📈 성능 튜닝 활용

💻 메트릭 기반 최적화

최적화 시나리오:
  문제: "사이트가 느려졌다는 사용자 신고"
  
  1단계 - 메트릭 확인:
    - API 응답시간: 0.8초 → 2.3초 (증가)
    - CPU 사용률: 45% → 78% (증가)
    - 메모리: 60% → 85% (증가)
    - DB 연결 수: 50개 → 180개 (증가)
  
  2단계 - 패턴 분석:
    - 특정 API (/api/reports) 호출 급증
    - 해당 API 응답시간: 15초
    - DB 쿼리 실행 시간: 12초
  
  3단계 - 해결책:
    - DB 쿼리 최적화
    - 캐싱 레이어 추가
    - 비동기 처리 도입
  
  4단계 - 효과 측정:
    - API 응답시간: 2.3초 → 0.4초 (개선)
    - CPU 사용률: 78% → 50% (개선)
    - 사용자 만족도: 복구

🎯 핵심 포인트 정리

✅ 반드시 기억할 개념

  1. 메트릭 = 시스템 상태의 숫자 표현

    • 주관적 표현 ❌ → 객관적 수치 ✅

  2. 시계열 데이터의 중요성

    • 현재 상태뿐 아니라 변화 추이 파악

  3. Pull 방식의 장점

    • 서버가 죽어도 프로메테우스가 계속 시도

  4. Service Discovery

    • 쿠버네티스 동적 환경에서 필수 기능

  5. PromQL

    • 메트릭 데이터 조회 및 분석을 위한 전용 언어

🔗 다음 학습 연결고리

다음 단계 미리보기

  1. 모니터링 파이프라인: 데이터가 어떻게 흘러가는지
  2. 프로메테우스 아키텍처: 각 구성요소의 역할
  3. 실습: Vagrant로 직접 설치하고 확인해보기

📚 관련 문서

프로메테우스는 쿠버네티스 환경에서 ‘눈과 귀’ 역할을 하는 필수 도구입니다! 🎯

그래프 뷰

백링크