훈훈훈

Amazon AWS :: Aurora MySQL JDBC driver 정리

훈훈훈 — Thu, 18 Aug 2022 00:45:03 +0900

Introduction

이번 글은 AWS Aurora MySQL 를 사용할 때 어떤 MySQL JDBC driver 라이브러리 사용할지 고민하면서 찾아보게 된 내용을 정리해보기로 하였다.

간단하게 요약하자면 MariaDB connector / J 와 AWS MySQL JDBC 사이에 고민을 했고, 두 라이브러리를 비교해보게 되었다.

MariaDB connector / J

MariaDB Connector / J 공식문서를 보면 아래와 같이 auroa 옵션을 부여할 경우 replication 과 failover 기능을 사용할 수 있는 것을 알 수 있다. 해당 기능의 장점은 별 다른 구현 없이 failover 와 replication 를 쉽게 이용할 수 있다는 점이다.

하지만, MariaDB JDBC drvier 버전 3 부터는 더 이상 해당 기능을 지원하지 않는 것으로 명시되어 있다.

MariaDB JDBC drvier 2 버전대를 사용하여 애플리케이션을 운영할 수 있겠지만, 시간이 지남에 따라 결국에는 라이브러리를 교체하게 될 것이다.

처음에는 기존에 사용하였던 MariaDB connector / J 를 사용하려고 하였지만, 위와 같은 문제로 대안을 찾기 위해 AWS 공식 문서를 확인해보기로 했다.

참고로 MariaDB JDBC drvier 에서 지원하는 replication 기능은 애플리케이션에서 코드로 직접 구현할 수 있다. (참고 글)

하지만, slave 를 여러대 사용하는 경우 아래처럼 yml 파일에 매번 추가하고 Bean 으로 수동 등록해야하는 번거로움이 있다.

spring:
  datasource:
    master:
      hikari:
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://127.0.0.1:3306/master?serverTimezone=UTC
        username: root
        password: 1234

    slave1:
      hikari:
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://127.0.0.1:3306/slave1?serverTimezone=UTC
        username: root
        password: 1234
    
    slave2:
      hikari:
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://127.0.0.1:3306/slave2?serverTimezone=UTC
        username: root
        password: 1234
        
    slave3:
      hikari:
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://127.0.0.1:3306/slave3?serverTimezone=UTC
        username: root
        password: 1234

현재는 MariaDB JDBC drvier 를 사용하여 replication 과 failover 기능을 사용하고 있다.

spring:
  datasource:
    hikari:
      jdbc-url: jdbc:mariadb:aurora://___.rds.amazonaws.com:3306/db_name
      driver-class-name: org.mariadb.jdbc.Driver
      username:
      password:

MariaDB Connector / J vs AWS MySQL JDBC

MariaDB connector / J 버전 이슈에 대한 방안을 찾기 위해 관련 AWS 공식 문서를 찾아보았고, 해당 공식 문서에서 찾아 볼 수 있었다. 해당 문서에는 Amazon AWS 에서 개발한 AWS JDBC driver for MySQL 를 사용하는 것을 권장하는 것을 알 수 있다.

아래 문서에서도 관련 내용을 이야기 하고 있다.

AWS MySQL JDBC driver 를 사용하면 좀 더 향상된 failover 속도를 제공한다고 한다.

성능 관련해서는 아래 문서에서 확인할 수 있었다.

장애가 발생했을 때, MariaDB Connector / J 보다 더 빠르게 대응하는 것을 볼 수 있다.

이제까지 AWS 공식 문서에서 AWS JDBC driver for MySQL 에 관하여 소개하는 글들을 살펴보았다.

하지만 뭔가 놓친 기분이 들었다. failover 에 관한 내용은 성능 테스트 자료까지 자세하게 설명이 되어 있었지만, replication 에 관한 내용은 볼 수 없었다.

그래서 해당 프로젝트 github 을 보기로 하였다.

프로젝트 README 를 보면 Read-Write spliting (replication) 기능은 현재 지원하고 있지 않는 것을 알 수 있다.

현재 MariaDB Connector / J 에서 read only 트랜잭션인 경우 reader DB 로 라우팅 해주는 기능은 없는 것 같다.

사실 저 기능을 지원하지 않는다면 AWS JDBC driver for MySQL 를 사용할 이유는 없다고 생각한다.

아쉽지만, 혹시나 해당 기능은 언제 지원이 되는지 궁금하여 PR 들을 찾아보았다.

최근에 관련 몇몇 PR 들이 반영 된 것으로 보인다.

해당 PR 을 보면 1.2.0 버전에는 Read-write splitiing 기능이 배포될 것 같다.

현재 1.1.0 버전까지 릴리즈 되었으니, 빠르면 올해 안에 해당 기능을 사용할 수 있지 않을까 싶다.

이번에 작성한 글을 짧게 요약하자면, 아직은 MariaDB connector / J 2 버전대를 사용하고

추후 AWS JDBC driver for MySQL 1.2.0 버전이 나오고 별 다른 이슈가 없을 때, 라이브러리를 교체해도 좋을 것 같다.

# reference

https://github.com/awslabs/aws-mysql-jdbc

GitHub - awslabs/aws-mysql-jdbc: The Amazon Web Services (AWS) JDBC Driver for MySQL is a driver that enables applications to ta

The Amazon Web Services (AWS) JDBC Driver for MySQL is a driver that enables applications to take full advantage of the features of clustered MySQL databases. - GitHub - awslabs/aws-mysql-jdbc: Th...

github.com

https://github.com/mariadb-corporation/mariadb-connector-j

GitHub - mariadb-corporation/mariadb-connector-j: MariaDB Connector/J is used to connect applications developed in Java to Maria

MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. MariaDB Connector/J is LGPL licensed. - GitHub - mariadb-corporation/mariadb-connector-j: Maria...

github.com

https://johngrib.github.io/wiki/mariadb-connector-j/#failover-and-load-balancing-parameters

MariaDB Connector/J

johngrib.github.io

https://aws.amazon.com/ko/blogs/database/improve-application-availability-with-the-aws-jdbc-driver-for-amazon-aurora-mysql/

Improve application availability with the AWS JDBC Driver for Amazon Aurora MySQL | Amazon Web Services

In this post, we demonstrate how to use the Amazon Web Services (AWS) JDBC Driver for MySQL, which allows an application to take advantage of the features of clustered MySQL databases. You can use this driver as a drop-in replacement for the MySQL Connecto

aws.amazon.com

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Connecting.html

Amazon Aurora DB 클러스터에 연결 - Amazon Aurora

SSL을 사용하여 클러스터 엔드포인트에 연결하려면 클라이언트 연결 유틸리티에서 Subject Alternative Names(SAN)를 지원해야 합니다. 클라이언트 연결 유틸리티에서 SAN을 지원하지 않는 경우, Aurora DB

docs.aws.amazon.com

https://hoing.io/archives/1285

AWS JDBC Driver for Amazon Aurora MySQL

안녕하세요 이번 포스팅에서는 Amazon AWS 에서 새롭게 출시한 Java의 MySQL 접속 드라이버인 AWS JDBC Driver 에 대해서 확인 해보려고 합니다. 드라이버의 특징AWS JDBC Driver 는 MySQL 8.0.28 community driver 를

hoing.io

Spring boot :: Transaction default isolation level 은 어떻게 결정이 될까

훈훈훈 — Sun, 13 Mar 2022 17:18:43 +0900

Introduction

블로그 포스팅 스터디에서 스터디원과 Spring default isolation level 이 어떻게 결정 되는지 토론을 하게 되었다.

토론 도중에 스터디원분이 관련 StackOverFlow 글을 찾고 공유해주셨는데, 글 내용은 MySQL connectror/J 는 default isolation level 로 READ_COMMITTED 를 제공한다는 것이다.

실제로 코드 레벨에서 살펴보니 진짜 READ_COMMITTED 로 제공이 되고 있었다.

내가 알던 내용은 MySQL 은 storage engine 으로 innoDB 를 사용하는 경우 default isolation level 로 REPEATABLE_READ 를 제공한다는 것이다.

그렇기 때문에 MySQL connector/J 도 당연히 REPEATABLE_READ 로 제공이 될 줄 알았는데 결과는 꽤나 놀라웠다.

그와 반대로 MariaDB connector 는 REPEATABLE_READ 로 제공한다.

테스트로 스프링 애플리케이션에서 jdbc url 을 MySQL 로 연결하였을 때 isolcation level 값을 확인해보았다.

그 결과 REPEATABLE_READ 가 나왔다.

왜 이런 결과가 나오는지 궁금하여 스프링 코드를 따라가 보면서 어떻게 default isolation level 을 결정하는지 찾아보게 되었고, 그 과정을 정리해보려고 한다.

결론부터 먼저 말하자면 스프링에서 MySQL 을 사용하는 경우 REPEATABLE_READ 로 제공이 된다.

(실제로는 RDBMS 와 커넥션을 맺고 정보를 가져옴)

이번 계기로 어설프게 대충 판단을 하면 안되는 것을 다시 한 번 느꼈다.

@Transactional test

일단 스프링에서 어떻게 동작하는지 아래 코드로 테스트 해보았다.

(해당 코드는 예전에 예제로 만든 프로젝트이며, 전체 코드는 Github 에서 확인할 수 있다.)

@Service
@RequiredArgsConstructor
public class AccountService {
  private final AccountRepository accountRepository;
  private final PasswordEncoder passwordEncoder;
  private final DataSource dataSource;

  @Transactional
  public AccountDto createAccount(@Valid final SignUpDto accountDto) throws SQLException {
    final Account existAccount = accountRepository.findAccountByEmail(accountDto.getEmail()).orElse(null);
    if (existAccount != null) {
      throw new IllegalArgumentException("duplicated");
    }

    final Account account = Account.builder()
        .name(accountDto.getName())
        .email(accountDto.getEmail())
        .password(passwordEncoder.encode(accountDto.getPassword()))
        .build();

    System.out.println("------------------------------------");
    System.out.println(dataSource.getConnection().getTransactionIsolation());
    System.out.println("------------------------------------");
    
    return AccountDto.of(accountRepository.save(account));
  }
}

