[실시간 대용량 서비스] 모니터링 시스템 구축은 왜 필요한가 ?

프로젝트의 구현과정을 어느정도 경험하면서 모니터링 시스템은 왜 필요한지에 대한 궁금증이 생겼다.

 

모니터링 시스템은 종류도 많고 담당하는 역할도 정말 다양한데 그 중에서도 나는 이번 프로젝트에서 

 

Grafana + Prometheus를 활용한 모니터링 시스템 구축을 진행하고자 한다. 

 

📝 모니터링 시스템의 종류와 비교 정리

위에서 설명했듯 모니터링 시스템의 종류는 아래와 같이 다양했다.

구분	대표 툴	역할	장점	단점	적합한 환경
Metrics 수집	Prometheus	메트릭 수집/ 저장	Kubernetes 표준, 강력한 쿼리(PromQL), 오픈소스	초기 세팅 필요	컨테이너 /클라우드 환경
시각화	Grafana	대시보드/알림	다양한 데이터소스, Alert 기능	별도 구성 필요	거의 모든 환경
로그 분석	ELK Stack	로그 저장/검색	강력한 검색, 대규모 운영 적합	무겁고 비용 높음	대규모 서비스
로그 분석(경량)	Loki	로그 집계	가볍고 Grafana와 궁합 좋음	ELK보다 기능 제한	중소규모 서비스
분산 추적	Jaeger / Grafana Tempo	요청 병목 추적	마이크로서비스에 유ㅠ용	초기 학습 필요	MSA 구조
상용 APM	Datadog / New Relic	통합 모니터링	자동 계측, UI 완성도 높음	비용	기업/대규모

 

위의 내용을 풀어서 다시한번 설명하자면

1. Metrics vs Logs vs Tracing

• Metrics → "서버 상태를 숫자로 본다"
• Logs → "무슨 일이 발생했는지 본다"
• Tracing → "요청 하나가 어디서 느린지 본다"

운영 관점에서 가장 먼저 필요한건 보통 Metrics에 해당한다.

그 이유로는

• 장애 감지
• 성능 저하 감지
• 리소스 초과 감지

에 대한 부분이 숫자로 먼저 보이기 때문이다.

 

🤔 왜 Prometheus + Grafana를 선택해야 했는가 

이번에 진행하는 프로젝트 자체가 Spring Boot 기반 프로젝트인 점,

Docker 컨테이너 환경에 EC2 서버로 운영을 진행하고 있고 규모가 크지 않은 단계에서의 운영환경인 점을 고려하여

• 비용 효율이 좋고
• 컨테이너 친화성이 있고 
• 확장 가능성을 갖고 있으며 
• 참조할 만한 레퍼런스가 풍부한 툴을 사용해야 했다.

그 중에서도 위의 내용을 보완하기 위해 선택한 툴들을 정리하자고 하면

 

☑️ Prometheus를 선택한 이유

• Spring Boot Actuator와 바로 연동 가능
• Kubernetes / 컨테이너 환경에서 사실상 표준으로 사용을 한다는 점
• Pull 기반 구조 → 중앙 관리가 용이하고
• PromQL을 통한 세밀한 분석이 가능하고
• 완전 오픈소스로 비용 부담이 없다는 점이었다.

즉, 현재 인프라 구조와 가장 자연스럽게 연결되는 메트릭 수집 시스템

☑️ Grafana를 선택한 이유

• Prometheus와 궁합이 뛰어남
• 다양한 대시보드 템플릿 존재
• Alert 기능 기본 제공
• Loki, Tempo까지 확장 가능

즉, 단순 시각화를 넘어 확장 가능한 관측 플랫폼이라는 이유에서였다

 

상용 APM은 아무래도 프로젝트의 규모나, 비용의 부담을 고려하지 않을 수 없어서 위의 툴을 채택하게 되었다. 

 

👉 현재의 아키텍쳐 구조, 그리고 모니터링 시스템 도입 이후 아키텍쳐의 모습

기존의 아키텍쳐 구조는 다음과 같았다.

• 사용자 요청 → 서버 → DB
• 단일 요청 흐름 중심 구조에 있었다면,

 

변경 후 아키텍쳐의 구조는

• 사용자 요청 흐름
• 메트릭 수집 흐름

즉 데이터 흐름이 하나 더 생기는 부분이라고 볼 수 있다 .

 

이를 통해 아래와 같은 변화를 기대할 수 있을 것으로 본다. 

• Before : 장애 / 지연 발생  → 로그 찾아보기 → 재현 어려움
• After : 지표 이상 감지 → 문제 원인의 후보를 좁힘 → 대응 시간 단축

🔍 그렇다면 무엇을 모니터링 할 것인가? 

모니터링 시스템을 도입하는 것과 더불어 중요한 포인트는 어떤 지표를 기준으로 시스템을 바라볼 것인가 에 대한 정의이다.

운영 관점에서 가장 기본이 되는 지표는 다음과 같이 설정하기로 했다.

 

1. Traffic(트래픽)

• 초당 요청 수(RPS)
• 엔드포인트별 호출량

서비스에 유입되는 요청의 양을 확인함으로써 비정상적인 트래픽 증가나 스파이크를 감지할 수 있다.

 

2. Errors(에러율)

• 4xx 에러 비율
• 5xx 에러 비율

5xx 에러 비율은 서버 내부 오류를 의미하기 때문에 운영에서 가장 민감하게 관찰해야 하는 지표 중 하나이다.

 

3. Duration(지연 시간)

• 평균 응답 시간
• p95 / p99 latency

평균값은 정상이어도 일부 요청이 극단적으로 느려질 수 있기 때문에 p95 지표를 기준으로 모니터링을 진행할 예정이다.

 

4. Saturation (자원 사용률)

• CPU 사용량
• JVM Heap 사용률
• GC pause 시간
• DB 커넥션 풀 사용 현황

리소스 고갈은 장애로 직결되기 때문에 사전에 감지할 수 있는 기준선을 설정하는 것이 중요하다 .

 

실제 구현 과정에서 발생한 특이사항과 진행 내용에 대해서는 다음 포스팅으로 이어가도록 하겠다.