[4주차] RateLimit 구현 및 Jacoco 커버리지 테스트

[zhdiddl]

제목(title)

[4주차] RateLimit 구현 및 Jacoco 커버리지 테스트

작업 내용

• Google Guava 사용해 Rate Limit 적용
• Lua Script 사용해 Redis 기반 Rate Limit 로직으로 대체
• 컨트롤러, 서비스, 리포지토리 테스트 작성
• Jacoco 커버리지 테스트 후 결과 README에 추가

이번 주차에서 고민되었던 지점이나, 어려웠던 점을 알려 주세요.

아래의 문제를 해결하지 못했습니다... 😓

• 문제: 작성한 테스트 중 ReservationJpaRepositoryTest가 실패
• 가설 수립: RedisTemplate 빈을 주입하는 것에 실패한 것으로 판단

NoSuchBeanDefinitionException: No qualifying bean of type 'org.springframework.data.redis.core.RedisTemplate<java.lang.String, java.lang.String>' available

• 시도한 내용:

1. 테스트용 Redis 설정 클래스 작성

@TestConfiguration
public class RedisTestConfig {

    @Bean
    public RedisTemplate<String, String> redisTemplate() {
        RedisTemplate<String, String> template = Mockito.mock(RedisTemplate.class);
        when(template.opsForValue()).thenReturn(Mockito.mock(ValueOperations.class));
        return template;
    }
}

2. JPA 테스트에 해당 빈을 주입하는 애노테이션 추가

@DisplayName("[JPA 테스트] 예약 리포지토리")
@Import(RedisTestConfig.class)
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) // 실제 DB에서 테스트
@DataJpaTest
class ReservationJpaRepositoryTest {
...

• 다른 시도: test 용 application 을 아래처럼 작성해서 @ActiveProfiles("test") 애노테이션을 JPA 테스트에 추가

spring:
  cache:
    type: none
  data:
    redis:
      host: localhost
      port: 0  # Redis 연결 방지
      timeout: 0

• 결과: JPA 테스트만 성공하고 다른 테스트가 모두 실패

java.lang.IllegalStateException: ApplicationContext failure threshold (1) exceeded

리뷰 포인트

• 위 문제의 원인을 잘 이해하지 못해 어떻게 해결할 수 있을지 궁금합니다.
• Test Fixtures 적용하지 못한 상태입니다. 인프라 모듈과 애플리케이션 모듈에 테스트 코드가 분산되어 있고 각 테스트에서 필요한 객체가 다르다 보니 java-test-fixtures를 어떻게 적용해야 할지 잘 모르겠습니다.
• 기능이 추가되면서 헥사고날 아키텍처 기반으로 설계한 초기 방향성과 멀어진 것 같은데 리팩토링이 필요하다면 어떤 부분을 중점적으로 고민해야 할지 궁금합니다.
• (3주차 PR이 merge가 되지 않아 저번 주 커밋까지 포함된 것 같습니다. 이번 주 추가한 커밋은 cc1050d 부터 입니다)

[DongHyunKIM-Hi]

querydsl을 사용하고 있는 상황이라면 엔티티 간의 Join을 위한 OneToMany, ManyToOne 같이 Join을 위한 어노테이션 사용을 지양하는 경향이 있습니다. 그 이유로는 JPA의 연관 관계를 사용하면 자동으로 생성되는 쿼리가 복잡해지고, 성능 최적화가 어려울 수 있기 떄문입니다. 반면 QueryDSL을 사용하면 필요한 필드만 선택적으로 조회하거나, 복잡한 조인 조건을 직접 제어할 수 있어서 더 유연하게 쿼리를 작성할 수 있습니다!

100 % 안좋다는 것은 아닌데 이러한 관점도 있으니 참고 해주시면 좋을 것 같습니다!

[DongHyunKIM-Hi]

생성자 어노테이션을 사용하지 않은 이유가 특별하게 있는 것이 아니면 사용하는 것을 추천 드립니다. 유지보수 측면에서 혹은 다른 개발자가 누락할수있는 실수가 발생할수있기 때문에 자동으로 관리해주는 것이 좋다고 생각합니다

[DongHyunKIM-Hi]

현재 도메인에서는 1개의 상품에 대해서 선착순으로 경쟁하는 상황이지만 다수의 상품에서 선착순으로 경쟁할 때는 ( ex) 선착순 특가 잔여 상품 3개 ) 락 획득 실패한 요청에 대해서도 재시도 처리를 넣어주어서 처리하는 방법도 많이 사용되고 있으니 참고해주시면 좋을 것 같아요. @retryable을 통해서 ObjectOptimisticLockingFailureException 예외 발생시 동작하도록 하는 식으로 말이죠 ㅎㅎ