간단하게 @Transactional 이 선언 된 메소드에서 transaction isolataion level 을 조회해보았다.

isolation level = 4로 나오고 해당 번호는 REPEATABLE_READ 를 뜻한다.

해당 값이 의미하는 바는 Connection interface 에서 확인할 수 있다.

Code Analysis

이제 스프링 코드를 디버깅하면서 어떻게 동작하는지 살펴보자.

Spring 애플리케이션을 실행시키면 NonRegisteringDriver 클래스의 connect 메소드는 jdbc url 을 파라미터로 전달 받은 후에 Connection 객체를 생성 후에 리턴을 하게 된다.

생성이 되는 Connection 객체는 com.mysql.cj.jdbc.ConnectionImpl 클래스이며 해당 객체가 생성이 되면서 isolation level 도 결정한다.

이제 ConnectionImpl 객체가 생성 되는 과정을 살펴보자

ConnectionImpl 클래스의 getInstance 메소드는 정말 단순하다.

해당 클래스의 생성자를 호출해서 리턴하는 역할만 한다.

그 다음으로 ConnectionImpl 클래스 생성자에는 여러 로직들이 들어있어 다소 코드 라인이 좀 길다.

그래서 전체 코드는 첨부하지 않고 부분 부분 캡쳐해서 넣었다.

먼저 살펴볼 내용은 위에 서론에서 언급한 내용이다.

해당 라인에서 MySQL Connector/J 에서 정의한 메타 데이터를 가져오게 되는데, 여기에서는 코드에서 정의한 default isolation level 로 초기화가 된다.

해당 라인을 실행시켰을 때 디버깅한 값을 확인해보면 isolation level = 2(READ_COMMITTED) 로 세팅된 것을 볼 수 있다.

그 다음에는 몇 라인 아래에 있는 createNewIO 메서드를 확인해보자

해당 메서드 호출 후에 isolation level = 4 (REPEATABLE_READ) 로 세팅이 된다.

createNewIO 메소드르 이후 아래 흐름으로 메소드 Call 이 발생한다.

마지막으로 checkTransactionIsolationLevel 메소드에서 MySQL 서버와 커넥션을 맺고 isolataion level 을 가져오게 된다.

이후 처리하는 과정을 더 있는 것 같지만, 목적은 이미 달성했기에 이정도에서 마무리하려고 한다.

Spring Data :: Spring Data Elasticsearch refresh policy 정리

훈훈훈 — Mon, 31 Jan 2022 00:09:35 +0900

이슈

얼마전에 검색 API 를 호출하면 데이터가 종종 빈 값이 반환되는 이슈가 있었다.

이슈가 발생하는 시점은 Indexer 어플리케이션에서 Elasticsearch 인덱스에 Bulk Insert 할 때 였다. 해당 시점에 데이터를 조회 하였을 때, 데이터가 비어있는 현상을 발견하였다.

이슈가 발생한 원인은 Elasticsearch 는 refresh interval 기능이 존재하기 때문이다.

Elasticsearch 공식문서를 확인해보면 아래와 같이 설명을 하고 있다.

해당 기능은 디폴트로 1s 마다 refresh interval 를 수행하게 되는데, 우리가 Elasticsearch 에서 조회하는 내용은 1s 이전 데이터를 의미한다. 엄밀하게는 지난 30s 동안 한 번 이상의 검색 요청을 받은 인덱스에 대해서만 refresh 가 진행이 된다.

추가로 refresh 가 어떤식으로 진행이 되는지 좀 더 자세히 살펴보자.

해당 내용은 QBOX 의 글을 참고하였다.

데이터가 색인이 되면 샤드 내에 있는 Translog (트랜잭션 로그) 와 인메모리 버퍼에 저장이 된다.

그리고 1s 마다 (디폴트) 주기적으로 인덱스를 refresh 를 할 때, 인메모리 버퍼에 있는 데이터를 새로 생성된 세그먼트에 복사를 하며 그 이후 refresh 한 데이터를 검색할 수 있게 된다고 한다.

Elasticsearch 에서는 refresh 를 컨트롤하기 위해 몇가지 옵션을 제공해주는데 기능적으로 분류를 해보면 아래와 같다.

(1) 디폴트 옵션 (false)
(2) 즉시 새로고침 (true)
(3) 새로고침 될 때까지 기다림 (wait_for)

실시간을 어느정도 보장받기 원한다면, (2) 번 혹은 (3) 번을 선택하는 방법이 있다.

즉시 true(새로고침을 하는 옵션) 은 매 요청마다 즉시 즉시 새로고침을 하기때문에 가장 높은 실시간을 보여줄 수 있겠지만, 매번 refresh 를 즉시 진행해버리기 때문에 높은 리소스를 많이 사용하게 된다.

반면에 wait_for 옵션은 새로고침이 될 때까지 기다리고 응답을 보내주는 정책이다.

이 정책도 높은 실시간을 보여주지만, 즉시 새로고침에 비하면 대기 시간이 길다. 그래도 즉시 refresh 하는 것 보다는 낮은 리소스를 소비한다.

각각 옵션의 장단점이 있지만, 색인 속도를 포기하고 리소스를 적게 소모하는 wait_for 이 많이 사용되는 것 같다.

각 옵션을 비교해보고 사내에서 Bulk 작업을 수행할 때, wait_for 옵션을 지정하는 것으로 정책을 잡았다.

해결 방법

해당 이슈를 해결하기 위해 데이터를 색인할 때 RefreshPolicy 를 wait_for 옵션으로 사용하기로 하였다.

스프링에서는 RefreshPolicy 이름을 약간 다르게 정의한다.

아래 Spring data elasticsearch 에서 제공하는 RefreshPolicy Enum 을 살펴보자.

이름만 보고 추론을 해보면 대충 알 것 같지만, 정확하지는 않기에 좀 더 찾아보니 org.elasticsearch.action.support 패키지에 있는 WriteRequest 인터페이스 내부에 RefreshPolicy EnumType 이 아래와 같이 동일하게 정의 되어 있다.

코드와 주석을 보면 Spring data elasticsearch 에서 정의한 RefreshPolicy Enum 과 이름이 동일한 것을 알 수 있고, 각각 옵션에 대한 설명이 적혀있다.

여기서 왜 동일한 Enum 을 새로 만들어서 사용하는지 의문이 들었다.

유추해보면 Spring data elasticsearch 에서 org.elasticsearch.action.support 패키지에 있는 Enum 을 사용하려고 했지만, WriteRequest 인터페이스 내부에 있는 Enum 이기 때문에 RefreshPolicy Enum 을 가져다가 사용한다면 WriteRequest 인터페이스에 강하게 결합이 되어 ?? 새로 생성을 해서 사용하는 것인가 싶다. 같은 예시로 OpType Enum이 있다.

다시 돌아와서 코드와 주석을 읽어 보면 각각의 타입에 대한 설명은 주석에 잘 명시되어 있다.

이 글에서는 문제가 된 이슈를 해결하기 위해 wait_for 사용하려고 하기 때문에 RefreshPolicy 를 WAIT_UNTIL 으로 세팅하려고 한다.

공식 문서를 참고하여 코드로 작성하면 아래와 같이 할 수 있다.

@Configuration
@EnableElasticsearchRepositories(basePackages = "com.hooon.dataes.repository")
@ComponentScan(basePackages = { "com.hooon.dataes.service" })
public class ElasticSearchConfig {

  @Bean
  public RestHighLevelClient client() {
    ClientConfiguration clientConfiguration = ClientConfiguration.builder()
        .connectedTo("localhost:9200")
        .build();

    return RestClients.create(clientConfiguration).rest();
  }

  @Bean
  public ElasticsearchOperations elasticsearchTemplate() {
    ElasticsearchRestTemplate elasticsearchRestTemplate = new ElasticsearchRestTemplate(client());
    elasticsearchRestTemplate.setRefreshPolicy(RefreshPolicy.WAIT_UNTIL); // RefreshPolicy 설정

    return elasticsearchRestTemplate;
  }

}

Spring bean 으로 ElasticsearchOperations 을 등록할 때 refreshPolicy 를 설정할 수 있다.

스프링 공식문서를 읽어보면 refresh policy 값은 반드시 설정하라고 말하고 있다.

(앞으로는 공식 문서를 좀 더 꼼꼼히 읽어봐야겠다..)

# reference

https://qbox.io/blog/refresh-flush-operations-elasticsearch-guide/

Guide to Refresh and Flush Operations in Elasticsearch | Qbox HES

Not yet enjoying the benefits of a hosted ELK-stack enterprise search on Qbox? Discover how easy it is to manage and scale your Elasticsearch environment.

qbox.io

https://www.codetd.com/en/article/6497511

Elasticsearch data refresh policy brief RefreshPolicy - Code World

Disclaimer: This article is a blogger hanchao5272 original articles, please indicate the source and leave the original link address, thank you! https://blog.csdn.net/hanchao5272/article/details/89151166 Explanation By default, ElasticSearchthe index refres

www.codetd.com

https://www.elastic.co/guide/en/elasticsearch/reference/7.16/near-real-time.html#img-pre-refresh

Near real-time search | Elasticsearch Guide [7.16] | Elastic

The overview of documents and indices indicates that when a document is stored in Elasticsearch, it is indexed and fully searchable in near real-time--within 1 second. What defines near real-time search? Lucene, the Java libraries on which Elasticsearch is

www.elastic.co

https://www.elastic.co/guide/en/elasticsearch/reference/7.16/docs-refresh.html

?refresh | Elasticsearch Guide [7.16] | Elastic

