Actuator와 Micrometer로 기준선 만들기

성능 개선은 "느린 것 같다"는 느낌이 아니라 반복해서 비교할 수 있는 기준선에서 시작합니다. 요청 지연 시간, 처리량, 오류율, 포화도를 같은 조건에서 기록해야 변경 전후가 실제로 나아졌는지 판단할 수 있습니다.

Spring Boot Actuator는 운영 endpoint를 제공하고, Micrometer는 애플리케이션의 측정값을 벤더 중립적인 meter로 기록합니다. Observation은 같은 계측 지점에서 metric과 trace에 필요한 문맥을 함께 다루는 API입니다.

최적화는 측정 가능한 가설에서 시작한다

평균 응답 시간만 보면 소수의 매우 느린 요청이 가려질 수 있으므로 p50·p95·p99 같은 분포를 봅니다. 처리량이 늘었더라도 오류율과 DB pool 대기가 함께 증가했다면 성공적인 개선이 아닙니다. 네 신호를 함께 읽어야 병목을 다른 위치로 옮긴 일을 최적화로 착각하지 않습니다.

tag는 비교 축을 만들지만 값 종류가 무한히 늘면 시계열 저장소를 압박합니다. operation=subject-summary처럼 선택지가 제한된 값은 low-cardinality tag로 적합하지만, 사용자 입력인 subject나 세션 ID는 tag로 넣지 않습니다.

Actuator와 Observation을 요청 경로에 연결한다

보고서 생성 경계를 study.report Observation으로 감쌉니다. 성공과 실패 모두 같은 계측 지점을 지나므로 호출 횟수와 소요 시간을 비교할 수 있습니다.

package com.andongmin.studylog.report;

import io.micrometer.observation.Observation;
import io.micrometer.observation.ObservationRegistry;
import org.springframework.stereotype.Service;

@Service
public class ObservedReportService {
    private final StudyReportService reports;
    private final ObservationRegistry registry;

    public ObservedReportService(StudyReportService reports,
            ObservationRegistry registry) {
        this.reports = reports;
        this.registry = registry;
    }

    public ReportPort.SubjectReport report(String subject) {
        return Observation.createNotStarted("study.report", registry)
                .lowCardinalityKeyValue("operation", "subject-summary")
                .observe(() -> reports.report(subject));
    }
}

management.endpoints.web.exposure.include=health,info,metrics
management.endpoint.health.show-details=never

Actuator endpoint 공개 범위와 방화벽·인증 범위는 별개입니다. 인터넷에 그대로 노출하지 말고 운영 네트워크와 Spring Security 정책으로 접근을 제한합니다. health 세부 정보를 숨긴 설정도 내부 구성과 장애 원인을 불필요하게 공개하지 않기 위한 선택입니다.

부하 전후 p95와 오류율을 비교한다

서버를 실행한 터미널은 그대로 두고, 다른 터미널에서 보고서 API를 여러 번 호출한 뒤 meter를 조회합니다. 아래 /api/reports/Spring 경로는 ch7의 보고서 Controller 경로에 맞게 조정하세요.

./mvnw -q spring-boot:run

curl -s -H "Authorization: Bearer $READ_TOKEN" \
  http://localhost:8080/api/reports/Spring > /dev/null
curl -s http://localhost:8080/actuator/metrics/study.report

호출 뒤 study.report의 count와 total time이 증가하고 subject 값은 metric tag로 들어가지 않아야 합니다.

기준선에는 실행 조건도 함께 기록한다

요청 수치만 저장하면 다음 측정과 비교할 수 없습니다. JVM 옵션, CPU·메모리 제한, 데이터 양, 동시 사용자 수, warm-up 시간, DB pool 크기를 결과와 함께 기록합니다. 코드가 같아도 조건이 다르면 p95 차이를 코드 변경의 효과로 결론 내릴 수 없습니다.

기준선을 만들었으니 다음에는 흔한 병목인 JPA 쿼리 수와 데이터베이스 실행 계획을 직접 확인합니다.