아키텍처
MultiDatasource·Prologue로 Pod·JVM 비용 절감
두줄요약
Pod·JVM 반복 비용을 줄이기 위해 서비스 경계와 데이터 경계를 유지한 통합 Boot 구조를 설계했습니다.\nMultiDatasource와 package 기반 트랜잭션 라우팅을 Prologue 자동 구성으로 공통화했습니다.
문제 상황
- 마이크로서비스별 Pod·JVM·Spring Context·thread pool·connection pool의 반복 비용
- 낮은 트래픽 서비스까지 독립 실행 단위로 유지할 때의 운영 대상 증가
구조와 흐름
- 서비스별 Gradle 모듈·package·DataSource·persistence unit 유지, 통합 Boot를 유일한 실행 진입점으로 구성
- 서비스별 EntityManagerFactory·JpaTransactionManager·Flyway를 분리하고 package 기반으로 트랜잭션 라우팅
- 검증된 MultiDatasource topology와 persistence Bean 생성 규칙을 Prologue 자동 구성으로 공통화
트레이드오프
- 하나의 JVM에서 중복 런타임 자원 절감 가능, 서비스별 connection pool 예산의 통합 관리 필요
- 통합 Context의 Bean·Config 충돌과 장애 영향 범위 확대 가능성
- 다중 DataSource 간 원자적 트랜잭션 미지원, 보상 처리·outbox·재시도·멱등성 등 별도 전략 필요
성능/운영 포인트
- HikariCP maximumPoolSize·minimumIdle과 DB max_connections의 topology 단위 산정
- CPU·heap·GC·thread 수·DB connection·장애 범위의 운영 환경 측정 필요
- 독립 확장·상이한 배포 주기·강한 장애 격리 요구 서비스의 별도 Pod 유지