The Index, Update, Delete, and Bulk APIs support setting refresh to control when changes made by this request are made visible to search. These are the allowed values: Empty string or true Refresh the relevant primary and replica shards (not the whole inde

www.elastic.co

https://wedul.site/542

Elasticsearch에서 refresh 정리

Elasticsearch에서 document를 업데이트하고 바로 해당 정보를 조회하려고 했다. 하지만 조회가 되지 않았다. 분명이 업데이트가 종료된 것을 확인 했는데 왜 그런지 의문이 들었다. 그래서 찾아봤는

wedul.site

https://docs.spring.io/spring-data/elasticsearch/docs/current/reference/html/#reference

Spring Data Elasticsearch - Reference Documentation

The Spring Data infrastructure provides hooks for modifying an entity before and after certain methods are invoked. Those so called EntityCallback instances provide a convenient way to check and potentially modify an entity in a callback fashioned style. A

docs.spring.io

Spring Data :: Spring Data Elasticsearch _class 필드 자동 생성 비활성화

훈훈훈 — Sat, 27 Nov 2021 13:36:52 +0900

이슈

Spring data elasticsearch 를 사용하여 색인을 하면 아래와 같이 _class 라는 필드가 자동 생성이 되는 것을 볼 수 있다.

해당 필드는 sava 메소드를 호출할 때 사용했던 도큐먼트 객체에 대한 정보를 담고 있지만, Elasticsearch 를 호출하는 클라이언트 입장에서는 불필요한 데이터이다. 따라서 굳이 저 필드를 생성할 필요는 없다고 생각한다.

_class 필드가 존재하는 목적이 궁금하여 스택오버플로우를 검색해보니, spring data elasticsearch 프로젝트를 리드하시는 분의 답변을 찾을 수 있었다.

100% 이해가 되는 문장은 아니지만 상속 관련 된 객체를 사용할 때 사용하는 필드라고 한다.

그렇다면 상속을 하지 않는 도큐먼트 객체들에 대해서는 해당 필드는 사용하지 않기 떄문에 제거해도 된다고 결론을 낼 수 있을 것 같다.

(정확하게 어떤 기능을 하는지는 이해가 되지는 않지만, Spring data elasticseach 에서 사용하는 메타데이터인 것 같다.)

해결 방법

해당 필드가 자동 생성되는 것을 막기 위해서 Spring data elasticseach Github 이슈를 확인해보니 spring data elasticsearch 4.3 버전부터 서포트 하는 것을 알 수 있다.

@Getter
@ToString
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Document(indexName = "user", createIndex = false, writeTypeHint = WriteTypeHint.FALSE)
public class UserDocument {

  @Id
  private String id;

  @Field(type = FieldType.Text)
  private String name;

  public void setName(String name) {
    this.name = name;
  }
}

@Document 어노테이션에 writeTypeHint 을 False 로 설정하면, 색인할 때 _class 필드 자동 생성을 비활성화하는 것을 볼 수 있다.

** 참고

https://github.com/spring-projects/spring-data-elasticsearch/issues/1883

How to remove the _class field when automatically creating index and how to specify what fields we want return in query? · Issu

There are two questions: A field named _class will be inserted automatically when spring-data-elasticsearch creates an index, even though it is not desired. I wonder how to avoid that. *Repository ...

github.com

https://stackoverflow.com/questions/66062703/is-there-any-way-to-force-spring-not-to-use-create-class-field-in-the-mapping

Is there any way to force spring not to use/create '_class' field in the mapping?

The thing is on production servers we got mapping for Elasticsearch with dynamic set to strict. Currently, we use a rest level client to communicate with Elastisearch, however, we would like to mig...

stackoverflow.com

https://stackoverflow.com/questions/65126545/reading-from-elastic-search-using-spring-boot-where-es-record-without-class-at

Reading from elastic search using Spring boot, where ES record without _class attribute

I am trying to read/search the existing records in Elastic Search via Spring Data + Elastic Search.The existing records in the elastic search does not have the _class attribute. { "_index&qu...

stackoverflow.com

Spring Data :: Spring Data Elasticsearch rollover index 정리

훈훈훈 — Fri, 26 Nov 2021 01:23:12 +0900

Introduction

이번에 HighLevelRestClient 를 사용하여 운영하던 Indexer 어플리케이션에 Spring Data Elasticsearch 를 적용 해보게 되었다.

새로운 라이브러리를 적용 후 Alias 를 사용한 Rollover Index 기능 구현은 프레임워크 버전에 따라 구현 방법이 조금씩 다른 것 같아 적절한 레퍼런스를 찾기가 좀 어려웠었다.

다행히 스택오버플로우를 보다가 Spring Data Elasticsearch 프로젝트 리드하시는 분의 블로그에 좋은 글을 찾아 쉽게 해결할 수 있었고, 관련해서 내용을 정리해보려고 한다.

에제 코드는 Github 에서 확인해볼 수 있다.

Rollover Index

위 그림을 보듯이 요청을 alias 이름으로 받고 데이터는 alias 와 mapping 되어 있는 index 를 통해 데이터를 요청하는 것을 볼 수 있다.

따라서 클라이언트는 ES 에 존재하는 여러 index 의 이름을 알 필요는 없고 alias 를 통해 데이터를 받아오며, 실질적으로 gateway 역할을 한다고 볼 수 있다.

batch 등을 통해 데이터를 가공하여 index 를 새로 생성한다면 시간 값 등을 index 이름 뒤에 붙여주는 방식으로 index 를 생성하면 된다.

그리고 Alias 를 매핑해주면 된다.

Spring Data Elasticsearch

Spring Data Elasitcsearch 는 4.0 버전으로 올라오면서 많은 부분들이 변한 것 같다.

눈에 띄는 것은 ElasticsearchOperations 인터페이스이다. 해당 인터페이스를 호출하여 Elasticsearch 에 요청을 간편하게 보낼 수 있다.

이전에는 직접 생성한 쿼리를 HighLevelRestClient 를 사용하여 요청 보냈지만, ElasticsearchOperations 은 이를 wrapping 하여 간편하게 사용할 수 있도록 도와준다.

그리고 ElasticsearchOperations 인터페이스에서 사용하는 IndexOperations 인터페이스를 사용하면 인덱스 생성, 삭제, Alias 설정 등 다양한 기능을 지원해준다. 아래 이미지는 해당 인터페이스의 일부분만 갭쳐하였고, 실제로 확인해보면 더 많은 메소드들을 볼 수 있다.

그리고 Spring Data Elasitcsearch 4.1 버전에서도 바뀐 부분이 있는데 일단 IndexTemplate 을 지원하기 시작했다.

그리고 이번에 사용할 Alias 도 변경된 부분이 있는데, 기존에 사용한 AliasQuery 은 Deprecated 되고 AliasAction 을 사용하도록 권장하고 있다. (왜 AliasQuery 가 Deprecated 가 되었는지는 좀 더 찾아봐야될 것 같다....)

그리고 여러 메서드들이 추가가되었는데, 이번 예제에서 사용할 메서드인 alias( ), 그리고 getAliasesForIndex( ) 가 추가되었다.

Code Example

이제 코드 예제를 살펴보자.

먼저 아래와 같이 의존성을 추가한다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-elasticsearch'
}

Spring boot 는 2.6.0 버전을 사용하였을 때, 자동적으로 Spring data elasticsearch 는 4.3 버전이 추가되었다.

혹여나 Spring boot 버전이 낮더라도 2.3 버전 이상이면 starter-data-elasticsearch 가 아닌 직접 의존성을 추가하면 spring data elasticsearch 4.3 까지 적용이 되었다.

의존성이 정상적으로 적용이 된 이후에 아래와 같이 RestHighLevelClient 와 ElasticsearchOperations 를 Bean 으로 등록한다.

해당 코드는 Bealdung 글을 참고하였다.

@Configuration
@EnableElasticsearchRepositories(basePackages = "com.hooon.dataes.repository")
@ComponentScan(basePackages = { "com.hooon.dataes.service" })
public class ElasticSearchConfig {

  @Bean
  public RestHighLevelClient client() {
    ClientConfiguration clientConfiguration = ClientConfiguration.builder()
        .connectedTo("localhost:9200")
        .build();

    return RestClients.create(clientConfiguration).rest();
  }

  @Bean
  public ElasticsearchOperations elasticsearchTemplate() {
    return new ElasticsearchRestTemplate(client());
  }

}

예제로 사용할 아래 User Entity 클래스는 간단하게 필드 두 개로 만들었다.

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(name = "users")
public class User {

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  @Column(name = "id", nullable = false)
  private Long id;

  @Column(name = "name", nullable = false, length = 10)
  private String name;

  @Builder
  public User(String name) {
    this.name = name;
  }
}

conertDocument 메서드는 아래에서 확인할 도큐먼트 클래스로 캐스팅하는 메소드이다.

실제로 필드만 매핑하는 거라면 modelMapper 로 대체하여도 무방하다.

이제 index 에 저장할 Doucument 객체를 만들자.

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Document(indexName = "user", createIndex = false)
public class UserDocument {

  @Id
  private String id;

  @Field(type = FieldType.Text)
  private String name;

}

@Document 어노테이션에는 생성할 인덱스 이름인 user 를 적었지만, 실제로는 index 이름이 아닌 alias 이름으로 사용할 것이다.

index 이름은 user-1637745625207, user-1637745625210 등 user 를 prefix 로 사용하려고 한다.

다시 정리하자면, user 라는 이름으로 index 를 생성하지 않을 것이며 그렇기 때문에 어플리케이션이 실행될 때 자동으로 인덱스를 생성하는 옵션인 createIndex 옵션은 false 로 설정한다.

아래 클래스는 인덱스 객체를 생성하는 유틸클래스이다.

public class IndexUtil {

  public static IndexCoordinates createIndexNameWithPostFixWrapper(String indexName) {
    return IndexCoordinates.of(indexName + "-" + Instant.now().toEpochMilli());
  }

  public static IndexCoordinates createIndexNameWrapper(String indexName) {
    return IndexCoordinates.of(indexName);
  }

}

인덱스 이름을 받으면 그대로 인덱스 객체를 생성하는 메서드와 뒤에 epochMilli 를 붙여주는 메서드 두 가지를 만들었다.

epochMilli 를 붙여주는 이유는 생성되는 인덱스마다 이름이 중복이 되지 않기 위함이다. 그래야 색인을 할 때마다 새로운 인덱스를 만들며 기존 인덱스랑 이름이 중복이 되지 않기 때문이다.

이제 공통으로 사용할 레포지토리를 만들어 보자.

@Repository
public interface BaseElasticSearchRepository<T> {

  <S extends T> S save(S entity, IndexCoordinates indexName);

  <S extends T> Iterable<S> saveAll(Iterable<S> entities, IndexCoordinates indexName);

  boolean setAlias(IndexCoordinates indexNameWrapper, IndexCoordinates aliasNameWrapper);

  Set<String> findIndexNamesByAlias(IndexCoordinates aliasNameWrapper);

  boolean deleteIndex(IndexCoordinates indexNameWrapper);

}

위 예제는 해당 블로그에 있는 예제를 참고하였다. 참고한 예제는 하나의 Document 에 대한 케이스로 설명하고 있지만, 어플리케이션에 존재하는 모든 Document 객체에서 공통적으로 사용할 수 있는 기능이기 때문에 BaseElasticSearchRepository 로 네이밍하였다.

위 처럼 레포지토리 인터페이스를 생성한 목적은 기존에 존재하는 CrudRepository 에 정의되어 있는 save 메서드를 호출하면 @Document 에 설정한 index 이름에 저장을 한다.

하지만 우리가 필요한 것은 index + XXX 에 저장하는 것이 목표이기 때문에 새로운 레포지토리 인터페이스를 만들어야 한다.

아래와 같이 구현하였지만, alias 세팅, alias 로 연결 된 인덱스 찾기, 인덱스 삭제 같은 기능들도 공통적으로 사용할 것 같아 추가적으로 더 정의하였다.

아래 코드는 위에 작성한 인터페이스의 구현체이다.

@Repository
@RequiredArgsConstructor
public class BaseElasticSearchRepositoryImpl<T> implements BaseElasticSearchRepository<T> {

  private final ElasticsearchOperations operations;

  @Override
  public <S extends T> S save(S entity, IndexCoordinates indexName) {
    return operations.save(entity, indexName);
  }

  @Override
  public <S extends T> Iterable<S> saveAll(Iterable<S> entities, IndexCoordinates indexName) {
    return operations.save(entities, indexName);
  }

  @Override
  public boolean setAlias(IndexCoordinates indexNameWrapper, IndexCoordinates aliasNameWrapper) {
    IndexOperations indexOperations = operations.indexOps(indexNameWrapper);
    AliasActions aliasActions = new AliasActions();
    aliasActions.add(new AliasAction.Add(AliasActionParameters.builder()
        .withIndices(indexOperations.getIndexCoordinates().getIndexNames())
        .withAliases(aliasNameWrapper.getIndexName())
        .build()));

    return indexOperations.alias(aliasActions);
  }

  @Override
  public Set<String> findIndexNamesByAlias(IndexCoordinates aliasNameWrapper) {
    IndexOperations indexOperations = operations.indexOps(aliasNameWrapper);
    return indexOperations.getAliasesForIndex(aliasNameWrapper.getIndexName()).keySet();
  }

  @Override
  public boolean deleteIndex(IndexCoordinates indexNameWrapper) {
    IndexOperations indexOperations = operations.indexOps(indexNameWrapper);
    return indexOperations.delete();
  }

}

Spring data elasticserach 4.0 버전에 추가 된 ElasticsearchOpertions 를 사용하여 로직을 구현하였다.

위에서도 언급하였지만, ElasticsearchOpertions 을 사용하면 HighLevelRestClient 로 직접 request 를 보내지 않고 간단하게 메서드만 호출하는 방법으로 Elasticsearch 에 요청을 보낼 수 있다.

색인만 할 때는 아래 인터페이스가 필요 없을 수도 있지만, 추후에 조회 기능도 함께 사용할 수 있도록 ElasticsearchRepository 그리고 위에서 생성한 인터페이스를 확장한 레포지토리 인터페이스를 만들었다.

@Repository
public interface UserDocumentRepository extends
    ElasticsearchRepository<UserDocument, String>,
    BaseElasticSearchRepository<UserDocument> {

  List<UserDocument> findUserDocumentByName(String name);
}

해당 인터페이스로 서비스 레이어에서 저 인터페이스 하나로 위에서 정의한 BaseElasticSearchRepository 에 있는 메서드들과 findBy ~~ 와 같은 Spring data 프로젝트에서 지원하는 메서드 둘 다 사용할 수 있게 되었다.

이제 색인하는 로직을 살펴보자.

@Service
@RequiredArgsConstructor
public class UserIndexingService {

  private final UserRepository userRepository;
  private final UserDocumentRepository userDocumentRepository;
  private final ModelMapper modelMapper;

  private static final String INDEX_PREFIX_NAME ="user";
  private static final String ALIAS_NAME = "user";

  @PostConstruct
  public void indexingUserDate() {
    IndexCoordinates indexNameWrapper = IndexUtil.createIndexNameWithPostFixWrapper(INDEX_PREFIX_NAME);
    IndexCoordinates aliasNameWrapper = IndexUtil.createIndexNameWrapper(ALIAS_NAME);

    Set<String> existIndexNames = userDocumentRepository.findIndexNamesByAlias(aliasNameWrapper);
    List<User> users = userRepository.findAll();

    List<UserDocument> userDocuments = users.stream()
        .map(user -> modelMapper.map(user, UserDocument.class))
        .collect(Collectors.toList());


    userDocumentRepository.saveAll(userDocuments, indexNameWrapper);

    existIndexNames.forEach(indexName -> userDocumentRepository.deleteIndex(IndexUtil.createIndexNameWrapper(indexName)));
    userDocumentRepository.setAlias(indexNameWrapper, aliasNameWrapper);

  }

}

색인하는 과정은 간단하게 아래와 같은 절차로 실행이 된다.

1. user alias 에 매핑된 index 이름 조회
2. DB 에 있는 user 전체 데이터 조회 후 색인
3. (1)번에서 조회한 index 삭제
4. (2) 번에서 생성한 index 에 alias 매핑

실행시키먄 아래와 같이 정상적으로 데이터가 색인이 된 것을 볼 수 있다.

** 참고

https://www.sothawo.com/2020/11/implement-a-rolling-index-strategy-with-spring-data-elasticsearch-4-1

Implement a rolling index strategy with Spring Data Elasticsearch 4.1 | sothawo

With the release of version 4.1 Spring Data Elasticsearch now supports the index templates of Elasticsearch. Index templates allow the user to define settings, mappings and aliases for indices that are automatically created by Elasticsearch when documents

www.sothawo.com

https://github.com/sothawo/blog-sde-rolling-index

GitHub - sothawo/blog-sde-rolling-index

Contribute to sothawo/blog-sde-rolling-index development by creating an account on GitHub.

github.com

https://stackoverflow.com/questions/65490480/aliasquery-is-deprecated-in-spring-data-elasticsearch-4-1

AliasQuery is deprecated in Spring Data Elasticsearch 4.1

How do I migrate from Spring Data Elasticsearch 4.0 IndexOperations.addAlias to Spring Data Elasticsearch 4.1 IndexOperations.alias? I have the following method: @Autowired ElasticsearchOperations

stackoverflow.com

https://www.elastic.co/guide/en/elasticsearch/reference/6.8/indices-rollover-index.html

Rollover Index | Elasticsearch Guide [6.8] | Elastic

The rollover index API rolls an alias over to a new index when the existing index is considered to be too large or too old. The API accepts a single alias name and a list of conditions. The alias must point to a write index for a Rollover request to be val

www.elastic.co

https://www.baeldung.com/spring-data-elasticsearch-tutorial

Spring Cloud :: Spring cloud sleuth 정리

훈훈훈 — Sat, 13 Nov 2021 23:41:03 +0900

Introduction

시스템 로그로 디버깅을 할 때 확인하려는 메서드가 비동기로 호출되거나 멀티 스레드로 동작 한다면 히스토리를 추적하기 무척 어려울 것이다. 이때 Spring cloud sleuth 를 사용한다면 좀 더 편리한 로깅 환경을 제공 받을 수 있다.

단순히 라이브러리 의존성을 추가하는 것만으로도 요청의 흐름을 추적하는데 큰 도움을 주기 때문에 이번에 도입하게 되어 공부했던 내용을 정리해보려고 한다.

Sleuth

먼저, Spring cloud sleuth 가 무엇인지 공식 문서를 통해 확인해보자.

간단하게 의역을 해보면, Sleuth 를 사용하면 요청과 메시지들을 추적할 수 있게 해준다고 적혀있다.
이를 통해 요청에 대한 히스토리를 연관 시킬 수 있다고 소개하고 있다.

이러한 기능은 Microservice architecture 에서 사용하였을 때 정말 유용하다고 할 수 있다.

위 그림을 보면, 각각의 서버는 요청을 보낼 때 추적 정보를 보내는 것을 볼 수 있다.

각 정보는 Protocol 의 Header 를 통해 전달하며, 정보를 수신한 서버는 다음 서버에게 동일한 정보를 제공하는 방식으로 요청 흐름을 추적할 수 있다.

이제 Sleuth 가 우리에게 어떻게 도움을 주는지 살펴보자. 아래는 공식 문서에 있는 요청 흐름에 관한 이미지이다.

최초 Request 가 발생한 시점부터 마지막 Reponse 가 발생할 때까지 모두 동일한 trace id 가 할당된 것을 볼 수 있다.

그리고 매번 새로운 작업이 발생할 때마다 span id 는 계속 바뀌는 것을 볼 수 있다.

정리하자면, 아래와 같이 정의할 수 있다.

(1) Trace Id 
전체 작업에 할당된 ID 이다.
작업은 각각의 작은 단위들로 구성되어 있다고 한다면, 각각의 작은 단위들은 공통의 Trace ID 를 갖고 있다.

(2) Span Id
각각의 작은 단위들이 가지고 있는 ID 이다.
모두 서로 다른 ID 를 가지고 있기 때문에 서로 다른 작업 단위들을 구분해주는 역할을 할 수 있다.

Example

이제 예제 코드를 통해 한 번 살펴보자. 예제 코드는 Baeldung 에 소개 된 코드를 가져왔다.

Case 1. 싱글 스레드

- 예제 코드

@Slf4j
@RestController
public class HelloController {
  
  @GetMapping("/hello")
  public String helloSleuth() {
    log.info("Hello sleuth");
    log.info("Bye sleuth");
    
    return "ok";
  }

}

- 실행 결과

어플리케이션을 실행시키고 GET /hello 를 호출했을 때 위의 결과 처럼 로깅이 되는 것을 볼 수 있다.

출력 된 로그는 순서대로 어플리케이션 이름, Trace ID, Span ID 이다.

위 예제에서는 Trace ID 와 Span ID 가 동일한 것을 볼 수 있다.

Case 2. 두개 이상의 스레드

- 예제 코드

@Slf4j 
@RequiredArgsConstructor
@RestController
public class TestController {

  private final Executor executor;

  @GetMapping("/new-thread")
  public String newThread() {
    log.info("create newThread");

    Runnable runnable = () -> {
      log.info("I'm inside the new thread");
    };
    executor.execute(runnable);

    log.info("I'm done");

    return "ok";
  }
}

- 실행 결과

어플리케이션을 실행시키고 GET /new-thread 를 호출했을 때 위의 결과 처럼 로깅이 되는 것을 볼 수 있다.
살펴보아야할 점은 서로 다른 thread 에서 실행되고 있지만, Trace ID 는 동일하다는 것을 볼 수 있다.

따라서 MSA 환경이 아닌 모놀리스 방식의 싱글 어플리케이션이라도 Sleuth 를 적용한다면 각 요청의 흐름을 추적하기에 많은 도움을 받을 수 있다.

참고

https://happycloud-lee.tistory.com/216

[SC10] Spring Cloud Sleuth와 Zipkin 이란 ?

1. Sleuth와 Zipkin 이해 1) WHY ? 마이크로서비스로 큰 서비스를 잘게 쪼개어 개발하게 되면 자연스럽게 마이크로서비스간에 연결이 많아지고 복잡하게 됩니다. 예를 들어 고객 '홍길동'이 2021-02-01 13:

