문제
분석 시스템과 LIMS를 연결하는 초기안은 분석 반응마다 Java 모듈을 새로 실행하는 방식이었다. 모듈은 실행될 때 설정을 읽고 DB에 연결해 데이터를 처리한 뒤 종료됐다. 기존 분석 자체는 짧게 끝나는데 JVM 기동과 DB 연결 비용이 반응마다 반복되면 전체 처리량이 낮아질 수 있었다.
처음에는 Connection Pool을 적용하면 연결 비용을 줄일 수 있다고 예상했다. 하지만 Pool의 효과는 Connection을 다음 요청에서도 재사용할 수 있을 때만 생긴다. 프로세스가 한 번 처리한 뒤 종료된다면 Pool도 함께 사라진다.
구현 방식을 나눠 측정
추측으로 구조를 결정하지 않기 위해 세 가지 방식을 실제 서버에서 구현하고 실행 구간을 나눠 비교했다.
- Spring Boot와 HikariCP
- Non-Spring MyBatis Connection Pool
- 직접 JDBC 연결
측정 구간은 애플리케이션 초기화, Connection 획득, Query 실행, Result Mapping으로 분리했다. Query만 빠른지 보는 대신 요청 한 건이 프로세스 시작부터 결과 반환까지 부담하는 전체 비용을 확인했다.
Pool이 해결하지 못한 이유
반응마다 새로운 JVM이 시작되면 Pool은 빈 상태에서 생성된다. 첫 Connection을 만든 뒤 재사용할 다음 요청이 오기 전에 프로세스가 종료되므로, Pool 초기화 비용은 추가되지만 재사용 이점은 얻기 어렵다.
Spring Boot·Non-Spring MyBatis Pool·직접 JDBC 방식의 초기화·Connection·Query·Mapping 구간을 측정하는 코드는 확인했다. 다만 실행 결과 로그는 보존되지 않아 구체적인 시간값을 실제 성능이나 달성 수치로 채택하지 않는다. 확인 가능한 결론은 반응마다 JVM이 종료되는 구조에서는 Pool 재사용 효과를 얻기 어렵다는 생명주기 판단이다.
판단을 바꾼 지점
Spring Boot, MyBatis Pool, 직접 JDBC 중 어느 구현이 조금 더 빠른지를 고르는 것으로는 반복 초기화라는 상위 병목을 제거할 수 없었다. 그래서 라이브러리 선택 문제가 아니라 프로세스 생명주기 문제로 다시 정의했다.
선택한 방향은 LIMS 연계 기능을 상시 기동 애플리케이션으로 운영하고, 분석 시스템이 REST API를 호출하도록 바꾸는 것이었다. JVM과 Pool을 유지한 채 여러 요청을 처리하므로 초기화와 Connection 생성 비용을 요청마다 반복하지 않는다.
REST API 구조
실제 API 메서드명은 공개하지 않고 담당 기능으로만 설명한다.
- 분석 결과와 관련 데이터를 저장하는 API
- 분석에 필요한 샘플 정보를 조회하는 API
- 분석 실패 상태와 원인을 전달하는 API
- 요청값 검증, 토큰 인증, 표준 예외 응답과 요청·응답 이력 저장
- 본사·유럽·일본 Profile과 Oracle·MariaDB Mapper 분리
결과, 결과 파일, 신호 정보, 반응 상태, 주문별 집계, Report와 변경 이력은 하나의 트랜잭션 경계에서 처리했다. 기존 데이터 존재 여부에 따른 Insert와 Update 분기도 API 내부 책임으로 모았다.
확인 가능한 측정 범위
세 구현의 구간별 측정 코드는 구현 방식과 비교 범위를 확인하는 근거다. 실행 결과 로그가 보존되지 않은 만큼 특정 시간이 달성됐다고 주장하지 않고, 프로세스 종료와 함께 Pool도 사라져 다음 반응에서 Connection을 재사용할 수 없다는 구조적 판단까지만 확정 범위로 둔다.
적용 결과
반응별 모듈 기동 방식의 처리량 위험을 운영 도입 전에 제거하고, 분석 시스템과 LIMS 사이의 결과·오류·Comment 전달을 상시 기동 REST API 계약으로 통합했다. 담당 범위는 전체 분석 제품의 설계나 개발이 아니라 AS-IS 분석, 연계 구조 검증, 직접 수행한 LIMS API와 오류 처리, 법인 환경 적용이었다.
정리
Connection Pool은 프로세스보다 오래 살 수 없다. 성능 문제의 원인이 객체 생명주기보다 상위인 프로세스 생명주기에 있다면 Pool 구현을 바꾸는 최적화만으로는 해결되지 않는다. 측정 단위도 Query 시간에 머물지 않고 프로세스 시작부터 종료까지 확장해야 구조를 바꿔야 할 지점을 찾을 수 있다.