[DevOps] Prometheus & Grafana: 장애 방어 모니터링 구축 (골든 시그널)

📌 핵심 요약

  • 기존 Push 방식과 대비되는 Prometheus의 Pull 방식 아키텍처 이해
  • 구글 SRE 팀이 제안하는 4가지 골든 시그널(Golden Signals) 모니터링 방법
  • Grafana 연동 및 실무에서 꼭 설정해야 할 Alert(알람) 전략

"서버 죽었어?"라는 고객의 항의 전화를 받고서야 장애를 인지한다면, 그 개발팀의 운영 능력은 낙제점입니다. 모니터링 없는 배포는 눈을 감고 고속도로를 달리는 것과 같습니다.

AWS CloudWatch나 Datadog 같은 훌륭한 유료 도구도 있지만, 비용 부담이 만만치 않습니다. 전 세계 데브옵스 표준으로 자리 잡은 오픈소스 조합, Prometheus(수집)와 Grafana(시각화)를 통해 "잠들 수 있는 밤"을 만드는 법을 알아봅니다.

서버 대시보드

1. 아키텍처의 혁명: Pull vs Push

과거의 모니터링 도구(Zabbix 등)는 각 서버의 에이전트가 중앙 서버로 데이터를 쏘는 Push 방식이었습니다. 서버가 늘어날수록 중앙 서버에 부하가 걸리고, 트래픽이 폭주할 때 모니터링 시스템부터 죽는 경우가 많았습니다.

Prometheus는 반대로 Pull 방식을 채택했습니다.

  • Exporter: 각 서버(App, DB)는 /metrics라는 엔드포인트에 자신의 상태를 노출만 합니다.
  • Prometheus Server: 주기적(예: 15초)으로 각 타겟을 방문하여 데이터를 긁어갑니다(Scraping).
  • 장점: 수집 서버가 죽어도 애플리케이션에는 전혀 영향이 없으며, 수천 대의 서버로 확장하기 쉽습니다.

2. 무엇을 봐야 하는가? (골든 시그널)

수많은 그래프 중 무엇부터 대시보드에 띄워야 할까요? 구글 SRE(Site Reliability Engineering) 북에서는 4가지 골든 시그널을 정의합니다.

시그널 설명 PromQL 예시 (쿼리)
Latency (지연 시간) 요청 처리에 걸리는 시간 (평균보다는 P95, P99가 중요) rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])
Traffic (트래픽) 초당 요청 수 (RPS) rate(http_requests_total[1m])
Errors (에러율) 전체 요청 대비 5xx 에러 비율 rate(http_requests_total{status=~"5.."}[5m])
Saturation (포화도) 자원(CPU, Memory)이 얼마나 꽉 찼는지 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

3. Grafana 연동 및 알람(Alert) 설정

Prometheus의 기본 UI는 투박합니다. Grafana를 연결하면 데이터를 시각적으로 아름답게 볼 수 있을 뿐만 아니라, Alerting 기능을 사용할 수 있습니다.

🚨 알람 규칙 설정 팁

"CPU 80% 넘으면 알람" 같은 단순한 규칙은 피로감만 유발합니다(False Alarm).

  • 증상 기반 알람 (Symptom-based): "CPU가 높다"보다는 "응답 속도가 2초를 넘었다"가 더 중요한 알람입니다.
  • 지속 시간 고려: 1초 튀는 것은 무시하고, "5분 동안 에러율이 1% 이상일 때"와 같이 조건을 거십시오.
  • 채널 분리: 심각한 장애(P0)는 전화/SMS로, 경미한 경고(P3)는 Slack 채널로 보내세요.

4. 결론

완벽한 시스템은 없습니다. 하지만 "관측 가능한(Observable)" 시스템은 있습니다.

처음부터 화려한 대시보드를 만들려 하지 마세요. ① Spring Boot Actuator와 Prometheus 연동, ② Grafana에 기본 대시보드 Import, ③ 에러율 1% 이상 시 Slack 알림. 이 3단계만 구축해도 주말이 훨씬 평화로워질 것입니다.

이 블로그의 인기 게시물

Docker 컨테이너 'Connection Refused' (Errno 111) 오류 해결 가이드