happycloud-lee.tistory.com

https://dzone.com/articles/tracing-in-microservices-with-spring-cloud-sleuth

Tracing in Microservices With Spring Cloud Sleuth - DZone Java

dzone.com

https://engineering.linecorp.com/ko/blog/line-ads-msa-opentracing-zipkin/

LINE 광고 플랫폼의 MSA 환경에서 Zipkin을 활용해 로그 트레이싱하기 - LINE ENGINEERING

안녕하세요. LINE Ads에서 DSP Manager를 담당하고 있는 김용훈입니다. LINE Ads는 일본과 태국, 대만 등 전 세계 LINE 사용자를 대상으로 하는 글로벌 광고 플랫폼을 개발하고 있습니다. LINE의 광고 플랫

engineering.linecorp.com

https://www.studytonight.com/post/request-tracing-in-microservices-using-spring-cloud-sleuth-andzipkin

Request Tracing in Microservices using Spring Cloud Sleuth and Zipkin - Studytonight

To understand what is Spring Cloud Sleuth and Zipkin and why we need them in a microservices architecture where a single monolithic application is divided into smaller services, we first need to understand the problem that microservices architecture leads

www.studytonight.com

https://refactorfirst.com/distributed-tracing-with-spring-cloud-sleuth.html

Distributed Tracing with Spring Cloud Sleuth And Zipkin

