Spring AOP - Master & Slave DB 쿼리 분산하기

DB 이중화를 구축했다면 어플리케이션에서도 읽기 전용 DB를 구분해서 쿼리를 분산해야 한다. 먼저 쿼리 분산에 대한 정책을 설정해야 하는데, 다음과 같은 형태로 쿼리 분산을 시켜볼 예정이다.

규칙 1. @RouteDataSource(type)을 이용해 DB를 결정 (type: MASTER | SLAVE)
규칙 2. @Transactional(readOnly)을 이용해 DB를 결정 (readOnly: true | false)

@RouteDataSource(MASTER)
public service() {
  // ...
}

@Transactional(readOnly=true)
public service() {
  // ...
}

 

Datasource 정보 등록

먼저 yaml 파일 작성을 해야 하는데, 특별한 것은 없고 Master, Slave에 대한 DataSource 정보를 작성해주면 된다. 

 

`application.yml`

spring:
  datasource:
    master:
      hikari:
        username: ${MASTER_USERNAME}
        password: ${MASTER_PASSWORD}
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: ${MASTER_JDBC_URL}
        
    slave:
      hikari:
        username: ${SLAVE_USERNAME}
        password: ${SLAVE_PASSWORD}
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: ${SLAVE_JDBC_URL}

 

참고로 jdbc-url은 `jdbc:mysql://{RDS 엔드포인트}/{DB 이름}` 형식으로 작성하면된다. 그리고 나서 Master DB와 통신할 Bean 객체와 Slave DB와 통신할 Bean 객체를 등록해야 한다.

 

`DataSourceConfig.java`

package com.anchor.global.db;

import com.querydsl.jpa.impl.JPAQueryFactory;
import jakarta.persistence.EntityManager;
import jakarta.persistence.EntityManagerFactory;
import java.util.HashMap;
import java.util.Map;
import javax.sql.DataSource;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.boot.autoconfigure.orm.jpa.HibernateProperties;
import org.springframework.boot.autoconfigure.orm.jpa.HibernateSettings;
import org.springframework.boot.autoconfigure.orm.jpa.JpaProperties;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.boot.jdbc.DataSourceBuilder;
import org.springframework.boot.orm.jpa.EntityManagerFactoryBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.DependsOn;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy;
import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;
import org.springframework.orm.jpa.JpaTransactionManager;
import org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean;
import org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.annotation.EnableTransactionManagement;

@Configuration
@EnableTransactionManagement
public class DataSourceConfig {

  private final String MASTER_DATASOURCE = "masterDataSource";
  private final String SLAVE_DATASOURCE = "slaveDataSource";
  private final String ROUTING_DATASOURCE = "routingDataSource";
  private final String LAZY_ROUTING_DATASOURCE = "lazyRoutingDataSource";
  private final HibernateProperties hibernateProperties;
  private final JpaProperties jpaProperties;

  public DataSourceConfig(JpaProperties jpaProperties) {
    this.jpaProperties = jpaProperties;
    this.hibernateProperties = new HibernateProperties();
    hibernateProperties.setDdlAuto("create-drop");
  }

  /*
   * yml 파일에 정의한 Master DB 정보를 불러와 DataSource Bean 등록
   */
  @Bean(MASTER_DATASOURCE)
  @ConfigurationProperties(prefix = "spring.datasource.hikari.master")
  public DataSource masterDataSource() {
    return DataSourceBuilder.create()
        .build();
  }

  /*
   * yml 파일에 정의한 Slave DB 정보를 불러와 DataSource Bean 등록
   */
  @Bean(SLAVE_DATASOURCE)
  @ConfigurationProperties(prefix = "spring.datasource.hikari.slave")
  public DataSource slaveDataSource() {
    return DataSourceBuilder.create()
        .build();
  }

  @DependsOn({MASTER_DATASOURCE, SLAVE_DATASOURCE})
  @Bean(ROUTING_DATASOURCE)
  public AbstractRoutingDataSource routingDataSource(
      @Qualifier(MASTER_DATASOURCE) DataSource masterDataSource,
      @Qualifier(SLAVE_DATASOURCE) DataSource slaveDataSource
  ) {
    AbstractRoutingDataSource routingDataSource = new AbstractRoutingDataSource() {
      @Override
      protected Object determineCurrentLookupKey() {
        return RouteDataSourceManager.getCurrentDataSourceName();
      }
    };
    Map<Object, Object> targetDataSources = new HashMap<>();
    targetDataSources.put(RouteDataSource.DataSourceType.MASTER, masterDataSource);
    targetDataSources.put(RouteDataSource.DataSourceType.SLAVE, slaveDataSource);

    routingDataSource.setTargetDataSources(targetDataSources);
    routingDataSource.setDefaultTargetDataSource(masterDataSource);

    return routingDataSource;
  }