[DongHyunKIM-Hi]

좋으점

• 코드가 깔끔하고 어떤 생각으로 해당 코드를 작성했는지 명확하게 알 수 있어서 좋았습니다.
• 다양한 방식으로 락을 시도하고 이를 비교한 내용이 있어서 좋았습니다.

위 문제의 원인을 잘 이해하지 못해 어떻게 해결할 수 있을지 궁금합니다.
해당 내용만으로는 어떻게 해결해야 할지 명확하게 판단이 잘 안가는 것 같습니다. 우선 현재 작성된 코드를 보니 redisconfig쪽에 RedisTemplate 관련된 설정이 없는 것으로봐서 일단 RedisTemplate<String, String>을 명시해주고 (필요 없을지언정 일단 어디가 문제인지 명확하게 하기 위해서) 그래도 문제가 발생하는지 에러 로그가 변경되는지 확인해볼 것 같습니다.
변경시 다른 에러로 변경되거나 해결된다? 그럼 문제가 더 추려지는 것이고
변경이 안된다? 그럼 redis 관련 빈 등록 문제가 아니니 다른 테스트 환경 문제를 볼것 같습니다. 혹은 @SpringBootTest로 돌려서 모든 설정을 로드 했을 경우에도 에러가 뜨는지 한번 더 확인하면서 문제를 좁혀 갈 것 같습니다.

Test Fixtures 적용하지 못한 상태입니다. 인프라 모듈과 애플리케이션 모듈에 테스트 코드가 분산되어 있고 각 테스트에서 필요한 객체가 다르다 보니 java-test-fixtures를 어떻게 적용해야 할지 잘 모르겠습니다.

아래 링크를 참조해보면 좋을 것 같습니다.
https://medium.com/@jojiapp/gradle-multi-module에서-testfixtures를-이용하여-테스트-코드-중복-줄이기-3a4737f574f
https://leeeeeyeon-dev.tistory.com/122
https://toss.tech/article/how-to-manage-test-dependency-in-gradle

기능이 추가되면서 헥사고날 아키텍처 기반으로 설계한 초기 방향성과 멀어진 것 같은데 리팩토링이 필요하다면 어떤 부분을 중점적으로 고민해야 할지 궁금합니다.

개인적으로는 헥사고날 아키텍처 방향성에 맞게 잘 진행하고 있는 것 같아요. 그래도 자가 진단을 하고 싶다면 우선 현재 추가 및 변경된 내용중에서 도메인 레벨에서의 특이점이 있는지 먼저 확인해보면 좋습니다. 도메인 레벨은 앵간하면 초반에 추가되거나 컬럼이 추가 및 변경이 되거나 하지 않는 경우에 변경이 되었는지 그리고 그 주기가 빈번한지 먼저 보면 좋습니다. 그런데 현재 진행된 내용들을 살펴보니 도메인 레벨에서의 수정은 거의 일어나지 않았고 새로 추가된 도메인들도 기존의 도메인들과 별반 다르지 않고 유사한 형태로 추가되고 있어 특이점은 없어 보입니다.
다만 validate 는 논의해볼만한 관점입니다. 이유는 현재 인프라 모듈에서 바로 도메인 모듈에 접근하여 검증을 하고 있습니다. 이건 외부 요청이 어플리케이션을 거치지 않고 바로 도메인 모듈에 접근하는데 해당 구조는 생각해볼만하고 개인적으로는 입력 데이터 및 프로세스 흐름 검증은 애플리케이션 계층에서 처리하는 것이 적절하다고 생각합니다!
이후 어플리케이션 모듈에서 비즈니스 로직이 수행이된 이후에 검증은 도메인 모듈에서 진행되는 것이 맞다고 보고 있습니다.