In this article, we would learn how we can implement distributed tracing and understand the key concepts of distributed tracing.

refactorfirst.com

https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/html/getting-started.html#getting-started

Getting Started

If you are getting started with Spring Cloud Sleuth or Spring in general, start by reading this section. It answers the basic “what?”, “how?” and “why?” questions. It includes an introduction to Spring Cloud Sleuth, along with installation inst

docs.spring.io

https://www.baeldung.com/spring-cloud-sleuth-single-application

Spring boot :: Caffeine cache 정리

훈훈훈 — Sun, 31 Oct 2021 22:54:43 +0900

Introduction

사내에서 Local cache 라이브러리인 Caffeine cache 를 도입하게 되어 공부한 내용을 정리하게 되었다.

Caffeine cache 를 사용하면서 EhCache 와의 차이점이 궁금하여 두 라이브러리를 비교 후 간단한 예제 코드를 살펴보려고 한다.

예제 코드는 깃헙에서 확인할 수 있다.

Caffeine cache vs EhCache 3.xx

먼저 Caffeine cahce 에 대하여 살펴보자

Baeldung 에서는 Caffeine Cache 를 아래와 같이 소개하고 있다.

Caffeine 깃헙 위키는 아래와 같이 소개하고 있다.

공통적으로 High Performance Java caching Library 라고 소개하고 있다.
문서를 읽어보면 캐시와 ConcurrentMap 과의 차이점도 설명으로 덧붙이고 있다.
ConcurrentMap 에 저장된 데이터는 해당 Map 이 제거될 때까지 영구적으로 보관된다고 한다.

반면에 캐시는 evict 로직이 Auto 로 동작하게끔 구성이 된다고 한다.
그리고 Caffeine Cache 는 eviction policy 로 Window TinyLfu 라는 것을 사용한다.

해당 알고리즘을 사용함으로써 최적의 적중률(near-optimal hit rate)을 보여준다고 한다.

Window TinyLfu 에 대하여 궁금하다면 해당 링크를 읽어보길 바란다.

이제 Ehcache 에 대하여 살펴보자.

EhCache 는 Java 진영에서 유명한 Local Cache 라이브러리 종류 중 하나이다.

EhCache 는 Caffeine Cache 보다 더 많은 기능을 제공해준다.
분산 처리, Cache Listener 그리고 Off Heap 에 캐싱된 데이터를 저장할 수 있다. 그 외 더 많은 기능들은 공식문서에서 확인할 수 있다.

아래 그림은 Ehcache 공식문서에 있는 Distributed Caching 관련 내용이다.

위 그림을 보면 각 어플리케이션 내에 저장되어 있는 캐시를 Terracotta 라는 Hub 역할을 하는 분산 캐시 서버에 동기화하는 과정을 볼 수 있다.

EhCache 의 Distributed Caching 에 대하여 좀 더 알아보고 싶다면 해당링크를 참고하길 바란다.

아래 그림은 EhCache 공식문서에 있는 Storage tiers hierarchy 구조이다.

EhCache 는 Heap 메모리 공간 이외에 데이터를 저장할 수 있는 Off Heap 기능을 지원한다.
Off Heap 기능을 사용하면 GC 로 부터 자유로워 질 수 있는 장점이 있다.

하지만, Off Heap 에 저장되어 있는 데이터를 저장 및 불러올 떄는 직렬화 비용이 발생하게 된다.

이제 벤치마크 자료를 통해 성능을 비교해보자.

아래 자료는 Caffeine cache 깃헙 위키에서 제공하는 데이터이다.

측정 값과 단위는 아래와 같다.

- Throughput: 단위 시간당 디지털 데이터 전송으로 처리하는 양
- ops/s: operations per second (초당 작업)

읽기 100% 성능 측정

읽기 100% 성능 측정 테스트에서는 Caffeine Cache 가 가장 좋은 성능을 보여주었고 그 다음으로는 ConcurrentLinkedHashMap 이 좋은 성능을 보여주었다.

위에서 비교했던 EhCache 는 다소 아쉬운 성능을 보여주었다.

읽기 75% 쓰기 25% 성능 측정

읽기 75% 쓰기 25% 성능 측정 테스트에서도 역시 Caffeine Cache 가 가장 좋은 성능을 보여주었고 그 다음으로는 ConcurrentLinkedHashMap 이 좋은 성능을 보여주었다.

하지만, 읽기 100% 성능 측정과는 다르게 Caffeine Cache 와 ConcurrentLinkedHashMap 의 성능 차이가 2배 정도 차이가 나는 것을 볼 수 있다.

마찬가지로 위에서 비교했던 EhCache 는 다소 아쉬운 성능을 보여주었다.

쓰기 100% 성능 측정

쓰기 100% 성능 측정 테스트에서도 역시 Caffeine Cache 가 가장 좋은 성능을 보여주었고 그 다음으로는 ConcurrentLinkedHashMap 이 좋은 성능을 보여주었다.

마찬가지로 Caffeine Cache 와 ConcurrentLinkedHashMap 의 성능 차이가 2배 정도 차이가 나는 것을 볼 수 있다.

정리하자면, Caffeine Cache 는 EhCache 처럼 다양한 기능은 제공하지는 않지만 심플하게 메모리에 데이터를 캐싱하고 불러오는 작업만 한다면 가장 뛰어난 성능을 보여준다.

Caffeine cache example

이제 Spring boot 환경에서 사용 예시를 간단하게 살펴보자

Caffeine cahce 를 사용하기 위해 아래와 같이 의존성을 추가하자.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-cache'
    implementation 'com.github.ben-manes.caffeine:caffeine'
    
}

그 다음 @EnableCaching 를 사용하여 스프링 어플리케이션이 캐시를 사용할 수 있게 하자.

@EnableCaching // 캐시 기능을 활성화한다.
@SpringBootApplication
public class CacheApplication {

  public static void main(String[] args) {
    SpringApplication.run(CacheApplication.class, args);
  }

}

이제 캐시에 대한 Enum 값을 정의하자.

@Getter
public enum CacheType {
  USERS(
      "users",      // 캐시 이름: users
      5 * 60,       // 만료 시간: 5 분
      10000         // 최대 갯수: 10000
  );

