V1 Monitoring - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki

1. 도입 배경 및 목표

V1 Monitoring에서는 서비스 장애를 “서버가 죽었는지”가 아니라 “서비스가 정상 동작하는지”로 판단해야 함. 특히 외부 API와 Polling 요청이 몰리는 구조에서 DB 병목은 곧 체감 장애로 이어지기 때문에, 커넥션 풀(HikariCP)의 Active/Pending 상태를 핵심 선행 지표로 선정함.

2. 문제 상황

CloudWatch Agent 기반으로 JVM/GC 등 기본 지표는 수집 중이었으나, 정작 서비스 안정성에 직결되는 HikariCP 커넥션 풀 메트릭이 CloudWatch에 나타나지 않는 상황이 발생함. Actuator/JMX에서는 메트릭 조회가 가능했으나, “조회 가능”과 “CloudWatch로 전송”은 별개로 동작하고 있었음.

3. 해결 및 분석 과정

3.1 단계 1: 의존성 및 권한 기반의 기본 연동 시도

micrometer-registry-cloudwatch를 적용하고, CloudWatch 전송에 필요한 IAM 권한(예: PutMetricData)을 부여함. Actuator/JMX에서 값이 보이는 것을 근거로 “자동 전송될 것”이라 기대했으나, CloudWatch 콘솔에서 지표가 계속 비어있는 상태가 유지됨. 이 단계에서 의존성 추가만으로 자동 연동이 완성되지 않음을 확인함.

3.2 단계 2: CloudWatchMeterRegistry 수동 Bean 등록으로 전송 경로 강제 활성화

Spring Boot 자동 설정만으로는 전송 주기(step), namespace, registry 활성화 여부가 명확히 제어되지 않는 문제가 핵심 원인으로 판단함. 따라서 CloudWatchConfig를 커스터마이징하고 CloudWatchMeterRegistry를 수동 Bean으로 등록하여 전송 매커니즘을 강제로 활성화함. 이 조치 이후 CloudWatch에 HikariCP 메트릭이 실제로 생성되는 것을 확인하여, “수집 → 레지스트리 등록 → 전송” 파이프라인이 정상화되었음을 검증함.

3.3 단계 3: 비용 위기 감지 및 필터링 전략 적용

수동 등록 이후 문제가 하나 더 드러남. HikariCP만 올라오는 것이 아니라, JVM/Tomcat/CPU/스레드 등 Actuator 기반 지표 전부가 CloudWatch로 전송되면서 사용자 정의 메트릭이 600개 이상 생성되는 현상이 발생함. CloudWatch는 사용자 정의 메트릭이 늘어날수록 비용이 선형적으로 증가하기 때문에, 이 상태를 유지하면 월 수십만 원 단위 과금 위험이 현실화됨. 이에 따라 운영 관점에서 “많이 모으는 모니터링”이 아니라 “필수만 모으는 모니터링”으로 방향을 전환함.

최종적으로 MeterFilter를 적용하여 hikaricp 관련 지표만 허용하고 나머지는 차단함. 이로써 가시성(Active/Pending 모니터링)과 비용(불필요 지표 전송 차단)을 동시에 달성함.

4. CloudWatch로만 모니터링한 이유

4.1 V1 단계의 목표가 “최단 시간 내 운영 가시성 확보”였음

V1에서 가장 중요한 것은 완벽한 관측 플랫폼 구축이 아니라, 장애를 빠르게 감지하고 원인에 접근 가능한 수준의 가시성을 최소 비용/최소 복잡도로 확보하는 것이었음. CloudWatch는 이미 AWS 인프라 안에서 기본 관측 채널로 자리 잡고 있고, IAM/네임스페이스/대시보드로 바로 운영 가능한 장점이 있어 초기 목표에 부합함.

4.2 Prometheus 도입은 “인프라 운영 책임”이 함께 따라옴

Prometheus를 선택하면 단순히 메트릭을 보는 수준을 넘어, 서버/스토리지/고가용성/업그레이드/백업/보안까지 운영 항목이 확장됨. 즉 “모니터링 기능”을 얻는 대신 “모니터링 플랫폼 운영”이라는 새로운 제품을 하나 더 만드는 것과 같아짐. V1에서는 신규 운영 부하를 늘리기보다, 기존 AWS 운영 흐름에 녹는 CloudWatch로 집중하는 것이 합리적이었음.

4.3 비용 관점에서 Prometheus가 항상 더 싸다고 단정할 수 없었음

Prometheus는 메트릭 개수 자체 과금은 없지만, 그 대신 클러스터 리소스(메모리/디스크)와 보관 정책(장기 저장 시 Thanos/Mimir 등) 비용이 발생함. V1에서는 “장기 분석”보다 “즉시 장애 감지”가 우선이었고, 필요한 지표를 HikariCP로 좁히면 CloudWatch 비용도 통제 가능했기 때문에 CloudWatch가 더 현실적인 선택이었음.

4.4 결론적으로 “V1은 CloudWatch, 확장 단계에서 Prometheus” 전략이 적합했음

현 단계에서는 CloudWatch로 핵심 지표 중심의 최소 관측 체계를 먼저 완성함으로써 운영 안정성을 확보함. 이후 트래픽 성장과 함께 SLI/SLO 기반의 장기 분석, 고해상도 메트릭/카디널리티 확장, 서비스 간 상세 비교가 필요해지는 시점에 Prometheus(또는 Managed Prometheus)로 확장하는 로드맵이 자연스러움.

5. 운영 적용 방식 요약

HikariCP 핵심 지표(Active, Pending 중심)를 CloudWatch로 전송하고, 대시보드/알람 기준을 “DB 병목 조기 감지” 관점으로 설정함. 불필요한 메트릭은 MeterFilter로 차단하여, 모니터링이 비용 부채로 변질되는 것을 예방함.

6. 배운 점

“의존성 추가 = 자동 연동”이 아니라, 클라우드 연동에서는 전송 주기/레지스트리 활성화/권한/네임스페이스를 서비스가 직접 제어해야 함을 확인함. 또한 모니터링은 많이 쌓는 것이 목적이 아니라, 우리 서비스에서 실제 장애를 앞당겨 감지하는 핵심 지표를 선별하는 설계 활동임을 체감함. 비용까지 포함해서 설계해야 운영에서 지속 가능한 모니터링이 된다는 점을 V1에서 학습함.