  @DependsOn(ROUTING_DATASOURCE)
  @Bean(LAZY_ROUTING_DATASOURCE)
  public LazyConnectionDataSourceProxy lazyRoutingDataSource(
      @Qualifier(ROUTING_DATASOURCE) DataSource routingDataSource) {
    return new LazyConnectionDataSourceProxy(routingDataSource);
  }

  @Bean
  public EntityManagerFactoryBuilder entityManagerFactoryBuilder() {
    return new EntityManagerFactoryBuilder(new HibernateJpaVendorAdapter(), new HashMap<>(), null);
  }

  @DependsOn(LAZY_ROUTING_DATASOURCE)
  @Bean
  public LocalContainerEntityManagerFactoryBean entityManagerFactory(
      EntityManagerFactoryBuilder builder,
      @Qualifier(LAZY_ROUTING_DATASOURCE) DataSource lazyRoutingDataSource) {
    var props = hibernateProperties.determineHibernateProperties(jpaProperties.getProperties(),
        new HibernateSettings());
    return builder
        .dataSource(lazyRoutingDataSource)
        .packages("com.anchor.domain.**.domain")
        .properties(props)
        .persistenceUnit("common")
        .build();
  }

  @DependsOn(LAZY_ROUTING_DATASOURCE)
  @Bean
  public JdbcTemplate jdbcTemplate(@Qualifier(LAZY_ROUTING_DATASOURCE) DataSource dataSource) {
    return new JdbcTemplate(dataSource);
  }

  @Bean
  public PlatformTransactionManager transactionManager(
      EntityManagerFactory entityManagerFactory) {
    return new JpaTransactionManager(entityManagerFactory);
  }

  @Bean
  public JPAQueryFactory JPAQueryFactory(EntityManager entityManager) {
    return new JPAQueryFactory(entityManager);
  }

}

 

작성해야 하는 클래스들이 더 있는데, 핵심적인 클래스에 대한 설명과 함께 아래에 코드를 추가하겠다.

 

관련 클래스 분석

1. DataSourceConfig

Spring Data JPA의 Auto Configuration을 사용하지 않고 별도의 설정을 하기 위한 설정 클래스이다.

 

2. AbstractRoutingDataSource

DataSource에 대한 Routing 정책을 결정하는 역할을 하는 추상 클래스이다. 가장 먼저 determineCurrentLookupKey()를 정의해야 하는데 Lookup Key는 DataSource를 결정하는 식별자 역할을 한다. 즉, determineCurrentLookupKey()를 어떻게 정의하느냐에 따라 사용할 DB를 선택하는 방법이 달라진다.

이후 setTaretDataSources()를 통해 LookupKey와 DataSoucre Bean을 등록해주면 initialize()를 통해 resolvedDataSources로 복사된다. 

JDBC Connection을 필요로 할 때 determineTargetLookupKey()의 결과에 따라 DataSource가 반환된다.

 

3. RouteDataSourceManager + 

`RouteDataSourceManager`

package com.anchor.global.db;

import static com.anchor.global.db.RouteDataSource.DataSourceType.MASTER;
import static com.anchor.global.db.RouteDataSource.DataSourceType.SLAVE;

import org.springframework.transaction.support.TransactionSynchronizationManager;

public class RouteDataSourceManager {

  private static final ThreadLocal<RouteDataSource.DataSourceType> currentDataSourceName = new ThreadLocal<>();

  public static RouteDataSource.DataSourceType getCurrentDataSourceName() {
    if (currentDataSourceName.get() == null) {
      return TransactionSynchronizationManager.isCurrentTransactionReadOnly() ? SLAVE : MASTER;
    }
    return currentDataSourceName.get();
  }

  public static void setCurrentDataSourceName(RouteDataSource.DataSourceType dataSourceType) {
    currentDataSourceName.set(dataSourceType);
  }

  public static void removeCurrentDataSourceName() {
    currentDataSourceName.remove();
  }

}