  CacheType(String cacheName, int expireAfterWrite, int maximumSize) {
    this.cacheName = cacheName;
    this.expireAfterWrite = expireAfterWrite;
    this.maximumSize = maximumSize;
  }

  private final String cacheName;
  private final int expireAfterWrite;
  private final int maximumSize;

}

Enum 을 사용하여 캐시 이름, 만료 시간, 저장 가능한 최대 갯수를 정의하였다.

그 다음, cacheManager 를 Bean 으로 등록하자.

@Configuration
public class CacheConfig {

  @Bean
  public CacheManager cacheManager() {
    List<CaffeineCache> caches = Arrays.stream(CacheType.values())
        .map(cache -> new CaffeineCache(cache.getCacheName(), Caffeine.newBuilder().recordStats()
                .expireAfterWrite(cache.getExpireAfterWrite(), TimeUnit.SECONDS)
                .maximumSize(cache.getMaximumSize())
                .build()
            )
        )
        .collect(Collectors.toList());

    SimpleCacheManager cacheManager = new SimpleCacheManager();
    cacheManager.setCaches(caches);

    return cacheManager;
  }

}

CacheType 에 등록한 캐시들을 Caffeine 캐시 객체로 생성 후 SimpleCacheManager 객체에 등록하였다.

이제 캐시가 정상적으로 동작하는지 아래 유저 객체를 사용하여 테스트를 해보자.

@Getter
public class User {
  private final Long id;
  private final String email;
  private final String name;

  @Builder
  public User(Long id, String email, String name) {
    this.id = id;
    this.email = email;
    this.name = name;
  }
}

테스트를 위해 간단한 Controller 를 작성해보았다.

@RestController
public class UserController {

  Map<Long, User> userMap = new ConcurrentHashMap<>();

  @PostConstruct
  public void init() {
    User user1 = User.builder()
        .id(1L)
        .name("test1")
        .email("test1@test.com")
        .build();

    User user2 = User.builder()
        .id(2L)
        .name("test2")
        .email("test2@test.com")
        .build();

    User user3 = User.builder()
        .id(3L)
        .name("test3")
        .email("test3@test.com")
        .build();

    userMap.put(user1.getId(), user1);
    userMap.put(user2.getId(), user2);
    userMap.put(user3.getId(), user3);

  }

  @Cacheable(cacheNames = "users")
  @GetMapping("/users")
  public List<User> getUser() throws InterruptedException {
    Thread.sleep(10000);
    Set<Long> userIds = userMap.keySet();

    return userIds.stream()
        .map(userId -> userMap.get(userId))
        .collect(Collectors.toList());

  }

}

간단하게 코드를 작성하기 위해서 Controller, Service, Repository 로 계층을 구분하지 않고 1 Layer 로 작성하였다.

데이터는 DB 는 사용하지 않고 간단하게 ConcurrentHashMap 을 사용하여 어플리케이션이 실행될 때 초기화를 하도록 만들었다.

그리고 성능 측정을 위하여 GET /users 가 호출되면 10s 동안 thread 를 sleep 하도록 api 를 만들었다.

이제 api 호출을 통해 캐시가 정상적으로 동작하는지 살펴보자.

첫 번째 호출할 때는 응답 시간이 약 10s 정도 걸린 것을 볼 수 있다.

다시 한 번 api 를 호출해보자.

두 번째 호출부터 약 4ms 정도 걸리는 것을 볼 수 있다.

참고

https://github.com/ben-manes/caffeine/wiki

GitHub - ben-manes/caffeine: A high performance caching library for Java

A high performance caching library for Java. Contribute to ben-manes/caffeine development by creating an account on GitHub.

github.com

https://www.ehcache.org/documentation/3.4/tiering.html

Ehcache Tiering Options

In order to understand what happens for different cache operations when using multiple tiers, here are examples of Put and Get operations. The sequence diagrams are oversimplified but still show the main points. Figure 2. Multiple tiers using Put Figure 3.

www.ehcache.org

https://gosunaina.medium.com/cache-redis-ehcache-or-caffeine-45b383ae85ee

Cache — Redis, EhCache or Caffeine?

A cache is a reserved storage location that collects temporary data to help websites, browsers, and apps load faster. The data stored in a…

gosunaina.medium.com

https://blog.yevgnenll.me/posts/spring-boot-with-caffeine-cache

Spring boot 에 caffeine 캐시를 적용해보자 - 어떻게하면 일을 안 할까?

부제: 어떻게 하면 일을 조금이라도 안할까?

blog.yevgnenll.me

Spring boot :: Multiple DataSource 환경에서 @DataJpaTest 이슈 정리 및 스프링 코드 분석

훈훈훈 — Mon, 11 Oct 2021 01:52:42 +0900

Introduction

이번에는 Multiple DataSource 환경에서 JPA 로 개발 된 Repository 테스트를 할 때 사용하는 @DataJpaTest 로 테스트를 작성할 때 발생하는 문제, 그리고 어떻게 해결해야하는지에 대하여 정리해보려고 한다.

참고로 MyBatis 를 사용한다면, mybatis-spring-boot-starter-test 에 있는 @MyBatisTest 를 사용하면 된다.

@DataJpaTest 는 JPA, Entity Manager 를 @MyBatisTest 는 MyBatis 를 AutoConfiguration 을 하는 점 이외에는 동일하다.

예제 코드는 GitHub 에서 확인할 수 있다.

Problem

결론부터 말하자면 여러 DataSource 를 구성할 때 프로퍼티를 spring.datasource.url 이 아닌 spring.datasource.master.hikari 와 같이 커스텀하게 작성해서 발생하는 이슈이다.

아래는 일반적으로 단일 DataSource 를 사용할 때 작성하는 프로퍼티이다.

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://127.0.0.1:3306/multiple-datesource?serverTimezone=UTC
    username: root
    password:

Spring boot 는 DataSource 를 AutoConfiguration 을 할 때, 기본적으로 spring.datasource.url 를 가져오지만, 여러 Datasource 를 구성하는 경우 Hikari CP DataSource 를 생성하기 위해서는 커스텀하게 작성한다.

이제 왜 이런 이슈가 발생하는지 예제 코드를 보면서 살펴보자.

아래는 예제로 작성한 DataSource 설정 클래스이다.

@Configuration
public class DataSourceConfig {

    @Primary
    @Bean(name = "masterDataSource")
    @ConfigurationProperties(prefix="spring.datasource.master.hikari")
    public DataSource masterDataSource() {
        return DataSourceBuilder.create()
                .type(HikariDataSource.class)
                .build();
    }

    @Bean(name = "slaveDataSource")
    @ConfigurationProperties(prefix="spring.datasource.slave.hikari")
    public DataSource slaveDataSource() {
        return DataSourceBuilder.create()
                .type(HikariDataSource.class)
                .build();
    }
}

Master / Slave 두 종류의 DataSource 로 구성하였고, 프로퍼티는 spring.datasource.master(slave).hikari 하위의 값들을 가져오도록 설정하였다.

그리고 아래는 Master / Slave datasource 를 구성하기 위한 프로퍼티 파일이다.

spring:
  datasource:
    master:
      hikari:
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://127.0.0.1:3306/multiple-datesource?serverTimezone=UTC
        read-only: false
        username: root
        password:

    slave:
      hikari:
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://127.0.0.1:3306/multiple-datesource?serverTimezone=UTC
        read-only: true
        username: root
        password:

이제 테스트 코드를 살펴보자.

아래 코드는 @DataJpaTest 를 사용하여 간단한 테스트 코드를 만들어 보았다.

@DataJpaTest
@AutoConfigureTestDatabase(replace = Replace.NONE)
public class JpaTest {

    @Autowired
    UserRepository userRepository;

    @Test
    void test() {
        User user = userRepository.findUserByName("name").orElse(null);
        System.out.println(user);
    }
}

만약 위 코드가 Multiple DataSource 로 구성하지 않았다면 정상적으로 테스트가 종료가 되겠지만, 현재 구조로 테스트를 실행한다면 아래와 같은 오류 메시지를 볼 수 있다.

Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured. Reason: Failed to determine a suitable driver class

위에서 언급했듯이, 프로퍼티 파일에서 spring.datasource.url 을 가져오지 못하여 어플리케이션 실행을 하지 못한다고 알려주고 있다.

이제 스프링 코드를 보면서 왜 이런 문제가 발생하는지 살펴보자.

테스트할 때 사용했던 @DataJpaTest 어노테이션을 살펴보자

@DataJpaTest 는 기본적으로 in-memory DB 를 사용한다.

MySQL, PostgreSQL 같은 DB 를 사용하려면 @AutoConfigureTestDatabase 사용하라고 주석에 명시되어 있다.

테스트 코드를 작성할 때, embedded database 인 H2 를 사용한다면 어플리케이션만 띄우면 되기 때문에 편리하겠지만, 데이터베이스에 따라서 SQL 이 조금씩 다르기 때문에 실제 라이브에 배포 된 어플리케이션의 테스트 정확도를 보장하지는 못한다.

두 가지 방법 중 어떤 방법이 더 좋다는 접근 보다는 어떤 점을 더 중요하게 생각하는지에 따라서 embedded 로 사용할지 혹은 실제 database 를 사용할지 결정하는 것이 좋다고 생각한다.

이 글에서는 @AutoConfigureTestDatabas 설정을 통해 MySQL 을 사용할 것이다.

이제 해당 어노테이션을 살펴보자.

@AutoConfigureTestDatabas 살펴보면, Enum 값인 Replace 가 있는 것을 볼 수 있다.

디폴트로 ANY 적용되고 AUTO_CONFIGURED, NONE 두 가지 타입이 더 있는 것을 볼 수 있다.

주석만으로는 각각 타입에 따라 어떤 동작을 하는지 파악하기 어려워서 실제로 저 값을 사용하는 코드를 살펴보자.

