레거시 주문 이력 서비스의 런타임과 모니터링 교체
BLOHA는 글로벌 전환 이후에도 과거 주문을 조회하기 위해 유지한 서비스입니다. 조회 기능에 큰 변화가 없어도 프레임워크와 의존성의 취약점, 모니터링 환경 변경에는 대응해야 했습니다.
2024년 7월부터 2025년 11월까지 모니터링 전환과 Java·Spring Boot 업그레이드, 후속 패치를 진행했습니다. 주문 조회를 계속 제공하면서 기반 환경을 바꾸는 작업이었습니다.
모니터링 전환
2024년 7월에는 New Relic에서 SignalFx로 모니터링을 옮겼습니다. Java Agent와 OpenTelemetry·Micrometer를 통한 계측·전송 구성을 확인하고, 새 환경에서도 필요한 지표와 알림을 볼 수 있도록 준비했습니다.
전환 전후에 HTTP 요청 수와 응답 시간, 오류율이 어떤 이름과 태그로 수집되는지 확인해야 했습니다. 대시보드가 열린다는 것만으로 같은 대상을 보고 있다고 판단할 수는 없었습니다. 자동 계측으로 수집하는 지표와 서비스에서 추가한 지표가 중복되는지도 살펴볼 항목이었습니다.
이는 이전 도구는 모두 자동이고 새 도구는 모두 수동이라는 구분과는 다릅니다. 사용하는 에이전트와 라이브러리 설정에 따라 수집 범위가 달라지므로 실제 서비스의 계측 구성을 기준으로 봐야 합니다.
Java 21과 Spring Boot 3 전환
2025년 10월에는 Java 11에서 21로, Spring Boot 2.7에서 3.5.6으로 올렸습니다. 의존성의 보안 취약점 대응도 이 작업에 포함됐습니다.
Spring Boot 3은 Java 17 이상을 요구하며 Spring Framework 6과 Jakarta EE 기반으로 바뀝니다. 프로젝트에서는 Java 21을 선택했습니다. 기존 JPA와 Servlet, Validation 관련 코드와 라이브러리가 함께 호환되는지 확인해야 했습니다.
예를 들어 JPA import는 다음처럼 바뀝니다. 패키지 이름만 일괄 치환하면 끝나는 작업은 아니고, 해당 API를 사용하는 의존성도 맞춰야 합니다.
-import javax.persistence.Entity;
+import jakarta.persistence.Entity;모든 javax 패키지가 jakarta로 바뀌는 것도 아닙니다. 아래 캐시 연동에 쓰는 JCache는 javax.cache API를 사용합니다. 적용하는 라이브러리의 실제 버전과 API를 확인해야 했습니다.
Caffeine을 이용한 Hibernate 캐시
이력 데이터는 저장한 뒤 거의 수정하지 않고 반복해서 조회하는 특성이 있었습니다. 이 접근 패턴을 바탕으로 Hibernate의 2차 캐시에 Caffeine을 사용하는 작업도 진행했습니다.
Spring의 @Cacheable과 Hibernate의 2차 캐시는 설정 대상이 다릅니다. spring.cache.caffeine.spec만 추가한다고 Hibernate 엔티티 캐시가 구성되지는 않습니다. Hibernate와 캐시 구현체를 연결하는 RegionFactory와 대상 엔티티·영역 설정이 필요합니다.
Hibernate 공식 문서는 Caffeine의 JCache 구현과 hibernate-jcache를 연결하는 구성을 안내합니다. 이때 엔티티 캐시와 쿼리 캐시도 구분해서 봐야 합니다. 조회 결과를 캐시한다고 모든 쿼리가 자동으로 캐시되는 것은 아닙니다.
캐시의 최대 크기와 만료 조건은 별도 설정입니다. 과거 주문이 거의 바뀌지 않더라도 데이터 보정이나 보존 기간에 따른 삭제가 있다면 캐시에서도 이를 반영해야 합니다. 읽기 빈도와 메모리 한도, 데이터 변경 경로를 기준으로 만료 조건을 정해야 합니다.
후속 패치와 조회 기능 확인
다음 달에는 Spring Boot 3.5.8 패치를 적용했습니다. 큰 버전 전환을 마친 뒤에도 의존성과 보안 패치 관리를 이어 갔습니다.
이런 작업에서는 기동과 컴파일 성공 외에 주문 상세와 CS 조회, 인증·권한 검사, 오류 응답을 확인해야 합니다. 캐시가 켜진 경우와 비워진 경우의 결과가 같은지, 모니터링과 알림이 계속 수집되는지도 확인할 항목입니다.
새로운 주문 기능을 추가한 작업은 아니었지만, 계속 제공해야 하는 조회 서비스를 이후에도 패치할 수 있는 상태로 유지하는 데 필요한 변경이었습니다.