PaymentMetrics Gauge 관련 이슈

[rabitis99]

1️⃣ 문제 요약

현재 PaymentMetrics.recordPaymentAmount / recordPaymentRefund에서

meterRegistry.gauge("payment.amount", Arrays.asList(Tag.of("payment_method", paymentMethod)), amount);

를 사용하고 있음.

문제점: 동일한 name + tag 조합으로 gauge를 재호출하면 기존 Gauge 객체만 유지, 이후 값 변경은 반영되지 않음.

결과: Prometheus/Grafana에서 금액 지표가 최초 등록 값으로 고정됨.

2️⃣ 현재 영향 범위

메트릭 정확성: 결제 금액 지표가 실시간 반영되지 않음.

결제 처리량 통계: Counter/Timer 기반은 정상 동작 → 영향 없음.

알림/포인트/캐시백 로직: 메트릭과 무관 → 영향 없음.

3️⃣ 기존 해결 방안

AtomicReference + Map 분리 구조 적용

paymentMethod별 AtomicReference를 저장

Gauge 등록 시 AtomicReference 바인딩

값 변경 시 ref.set(newAmount) 호출

장점

실시간 금액 반영 가능

멀티스레드 안전

등록 중복 문제 해결

단점

코드 복잡도 증가 → 과도한 설계 가능성

결제 건수가 많지 않다면 오버스펙

4️⃣ 선택적 대안

분리 구조 유지

장점: 실시간 금액 추적 가능, Prometheus 반영 정확

단점: 코드 복잡, 오버스펙 가능

기존 Gauge 구조 유지

장점: 코드 단순, 유지보수 용이

단점: 최초값만 기록 → 실시간 금액 지표 정확도 낮음

대응: 결제 건수/성공/실패만 모니터링해도 충분하면 OK

DistributionSummary 도입

결제 금액 통계를 누적/분포 형태로 수집

장점: 실시간 값 갱신 필요 없음, 통계/평균/퍼센타일 분석 가능

단점: 단일 최신 금액 지표는 불가

5️⃣ 검토 포인트

Prometheus에서 금액 지표 실시간 반영이 필수인가?

결제Method 종류 및 트래픽 수준

메트릭 활용 목적: 단순 통계 vs 실시간 모니터링

코드 단순화 vs 정확한 값 반영

6️⃣ 결론 (초안)

현재 구조로도 Counter/Timer 기반 통계는 충분히 운영 가능

실시간 금액 반영이 필요하면 AtomicReference 구조 적용

필요성 검토 후 결정