🫂 Team
📅 Duration
2025.06 - 현재
<aside> ⚠️
rw 도메인의 MySQL 데이터베이스 부하 부담을 줄이기 위해 배치 및 인터널 조회 쿼리에 ro3 도메인을 적용해야 했습니다.
관련 히스토리를 찾아보며 사내 라이브러리가 있음을 알게 되었으나, 해당 라이브러리에서는 한 쌍의 ro/rw 도메인 설정을 지원하는 것을 확인했습니다.
계좌 도메인의 MySQL 데이터베이스에서는 마스터와 로그로 분리해 사용되고 있어, 플랫폼 라이브러리를 그대로 적용하지 못하고 커스텀 설정이 필요했습니다.
</aside>
<aside> ☝
이전에 여러 DataSource를 JPA에 적용해본 경험이 없어, 먼저 commons에서 제공하는 Routing 관련 코드를 분석하였고,
해당 RoutingDataSource 및 AutoConfiguration을 참고하여 기존에 인터널 모듈에 적용되어있던 DataSource 관련 설정을 수정했습니다.
AbstractRoutingDataSource 를 상속하여 현재 트랜잭션의 readOnly 값에 따라 DataSource 가 결정하는 RoutingDataSource를 추가했습니다.
또한, 기존의 서비스와 인터널 모듈에서 통일되어 있던 설정에서 특정 값에 따라 각 모듈에서 서로 다른 설정이 적용되도록 했습니다.
작업 당시 사내 플랫폼 라이브러리의 코드를 참고하며 현 프로젝트에 추가하면서, 일부 클래스를 유사하게 가져온 것들이 있었습니다.
이에 추후 리팩토링을 통해 라이브러리 클래스를 그대로 사용할 수 있는 것들은 변경하여 프로젝트에 실제 필요한 클래스만 관리되도록 개선했습니다.
</aside>
<aside> ✌️
인터널 모듈과 달리 배치 잡에서는 일부 도메인 서비스를 그대로 사용하는 경우 외 대부분 QueryProvider 를 통해 직접 native 쿼리를 작성하고 있습니다.
따라서 기존 로직 역시 해당 QueryProvider 에서 DataSource를 직접 주입하고 있어, RO3 도메인이 설정된 DataSource로 변경하는 방식으로 진행했습니다.
배치 쿼리의 경우 서비스 로직과 달리 @Tx 로 선언적 트랜잭션을 명시할 수 없고, 스프링 배치 자체에서 각 배치 step의 chunk 단위로 트랜잭션을 관리한다는 점을 알게되어 위 방식을 선택했습니다.
</aside>
<aside> 💭
해당 작업 이후 실제 DataSource가 분기되는지 확인하기 위해 디버깅 해보면서 트랜잭션 및 DataSource, 커넥션 등의 흐름 등을 파악할 수 있었습니다.
AbstractRoutingDataSource.determineLookUpkey 호출되는 시점