클라우드‐WHY‐운영 - 100-hours-a-week/16-Hot6-wiki GitHub Wiki
목차
운영
왜 모니터링과 알람이 필요한가요?
서비스가 운영 환경에 올라간 순간부터, 개발 단계와는 다른 예측 불가능한 문제들이 발생합니다. 서버의 리소스 고갈, 외부 API 장애, 특정 요청에서만 발생하는 예외 등은 단순 로그만으로는 파악하기 어렵고, 사용자 불편으로 이어질 수 있습니다.
이러한 문제를 빠르게 감지하고 대응하기 위해서는, 시스템의 상태를 실시간으로 관찰(모니터링)하고, 이상이 감지되었을 때 즉시 알림을 받을 수 있는 구조가 필요합니다.
저희는 현재 메트릭 기반의 모니터링 시스템을 통해 리소스 사용량, 요청 수, 오류율 등을 관찰하고 있으며, 서비스가 중단되거나 응답이 비정상적으로 느려지는 경우를 탐지할 수 있도록 알람을 설정하고 있습니다. 실제로 AI 서버의 메모리 부하 문제를 조기에 탐지하거나 서비스 장애를 탐지하여 장애 대응한 경험이 있습니다.
또한, 단순 지표를 넘어서 트랜잭션 흐름이나 병목 구간을 추적할 수 있는 APM 기반 모니터링도 구축 중입니다. 이는 향후 문제의 원인을 더 정확히 파악하고, 성능 개선까지 이어질 수 있도록 도와줄 것입니다.
결국 모니터링과 알람은 단지 감시가 아닌, 서비스를 안정적으로 운영하기 위한 필수적인 관행이자 문화입니다.
왜 Prometheus와 Grafana를 사용하나요?
모니터링 도구를 선택할 때 가장 중요한 기준 중 하나는 현재의 아키텍처뿐 아니라, 앞으로의 변화까지 고려할 수 있느냐입니다. 저희는 애초에 아키텍처가 점진적으로 쿠버네티스 기반으로 전환될 계획이 있었기 때문에, 쿠버네티스와의 궁합이 뛰어난 스택을 염두에 두고 시작했습니다.
Prometheus는 CNCF의 공식 프로젝트로, 쿠버네티스 환경에서 사실상의 표준 모니터링 시스템입니다. 서비스 디스커버리, 메트릭 수집, 알람 설정 등 핵심 기능들이 쿠버네티스와 매우 자연스럽게 통합되며, 다양한 Exporter와 커뮤니티 생태계를 통해 빠르게 확장 가능합니다.
Grafana는 Prometheus의 메트릭을 시각화하는 데 있어 가장 널리 쓰이는 툴로, 대시보드 구성이 자유롭고 커뮤니티 템플릿도 풍부하여 운영 효율성을 높이는 데 도움이 됩니다.
처음에 고려했던 다른 스택으로는 ELK(Elasticsearch, Logstash, Kibana)가 있었습니다. 하지만 Elasticsearch는 상대적으로 메모리 사용량이 높고, 단순한 메트릭 기반의 모니터링보다는 로그 분석 및 검색에 특화되어 있어, 당시 필요했던 요구사항에는 오버스펙이라고 판단했습니다.
또한, Prometheus는 시계열 데이터 수집에 최적화된 구조를 가지고 있어, 단순 수치 기반 모니터링에서는 ELK보다 가볍고 효과적인 선택이었습니다. 이후 로그 기반 분석이 필요해지면서는 Loki를 별도로 도입했고, APM 기능은 Prometheus가 제공하지 않기 때문에 SigNoz를 통해 트랜잭션 기반 성능 추적까지 보완하게 되었습니다.
정리하자면, Prometheus와 Grafana는 단순한 "기본값"이 아니라,
쿠버네티스 환경과의 높은 호환성,
가벼운 리소스 사용과 확장성,
운영 편의성과 시각화 도구의 성숙도를 기준으로 선택한 전략적인 선택지였습니다.