Routing 정책을 실제로 정의한 커스텀 클래스이다. DB 타입을 세팅하고 지울 수 있는 메서드를 포함하고 있으며, ThreadLocal을 통해 해당 값을 저장할 수 있다. ThreadLocal은 스레드에게 독립적으로 값을 관리할 수 있는 기능을 제공하는 클래스이다. 요청 스레드별로 호출된 메서드의 DataSource 타입이 다르기 때문에 ThreadLocal을 통해 DataSourceType을 독립적으로 관리할 수 있다. 

 

`RouteDataSource`

package com.anchor.global.db;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface RouteDataSource {

  DataSourceType dataSourceType();

  enum DataSourceType {
    MASTER, SLAVE
  }

}

다음으로 서비스 메서드의 DB를 구분하기 위해 커스텀 어노테이션과 DB 타입을 정의해줬다.

 

`RouteDataSourceAspect`

package com.anchor.global.db;

import static com.anchor.global.db.RouteDataSource.DataSourceType.MASTER;
import static com.anchor.global.db.RouteDataSource.DataSourceType.SLAVE;

import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class RouteDataSourceAspect {

  @Before("@annotation(com.anchor.global.db.RouteDataSource) && @annotation(target)")
  public void setDataSource(RouteDataSource target) throws Exception {
    if (target.dataSourceType() == MASTER
        || target.dataSourceType() == SLAVE) {
      RouteDataSourceManager.setCurrentDataSourceName(target.dataSourceType());
    } else {
      throw new Exception("Wrong DataSource Type : Should Check Exception");
    }
  }

  @After("@annotation(com.anchor.global.db.RouteDataSource)")
  public void clearDataSource() {
    RouteDataSourceManager.removeCurrentDataSourceName();
  }

}

그리고 동적으로 서비스 메서드 위에 붙은 DB 타입을 포함하는 어노테이션을 획득하고, 이를 RouteDataSourceManager에 등록할 수 있도록 Spring AOP를 활용한 클래스를 정의했다.

 

4. LazyConnectionDataSourceProxy

LazyConnectionDataSourceProxy는 이름 그대로 DataSource에 대한 Connection을 나중에 가져오도록 하는 프록시 클래스이다. Connection 획득을 미뤄야 되는 이유는 LazyConnectionDataSourceProxy없이 메서드를 호출함으로써 확인할 수 있다.

 

적용 전

아래는 디버깅을 통해 CallStack에 호출된 메서드 순서이다.

1. Transaction을 시작하고 `DatasourceConnectionProviderImpl.getConnection()`을 호출한다.
2. Spring CGLIB에 의해 생성된 DataSourceConfig 프록시 객체를 통해 Connection 획득을 시도한다.
3. 이후 `AbstractRoutingSource.determineTargetDataSource()`를 통해 DataSource를 가져온다.
4. 내부적으로 `AbstractRoutingSource.determineCurrentLookupKey()`와 RouteDataSourceManager 내에 있는  `TransactionSynchronizationManager.isCurrentTransactionReadOnly()`가 순서대로 호출된다.
5. `TransactionSynchronizationManager.setCurrentTransactionReadOnly()`이 호출되면서 Transaction의 ReadOnly 특성을 세팅한다.

 

이 상태라면 readOnly가 true이든 false이든 항상 `TransactionSynchronizationManager.isCurrentTransactionReadOnly()`의 결과는 false가 나올 것이다. 의도한대로 동작하려면 `TransactionSynchronizationManager.setCurrentTransactionReadOnly()`가 `AbstractRoutingSource.determineDataSource()`보다 먼저 호출돼야 한다.

 

이러한 이유로 AbstractRoutingDataSource를 LazyConnectionDataSourceProxy로 감싸주게 되면 Connection Proxy를 우선 가져오고, Connection을 직접 사용할 때가 되서야 DataSource로부터 Connection을 가져온다. 결과적으로 DataSourceConfig 프록시 객체를 통해 Connection 획득을 뒤로 미뤄 Transaction의 ReadOnly 특성을 먼저 세팅해줄 수 있다.

 

적용 후

다음과 같이 순서가 변경된 것을 확인할 수 있다.

1. Transaction을 시작하고 `DatasourceConnectionProviderImpl.getConnection()`을 호출한다.
2.`TransactionSynchronizationManager.setCurrentTransactionReadOnly()`이 호출되면서 Transaction의 ReadOnly 특성을 세팅한다.
3. Spring CGLIB에 의해 생성된 DataSourceConfig 프록시 객체를 통해 Connection 획득을 시도한다.
4. 이후 `AbstractRoutingSource.determineTargetDataSource()`를 통해 DataSource를 가져온다.
5. 내부적으로 `AbstractRoutingSource.determineCurrentLookupKey()`와 RouteDataSourceManager 내에 있는  `TransactionSynchronizationManager.isCurrentTransactionReadOnly()`가 순서대로 호출된다.