아래 TestDatabaseAutoConfiguration 코드를 살펴보면 Replace 가 AUTO_CONFIGURED 또는 ANY 일 경우 embedded DB 를 생성하고 NONE 일 경우 아무런 행위 없이 지나가고 DataSourceAutoConfiguration 이 실행되는 것을 볼 수 있다.

위 과정까지가 테스트 어노테이션을 사용할 때 추가로 동작하는 부분이다.

이제 스프링이 DataSource Bean 을 등록할 때 사용하는 DataSourceAutoConfiguration 을 통해 DataSource 를 Bean 으로 등록하는 과정을 보자.

시작하기 전에 짚고 넘어가야 될 부분은 Spring boot 2.0 부터는 Tomcat Connection Pool 이 아닌 Hikari Connection Pool 을 사용한다. 따라서 DataSourceAutoConfiguration 을 통해 Hikari CP 가 등록되는 과정을 살펴보자.

아래는 DataSourceConfiguration 클래스에 있는 내부 클래스 Hikari 코드이다.

코드를 살펴보면 DataSourceProperties 를 넘겨 받아 DataSource 를 생성하는 것을 볼 수 있다.

이 부분이 Multiple DataSource 를 사용할 때 발생하는 문제의 시작점이라고 볼 수 있다.

그 이유는 파라미터로 받는 DataSourceProperties 를 보면 알 수 있는데, 코드를 살펴보면 spring.datasource 하위에 있는 값들을 가져오는 것을 볼 수 있다.

즉, 위의 예시처럼 spring.datasource.master.hikari 이런식으로 설정 값들을 작성을 하면 DataSourceProperties 는 값을 읽어올 방법이 없는 것이다.

아래는 DataSourceProperties 코드이다.

아래는 DataSourceConfiguration 클래스 내에 있는 Hikari 내부 클래스에서 createDataSource( ) 메서드를 호출할 때 실질적으로 호출되는 메서드이다.

해당 코드는 DataSourceBuilder 를 사용해서 프로퍼티와 타입을 가지고 DataSource 를 생성하는 것을 볼 수 있다.

문제의 원인은 위에서 발견했지만, DataSource 가 어떻게 생성이 되는지 궁금하여 DataSourceBuilder 코드를 좀 더 살펴 보았다.

먼저, DataSourceBuilder 는 스프링 부트 버전에 따라 코드가 변경되었다.

현업에서 사용했던 2.3.10 버전 그리고 위에서 계속 살펴보았던 예제 코드는 스프링 2.5.5 버전이다.

서로 살펴보면서 코드를 보던 중 상당 부분이 바뀌어서 두 버전 다 살펴보려고 한다.

먼저 2.3.10 버전의 DataSourceBuilder 보면 상당히 심플한 구조를 보이고 있다.

build( ) 메서드를 살펴보면, DataSource Type 을 가져오고 나서 bind( ) 메서드를 호출하여 url 과 jdbc-url 을 서로 매핑하는 것을 볼 수 있다.

그에 비하여 2.5.5 버전은 조금 복잡한 로직으로 되어 있다.

build( ) 메서드에서 첫번째 라인 DataSourceProperties.forType( ) 메서드의 호출을 따라가다 보면 아래와 같이 bind 역할을 하는 HikariDataSourceProperties 를 볼 수 있다.

아래는 HikariDataSourceProperties 내부 클래스 코드이다.

코드를 보면 DataSourceProperty 에 있는 값, 그리고 HikariDataSource 의 get(set) 메서드를 파라미터로 넘겨줘서 add( ) 하고 있는 것을 볼 수 있다.

호출되는 add( ) 는 마찬가지로 DataSourceBuilder 에 있는 MappedDataSourceProperties 내부 클래스에 있는 메서드이다. Map 객체에 데이터를 넣어주는 것을 볼 수 있다.

스프링 코드를 따라가 보았을 때, 저 Map 객체에서 위에서 저장 헀던, HikariDataSource 의 get(set) 메서드를 호출하면서 값들을 매핑하는 것을 볼 수 있다.

스프링 코드는 여기까지 살펴보고 정리하자면, @DataJpaTest 를 사용할 때 Spring boot 에서 기본적으로 지원하는 자동 설정으로 실행이 되기 때문에 오류가 발생한다. 이 문제를 해결하기 위해 @ImportAutoConfiguration 를 사용하여 등록한 Datasource 설정 클래스를 Import 시켜줘야 한다.

Code Example

아래 코드는 위에 예제에서 작성했던 Multiple DataSource 설정 클래스이다.

@Configuration
public class DataSourceConfig {

    @Primary
    @Bean(name = "masterDataSource")
    @ConfigurationProperties(prefix="spring.datasource.master.hikari")
    public DataSource masterDataSource() {
        return DataSourceBuilder.create()
                .type(HikariDataSource.class)
                .build();
    }

    @Bean(name = "slaveDataSource")
    @ConfigurationProperties(prefix="spring.datasource.slave.hikari")
    public DataSource slaveDataSource() {
        return DataSourceBuilder.create()
                .type(HikariDataSource.class)
                .build();
    }
}

위 설정 클래스를 아래 테스트 코드르 작성할 때, @ImportAutoConfiguration(DataSourceConfig.class) 라인을 추가해주면 정상적으로 실행이 되는 것을 볼 수 있다.

@AutoConfigureTestDatabase(replace = Replace.NONE)
@DataJpaTest
@ImportAutoConfiguration(DataSourceConfig.class)
public class JpaTest {

    @Autowired
    UserRepository userRepository;

    @Test
    void test() {
        User user = userRepository.findUserByName("name").orElse(null);
        System.out.println(user);
    }
}

Spring boot :: Mockito 로 WebClient 테스트 하기

훈훈훈 — Sun, 26 Sep 2021 23:40:49 +0900

Introduction

WebClient 를 사용하여 외부 API 를 Mock 기반 테스트를 할 때, response 값에 대한 stub 객체를 만드는 방법에 대하여 정리해보려고 한다. 전체 코드는 Github 에서 확인할 수 있다.

Problems

일반적으로 Mockito 를 사용할 때 아래와 같은 방법으로 stub 객체를 만들 수 있다.

( Mockito 는 BDD 방식을 지원하기 때문에 when( ) 대신 좀 더 가독성이 좋은 given ( ) 을 사용하였다. )

given(webClientWrapper.get()
    .uri("http://localhost:8080/test")
    .retrieve()
    .bodyToMono(String.class)
    .block()
).willReturn("ok");

하지만 테스트를 돌릴 때 위 코드 라인이 실행이 된다면, 아래와 같이 NPE 가 발생하는 것을 볼 수 있다.

given( ) 에서 NPE 가 발생하는 이유는 WebClient 는 Fluent API 이기 때문이다.

따라서 일반적인 객체에 대한 Stub 객체를 만드는 방법으로 테스트 코드를 작성한다면 정상적으로 동작하지 않게 된다.

정리하자면, 위에서 살펴본 NPE 는 Fluent API 에서 발생하는 문제인 것을 확인했으므로, 이제 해당 API 가 무엇인지 그리고 어떻게 Stubbing 을 하는지 알아보자.

Fluent API

Baeldung 글을 보면 Fluent API는 Method chaining 을 사용하여 Builder, Factory 등을 사용하는 것으로 정리되어 있다.

누구나 알 수 있는 예시로는 Java 의 Stream API 가 있다.

Fluent API 는 Method Chaining 을 사용하기 때문에 가독성은 좋지만, 그 속에는 여러 객체와 메서드가 숨겨져서 사용되고 있다.

따라서 만약 @Mock 을 사용한다면 아래와 같이 작성할 수 있다. 해당 예제는 해외 블로그 글에서 가져왔다.

@ExtendWith(MockitoExtension.class)
class ExampleTest {
 
  @Mock
  private WebClient webClient;
 
  @InjectMocks
  private InspirationalQuotesClient cut; // class under test
 
  @Test
  void test() {
 
    WebClient.RequestHeadersUriSpec requestHeadersUriSpec = Mockito.mock(WebClient.RequestHeadersUriSpec.class);
    WebClient.ResponseSpec responseSpec = Mockito.mock(WebClient.ResponseSpec.class);
 
    when(webClient.get()).thenReturn(requestHeadersUriSpec);
    when(requestHeadersUriSpec.uri("/api/quotes")).thenReturn(requestHeadersUriSpec);
    when(requestHeadersUriSpec.retrieve()).thenReturn(responseSpec);
    when(responseSpec.bodyToMono(String.class)).thenReturn(Mono.just("We've escaped hell"));
 
    String result = cut.fetchRandomQuote();
 
    assertEquals("We've escaped hell", result);
  }
}

코드를 보면 단순한 예제임에도 Stub 객체를 생성하기 위해 많은 코드를 작성해야되는 것을 볼 수 있다.

이 방법으로 테스트 코드를 작성한다면 너무 번거롭기 때문에 대안들을 찾아보다가 MockWebServer 라이브러리를 사용하는 예제를 찾긴 했다. 하지만 Mockito 만 사용해도 가능할 것 같아서 해당 방법은 패스하였다.

다시 돌아와서, Baeldung 글을 보면 Mockito 는 Answer 라는 객체로 Deep Stubbing 기능을 지원한다고 소개되어 있다.

Answer 은 enum 객체이며, 코드를 살펴 보면 여러 객체가 정의 된 것을 볼 수 있다.

그 중에서 RETURNS_DEEP_STUBS 객체를 @Mock(answer = Answers.RETURNS_DEEP_STUBS) 와 같이 사용하면 Deep Stub 을 만들 수 있다.

이제 위에서 봤던 내용들을 전체 코드로 살펴보자.

Code Example

간단하게 "ok" 문자열을 response 하는 API 를 만들고 WebClient 로 호출하는 service 코드를 테스트 하는 과정을 살펴보자.

- Controller

단순하게 "ok" 문자열을 response 하는 컨트롤러를 만들었다.

@RestController
public class TestController {
    