이미지
🎯 타겟 독자: Docker 입문자, 컨테이너를 띄웠으나 localhost 로 접속이 안 되는 백엔드 개발자, MSA(마이크로서비스) 구축 중 통신 오류를 겪는 엔지니어. 📝 요약: Docker 접속 오류(Errno 111)의 90%는 애플리케이션이 '0.0.0.0'이 아닌 '127.0.0.1' 로 바인딩 되어 있거나, 포트 포워딩(-p) 설정이 누락되어 발생합니다. 이 글에서는 네트워크 인터페이스의 차이를 이해하고, 외부 접속을 허용하는 올바른 설정법을 정리합니다. 1. 문제 정의: "컨테이너는 떴는데 접속이 안 돼요" Docker 입문자들이 가장 흔하게 겪는 상황입니다. docker ps 로 확인하면 상태(STATUS)는 분명히 Up 인데, 브라우저나 Postman으로 접속하면 즉시 연결이 거부됩니다. curl: (7) Failed to connect to localhost port 8080: Connection refused Python: ConnectionRefusedError: [Errno 111] Connection refused 이 문제는 방화벽 때문이 아닙니다. "누구의 요청을 들을 준비가 되었는가(Listen Address)" 에 대한 설정이 잘못되었기 때문입니다. 2. 원인 분석: 127.0.0.1의 함정 핵심은 Loopback(127.0.0.1) 과 Any Address(0.0.0.0) 의 차이입니다. 로컬 PC에서 개발할 때 서버를 localhost 로 띄우는 건 보안상 좋은 습관입니다. 하지만 Docker 컨테이너는 독립된 IP를 ...
자세한 내용 보기

Redis 캐싱 전략 완벽 가이드: Look Aside부터 Write Back까지 (DB 부하 줄이기)

이미지
🎯 타겟 독자: 사용자가 몰릴 때마다 DB CPU가 100%를 치는 상황을 겪는 백엔드 개발자, Redis를 단순히 get/set 으로만 쓰고 있는 주니어 엔지니어. 📝 요약: 캐시(Cache)는 성능 향상의 치트키지만, 잘못 쓰면 데이터 불일치(Inconsistency) 라는 재앙을 부릅니다. 이 글에서는 가장 대중적인 Look Aside(Lazy Loading) 패턴과 쓰기 성능을 극대화하는 Write Back 패턴의 작동 원리, 장단점, 그리고 언제 무엇을 써야 하는지 명확한 기준을 제시합니다. 1. 캐싱 패턴이 왜 중요한가요? "그냥 Redis에 넣으면 되는 거 아닌가요?"라고 묻는다면 반은 맞고 반은 틀립니다. 캐시를 데이터베이스(DB)와 어떤 순서로 연동하느냐에 따라 시스템의 데이터 정합성 과 성능 이 완전히 달라지기 때문입니다. 2. 패턴 ① Look Aside (Lazy Loading) - 국룰 전략 현업에서 80% 이상 사용되는 가장 일반적인 읽기 전략입니다. 캐시를 옆(Aside)에 두고 필요할 때만 데이터를 가져옵니다. 작동 순서 앱이 데이터를 찾을 때 먼저 캐시(Redis)를 찌릅니다. 캐시에 데이터가 있으면(Cache Hit) 바로 반환합니다. (DB 부하 0) 없으면(Cache Miss) DB에서 조회 하여 가져옵니다. 가져온 데이터를 캐시에 저장 하고 반환합니다. public User getUser(Long id) { // 1. 캐시 조회 User user = redisTemplate.opsForValue().get("user:" +...
자세한 내용 보기

브라우저 렌더링 원리: Reflow와 Repaint 최적화 가이드 (CRP 심층 분석)

이미지
📌 핵심 요약 CRP(Critical Rendering Path) 의 5단계: DOM → CSSOM → Render Tree → Layout → Paint 성능의 주범 Reflow(Layout) 와 Repaint 의 차이점 애니메이션 성능 최적화: 왜 top/left 대신 transform 을 써야 하는가? (GPU 가속과 Composite) "사용자가 주소창에 URL을 입력하고 엔터를 쳤을 때, 화면에 네이버 메인이 뜨기까지 무슨 일이 일어나는가?" 이 질문은 네트워크 관점(DNS, TCP/IP)에서도 답변할 수 있지만, 프론트엔드 개발자라면 렌더링 엔진(Rendering Engine)이 HTML과 CSS를 해석해서 픽셀로 바꿔주는 과정, 즉 CRP(Critical Rendering Path)를 설명할 수 있어야 합니다. 이 원리를 알아야 "왜 리액트가 Virtual DOM을 쓰는지", "왜 애니메이션이 버벅이는지" 이해할 수 있습니다. 1. 렌더링 파이프라인 (The Pipeline) 브라우저는 다음 5단계를 거쳐 화면을 그립니다. DOM 트리 생성: HTML 문서를 파싱 하여 태그 간의 관계(부모-자식)를 트리 구조로 만듭니다. CSSOM 트리 생성: CSS 파일과 인라인 스타일을 파싱 하여 스타일 규칙 트리를 만듭니다. Render Tree 생성: DOM과 CSSOM을 결합하여 "실제로 화면에 표시될 노드" 만 추려냅니다. Layout (Reflow): 각 노드가 화면의 어느 위치에, 어떤 크기(px) 로 배치될지 기하학적 계산을 수행합니다. ...
자세한 내용 보기