[실시간 대용량 서비스] Prometheus 모니터링 시스템 실제 적용기

개념 정리와 설계 의도를 담았던 이전 포스팅에 이어서 실제 구현을 진행하고 나서의 내용들을 정리해보고자 한다.

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

이미 CI/CD 기반 배포 환경이 구성되어 있었기 때문에,

모니터링 시스템 또한 Docker 기반 구조 안에서 자연스럽게 통합하는 방향으로 접근했다.

 

 

그리고 프로젝트의 설정을 진행했는데, 가장 먼저 필요했던 건 의존성 추가를 통해 정상적으로 모니터링이 동작할 수 있도록 하는 부분이었다.

 

implementation 'org.springframework.boot:spring-boot-starter-actuator'
runtimeOnly 'io.micrometer:micrometer-registry-prometheus'

 

1. Actuator 연동과 첫 번째 문제 - 401 오류

의존성 추가 이후 실제 서버에서의 동작을 점검하기 위해 /actuator/prometheus 엔드포인트가 정상적으로 노출되는지 확인했다.

 

Prometheus는 이 엔드포인트를 주기적으로 scrape 하여 메트릭을 수집하게 되는데,

초기 설정에서는 Prometheus Target 상태가 DOWN으로 표시되었다.

 

로그를 확인해보니 다음과 같은 메시지가 나타났다.

server returned HTTP status 401

 

이 에러의 경우는 Spring Security의 설정으로 인해 인증이 요구됨으로서 접근이 차단되었던 부분을 고려하지 못해 발생했었다.

 

2. 단순 해결과 두번째 고민 - 보안 이슈

문제를 해결하기 위해 SecurityPathPolicy 내 permitAll() 대상으로 해당 엔드포인트를 추가하였더니 

Prometheus Target 상태가 정상적으로 UP 되고, 메트릭 수집 또한 정상적으로 동작하였다.

 

그러나 코드 리뷰 과정에서 중요한 피드백을 받았다. 

/actuator/prometheus를 공개 API 포트(8080)에서 permitAll로 열어두는 것은 보안상 위험할 수 있다.

운영 환경에서 안전한 구조인가? 에 대한 고민을 하게되는 순간이었다.

 

3. Management Port 분리 - 구조적 개선

결국 선택한 방법은 Actuator를 서비스 포트와 분리하는 것이었다.

• 서비스 요청 포트 : 8080
• 관리용 Actuator 포트 : 9091

management.server.port=9091 설정을 통해 Actuator는 별도의 관리 포트에서만 동작하도록 분리하였다.

 

또한 Docker Compose 설정에서 해당 포트는 expose만 사용하여 Docker 네트워크 내부에서만 접근 가능하도록 구성하였다.

    expose:
      - "9091"

 

이렇게 설정하는 경우 외부에서는 해당 포트에 접근할 수 없기 때문에 실질적인 보안 위험을 제거할 수 있었다.

이 과정에서 단순 설정 수정이 아닌 서비스 트래픽과 관리 트래픽을 분리하는 설계의 중요성을 체감하게 되었다. 

 

4. Docker 네트워크의 이해

Grafana에서 Prometheus를 연동하는 과정에서도 작은 혼란이 있었다. 

처음에는 Prometheus URL을 다음과 같이 설정하였다.

http://localhost:9090

 

Grafana는 별도의 컨테이너에서 실행되고 있기 때문에 Grafana 컨테이너 내부에서의 localhostsms Prometheus가 아니라 자기 자신을 의미했다. 

 

그래서 올바른 경로로 적용하면 다음과 같았는데

http://peaktime-prometheus:9090

Docker 네트워크 내부에서는 컨테이너 이름이 DNS처럼 동작한다는 점을 이해해야만 해결할 수 있는 문제였다.

 

5. EC2에서의 충돌 - 운영 서버는 개발 공간이 아니다.

운영 서버에서 git pull을 통해 작업을 진행함에 있어서 충돌이 발생하였다.

 

이는 운영 서버에 존재하는 docker-compose 파일과 원격 파일의 변경사항이 충돌함으로서 발생한 문제였다.

 

EC2 서버를 다시 재설정하고 띄우는 과정에서 발생한 부분으로  한가지 원칙을 명확하게 해야함을 깨달았다.

 

운영 서버는 코드를 수정하는 공간이 아니라, 배포된 결과를 실행하는 공간이다.

 

모든 과정들은 로컬 브랜치 → PR → Merge → 서버 pull 의 흐름으로 진행하기로 했다.

 

6. 최종 구성한 대시보드 구성 

이번 프로젝트에서 구성한 대시보드는 별도 커스터마이징을 크게 진행하거나 하지는 않았고 핵심 지표를 중심으로 설계하였다.

 

• RPS (Request per Second)
  • 전체 요청량 추적
  • 트래픽 급증 감지
• 5xx Error Rate
  • 서버 내부 오류 비율 모니터링
  • 1% 이상 시 주의 필요
• 평균 응답 시간
  • 서비스 체감 성능 확인
• JVM Heap / GC
  • 메모리 누수 및 GC 과부하 감지

 

이러한 대시보드를 통해서 얻은 효과는 다음과 같이 정리할 수 있었다. 

 

• 단순히 로그를 뒤져보는 방식이 아닌 시스템 상태를 수치로 바라보는 관점을 제공한다.
• 기존에는 장애가 발생한 이후 로그를 통해 원인을 추적하는 방식이었다면, 이제는 지표를 통해 이상 징후를 먼저 감지할 수 있는 구조가 되었다.
• GC, Heap 사용량, 응답 시간 등의 지표를 함께 보면서
  트래픽 증가 → Heap 증가 → GC 증가 → Latency 증가 와 같은 흐름을 관찰할 수 있게 되었다.

이는 단순 기능 개발을 넘어서서, 애플리케이션이 런타임 환경에서 어떻게 동작하는지를 이해하는 데 도움이 되었다.

• CI/CD 기반으로 배포가 이루어지는 구조에서 배포 이후 성능 변화나 오류율 변화를 즉시 확인할 수 있다.
  이를 통해 배포가 시스템에 어떤 영향을 미쳤는지 확인할 수 있는 근거를 제공할 수 있었다.
• 모니터링 관련 추가 이후에는 왜 에러가 발생했을까? 에서 질문이 출발했다면 지표가 언제부터 비정상적으로 변했는가에 대해 선제적 운영에 가까워질 수 있었다. 

🔥 정리하며..

다만, Metrics 기반 모니터링은 이상 징후를 감지하는데는 효과적이지만, 구체적인 요청 로그나 사용자 단위 분석까지는 제공하지 못한다.

 

따라서 다음 단계로 로그 기반 관측 환경 (ELK)을 구성하여 보다 정밀한 원인 분석이 가능한 구조로 확장해보고자 한다.