1. 왜 모니터링을 해야 할까? 4대 골든 시그널과 시스템 구성 요소

지금까지 Kafka, Cassandra 같은 강력한 분산 시스템을 배웠습니다. 하지만 아무리 잘 만든 시스템이라도 '지금 잘 동작하고 있는지', '문제가 생겼다면 어디가 아픈지' 알 수 없다면 무용지물입니다. 모니터링은 개발자가 만든 시스템의 건강 상태를 지속적으로 확인하고, 문제가 발생했을 때 즉시 대응할 수 있게 해주는 '디지털 청진기'와 같습니다.

특히 MSA(Microservice Architecture) 환경에서는 수많은 서비스들이 복잡하게 얽혀있기 때문에, 체계적인 모니터링 시스템 없이는 장애의 원인을 찾는 것 자체가 불가능에 가깝습니다.

모니터링의 목표: "장애가 발생하기 전에 알아채고, 발생했다면 즉시 원인을 찾는다"

모니터링은 단순히 시스템이 죽었는지 살았는지만 보는 것이 아닙니다.

비유: 자동차 계기판과 건강검진

모니터링은 자동차의 계기판과 같습니다. 속도, RPM, 기름 잔량, 엔진 온도 등을 실시간으로 보여주어 운전자가 현재 차량 상태를 정확히 알고 안전하게 운전할 수 있게 돕습니다. 만약 '엔진 경고등'이 켜지면, 운전자는 즉시 문제를 인지하고 정비소로 향할 수 있습니다.

또한, 정기적으로 받는 건강검진과도 같습니다. 혈압, 혈당, 콜레스테롤 수치 등을 주기적으로 측정하여 현재 건강 상태를 파악하고, 잠재적인 질병을 조기에 발견하여 예방하는 것과 동일한 원리입니다.

무엇을 봐야 할까? 구글이 말하는 4대 골든 시그널

구글 SRE(Site Reliability Engineering) 팀은 사용자 관점에서 서비스 상태를 파악하기 위한 가장 중요한 4가지 지표, '골든 시그널'을 제시했습니다. 이 지표들만 잘 봐도 대부분의 문제를 감지할 수 있습니다.

골든 시그널 의미 백엔드 개발자가 봐야 할 것 (예시)
지연 시간 (Latency) 요청을 처리하는 데 걸리는 시간. 성공한 요청과 실패한 요청을 구분해서 봐야 합니다. API 응답 시간 (p99, p95), DB 쿼리 시간, 외부 API 호출 시간
트래픽 (Traffic) 시스템에 가해지는 부하의 양. 초당 요청 수 (RPS), HTTP 요청량 (bytes), DB 커넥션 수
에러 (Errors) 실패한 요청의 비율. HTTP 5xx 에러 비율, 4xx 에러 비율, 예외(Exception) 발생 수
포화도 (Saturation) 시스템이 얼마나 '한계'에 가까워졌는가. 가장 예측하기 어려운 지표. CPU 사용률, 메모리 사용률, 디스크 I/O, 큐(Queue)의 길이

왜 평균(Average)이 아닌 p99, p95를 봐야 할까?

API 응답 시간의 '평균'은 성능을 왜곡할 수 있는 위험한 지표입니다. 예를 들어, 100개의 요청 중 99개는 100ms 만에 처리되었지만 1개만 10초(10,000ms)가 걸렸다고 가정해봅시다.

따라서 대부분의 사용자가 겪는 실제 경험을 파악하기 위해서는 p95(상위 5%), p99(상위 1%) 지표를 반드시 확인해야 합니다.

모니터링 시스템의 4가지 구성 요소

우리가 흔히 사용하는 '프로메테우스 + 그라파나' 조합은 이러한 모니터링 시스템의 역할을 수행하는 오픈소스 도구들입니다.

  1. 수집기 (Collector / Agent): 모니터링할 대상(서버, 애플리케이션, DB 등)으로부터 메트릭 데이터를 수집하는 역할을 합니다. (e.g., Prometheus 서버, Telegraf, 각종 Exporter)
  2. 저장소 (Storage): 수집된 대규모 시계열 데이터를 효율적으로 저장하고 조회할 수 있는 데이터베이스입니다. (e.g., Prometheus TSDB, M3DB, Thanos)
  3. 시각화 도구 (Visualizer): 저장된 데이터를 사람이 이해하기 쉬운 그래프나 대시보드로 보여주는 도구입니다. (e.g., Grafana, Kibana)
  4. 알림 시스템 (Alerter): 특정 조건(e.g., "CPU 사용률 90% 5분 이상 지속")이 충족되었을 때, 담당자에게 슬랙, 이메일 등으로 경고를 보내는 시스템입니다. (e.g., Prometheus Alertmanager)

면접관의 시선 💡

Q: "담당하고 있는 서비스의 상태를 파악하기 위해 어떤 지표들을 주로 모니터링하고, 그 이유는 무엇인가요?"

A: "저는 구글의 4대 골든 시그널인 Latency, Traffic, Errors, Saturation을 기준으로 모니터링합니다. 첫째, API 응답 시간의 p99, p95 Latency를 통해 실제 사용자가 겪는 성능 저하를 파악합니다. 둘째, RPS와 같은 Traffic 지표로 현재 시스템에 가해지는 부하 수준을 확인합니다. 셋째, HTTP 5xx 에러 비율을 통해 서비스의 안정성을 측정하고, 마지막으로 CPU/메모리 사용량과 DB 커넥션 풀 같은 Saturation 지표를 통해 시스템의 한계 용량을 예측하고 장애를 예방합니다. 이 지표들을 종합적으로 분석하면 서비스의 건강 상태를 다각도로 이해하고 문제 발생 시 신속하게 원인을 파악할 수 있습니다."


Q: "모니터링 시스템을 직접 구축한다면 어떤 구성 요소들을 고려해야 할까요?"

A: "모니터링 시스템은 크게 수집, 저장, 시각화, 알림의 네 가지 요소로 구성됩니다. 첫째, 각 서버와 애플리케이션에서 메트릭을 수집할 '수집기'가 필요합니다. 둘째, 수집된 시계열 데이터를 저장하고 쿼리할 수 있는 '저장소'가 필요합니다. 셋째, 이 데이터를 그래프와 대시보드로 보여줄 '시각화 도구'가 필요하며, 마지막으로 특정 임계치를 넘었을 때 담당자에게 경고를 보내는 '알림 시스템'이 필요합니다. 대표적인 오픈소스 조합으로는 수집과 저장, 알림을 담당하는 프로메테우스(Prometheus)와 시각화를 담당하는 그라파나(Grafana)를 사용하여 구축할 수 있습니다."