모니터링 시스템 구축 실전 도입기

"사이트가 안 열려요"

고객사 담당자에게서 전화가 왔다. 확인해보니 서버가 30분 전에 죽어 있었다. 30분 동안 아무도 몰랐다. 서버 상태를 확인하는 방법이 SSH 접속해서 htop 치는 것밖에 없었으니까.

이 사건 이후로 모니터링 시스템 도입이 최우선 과제가 됐다.

왜 Prometheus + Grafana였나

후보는 세 가지였다. Datadog, New Relic, Prometheus + Grafana.

Datadog은 기능이 좋지만 호스트당 월 2만원이 넘었고, 서버 대수를 곱하면 부담이 됐다. Prometheus + Grafana는 오픈소스라 비용이 거의 없다. 러닝 커브가 있지만 한 번 익히면 자유도가 높다.

(사실 비용 문제가 결정적이었다.)

첫째 주: 생각보다 금방 됐다

Prometheus를 Docker로 띄우고, Node Exporter로 서버 메트릭을 수집하기 시작했다. CPU, 메모리, 디스크, 네트워크. 기본 메트릭만으로도 서버 상태 파악에 충분했다.

애플리케이션 메트릭은 Spring Boot의 Micrometer를 통해 노출했다. /actuator/prometheus 엔드포인트 하나면 Prometheus가 알아서 스크래핑해간다. prometheus.yml에 타겟 추가하고 scrape_interval 15초로 설정한 게 전부다. 반나절이면 기본 구성이 끝난다.

둘째 주: 대시보드 만드는 게 재밌었다

Grafana에서 대시보드 만드는 건 솔직히 좀 재밌었다. 커뮤니티 대시보드를 import하면 기본적인 서버 모니터링은 5분 만에 완성된다. Node Exporter 대시보드(ID: 1860)가 특히 좋았다.

커스텀 대시보드는 시간이 좀 걸렸다. PromQL이 처음엔 낯설었다. rate(http_requests_total[5m])이 5분간 초당 평균 요청 수라는 걸 이해하는 데 하루가 걸렸다. 근데 한 번 익히니까 강력했다. 99퍼센타일 응답 시간, 에러율 추이, 서비스별 트래픽 비교를 실시간으로 볼 수 있다는 건 이전과 완전히 다른 세계였다.

셋째 주: 알림이 너무 자주 왔다

Alertmanager를 연동하고 Slack 웹훅으로 알림을 보내도록 설정했다. CPU 80% 이상 5분 지속, 메모리 90% 이상, API 에러율 5% 이상, 응답 시간 99퍼센타일 3초 이상.

근데 처음에 알림이 너무 자주 왔다. 임계치를 너무 낮게 잡은 탓이었다. 알림 피로는 알림을 무시하게 만든다. 2주간 관찰하면서 조정했고, 하루 평균 0-2건으로 안정화됐다.

몰랐던 문제들이 보이기 시작했다

모니터링을 붙이고 나서 발견한 것들. 매일 새벽 3시에 CPU가 90%까지 치솟는 현상이 있었다. 알고 보니 cron으로 돌리던 배치 작업이 인덱스 없는 쿼리를 실행하고 있었다.

특정 API의 응답 시간이 주중 오후에만 느려지는 패턴도 발견했다. 외부 API 호출 타임아웃이 원인이었다. 이런 건 모니터링 없이는 절대 알 수 없었다.

비용은 월 2만원

Prometheus와 Grafana는 자체 서버에서 운영하니까 EC2 비용만 든다. t3.small 하나에 둘 다 올렸고 월 2만원 정도. 메트릭 보존 기간은 30일로 설정했다. 우리 규모에서는 이걸로 충분하다.

이전으로 돌아갈 수 없다

이제 장애를 사용자보다 평균 5분 먼저 인지한다. 서버 상태를 대시보드 하나로 한눈에 파악한다. 성능 이슈를 데이터 기반으로 분석한다.

모니터링 없는 서비스 운영은 계기판 없이 차를 모는 거다. 시작이 어려울 뿐, 한 번 구축하면 이전으로 안 돌아간다.