feature/#43 cqrs application

[jvnlee]

구현 내용

📌 식당 조회 API의 성능 향상을 위해 데이터베이스 분리

DataSource를 하나만 가지고 있던 기존 구조에서, READ용과 WRITE용 2개를 가지도록 변경하고 필요에 따라 Routing 하는 기능을 구현함.

CQRS 패턴 도입이라고 표현했으나, 엄밀하게는 아님. CQRS 패턴은 READ용 DB로만 READ를 수행하고, WRITE용 DB로만 CREATE/UPDATE/DELETE를 진행하지만, 현재 프로젝트에서는 도입 취지 상 집계 데이터가 포함되는 특정 조회 API의 성능 향상에 초점을 두고 있어 당장으로서는 완벽하게 Command와 Query의 분리를 목표로 하지 않음.

따라서 현재는 식당 조회 API의 경우에만 READ DB로부터 조회를 수행하고, 나머지 일반 조회 API의 경우는 WRITE DB에서 조회를 수행하도록 함.

이 기능을 도입한 배경도 결국은 식당 정렬 조회 API의 성능을 개선해보기 위함이었음

식당에 관련된 avgRating이나 reviewCount 같은 대규모 집계가 필요한 데이터를 READ DB에 저장해두고 조회 시점에 별도의 집계 함수 실행 없이 빠른 성능을 이끌어내는 것을 목표로 함.

 

docker-compose.yml

• yml 파일을 dev와 prod 프로필별로 구분하여 빌드 방식과 환경 변수 세팅을 다르게 진행

• mysql이라는 이름의 단일 데이터베이스 컨테이너를 사용하던 환경에서, read-db와 write-db 2개의 데이터베이스 컨테이너를 사용하도록 변경

• health check condition을 추가하여 2개의 DB 컨테이너가 모두 정상적으로 실행된 경우에만 app 컨테이너를 실행하도록 함

  app 컨테이너 시작 시, Spring Boot가 DB 초기화 전에 Application Context를 초기화하여 실패하는 문제 방지

• Git에 공개하지 않은 init.sql 파일 실행하는 옵션 추가

  init.sql: DB 사용자 권한 설정과 DDL 실행

 

DataSourceRouter

• AbstractRoutingDataSource를 구현하여 현재 DataSourceType을 보고 적절한 DataSource로 찾아가도록 안내하는 역할

  ThreadLocal 변수로 현재 DataSourceType을 보관

• determineCurrentLookupKey(): currentDataSource 필드로부터 현재 타겟으로 하는 DataSourceType을 읽어와 로그로 남기고 반환

 

DataSourceConfig

• writeDataSource() & readDataSource(): 각각 쓰기 데이터베이스와 읽기 데이터베이스를 위한 DataSource Bean 초기화

• dataSourceRouter(): DataSourceRouter를 Bean을 만들고, 2개의 DataSource를 Map에 넣어 타겟으로 지정함.

• lazyDataSource(): DataSourceRouter를 프록시로 감싸서 커넥션 획득을 지연시키는 LazyConnectionDataSourceProxy Bean 초기화

 

EntityManagerFactoryConfig

(dev와 prod 프로필용으로 구분되어 있음)

• ~entityManagerFactory(): LazyConnectionDataSourceProxy를 DataSource로 사용하는 커스텀 EntityManagerFactory를 생성

 

TransactionManagerConfig

• transactionManager(): 커스텀 EntityManagerFactory를 적용할 커스텀 JpaTransactionManager를 생성

 

@AggregatedData

@Transactional(readOnly = true)가 붙어있는 것과 별개로, @AggregatedData라는 커스텀 어노테이션이 붙어있어야만 READ_ONLY 데이터베이스로 라우팅됨.

 

DataSourceRoutingAspect

Spring AOP를 이용하여 @AggregatedData 어노테이션이 붙은 메서드가 호출될 때, DataSourceRouter가 타겟을 READ_ONLY로 변경하도록 함.

 

DataSourceRouterCleanerInterceptor

DataSourceRouter가 가진 ThreadLocal 변수를 기본값인 WRITE_ONLY로 초기화시킴

초기화 하지 않는 경우 잔존 값으로 인해 발생하는 버그를 방지

 

📌 이벤트로 조회용 데이터베이스의 데이터 동기화

Spring의 ApplicationEventPublisher로 특정 WRITE DB 작업 후 이벤트를 발행하고, 이벤트 핸들러를 통해 해당 작업을 READ DB에도 반영하는 구조

RestaurantReviewStat

avgRating이나 reviewCount 같은 집계 데이터가 포함된 식당 엔티티.

READ DB에서 관리하며, WRITE DB에서 관리하는 Restaurant 엔티티의 조회용 버전이라고 볼 수 있음.

여러 개의 ReviewCreatedEvent 핸들링에 의해 동시에 집계 데이터가 업데이트 될 때, 정합성 문제가 발생할 소지가 있어 낙관적 락을 적용

낙관적 락을 적용한 이유

• 식당 리뷰 등록은 예약 기능과 달리 한날 한시에 동시다발적으로 사용되는 기능이 아니기 때문에 동시성 문제 발생 가능성이 매우 낮음

• 이벤트 핸들링은 어차피 본 요청과 별개로 비동기로 이루어지기 때문에 충돌 시 재시도 처리를 하는데에 성능적 부담이 없음

 

RestaurantReviewStatService

• search(), view(): 기존에 RestaurantService에 있던 조회 기능을 옮겨옴.

  READ DB로부터 집계 데이터를 즉시 읽어올 수 있기 때문에 분리 전의 기존 방식에 비해 큰 성능 향상을 기대할 수 있는 지점

• register(), update(), delete(): 각각 WRITE DB에서 발생한 Restaurant의 생성, 수정, 삭제 작업을 READ DB의 RestaurantReviewStat에 반영

  RestaurantCreatedEvent, RestaurantUpdatedEvent, RestaurantDeletedEvent 핸들링 과정에서 호출됨

• updateReviewData(): WRITE DB에 생성된 Review로 인한 평균 별점과 전체 리뷰 개수 변화를 READ DB의 RestaurantReviewStat에 반영

  ReviewCreatedEvent 핸들링 과정에서 호출됨

 

RestaurantEventHandler

RestaurantCreatedEvent, RestaurantUpdatedEvent, RestaurantDeletedEvent를 감지해서 비동기 핸들링. RestaurantReviewStatService의 register(), update(), delete() 메서드를 호출하여 READ-DB에 반영

 

ReviewCreatedEventHandler

ReviewCreatedEvent를 감지해서 비동기 핸들링. RestaurantReviewStatService의 updateReviewData() 메서드를 호출하여 READ-DB에 반영

 

📌 Testcontainers를 사용하는 테스트 환경에 DB 분리 반영

TestcontainersContext

기존의 TestContextInitializer 대신, 통합 테스트를 위한 컨테이너 환경을 세팅하는 역할

통합 테스트 클래스에서 해당 클래스를 상속하여 TC를 사용할 수 있음

 

RestaurantReviewStatIntegrationTest

Restaurant와 관련된 변경 사항이 이벤트 처리를 통해 READ-DB의 RestaurantReviewStat에 정상적으로 반영되는지 테스트하는 통합 테스트 클래스