---

발생한 이슈

이슈1. p6spy 호환성 문제

원인 분석

우리는 개발과정에서 p6spy-spring-boot-starter를 이용해 쿼리 로그를 Console에 출력하는 방식으로 쿼리를 확인했다. 그리고 DB 이중화 설정을 적용하고 난 뒤 동일한 쿼리 로그가 3번 찍히는 문제가 발생했다.

 

디버깅 결과, `P6DataSource.getConnection()` 메서드가 3번 호출되면서 3개의 서로 다른 3개의 DataSource를 가져오는 것을 확인할 수 있었다.

 

원인을 파악하기 위해서는  P6Spy의 동작과정을 이해할 필요가 있다. P6Spy는 구조적으로 JDBC 드라이버 앞에 P6Spy 드라이버를 위치시켜 발생하는 쿼리를 감지하고 로그를 남긴다.

 

좀 더 상세한 동작과정을 살펴보기 위해 P6DataSource 클래스의 생성자에 Break Point를 찍고 디버깅을 돌려보았다.

먼저 등록된 Bean을 초기화하고 `DataSourceDecoratorBeanPostProcessor.class`에 의해 PostProcessing을 진행한다.

호출된 `postProcess...` 메서드를 보면 `P6SpyDataSourceDecorator.decorate()` 메서드에 의해 등록된 Bean이 P6DataSource로 반환된다. 아래 사진과 같이 모든 DataSource Bean들이 위 과정을 거치기 때문에 총 4개의 P6DataSource가 생성된다. 문제 상황은 이러한 이유로 발생한다.

조금만 더 추가하자면, DataSource Bean들은 생성된 P6DataSource 내에 realDataSource로 등록된다. 그리고 P6Proxy 구현체(ConnectionWrapper, StatementWrapper, ...)등에 의해 wrapping됨으로써 쿼리를 감지할 수 있게 되는 것이다.

 

해결 방법

특정 DataSource에 대해서만 Decorater가 적용되도록 CustomBeanPostProcessor를 구현하는 등의 여러 시도를 해봤지만 실패했다. p6spy-spring-boot-starter 의존성을 추가하면 `DataSourceDecoratorBeanPostProcessor`클래스를 AutoConfiguration으로 등록하기 때문에 딱히 방법이 없는듯 했다.

 

뿐만 아니라 중복 로그가 출력되는 문제 외에도 LazyConnectionDataSourceProxy가 의도대로 적용되지 않는 문제도 있었기 때문에 이를 해결하지 못한다면 사용을 하지 않는 것이 옳다고 판단했다. 

 

자동 구성을 사용하지 않는 p6spy 의존성을 추가해서 할 수 있을것 같지만, 꼭 p6spy가 아니더라도 Hibernate를 통해서 별도의 로깅 처리를 할 수 있기 때문에 일단은 p6spy 의존성을 제거하는 방향으로 결정했다.

 

이슈2. ddl-auto 미동작

Master - Slave 방식으로 Bean을 등록하면 `spring.jpa.hibernate.ddl-auto`를 적용해도 스키마가 생성되지 않는다. 그 이유는 `spring.jpa.hibernate` 속성은 JpaBaseConfiguration을 상속한 HibernateJpaConfiguration 클래스에 의해 적용되는데, LocalContainerEntityManagerFactoryBean을 직접 등록해서 해당 Bean에 대한 auto configuration이 동작하지 않는다.

 

따라서 LocalContainerEntityManagerFactoryBean을 생성할 때 HibernateProperties 클래스의 determineHibernateProperties() 메서드로 properties를 구성해서 주입해야 한다. 이미 위의 코드에 작성돼있기 때문에 코드를 추가하진 않겠다.

 

마무리

p6spy를 지움으로 인해 테스트는 Master DB에는 없고, Slave DB에만 있는 데이터를 조회하는 방식으로 진행했다. 앞서 의도한 규칙대로 잘 동작하는 것을 확인할 수 있었다. 생각했던 것보다 많은 내용들이 뒤섞여 있어서 시간이 꽤 걸렸는데 좋은 경험이 되었던 것 같다.