    @GetMapping("/test")
    public ResponseEntity<String> test() {
        return ResponseEntity.ok().body("ok");
    }
}

- WebClient Wrapper

WebClient 를 사용할 때, 매번 Builder 를 정의해야 되기 때문에 중복 코드가 발생헐 수 밖에 없다.

따라서 BuilderWrapper 클래스를 만들고 생성자에 builder 를 build 할 수 있게 만들었다.

실제로는 여러 값들을 공통적으로 정의해서 사용할 수 있지만, 해당 예제는 간단하게 build( ) 하였다.

@Component
public class WebClientWrapper implements WebClient {

    private final WebClient webClient;

    public WebClientWrapper(WebClient.Builder builder) {
        webClient = builder.build();
    }
    
    @Override 
    // ... 생략 
}

- Service

위에서 만든 WebClientWrapper 를 사용하여 "/test" path 로 요청을 보내는 간단한 코드를 만들었다.

@Service
public class WebclientWrapperService {

    private final WebClientWrapper webClientWrapper;

    public WebclientWrapperService(WebClientWrapper client) {
        this.webClientWrapper = client;
    }

    public String request() {
        return webClientWrapper.get()
                .uri("http://localhost:8080/test")
                .retrieve()
                .bodyToMono(String.class)
                .block();

    }

}

- Test code

Deep Stub 를 사용하여 WebClient 를 테스트하는 코드를 만들었다.

해당 코드를 실행해보면 정상적으로 동작하는 것을 확인할 수 있다.

@ExtendWith(MockitoExtension.class)
class WebclientWrapperServiceTest {

    @Mock(answer = Answers.RETURNS_DEEP_STUBS) // Deep Stub
    WebClientWrapper webClientWrapper;

    @InjectMocks
    WebclientWrapperService service;

    @Test
    @DisplayName("WebClient_wrapper_객체_테스트")
    void requestTest() {
        // given
        given(webClientWrapper.get()
                .uri("http://localhost:8080/test")
                .retrieve()
                .bodyToMono(String.class)
                .block()
        ).willReturn("ok");

        // when
        String result = service.request();

        // then
        assertThat(result).isEqualTo("ok");

    }
}

추가로 만약 WebClient.Builder 를 Stubbing 해야 한다면 어떻게 해야할까??

아래처럼 WebClient.Buidler 를 직접 생성자로 넘겨준다면 코드가 약간 달라질 수 있다.

@Service
public class WebClientNotWrapperService {

    private final WebClient webClient;

    public WebClientNotWrapperService(WebClient.Builder builder) {
        webClient = builder.build();
    }

    public String request() {
        return webClient.get()
                .uri("http://localhost:8080/test")
                .retrieve()
                .bodyToMono(String.class)
                .block();

    }
}

Builder 는 자기 자신을 리턴하기 때문에 테스트 코드에서 아래 처럼 사용한다면 NPE 가 발생하게 된다.

@Mock(answer = Answers.RETURNS_DEEP_STUBS)
WebClient webClient;

@Mock
WebClient.Builder builder;

해당 문제를 해결하기 위해서 다시 Answer 객체에 주석을 살펴보면, RETURNS_SELF 를 사용해서 Builders 를 mocking 할 수 있는 것을 확인할 수 있다.

따라서 아래와 같이 코드를 작성을 하면 정상적으로 테스트가 되는 것을 확인할 수 있다.

@ExtendWith(MockitoExtension.class)
class WebClientNotWrapperServiceTest {

    @Mock(answer = Answers.RETURNS_DEEP_STUBS)
    WebClient webClient;

    @Mock(answer = Answers.RETURNS_SELF)
    WebClient.Builder builder;

    @InjectMocks
    WebClientNotWrapperService service;

    @BeforeEach
    void setUp() {
        given(builder.build()).willReturn(webClient);
        service = new WebClientNotWrapperService(builder);
    }
    
    // 중략 ...

}

좀 더 간단한 방법은 없을까??

마지막으로 가장 심플한 방법인 WebClient 를 사용하는 로직을 객체로 감싸고 해당 객체를 테스트 하는 방법을 소개하려고 한다.

간단하게 바로 코드로 살펴보자.

위에서 살펴봤던 WebClient 로 "/test" path 에 요청을 날리는 로직을 함수로 분리하였다.

@Component
@RequiredArgsConstructor
public class WebClientRequest {

    private final WebClientWrapper webClientWrapper;

    public String requestTest() {
        return webClientWrapper.get()
                .uri("http://localhost:8080/test")
                .retrieve()
                .bodyToMono(String.class)
                .block();
    }

}

service 에서는 위에서 분리한 객체를 단순히 호출만 하도록 변경하였다.

@Service
public class WebClientObjectService {

    private final WebClientRequest webClientRequest;

    public WebClientObjectService(WebClientRequest webClientRequest) {
        this.webClientRequest = webClientRequest;
    }

    public String request() {
        return webClientRequest.requestTest();
    }
}

테스트 코드는 간단하게 위에서 분리한 객체만 stub 객체를 만들어서 테스트를 진행하였고, 정상적으로 동작하는 것을 확인할 수 있다.

@ExtendWith(MockitoExtension.class)
class WebClientObjectServiceTest {

    @Mock
    WebClientRequest webClientRequest;

    @InjectMocks
    WebClientObjectService service;

    @Test
    void request() {
        // given
        given(webClientRequest.requestTest())
                .willReturn("ok");

        // when
        String result = service.request();

        // then
        assertThat(result).isEqualTo("ok");
    }
}

참고

https://www.baeldung.com/spring-mocking-webclient

https://www.baeldung.com/mockito-fluent-apis

https://rieckpil.de/creating-deep-stubs-with-mockito-to-chain-method-stubbing/

https://circlee7.medium.com/mockito-mock-answer-3212b135262a

http://wonwoo.ml/index.php/post/2364

Spring boot :: JPA, Mybatis Transaction Manager 정리

훈훈훈 — Mon, 6 Sep 2021 23:14:39 +0900

Introduction

이번에는 Mybatis 와 JPA 를 동시에 적용한 환경에서 어떤 transactionManager 를 사용해야되는지 살펴보려고 한다.

해당 글은 스프링에서 트랜잭션을 담당하는 핵심 인터페이스인 PlatformTransactionManager 를 먼저 정리 후, Mybatis 그리고 JPA 에 대한 내용을 정리하는 순서로 작성하였다.

PlatformTransactionManager

스프링 트랜잭션 추상화의 핵심 인터페이스이다.

모든 스프링 트랜잭션 기능과 코드는 이 인터페이스를 통해 트랜잭션 서비스를 이용할 수 있다.

아래는 해당 인터페이스에 정의 된 메서드 목록이다.

getTransaction( ) 메서드는 트랜잭션 속성에 따라 새로 생성하거나 진행 중인 트랜잭션에 참여하거나, 진행 중인 트랜잭션을 무시하고 새로운 트랜잭션을 만드는 식으로 동작을 한다.

즉, 트랜잭션 전파 기법을 이용해 자유롭게 조합하고 확장할 수 있게 할 수 있다.

그리고 파라미터로 받는 TransactionDefinition 은 트랜잭션 전파(propagation) 과 격리 수준(isolation) 을 나타낸다.

아래 그림에서 TransactionDefinition 인터페이스 구조를 볼 수 있다.

마지막으로 PlatformTransactionManager 를 구현하고 있는 클래스들을 살펴보면 아래 그림과 같다.

앞으로 살펴 볼 DataSourceTransactionManager 그리고 JPATransactionManager 는 PlatformTransactionManager 의 구현체인 것을 볼 수 있다. 이 외에도 다양한 구현체를 확인할 수 있다.

Mybatis Transaction

Mybatis 공식 문서를 살펴보면, Spring 에서 DataSourceTransactionManager 를 사용하는 것을 알 수 있다.

DataSourceTransactionManager 는 아래와 같이 등록 할 수 있는 것으로 공식 문서에서 확인할 수 있다

이제 Mybatis 가 사용하는 DataSourceTransactionManager 에 대하여 알아보자.

DataSourceTransactionManager 클래스는 아래와 같은 의존 관계를 가지고 있는 것을 볼 수 있다.

위에서 살펴 보았던 PlatformTransactionManager 를 구현한 AbstractPlatformTransactionManager 를 구현하고 있는 클래스인 것을 확인할 수 있다.

DataSourceTransactionManager 에 대하여 좀 더 살펴보자.

해당 클래스는 Connection 객체에 존재하는 트랜잭션 api 를 이용해서 트랜잭션을 관리해주는 트랜잭션 매니저이다.

또한 사용하기 위해서는 DataSource 가 스프링 빈으로 등록이 돼야 한다.

사용할 수 있는 DAO 로는 JDBC 와 Mybatis 가 있다.

JPA Transaction

이제 JPA 에서 사용하는 JPATransactionManager 를 살펴보자.

먼저 의존관계를 살펴보면 DataSourceTransactionManage 클래스와 유사한 것을 볼 수 있다.

JPATransactionManager 는 기본적으로는 JPA API 를 이용할 때 사용한다.

그런데 JPA 의 EntityManagerFactory 가 스프링의 빈으로 등록된 DataSource 를 사용할 수 있다.

그렇기 때문에 JPA 에서 사용하는 DataSoure 를 JDBC, Mybatis 에서 사용할 수 있다.

따라서 JPATransactionManager 는 DataSourceTransactionManager 가 제공하는 DataSource 레벨의 트랜잭션 관리 기능을 동시에 제공한다.

결과적으로 JPATransactionManager 를 사용하면서 JDBC, Mybatis 의 트랜잭션 관리도 같이 할 수 있다.

Conclusion

위 내용을 정리하자면 Mybatis 를 단독으로 사용할 경우 DataSourceTransactionManager 를 스프링 빈으로 등록이 필요하지만, JPA를 사용할 경우 JPATransactionManager 로 같이 관리가 가능하기 때문에 별도의 TransactionManager 를 등록할 필요는 없다.