우리는 request의 getRemoteAddr() 을 통해 IP 주소를 가져올 수 있습니다.

그런데 이때 가져온 주소가 정말 클라이언트의 IP 주소일까요?

사용자에 대한 정보를 얻을 수 있는 HTTP 요청 헤더 예시

일반적으로 클라이언트와 서버는 직접 메시지를 주고 받지 않습니다.

메시지는 복잡한 네트워크를 경유하여 목적지에 도착하게 되는데, 이 과정에서 프록시나 로드 밸런서를 거치게 되면 IP 주소가 변경될 수 있습니다.

이때 X-Forwarded-For 헤더를 통해 우리는 요청 메시지의 발자취를 확인할 수 있습니다.

X-Forwarded-For

X-Forwarded-For 헤더는 HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별하기 위해 사용하는 헤더입니다. 클라이언트와 서버 중간에서 트래픽이 프록시나 로드 밸러서를 거치면 서버 접근 로그에는 프록시나 로드 밸러서의 IP 주소가 남게 되는데 이때 클라이언트의 IP 주소를 보기 위해 X-Forwarded-For 요청 헤더가 사용됩니다. X-Forwarded-For 헤더는 프록시 서버를 경유할 때마다 서버의 IP 주소 정보를 쉼표로 구분해 연결해 나갑니다.

X-Forwarded-For: <client>, <proxy1>, <proxy2>

가장 오른쪽 IP 주소는 가장 마지막에 거친 프록시 IP 주소이고, 가장 왼쪽의 IP 주소는 최초 클라이언트의 IP 주소가 됩니다. 따라서 우리는 X-Forwarded-For 해더의 맨 앞 주소를 확인하면 클라이언트의 IP를 알 수 있습니다.

만약 X-Forwarded-For 헤더의 필드가 비어있다면 getRemoteAddr() 을 통해 가져온 IP 주소가 클라이언트의 IP 주소라고 판단할 수 있습니다.

Spring Boot Config

Spring Boot에서 클라이언트의 IP 주소를 가져오는 방법은 크게 2가지가 있습니다.

1. 직접 X-Forwarded-For Header 확인하기

request.getHeader("X-Forwarded-For") 를 통해 헤더 정보를 가져온 다음 직접 파싱하여 프록시나 로드 밸런서를 통해 기록된 클라이언트의 IP가 있는지 확인할 수 있습니다.

2. request.getRemoteAddr() 설정하기

또는 getRemoteAddr() 을 호출했을 때, X-Forwarded-For 헤더의 값을 전달할 수 있도록 설정할 수 있습니다.

아무것도 설정하지 않으면 기본적으로 Socket으로 연결된 IP 주소를 반환합니다.

native

컨테이너의 기본 자원을 사용하는 방식입니다.

server:
  forward-headers-strategy: native

아래의 org.springframework.boot.autoconfigure.web.embedded.TomcatWebServerFactoryCustomizer 내부의 customizeRemoteIpValue를 보면, getOrDeduceUseForwardHeaders() 가 true일 때 새로운 RemoteIpValue 인스턴스를 생성하는 것을 확인할 수 있습니다.

getOrDeduceUseForwardHeaders() 는 forward-headers-strategy가 native로 설정되어 있다면 true를 반환합니다.

RemoteIpValue의 내부 코드를 살펴보면 다음과 같은 필드가 정의되어 있고

invoke() 에서 해당 헤더를 가져와 파싱하는 과정을 거치는 것을 확인할 수 있습니다.

만약 String remoteIp 가 null 이 아니라면 request.setRemoteAddr() 을 통해 파싱한 결과를 설정하게 됩니다.

framework

스프링에서 제공하는 ForwardedHeaderFilter를 사용하는 방식입니다.

server:
  forward-headers-strategy: framework

Extract values from "Forwarded" and "X-Forwarded-*" headers, wrap the request and response, and make they reflect the client-originated protocol and address in the following methods: . . .

주석을 살펴보면 Forwarded 및 X-Forwarded-* 헤더에서 값을 추출하여 요청과 응답에 반영하는 동작을 수행함을 알 수 있습니다.

헤더의 범위는 기본적으로 다음과 같이 설정되어 있습니다.

Override한 getRemoteAddr() 을 살펴보면 파싱한 결과가 null 이 아닌 경우 파싱한 결과를 반환하고 null 인 경우 기존의 getRemoteAddr() 의 결과를 그대로 반환하도록 구현돼 있습니다.

이는 프록시나 로드 밸러서에 의해 IP 주소가 변경되지 않고 목적지에 도착한 경우 X-Forwarded-For 헤더에 아무것도 기록되지 않았으므로 현재 요청을 보낸 IP 주소를 그대로 반환하기 위함입니다.

Nginx Config

만약 서버와 같은 컴퓨터에서 Nginx를 프록시로 두고 있다면 127.0.0.1 이라는 클라이언트 IP 주소를 얻게 될 수 있습니다. 이는 X-Forwarded-For 헤더를 제대로 설정해 주지 않아 발생하는 문제일 가능성이 높습니다. 이때 Nginx에 다음과 같은 설정을 추가해 줍니다.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

$proxy_add_x_forwarded_for 는 클라이언트의 X-Forwarded-For 헤더의 필드에 변수 $remote_addr 을 쉼표로 구분하며 결합하는 동작을 수행합니다. 만약 필드가 존재하지 않는다면 변수 $remote_addr 를 새로 필드에 설정하게 됩니다.

이렇게 모든 설정을 마치면 우리는 request.getRemoteAddr() 을 통해 진짜 클라이언트의 IP 주소를 가져올 수 있게 됩니다!

Reference

HTTP 완벽 가이드 stack overflow ServerProperties.ForwardHeadersStrategy Javadoc Spring Boot Reference Documentation about forwarded headers NGINX

작성자 : 김서연

기존의 비즈니스 로직

수강 바구니 신청 페이지나 수강 신청 페이지를 접속할 때, 반드시 첫 페이지 강의 목록을 받아오는 HTTP 요청을 보냅니다. 따라서 첫 페이지의 강의 목록들은 조회 빈도가 높습니다.

(이때의 첫 페이지는 아무런 필터링을 사용하지 않은 강의 목록 요청의 첫 페이지입니다.)

수강 바구니 신청 페이지

수강 신청 페이지

HTTP 요청을 통해 받아오는 강의 목록 API는 총 20개의 강의 정보로 구성되어 있습니다. 또한 강의 목록들은 수강 신청 기간동안 데이터가 변경되지 않습니다. 이렇게 고정된 크기의 고정된 내용을 갖는 데이터를 항상 DB에서 조회해오는 것은 큰 오버헤드라 생각하여 첫 페이지의 강의 목록들을 캐싱하기로 결정하였습니다.

Spring Cache + Redis 를 사용하기 위한 환경 설정

dependencies {

    implementation 'org.springframework.boot:spring-boot-starter-data-redis'

    // ...
}

build.gradle

다음과 같이 spring data redis 의존성만 추가해주면 Spring Cache 를 사용할 수 있습니다.

@Configuration
@RequiredArgsConstructor
public class RedisConfig {

    private final RedisProperties redisProperties;

    @Value("${spring.data.redis.port}")
    private int port;

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory(redisProperties.getHost(), port);
    }

    // ...

    @Bean
    public CacheManager cacheManager(RedisConnectionFactory cf) {
        RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig()
            .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))        // key 는 String 직렬화
            .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()))        // value 는 Json 직렬화
            .entryTtl(Duration.ofMinutes(30L));        // 캐시 지속 시간은 30 분으로 설정

        return RedisCacheManager.RedisCacheManagerBuilder.fromConnectionFactory(cf).cacheDefaults(redisCacheConfiguration).build();
    }
}

RedisConfig 클래스

Spring Cache 에서 사용할 캐시를 Redis 로 선택하기 위해 다음과 같이 CacheManager 를 구현하고 스프링 빈으로 등록하였습니다.

캐싱하려는 데이터가 첫 번째 페이지 강의 목록 페이지이기 때문에 객체를 JSON 으로 직렬화해주는 GenericJackson2JsonRedisSerializer 를 value Serializer 로 채택하였습니다.

GenericJackson2JsonRedisSerializer 의 특징은 직렬화하려는 객체의 타입을 지정해주지 않아도 된다는 편리함이 있습니다. 객체의 타입을 지정해주지 않아도 역직렬화가 가능한 이유는 저장되는 데이터에 추가적인 필드 @class 덕분입니다. 해당 필드는 패키지 경로와 클래스 명을 포함하여 직렬화한 객체의 정보를 나타냅니다. 따라서 해당 필드와 역직렬화하려는 객체의 패키지 경로 + 클래스 명이 일치하고, 필드들이 일치한다면 성공적으로 역직렬화를 할 수 있습니다.

그러나 이러한 편리함은 단점이 될 수도 있습니다. 캐시에 데이터를 저장한 이후, 패키지 경로가 바뀌거나 클래스 명이 바뀌는 경우 @class 필드와 실제 역직렬화하려는 객체의 정보가 달라질 수 있습니다. 이 경우, 필드들이 일치하더라도 역직렬화에 실패하게 됩니다.

따라서 이런 불편함이 발생할 수 있는 상황이라면 Jackson2JsonRedisSerializer 와 같은 다른 Serializer 를 사용하는 것이 좋습니다.

그러나 저희 프로젝트는 마무리 단계에 접어들어 패키지 경로나 클래스명이 변할 가능성이 낮기 때문에 편의상 GenericJackson2JsonRedisSerializer 를 사용하였습니다.

@SpringBootApplication
@EnableCaching
public class CourseRegistrationSystemApplication {

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

}

마지막으로 SpringBoot 최상단에 @EnableCaching 을 붙여주면 Spring Cache 를 사용하기 위한 준비가 끝납니다.

Spring Cache 적용하기 - 절망편

    @Cacheable(value = "lecture", condition = "#lectureFilterOptions.fetchNoOption() && (#pageable.getPageNumber() == 0)")
    public LectureSchedulePage fetchLectureSchedule(Pageable pageable, LectureFilterOptions lectureFilterOptions) {
        return new LectureSchedulePage(
            lectureRepository.findMatchedLectures(
                    pageable,
                    lectureFilterOptions.getOpeningYear(),
                    lectureFilterOptions.getSemester(),
                    lectureFilterOptions.getSubjectDivision(),
                    lectureFilterOptions.getDepartmentId(),
                    lectureFilterOptions.getSubjectName())
                .map(LectureDetail::new));
    }

모든 준비를 마치고 강의 목록을 조회하는 서비스 메서드에 다음과 같이 Spring Cache를 위한 애노테이션을 사용합니다.

@Cacheable 은 value::key 를 key 값으로 하는 데이터가 캐시에 존재하지 않는다면 해당 메서드를 실행한 후, 결과물을 value::key 를 key 값으로 하여 저장해둡니다. 반면 value::key 를 key 값으로 하는 데이터가 이미 캐시에 존재한다면 해당 메서드를 실행하지 않고, 캐시에 저장된 value::key 에 대응되는 value 값을 반환합니다.

따라서 최초의 첫 강의 목록 페이지 요청 한번에 대해서만 DB에 조회하고, 후속 요청들은 DB 조회없이 캐시에 저장된 데이터를 제공받을 수 있습니다.

@Cacheable 의 condition 필드는 캐싱이 동작할 조건을 설정합니다. 아무런 필터링이 없는 첫 페이지 강의 목록을 조회할 때만 캐싱이 동작하도록 하였습니다.

@Getter
public class LectureFilterOptions {

    @NotNull
    private final Year openingYear;

    @NotNull
    private final Semester semester;

    private final SubjectDivision subjectDivision;
    private final Long departmentId;
    private final String subjectName;

    @Builder
    @Jacksonized
    private LectureFilterOptions(Year openingYear, Semester semester, SubjectDivision subjectDivision,
        Long departmentId,
        String subjectName) {
        this.openingYear = openingYear;
        this.semester = semester;
        this.subjectDivision = subjectDivision;
        this.departmentId = departmentId;
        this.subjectName = subjectName;
    }

    public boolean fetchNoOption() {
        return (subjectDivision == null) && (departmentId == null) && (subjectName == null);
    }

}

LectureFilterOptions 클래스의 fetchNoOption 메서드는 아무런 필터 조건이 없을 경우 true 를 반환한다.

이렇게 준비를 마쳤다고 생각해 서버를 돌려보았는데, DB 조회 로그가 매 요청마다 발생하였습니다.

그래서 캐싱이 제대로 되고있나 확인하기 위해 redis 에 저장된 key 들을 확인해보았습니다.

매 요청마다 새로운 key 값으로 데이터를 캐싱한다.

Spring Cache 적용하기 - 희망편

제가 @Cacheable 의 key 가 저장되는 방식을 제대로 이해하지 못해 다음과 같은 문제가 발생한 것이었습니다.

저는 @Cacheable 에서 key 필드를 생략하면 key가 생기지 않을거라 생각했습니다. 그러나 실제로는 key 필드를 생략하면 @Cacheable 의 default key generator인 SimpleKeyGenerator 가 동작하여 자동으로 key를 생성하였습니다.

SimpleKeyGenerator 는 파라미터들의 정보를 바탕으로 toString() 을 호출해 key를 생성하기 때문에 LectureFilterOptions 와 같이 객체가 파라미터로 넘어오는 경우, 조건이 같아도 객체가 달라 생성된 key 값이 달라지게 됩니다. 따라서 저장되는 value 는 같지만 key 값이 달라 매 요청마다 DB 조회 발생 및 캐시 저장이 이루어지게 된 것입니다.

따라서 이러한 문제를 해결하기 위해선 모든 필터링 없는 첫 페이지 강의 목록 요청 이 같은 key 값을 만들도록 설정해주면 됩니다.

여러가지 해결 방법이 있습니다.

1. Custom Key Generator 를 생성하고, 해당 Key Generator 가 동일한 key 값을 만들도록 설정한다.
2. LectureFilterOption 의 ToString 값을 필드값에 따라 생성되도록 재정의한다.
3. key 필드에 상수를 넣는다.

가장 간단한 방법은 3번이라고 생각해 key 필드에 상수를 넣는 방식으로 문제를 해결하였습니다.

    @Cacheable(value = "lecture", key = "T(site.courseregistrationsystem.util.ProjectConstant).LECTURE_NO_OPTION_FIRST_PAGE",
        condition = "#lectureFilterOptions.fetchNoOption() && (#pageable.getPageNumber() == 0)")
    public LectureSchedulePage fetchLectureSchedule(Pageable pageable, LectureFilterOptions lectureFilterOptions) {
        return new LectureSchedulePage(
            lectureRepository.findMatchedLectures(
                    pageable,
                    lectureFilterOptions.getOpeningYear(),
                    lectureFilterOptions.getSemester(),
                    lectureFilterOptions.getSubjectDivision(),
                    lectureFilterOptions.getDepartmentId(),
                    lectureFilterOptions.getSubjectName())
                .map(LectureDetail::new));
    }

key = "T(site.courseregistrationsystem.util.ProjectConstant).LECTURE_NO_OPTION_FIRST_PAGE" 를 추가함으로써 상수를 사용한다.

이때 SpringEL 문법에서는 상수 클래스 내의 상수를 가져오기위해 다음과 같이 패키지명을 작성해주어야 합니다.

최초의 요청만 lecture::firstPage key 값으로 데이터를 캐싱한다.

성능 측정 결과

성능 측정은 1000명의 user 가 한 번의 첫 페이지 강의 목록 조회 요청을 하는 상황으로 스크립트를 작성하였습니다.

• 캐시 적용 전

  25.12 초의 평균 응답 시간

• 캐시 적용 후

  1.01 초의 평균 응답 시간

비록 필터링 없는 첫 페이지의 강의 목록 조회에 대한 성능 개선만 이루어졌다는 점이 아쉽지만, 해당 API 요청이 가장 많다는 점을 고려하면 엄청난 성능 개선임을 알 수 있습니다. 데이터의 변경이 없는 상황에서의 적절한 캐싱은 엄청난 성능 개선을 만들어 낼 수 있음을 배울 수 있었습니다.

성능 개선을 위한 캐싱은 선택이 아닌 필수임을 느꼈습니다.

작성자: Hyun

출처

https://hyeri0903.tistory.com/237

https://karla.tistory.com/18

https://jgrammer.tistory.com/entry/%EB%AC%B4%EC%8B%A0%EC%82%AC-watcher-Cacheable-%EC%A4%91%EB%B3%B5%EB%90%98%EB%8A%94-key%EA%B0%92-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%B2%98%EB%A6%AC%ED%95%A0%EA%B9%8C

https://stackoverflow.com/questions/13381731/caching-with-multiple-keys

https://velog.io/@hkyo96/Spring-RedisTemplate-Serializer-%EC%84%A4%EC%A0%95

안녕하세요. 저희 수강신청 프로젝트내에서, 수강신청 가능 기간은 저장할 내용이 한정적이기에 spring data redis 를 사용하여 메모리에 저장하였습니다. 잘 알지못하고 적용한 redis 였기에 로직상으로 불필요하고 지저분한 부분이 많았었는데 이를 개선해나가는 과정과, 개선해나가는 과정에서 배운 내용들을 블로깅하려고 합니다.

기존의 비즈니스 로직

우선 리팩토링전의 코드들을 설명하겠습니다.

@RedisHash("enrollmentRegistrationPeriod")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class EnrollmentRegistrationPeriod {

    @Id
    private String targetGrade;
    private LocalDateTime startTime;
    private LocalDateTime endTime;

    @Builder
    private EnrollmentRegistrationPeriod(Grade targetGrade, LocalDateTime startTime, LocalDateTime endTime) {
        this.targetGrade = targetGrade.name();
        this.startTime = startTime;
        this.endTime = endTime;
    }

    public boolean isWithinTimeRange(LocalDateTime now) {
        return startTime.compareTo(now) <= 0 && now.compareTo(endTime) <= 0;
    }

}

redis 에 저장될 해쉬, 수강신청 기간을 나타낸다.

public interface EnrollmentRegistrationPeriodStorage extends CrudRepository<EnrollmentRegistrationPeriod, String> {
}

redis CRUD를 편하게 사용하기 위한 추상화된 리포지토리 인터페이스

이처럼 spring data 진영에서 제공하는 CrudRepository 와 @RedisHash 를 사용함으로써, 쉽게 객체를 redis 에 해쉬로 저장할 수 있었습니다. 그러나 CrudRepository 를 쓰면서 생긴 단점도 있었습니다.

    public RegistrationDate validateEnrollmentRegistrationPeriod(LocalDateTime now, Grade grade) {
        EnrollmentRegistrationPeriod registrationPeriodInGrade = enrollmentRegistrationPeriodStorage.findById(grade.name())
            .orElseThrow(EnrollmentRegistrationPeriodNotFoundException::new);

        CurrentYearAndSemester currentYearAndSemester = clockService.fetchCurrentClock();
        if (registrationPeriodInGrade.isWithinTimeRange(now)) {
            return new RegistrationDate(currentYearAndSemester);
        }

        EnrollmentRegistrationPeriod registrationPeriodInCommon = enrollmentRegistrationPeriodStorage.findById(Grade.COMMON.name())
            .orElseThrow(CommonEnrollmentRegistrationPeriodNotFoundException::new);

        if (registrationPeriodInCommon.isWithinTimeRange(now)) {
            return new RegistrationDate(currentYearAndSemester);
        }

        throw new InvalidEnrollmentTimeException();
    }

학생이 현재 수강신청을 하려는 시간이 (now), 적절한 수강신청 기간내의 시간인지를 검증하는 메서드

CrudRepository 를 사용함으로써 생긴 단점을 설명하기 전에 저희 비즈니스 로직을 먼저 설명하겠습니다.

1. 수강신청을 하려는 학생의 학년과, 현재 시간을 바탕으로 수강신청 가능 기간인지 검증을 시작합니다.

2. 우선, 학생의 학년을 key 로 하는 hash-value (학년 전용 수강 신청 기간) 을 가져옵니다. 2-1. 만약 학생의 학년을 key 로 하는 hash-value 가 없다면 예외를 던집니다.

3. 현재 시간이 앞서 구한 학년 전용 수강 신청 기간내의 시간인지 검증합니다. 3-1. 검증을 성공하면, 검증 로직을 정상 종료합니다.

4. 현재 시간이 학년 전용 수강 신청 기간이 아니므로, COMMON 을 key 로 하는 hash-value (공통 수강 신청 기간) 을 가져옵니다. 4-1. 만약 COMMON 을 key 로 하는 hash-value 가 없다면 예외를 던집니다.

5. 현재 시간이 공통 수강 신청 기간내의 시간인지 검증합니다. 5-1. 검증을 성공하면, 검증 로직을 정상 종료합니다.

6. 만약 검증이 정상 종료되지 않았다면, 현재 시간이 어떠한 수강 신청 기간에도 걸리지 않는 시간이므로 예외를 던집니다.

말로 정리하니 더욱 복잡합니다. 사실, redis 에 저장된 수강 신청 기간을 가져올 때, 학년 전용 수강 신청 기간과 공통 수강 신청 기간을 한번에 가져온 뒤, 한번에 검증을 진행한다면 이해하기 쉬울 것입니다. 그러나 CrudRepository 를 사용하기 때문에 세세한 쿼리를 할 수 없고 findById 로 수강 신청 기간을 하나씩 가져오다보니 로직이 이해하기 어려워졌습니다.

문제는 이뿐만이 아니었습니다. 이러한 비즈니스 로직으로 인해, 예외 발생이 일관적이지 않은 문제가 있었습니다.

• 학생이 수강신청을 진행하는 시간대가 학생 수강 신청 기간 범위에 부합하지 않고
• 공통 수강 신청 기간이 redis 에 저장되지 않았다면

공통 수강 신청이 존재하지 않는다는 예외가 발생합니다.

그러나

• 학생이 수강신청을 진행하는 시간대가 학생 수강 신청 기간 범위에 부합한다면
• 공통 수강 신청 기간이 redis 에 저장되지 않았더라도

공통 수강 신청이 존재하지 않는다는 예외가 발생합니다.

이처럼 예외 발생의 일관성이 없고, 비즈니스 로직이 헷갈려 이를 좀 더 직관적으로 개선해보고자 리팩토링을 마음먹게 되었습니다.

RedisTemplate 과 파이프라이닝

redis 에 저장된 수강 신청 기간 중, 학년 전용 수강 신청 기간과 공통 수강 신청 기간을 한번에 가져오는 것이 리팩토링의 목표였습니다. 특정 수강 신청 2개만 가져오는 로직을 CrudRepository 로는 하기 힘들다 판단하여 RedisTemplate 을 사용하였습니다.

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class EnrollmentRegistrationPeriodService {

    // ...

    private final RedisTemplate<String, String> redisTemplate;

    // ...

}

서비스 클래스에 RedisTemplate 추가

redis 에 파이프라이닝을 통해 특정 수강 신청들만 가져오는 로직을 구현할 수 있다고 판단하여 다음과 같이 비즈니스 로직을 수정하였습니다.

    public RegistrationDate validateEnrollmentRegistrationPeriod(LocalDateTime now, Grade grade) {
        ObjectMapper objectMapper = new ObjectMapper();

        redisTemplate.executePipelined(
                (RedisCallback<Object>)connection -> {
                    StringRedisConnection stringRedisConnection = (StringRedisConnection)connection;
                    stringRedisConnection.hGetAll(ENROLLMENT_REGISTRATION_PERIOD_PREFIX + grade.name());
                    stringRedisConnection.hGetAll(ENROLLMENT_REGISTRATION_PERIOD_PREFIX + Grade.COMMON.name());
                    return null;
                }
            ).stream()
            .map(lhm -> objectMapper.convertValue(lhm, EnrollmentRegistrationPeriod.class))
            .filter(period -> period.isWithinTimeRange(now))
            .findAny()
            .orElseThrow(InvalidEnrollmentTimeException::new);

        CurrentYearAndSemester currentYearAndSemester = clockService.fetchCurrentClock();
        return new RegistrationDate(currentYearAndSemester);
    }

바뀐 비즈니스 로직

redisTemplate.executePipelined(...) 내부에 한번에 보내고자 하는 redis 명령어 파이프라인을 만듦으로써 한번에 실행할 수 있습니다. 이 메서드의 return 값들은 List<LinkedHashMap<String, String>> 으로 redis 에 저장된 각 hash-value 의 필드명-필드값들이 하나의 LinkedHashMap 이 되어 리스트를 이루게 됩니다.

LinkedHashMap 으로는 현재 시간이 수강 신청 기간에 부합하는지 검증할 수 없으므로 LinkedHashMap 을 EnrollmentRegistrationPeriod 객체로 변환하기 위해 ObjectMapper 를 생성 후 사용했습니다. filter 를 이용하여 검증에 부합하는 수강 신청 기간이 단 하나라도 남는다면 현재 시간은 수강 신청이 가능한 기간이므로 검증을 통과합니다. 반면, 남는 수강 신청 기간이 하나도 없다면 현재 시간은 수강 신청이 가능하지 않은 기간이므로 예외를 던집니다.

훨씬 로직이 깔끔하고 직관적으로 변했습니다. 그러나 위의 비즈니스 코드는 정상적으로 동작하지 않습니다.

기본설정의 ObjectMapper 와 SpringBoot의 ObjectMapper

위의 비즈니스 코드는 런타임 에러를 발생시킵니다. 런타임 에러가 발생하는 이유는 2가지입니다.

1. 기본설정의 ObjectMapper 는 입력값이 deserialize 하려는 객체 타입에게는 없는 필드를 갖고있다면 에러를 던진다.

@RedisHash("enrollmentRegistrationPeriod")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class EnrollmentRegistrationPeriod {

    @Id
    private String targetGrade;
    private LocalDateTime startTime;
    private LocalDateTime endTime;

    @Builder
    private EnrollmentRegistrationPeriod(Grade targetGrade, LocalDateTime startTime, LocalDateTime endTime) {
        this.targetGrade = targetGrade.name();
        this.startTime = startTime;
        this.endTime = endTime;
    }

    public boolean isWithinTimeRange(LocalDateTime now) {
        return startTime.compareTo(now) <= 0 && now.compareTo(endTime) <= 0;
    }

}

redis 에 저장될 해쉬, 수강 신청 기간을 나타낸다.

redis 에 저장될 수강 신청 기간 클래스를 다시한번 보겠습니다. 수강 신청 기간을 저장할 때 CrudRepository 를 사용해 @RedisHash 를 통째로 저장하면 redis 에 어떻게 저장될까요? redis 에 저장되는 하나의 hash-value 가 갖는 필드들은 다음과 같습니다.

• targetGrade
• startTime
• endTime
• _class

_class 필드는 @RedisHash 가 붙은 클래스의 패키지 정보와 클래스 명이 저장됩니다. 이처럼 _class 필드 때문에 deserialize 하기 위한 입력값인 LinkedHashMap 에는 _class 필드가 추가됩니다.

반면 deserialize 의 결과값인 EnrollmentRegistrationPeriod 클래스에는 _class 라는 필드는 없으니 런타임 예외가 발생합니다.

이를 해결하기 위해서는 redis 에 hash-value 를 저장할 때, _class 필드를 저장하지 않거나, _class 필드를 deserialize 할 때 무시하는 방법이 있습니다.

2. 기본설정의 ObjectMapper 는 LocalDateTime 필드를 serialize/deserialize 할 수 없다.

EnrollmentRegistrationPeriod 클래스는 수강 신청 기간 정보를 가져야하기 때문에 LocalDateTime 필드를 갖고 있습니다.

그러나 기본설정의 ObjectMapper 는 LocalDateTime 필드를 serialize/deserialize 할 수 없으니 런타임 예외가 발생합니다.

이를 해결하기 위해서는 ObjectMapper 에 시간 변환을 위한 모듈을 추가해주어야 합니다.

앞서 런타임 예외가 발생한 문제점과 해결방안들을 살펴보았습니다. 각각의 문제점 해결을 위한 해결방안들을 적용해주어도 되지만, 스프링 부트 환경에서는 이 문제들을 더 쉽고 간편하게 한번에 해결할 수 있습니다.

바로 스프링 컨테이너에서 주입해주는 ObjectMapper 를 사용하는 것입니다.

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class EnrollmentRegistrationPeriodService {

    // ...

    private final RedisTemplate<String, String> redisTemplate;
    private final ObjectMapper objectMapper;

    // ...

    public RegistrationDate validateEnrollmentRegistrationPeriod(LocalDateTime now, Grade grade) {
        redisTemplate.executePipelined(
                (RedisCallback<Object>)connection -> {
                    StringRedisConnection stringRedisConnection = (StringRedisConnection)connection;
                    stringRedisConnection.hGetAll(ENROLLMENT_REGISTRATION_PERIOD_PREFIX + grade.name());
                    stringRedisConnection.hGetAll(ENROLLMENT_REGISTRATION_PERIOD_PREFIX + Grade.COMMON.name());
                    return null;
                }
            ).stream()
            .map(lhm -> objectMapper.convertValue(lhm, EnrollmentRegistrationPeriod.class))
            .filter(period -> period.isWithinTimeRange(now))
            .findAny()
            .orElseThrow(InvalidEnrollmentTimeException::new);

        CurrentYearAndSemester currentYearAndSemester = clockService.fetchCurrentClock();
        return new RegistrationDate(currentYearAndSemester);
    }

• 최종적으로 완성된 비즈니스 로직

• 다음과 같이 스프링 컨테이너에서 주입해주는 ObjectMapper 를 사용함으로써 앞서 런타임 에러들을 해결할 수 있다.

스프링 컨테이너에 있는 ObjectMapper 는 기본설정의 ObjectMapper 와 무엇이 다를까요? ObjectMapper 는 여러가지 옵션을 주어 커스터마이징을 할 수 있습니다. 스프링 부트 내부에서는 ObjectMapper 를 생성할 때, 앞선 1번, 2번 문제들을 해결하는 세팅을 포함한 여러가지 세팅을 합니다.

 configureFeature(objectMapper, DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

입력값을 Object 로 변환하는 deserialize 시에 Object 에 없는 필드가 있어도 에러를 발생시키지 않는다. 이러한 세팅이 1번 문제를 해결한다.

    Class<? extends Module> javaTimeModuleClass = (Class<? extends Module>)
            ClassUtils.forName("com.fasterxml.jackson.datatype.jsr310.JavaTimeModule", this.moduleClassLoader);
    Module javaTimeModule = BeanUtils.instantiateClass(javaTimeModuleClass);
    modulesToRegister.set(javaTimeModule.getTypeId(), javaTimeModule);

LocalDateTime 과 같은 시간 변환을 가능하게 해주는 모듈을 추가한다. 이러한 세팅이 2번 문제를 해결한다.

지금까지 spring data redis 를 사용한 수강 신청 기간을 검증하는 로직을 개선하는 과정과, 그 과정에서 공부한 ObjectMapper 에 대해 설명하였습니다.

잘 알지 못하는 상태에서 도입하는 기술들은 지저분한 코드를 만듭니다. 이렇게 쌓인 지저분한 코드들은 부채가 되어 마음한켠에 찝찝한 마음을 남기곤 했습니다. 이번에 리팩토링 기간을 길게 둔 덕분에, 잘 몰랐던 기술들을 다시금 차분히 공부해나가면서 리팩토링을 할 시간이 생겼는데 처음엔 막막했지만 조금씩 개선해나가면서 뿌듯함과 재미를 느낄 수 있어 뜻깊은 시간이었습니다.

작성자: Hyun

출처

https://docs.spring.io/spring-data/redis/reference/redis/pipelining.html

https://green-bin.tistory.com/63

https://sabarada.tistory.com/236

프로젝트 중간 점검을 마치고 기능 개선을 시작한 첫 주였습니다. 그 중에서 수강 신청 검증 단계에서 발생한 동시성 문제를 해결한 과정을 소개합니다. 😊

(1) 강의 정원을 초과해서 수강할 수 있다고?

현재 수강 신청을 위한 검증 단계에서 정원을 초과하여 신청하려고 하는지 확인하는 코드는 다음과 같습니다.

enrollment 는 강의 수강 신청에 성공하면 생기는 데이터입니다. 강의의 enrollment 개수를 count 해서 요청한 학생이 강의를 수강해도 정원을 초과하지 않는지 확인합니다.

위 코드가 제대로 된 검증을 수행하는지 테스트를 돌려서 확인해 보겠습니다.

정원이 30명인 강의에 대한 100개의 수강 신청 요청 스레드를 생성하여 수행한 결과,

위와 같이 테스트가 실패하는 것으로 나타났습니다.

즉, Race condition 문제가 발생하며 30명보다 더 많은 학생이 수강 신청에 성공하게 된 것입니다.

(2) 정원에 맞춰서 신청할 수 있도록 제대로 된 검증 구현하기

Race condition 문제를 해결하기 위해 데이터베이스에 Lock을 걸어서 순차적으로 요청을 처리할 수 있지만, 이 방법은 Lock이 걸린 범위에 대한 모든 접근이 불가하므로 수많은 요청을 처리하는 데 다소 많은 시간이 소요됩니다.

수강 신청이라는 단기간에 많은 사용자가 몰리는 이벤트 상황에 적합하지 않다고 판단하여 Redis를 사용해서 Lock을 구현하기로 합니다. 데이터베이스에 직접 Lock을 거는 것이 아니라 외부에서 Lock을 관리하기 때문에 해당 Lock 때문에 다른 비즈니스 로직에 부수 효과가 발생하는 것을 방지할 수 있습니다.

Spring Boot Redis의 기본 클라이언트인 Lettuce는 Spin Lock 방식으로 동작하기 때문에 많은 재요청이 필요한 수강 신청 상황에서는 Redis에 예상치 못한 부하를 발생시킬 수 있습니다. 따라서 최종적으로 pub-sub 방식의 Lock을 제공하는 Redisson 라이브러리를 사용하기로 결정했습니다.

Redisson GitHub

Lock의 key는 강의의 PK 값인 lectureId 로 지정하였습니다. 또한 lectureId or lectureNumber 를 사용하여 수강 신청 요청을 받고 있었기 때문에 lectureNumber 로 들어온 요청도 findByNumber() 를 통해 lectureId 를 읽어와서 Lock의 key로 사용하도록 하여 서로 다른 요청에도 정합성 문제가 발생하지 않도록 했습니다.

수정 전 EnrollmentService

EnrollmentService에서 lectureId 와 lectureNumber 각각의 요청에 따른 전처리를 한 다음 공통된 private enroll() 메서드를 사용하여 작업을 수행합니다.

새로 생성한 RedissonEnrollmentLockFacade

RedissonEnrollmentLockFacade를 생성하여 lectureId 와 lectureNumber 각각의 Lock 획득 Facade를 구현하고 EnrollmentService에게 enroll() 수행을 요청합니다.

수정 후 EnrollmentService

기존 private enroll() 메서드를 public으로 개방하고 lectureId 와 lectureNumber 각각의 요청에 대한 인터페이스는 제거했습니다.

(3) Lock 구현 후 테스트 결과 확인하기

이제 수정된 코드로 동일한 테스트를 수행합니다.

try 내부의 enrollmentService.enrollLecture() 를 redissonEnrollmentLockFacade.enrollLecture() 로 변경한 다음 테스트를 수행한 결과,

AssertionError가 발생하지 않고 정상적으로 종료되는 것을 확인할 수 있었습니다.

lectureId 와 lectureNumber 요청이 함께 들어온 경우에도 동시성 문제가 발생하지 않는지 확인하기 위한 테스트도 작성해보았습니다. 번갈아가면서 lectureId 와 lectureNumber 를 사용하여 수강 신청 요청을 보내도록 했고 테스트 결과,

문제없이 동작하는 것을 확인할 수 있었습니다.

마무리

Lock을 구현하는 과정에서 Facade라는 레이어를 추가하면서 JPA Transaction 범위에 따른 초기화 문제가 생기기도 했습니다. 해당 문제에 대해 아티클을 참고하였고, 필요한 연관 관계를 Fetch Join을 사용하여 한 번에 조회함으로써 해결하였습니다.

또한 동시성 테스트를 통해 정합성 문제가 발생하는 것을 직접 확인함으로써 멀티 스레딩 프로그램에서 자원에 대한 접근을 관리하는 것의 중요성을 실감할 수 있었습니다.

이로써 과정을 모두 소개했습니다. 이어서 Redis를 캐시로 활용하여 성능을 개선해보는 작업을 해보려고 합니다.

긴 글 읽어주셔서 감사합니다 🙂

작성자 : 김서연

프로젝트 진행 상황

현재 목표로 했던 모든 API를 완성했고 Vue를 사용하여 API 연동까지 끝마쳤습니다. 수강 신청 API 서버에서 제공하는 기능들은 다음과 같습니다.

• 쿠키와 세션을 사용한 로그인
• 학생, 학과 목록, 강의 정보, 수강 신청 기간 조회
• 수강 바구니와 수강 신청 내역 조회
• 수강 바구니 담기
• 수강 신청
• 이를 수행하는 데 필요한 검증들

자세한 API 문서는 링크를 확인해 주세요.

API 성능 측정

API의 평균 응답 속도를 측정하기 위해 K6를 사용하여 테스트를 진행했습니다. 학년별로 수강 신청을 진행함을 고려하여 1,000명의 가상 사용자를 설정하였습니다.

DB에 저장한 데이터의 수는 다음과 같습니다.

학생 : 5,000 (학년 당 1,000명, 4학년은 2,000명) 학과 : 54 교수 : 600 과목 : 3,000 강의 : 10,000

성능 측정 결과

API의 평균 latency 결과입니다. (AWS t2 micro ubuntu server)

중간 점검 결과

MySql을 방문하는 대부분의 API는 매우 느린 응답 속도를 보였고 일부는 모든 요청을 처리하지 못하고 연결이 끊어지기도 했습니다.

수강 신청 인원 수를 통한 수강 신청 가능 여부 검증 단계에서는 Race condition 문제가 발생하여 강의의 정원을 초과하여 신청된 경우도 있었습니다.

개선사항

앞으로 약 한 달동안 기능을 구현하면서 생긴 궁금증과 아쉬운 점들 중 몇 가지를 집중적으로 개선하고 과정을 블로그에 기록할 예정입니다.

• Spring Boot에서 Redis 사용의 Best practice 탐구하기
• 서비스 간의 의존 관계 구조 개선하기
• 세션 연장 시에 새로운 세션을 만들지 않고 TTL만 초기화하기
• API 변경이 있을 때, 촘촘한 테스트가 큰 오버헤드가 되는데, 어떻게 하면 이를 개선할 수 있을지 고민해보기
• 서비스 간의 의존 관계가 있는 경우, 테스트 코드에서 Spy 처리 vs given 절에서 전부 준비하기
• 데이터베이스 읽기 성능 개선하기
• 캐시를 사용하여 응답 속도 개선하기
• k6와 같은 성능 테스트 도구를 사용하는 방법과 시나리오를 설정하는 기준에 대해 학습하기
• Nginx worker 설정값 및 캐시 처리에 대해 학습하기
• Race condition 문제 해결하기

프로젝트 GitHub

코드를 작성하기 시작하면서, 구조나 우선 순위에 대한 토의와 변경이 많았던 한 주였습니다. 그 중에서 컨트롤러 테스트 구조가 변화했던 과정을 소개합니다. 😊

(1) Mocking 없이 실제 모듈들이 협력하도록 하자!

첫 번째 시도는 모든 객체들이 잘 협력하는지 확인하는 통합 테스트였습니다.

클라이언트의 요청부터 인터셉터를 제대로 통과하는지, 개별 객체가 우리가 기대하는 응답을 생성하여 서로 잘 주고 받는지 등... 하나의 애플리케이션으로서 문제없이 동작하는지 확인하는 것에 목적을 두었습니다.

따라서 mocking 없이 Spring Boot Context를 바탕으로 실제 객체를 사용하여 테스트를 수행했습니다.

높은 커버리지 점수, 그러나

결과적으로 비교적 적은 양의 코드를 작성하고도 높은 커버리지 점수를 받을 수 있었습니다. 그러나 광범위한 범위를 포함하고 있다보니 테스트가 실패했을 때 어디에서 어떤 오류가 발생했는지, 문제를 직관적으로 파악하기 어렵다는 단점을 갖게 됩니다.

이를 보완하기 위해서 어떤 하나의 부품이 문제없이 동작함을 보장하는 단위 테스트가 필요함을 생각했고, 컨트롤러 라는 관심사를 큰 덩어리에서 분리하게 됩니다.

(2) 컨트롤러 단위 테스트는 어때? Service는 Mocking!

이어진 두 번째 시도는 컨트롤러 가 제대로 동작하는지 확인하는 단위 테스트입니다.

예상한대로 컨트롤러가 서비스에서 전달받은 결과를 갖는 응답을 반환하는지, 요청에 따른 컨트롤러 매핑이 잘 되는지 등 우리가 결정한 관심사인 컨트롤러 라는 하나의 부품이 문제없이 동작하는지 확인하는 것에 목적을 두었습니다.

따라서 컨트롤러를 제외한 인터셉터나 서비스와 같은 객체들은 모두 mocking 처리를 해주었습니다.

실제 코드는 다음과 같이 작성했습니다.

@ExtendWith(RestDocumentationExtension.class)
public abstract class RestDocsSupport {

    protected MockMvc mockMvc;
    protected ObjectMapper objectMapper = new ObjectMapper();
    private final AccessTokenInterceptor accessTokenInterceptor = mock(AccessTokenInterceptor.class);
    private final RefreshTokenInterceptor refreshTokenInterceptor = mock(RefreshTokenInterceptor.class);

    @BeforeEach
    void setUp(RestDocumentationContextProvider provider) throws Exception {
        this.mockMvc = MockMvcBuilders.standaloneSetup(initController())
            .setControllerAdvice(GlobalExceptionHandler.class)
            .addInterceptors(accessTokenInterceptor, refreshTokenInterceptor)
            .apply(MockMvcRestDocumentation.documentationConfiguration(provider))
            .build();

        given(accessTokenInterceptor.preHandle(any(), any(), any()))
            .willReturn(true);
        given(refreshTokenInterceptor.preHandle(any(), any(), any()))
            .willReturn(true);
    }

    protected abstract Object initController();

}

class AuthControllerTest extends RestDocsSupport {

    private final AuthService authService = mock(AuthService.class);

    @Override
    protected Object initController() {
        return new AuthController(authService);
    }

    @Test
    @DisplayName("일반 로그인 : 성공")
    void loginSuccess() throws Exception {
        // given
        LoginForm loginForm = new LoginForm("yeon@email.com", "test!1234");

        given(authService.login(any(LoginForm.class)))
            .willReturn(new AuthenticationTokenPair("accessToken", "refreshToken"));

        // when & then
        .
        .
        .

보다 더 의미있는 테스트를 위해

결과적으로 덜어낸 만큼 빠르고 직관적인 컨트롤러 단위 테스트가 되었고, 자연스럽게 컨트롤러 외의 개별 객체들도 자신의 역할을 제대로 수행하는지 검증하는 작은 단위의 테스트를 갖게 되었습니다.

그러나 주변 환경을 전부 mocking 처리함으로써, 인터셉터에서 Authorization Header 를 확인하던 과정이 생략되는 문제점을 발견하게 됩니다.

개발자가 실수로 Authorization Header 에 Bearer [token] 을 설정하지 않고 REST Docs 문서를 생성해도 오류가 발생하지 않으므로 스스로 주의해야 할 포인트가 하나 늘어나게 되었습니다.

    // header 설정 예시
    ...

    // when & then
    mockMvc.perform(post("/reissue")
        .header(HttpHeaders.AUTHORIZATION, "Bearer refreshToken"))
    .
    .
    .

이를 해결하기 위해 mocking 처리한 인터셉터에 .will() 을 사용하여 임의로 헤더를 검사하는 코드를 추가할 수 있지만, 개발자가 놓친 부분이 더 있을 가능성을 고려하여 필요한 부분만 mocking 처리하는 것을 선택했습니다.

또한 일반적으로 앞단까지 포함하여 컨트롤러의 동작을 예상하기 때문에, 실제 애플리케이션에 가까운 컨트롤러 테스트로 개선이 필요함을 고려했습니다.

이어진 마지막 시도에서는 요청이 컨트롤러에 오기까지의 과정을 하나의 단위로 설정하게 됩니다.

(3) 컨트롤러와 밀접한 환경도 고려하는게 좋겠어!

마지막 시도는, 관련된 context를 바탕으로 컨트롤러 테스트를 수행하는 보다 실용적인 단위 테스트입니다.

@WebMvcTest 의 설명을 보면, 다음의 내용을 확인할 수 있습니다.

... 'focuses only on Spring MVC componets.' ... (i.e. @Controller, @ControllerAdvice, @JsonComponent, Filter, WebMvcConfigurer and HandlerMethodArgumentResolver beans not @Component, @Service or @Repository beans.).

• Spring MVC componets 에 집중한 테스트이다.
• 테스트 관심사와 관련된 빈들만 설정할 것이다.
• 따라서 @Controller , @ControllerAdvice , @JsonComponent , Filter , WebMvcConfigurer , HandlerMethodArgumentResolver 와 같은 빈들은 등록되지만 @Component , @Service 또는 @Repository 는 등록되지 않을 것이다.

즉, 저희가 원했던 것처럼 컨트롤러와 그 앞단까지의 환경을 바탕으로 테스트를 수행할 수 있게 도와주는 설정입니다.

@WebMvcTest 를 사용하여 수정한 실제 코드는 다음과 같습니다.

@WebMvcTest(controllers = {AuthController.class, MemberController.class})
@AutoConfigureRestDocs
public abstract class RestDocsSupport {

    @Autowired
    protected MockMvc mockMvc;

    @Autowired
    protected ObjectMapper objectMapper;

    @MockBean
    protected AuthService authService;

    @MockBean
    protected AuthManager authManager;

    @MockBean
    protected TokenManager tokenManager;

    ...

    @BeforeEach
    void setUp() {
        given(tokenManager.validateRefreshToken(any()))
            .willReturn(Jwts.claims().add("id", 1L).build());
        given(tokenManager.validateAccessToken(any()))
            .willReturn(Jwts.claims().add("id", 1L).build());

        given(authManager.validateAuthorizationHeader(any()))
            .willCallRealMethod();
    }

}

참고 : 인터셉터 코드

@Component
@RequiredArgsConstructor
public class AccessTokenInterceptor implements HandlerInterceptor {

    private static final String AUTHORIZATION_HEADER = "Authorization";
    public static final String ACCOUNT_ID = "id";

    private final AuthManager authManager;
    private final TokenManager tokenManager;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {
        if (CorsUtils.isPreFlightRequest(request))
            return true;

        String authorizationHeader = request.getHeader(AUTHORIZATION_HEADER);
        String token = authManager.validateAuthorizationHeader(authorizationHeader);

        Claims claims = tokenManager.validateAccessToken(token);

        request.setAttribute(ACCOUNT_ID, claims.get(ACCOUNT_ID, Long.class));
        return true;
    }

}

인터셉터에서 tokenManager 를 사용하여 토큰을 검증하는 부분만 mocking 처리하고, 헤더를 검증하거나 request.setAttribute() 하여 resolver에게 넘겨주는 부분은 정상적으로 동작하도록 했습니다.

위와 같은 구조는 어떤 부분이 mocking 되었는지 직관적으로 알 수 있으며, 다른 동작은 모두 정상적으로 수행될 것임을 예상할 수 있다는 장점을 갖습니다.

이전에 Authorization Header 에 값을 설정하지 않거나 Bearer 에 오타가 생겨도 오류를 발생하지 않았던 문제점 또한 해결되었습니다.

최종적으로, 현재 프로젝트에서는 위와 같은 구조를 유지하며 컨트롤러 테스트를 작성하고 있습니다.

Interceptor에서 false를 반환하면?

덧붙여, 두 번째 시도에서 Authorization Header 를 검증하기 위해 임의로 will() 메서드를 사용했던 경험을 공유하고 포스팅을 마무리하려고 합니다.

해당 시점에서 모든 인터셉터를 mocking 처리하여 사용하고 있었고,

    ...

    // 수정 전 코드
    given(accessTokenInterceptor.preHandle(any(), any(), any()))
            .willReturn(true);
    given(refreshTokenInterceptor.preHandle(any(), any(), any()))
            .willReturn(true);

Authorization Header 를 검증하기 위해 코드를 수정했습니다.

    ...

    // 수정 후 코드
    given(accessTokenInterceptor.preHandle(any(HttpServletRequest.class), any(), any()))
        .will((invocation) -> {
            HttpServletRequest request = invocation.getArgument(0);
            return authManager.validateAuthorizationHeader(
            request.getHeader(HttpHeaders.AUTHORIZATION)) != null;
        });
    given(refreshTokenInterceptor.preHandle(any(HttpServletRequest.class), any(), any()))
        .will((invocation) -> {
            HttpServletRequest request = invocation.getArgument(0);
            return authManager.validateAuthorizationHeader(
            request.getHeader(HttpHeaders.AUTHORIZATION)) != null;
        });

수정한 테스트 코드를 실행하니, 해당 인터셉터를 거치는 모든 요청은 다음과 같이 응답하고 테스트가 통과되지 않았습니다.

200 OK 라고 하지만 아무 데이터가 없는 빈 성공 응답

잘못되었다는 응답이 아니므로 어디서 무엇이 제대로 동작하지 않았는지 파악하기 어려웠으나, 디버깅 결과 mocking 처리한 authManager 를 간과하고 사용한 실수가 원인이었고 authManager 는 항상 null 을 반환했던 것이었습니다.

따라서 인터셉터는 항상 false 를 반환했을텐데 우리는 왜 200 OK 라는 답변을 받았던 걸까요?

Spring 공식 문서에 따르면, preHandle() 메서드가 false 를 반환하면 DispatcherServlet 은 인터셉터가 요청을 알아서 처리한 것으로 간주한다고 합니다.

즉, DispatcherServlet 은 인터셉터에서 false 를 반환해도 요청을 알아서 처리했다고 생각했고 response 에 상태 코드를 지정해주지 않았기 때문에 기본값인 200 OK 를 응답했던 것입니다.

마무리

이로써 @SpringBootTest 를 사용한 통합 테스트에서, 서버를 올리지 않는 빠른 단위 테스트를 거쳐, @WebMvcTest 를 사용하여 관련된 context를 바탕으로 컨트롤러를 테스트하는 구조까지 오게 된 과정을 모두 소개했습니다.

더 나은 구조를 고민하면서 낯선 mocking 기술도 시도해보고, 제대로 이해하지 못했던 동작 과정을 더 살펴보게 됐던 의미있는 시간이었습니다.

긴 글 읽어주셔서 감사합니다 🙂

작성자 : 김서연

이번주 프로젝트를 진행하면서, 가장 오랜시간 고민하며 작업한 Validation 적용 과정을 블로깅하려고 합니다.

길고 투박한 검증 애노테이션 제거하기

저는 첫 번째로 검증하려는 필드위에 붙이는 @Max, @Pattern, @Size 와 같은 애노테이션을 제거하고 싶었습니다.

@NoArgsConstructor
@AllArgsConstructor
@Getter
@Setter
public class SignUpForm {

    @Pattern(regexp = "^[0-9a-z-A-z]([\-.\w]*[0-9a-zA-Z\-_+])*@([0-9a-zA-Z][\-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,9}$", message = "이메일이 양식에 맞지 않습니다." )
    @Size(max = 62, message = "이메일 길이는 62자 이하입니다.")
    private String email;

    // ...
}

컨트롤러단에서 회원가입을 위해 클라이언트가 입력한 값을 받는 DTO 클래스

일반적이고 깔끔한 Bean Validation 적용방법이지만 제가 생각한 문제점은 다음과 같습니다.

• 애노테이션 안에 하드코딩된 정보가 너무 많습니다.

• 동일한 이메일 검증을 다른 DTO에서 하게 된다면, 다시 저 긴 @Pattern 과 @Size 애노테이션을 붙여 사용해야 합니다.

public class EditUserForm {

    @Pattern(regexp = "^[0-9a-z-A-z]([\-.\w]*[0-9a-zA-Z\-_+])*@([0-9a-zA-Z][\-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,9}$", message = "이메일이 양식에 맞지 않습니다." )
    @Size(max = 62, message = "이메일 길이는 62자 이하입니다.")
    private String email;

    // ...
}

만약 유저의 이메일을 변경하기 위해 다음과 같은 DTO를 만든다고 하면, 똑같이 여러개의 애노테이션을 붙여주어야 합니다.

• 검증이 어떤 방식으로 수행되는지 설명하기 어렵습니다.

예를 들어, 다음의 정규식이 어떤식으로 만들어졌는지 최소한의 주석을 달기가 어렵습니다.

이러한 문제점이 있다고 생각하여 저는 다른 방식으로 애노테이션 검증을 수행하게 되었습니다.

Constraint Annotation 적용

Constraint Annotation 이란 직접 만든 ConstraintValidator 를 연결한 애노테이션을 의미합니다. Constraint Annotation 을 검증하고 싶은 필드위에 붙임으로써, 제가 만든 Validator 의 검증을 적용할 수 있습니다. 이를 통해 DTO 코드는 다음처럼 바뀝니다.

@NoArgsConstructor
@AllArgsConstructor
@Getter
@Setter
public class SignUpForm {

    @EmailForm
    @EmailSize
    private String email;

    @NicknameForm
    private String nickname;

    @PasswordForm
    private String password;

}

DTO 클래스

이를 통해 DTO 클래스의 불필요하게 긴 하드코딩 정보들을 제거할 수 있었습니다. Constraint Annotation 중 @EmailForm 애노테이션을 한번 살펴보겠습니다.

@Documented
@Constraint(validatedBy = EmailForm.EmailFormValidator.class)
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface EmailForm {

    String message() default "이메일이 양식에 맞지 않습니다.";

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};

    class EmailFormValidator implements ConstraintValidator<EmailForm, String> {
        private final String REGEX_EMAIL = "^[0-9a-z-A-z]([\\-.\\w]*[0-9a-zA-Z\\-_+])*" // 소문자 알파벳이나 숫자로 시작하는 local part
            + "@([0-9a-zA-Z][\\-\\w]*[0-9a-zA-Z]\\.)+[a-zA-Z]{2,9}$";    // 서브 도메인, 도메인, 최상위 도메인

        private Pattern emailRegex = Pattern.compile(REGEX_EMAIL);

        @Override
        public boolean isValid(String emailInput, ConstraintValidatorContext context) {
            return emailRegex.matcher(emailInput).matches();
        }
    }

}

@Constraint(validatedBy = EmailForm.EmailFormValidator.class)

• 연결하고 싶은 ConstraintValidator 는 다음과 같이 연결합니다.
• 저는 가독성을 위해 애노테이션 내부에 Validator 클래스를 정의하였습니다.

ConstraintAnnotation 을 정의할 때 반드시 만들어주어야 하는 것은 message, groups, payload 입니다. message 는 메시지 관리를 위해 사용하고, groups 는 Validation 그룹을 나누기 위해 사용하며, payload 는 심각도를 나타냅니다.

message 에 담고 싶은 에러 메시지를 적고, Validator 내부에서 정규식을 사용하여 이메일 양식에 대한 검증을 수행할 수 있었습니다. 또한 정규식에 대한 간략한 주석을 달 수도 있었습니다.

만약 다른 DTO에서 이메일 형식을 검증하는 애노테이션이 필요하다면, @EmailForm 을 붙여주는것만으로 충분할 것입니다.

중복 이메일과 중복 닉네임 검증하기

사용자가 회원가입을 하는데, 이미 존재하는 이메일이거나 이미 존재하는 닉네임을 사용하려 한다면, 이를 막는것도 검증의 역할입니다. 이전에 수행한 프로젝트에서는 중복을 검사하는 검증, 즉 DB를 사용해야 하는 검증은 서비스 계층에서 수행하였습니다.

Service 메서드1 (DTO dto) {
    Repository.existsByXXX(dto.getXXX())
        .orElseThrow(예외);    // 검증 로직

    // 비즈니스 로직 ...
}

Service 메서드2 (DTO dto) {
    Repository.existsByXXX(dto.getXXX())
        .orElseThrow(예외);    // 검증 로직 중복!!

    // 비즈니스 로직 ...
}

대략적인 검증 형태

그러나 이렇게 중복 검증을 수행하게 되면 중복 검증이 필요한 모든 메서드가 검증 로직을 사용하게 되므로 지저분하고 불필요한 코드 중복이 발생하게 됩니다. 가급적이면 메서드내에서 비즈니스 로직만 수행하는 것이 보기도 좋고, 코드 중복도 제거할 수 있지 않을까 생각하여 중복검증을 수행하는 Constraint Annotation 을 만들어 DTO에 붙이기로 합니다.

@NoArgsConstructor
@AllArgsConstructor
@Getter
@Setter
public class SignUpForm {

    @EmailForm
    @EmailSize
    @EmailDuplicateCheck
    private String email;

    @NicknameForm
    @NicknameDuplicateCheck
    private String nickname;

    @PasswordForm
    private String password;

}

DTO 클래스에 중복 검증을 위한 애노테이션 @EmailDuplicateCheck, @NicknameDuplicateCheck 을 추가

이메일 중복 검사를 수행하는 @EmailDuplicateCheck 애노테이션의 코드는 다음과 같습니다.

@Documented
@Constraint(validatedBy = EmailDuplicateCheck.EmailDuplicateValidator.class)
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface EmailDuplicateCheck {

    String message() default "이미 존재하는 이메일입니다.";

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};

    class EmailDuplicateValidator implements ConstraintValidator<EmailDuplicateCheck, String> {
        private MemberRepository memberRepository;
        private AES256Manager aes256Manager;

        @Autowired
        public void setMemberRepository(MemberRepository memberRepository, AES256Manager aes256Manager) {
            this.memberRepository = memberRepository;
            this.aes256Manager = aes256Manager;
        }

        @Override
        public boolean isValid(String emailInput, ConstraintValidatorContext context) {
            String encryptedEmailInput = aes256Manager.encrypt(emailInput);
            return !memberRepository.existsByEmail(encryptedEmailInput);
        }

    }

}

• ConstraintValidator 는 기본생성자가 있어야 하므로, 필요한 의존성은 setter 주입하였습니다.

다음과 같이 DB를 사용하는 Validator 를 만듦으로써 컨트롤러 계층에서 클라이언트 입력값에 대한 모든 검증을 끝낸 DTO를 순수하게 사용할 수 있게 되었습니다.

하지만 이 방식에도 문제점은 있었습니다. 이메일 검증을 할 때 사용자가 정규식을 위반하는 불가능한 이메일을 입력하였다면, 굳이 DB를 거치는 비싼 검증을 수행할 필요가 있을까요? 저는 정규식이나 길이제한을 위반하는 이메일은 DB를 거치는 중복 검증을 수행하지 않아도 된다 생각하여, 정규식이나 길이제한 검증을 통과한 경우에만 DB를 거치는 중복 검증을 수행하도록 하고 싶었습니다.

Validator 순서 적용하기

앞서 말한 문제점을 해결하기 위해 검증 애노테이션의 순서를 적용하였습니다. 검증 애노테이션의 순서를 적용하는 방법은 그룹과 @GroupSequence 를 사용하는 것입니다.

우선적으로 그룹을 만듭니다.

public interface DBUsing {
}

DB를 사용하는 그룹

그 다음엔 DTO에 DB를 사용하는 검증 애노테이션에 앞서 만든 그룹을 설정해주고, 클래스 레벨에 @GroupSequence 를 적용해, 검증 순서를 정하면 됩니다.

@GroupSequence({SignUpForm.class, DBUsing.class})
@NoArgsConstructor
@AllArgsConstructor
@Getter
@Setter
public class SignUpForm {

    @EmailForm
    @EmailSize
    @EmailDuplicateCheck(groups = DBUsing.class)
    private String email;

    @NicknameForm
    @NicknameDuplicateCheck(groups = DBUsing.class)
    private String nickname;

    @PasswordForm
    private String password;

}

다음의 설정으로 아무런 그룹도 아닌 검증 애노테이션, 즉 DB를 사용하지 않는 검증이 먼저 수행되고, 이전 검증이 성공한 경우에만 DB를 사용하는 검증을 수행하게 됩니다.

그러나 이 구조에 대해서도 마음에 들지 않는 점이 있었습니다. 바로 (groups = DBUsing.class) 를 직접 넣어주어야 된다는 점입니다. 만약 엄청나게 많은 DB 검증 애노테이션이 프로젝트에 전역적으로 있다면 관리가 수월하지 않을 것입니다.

이를 해결할 수 있을까 많은 고민을 하였습니다. 제가 시도했던 접근 방법은 DB 검증을 수행하는 Constraint Annotation 의 그룹에 DBUsing.class 를 미리 넣는 것입니다. 이렇게 하면 DTO 클래스에 직접 명시하지 않아도 되겠다고 생각했습니다.

@Documented
@Constraint(validatedBy = EmailDuplicateCheck.EmailDuplicateValidator.class)
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface EmailDuplicateCheck {

    String message() default "이미 존재하는 이메일입니다.";

    Class<?>[] groups() default {DBUsing.class};

    Class<? extends Payload>[] payload() default {};

    // ...

}

그러나 이 방법은 문제에 봉착하게 됩니다.

jakarta.validation.ConstraintDefinitionException: HV000077: site.onandoff.member.validator.EmailDuplicateCheck contains Constraint annotation, but the groups parameter default value is not the empty array.

Constraint Annotation 은 group 을 empty array 로 설정해야 합니다! 전 세계의 코드를 뒤져봐도 Class<?>[] groups() default {} 를 설정한 코드를 못봤는데, groups 를 설정한 코드가 없었던건, Constraint Annotation 이 group을 설정해선 안되기 때문이었습니다.

그래서 결국 울며 겨자먹기로 group 을 명시해주는 구조를 유지하게 됩니다.

그러나 또 한가지의 문제에 봉착합니다. 바로 테스트코드 작성의 어려움입니다. 저희 프로젝트에선 컨트롤러 테스트는 RestDocsSupport 클래스를 상속받아, 하나로 통합된 테스트 환경으로 수행합니다. 또한 테스트 환경은 standaloneSetup 설정으로 필요한 의존성은 initController() 메서드를 통해, 실제 테스트코드에서 컨트롤러를 주입합니다

@ExtendWith(RestDocumentationExtension.class)
public abstract class RestDocsSupport {

    protected MockMvc mockMvc;
    protected ObjectMapper objectMapper = new ObjectMapper();
    private final AccessTokenInterceptor accessTokenInterceptor = mock(AccessTokenInterceptor.class);
    private final RefreshTokenInterceptor refreshTokenInterceptor = mock(RefreshTokenInterceptor.class);

    @BeforeEach
    void setUp(RestDocumentationContextProvider provider) throws Exception {
        this.mockMvc = MockMvcBuilders.standaloneSetup(initController())
            .setControllerAdvice(GlobalExceptionHandler.class)
            .addInterceptors(accessTokenInterceptor, refreshTokenInterceptor)
            .apply(MockMvcRestDocumentation.documentationConfiguration(provider))
            .build();

        given(accessTokenInterceptor.preHandle(any(), any(), any()))
            .willReturn(true);
        given(refreshTokenInterceptor.preHandle(any(), any(), any()))
            .willReturn(true);
    }

    protected abstract Object initController();

}

컨트롤러 테스트 통합 환경

따라서 테스트코드는 다음과 같이 작성할 수 있습니다.

class MemberControllerTest extends RestDocsSupport {

    private final MemberService memberService = mock(MemberService.class);

    @Override
    protected Object initController() {
        return new MemberController(memberService);
    }

    @Test
    @DisplayName("회원가입 성공 시, Redirect URL 과 회원이 DB에 저장될때의 pk값을 반환한다.")
    void signUpSuccess() throws Exception {
        // given
        SignUpForm signUpForm = new SignUpForm("ghkdgus29@naver.com", "hyun", "1234567a!");

        given(memberService.signUp(any(SignUpForm.class)))
            .willReturn(new SignUpSuccessResponse(1L));

        // when & then
        mockMvc.perform(post("/members")
                .content(objectMapper.writeValueAsString(signUpForm))
                .contentType(MediaType.APPLICATION_JSON))
            .andDo(print())
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.data.redirectURL").value("https://on-and-off.site"))
            .andExpect(jsonPath("$.data.savedMemberId").value(1))
            .andDo(document("signup-success",
                preprocessRequest(prettyPrint()),
                preprocessResponse(prettyPrint()),
                requestFields(
                    fieldWithPath("email").type(JsonFieldType.STRING).description("이메일"),
                    fieldWithPath("nickname").type(JsonFieldType.STRING).description("닉네임"),
                    fieldWithPath("password").type(JsonFieldType.STRING).description("비밀번호")
                ),
                responseFields(
                    fieldWithPath("code").type(JsonFieldType.NUMBER).description("코드"),
                    fieldWithPath("status").type(JsonFieldType.STRING).description("상태"),
                    fieldWithPath("message").type(JsonFieldType.STRING).description("메시지"),
                    fieldWithPath("data").type(JsonFieldType.OBJECT).description("응답 데이터"),
                    fieldWithPath("data.redirectURL").type(JsonFieldType.STRING).description("리디렉션 URL"),
                    fieldWithPath("data.savedMemberId").type(JsonFieldType.NUMBER).description("유저 PK")
                )
            ));
    }
}

서비스의 동작을 mocking 하면서 잘 실행될 줄 알았던 테스트코드에 큰 문제가 발생합니다. 바로 NullPointerException 입니다.

왜 이런 문제가 발생할까요? 컨트롤러 계층의 테스트코드이기 때문에, Service 까지는 mocking 해서 주입하지만 Repository 까지는 mocking 하지 않기 때문입니다. DB 검증을 수행하는 ConstraintValidator 는 MemberRepository 가 필요한데, 주입해주지 않았으니 NullPointerException 이 발생합니다.

어떻게 해결해야 할 지 고민을 많이 했습니다. 이쯤되는 트러블 슈팅은 자료도 별로 없고, Validator 를 일일히 mocking 하자니 RestDocsSupport 를 상속받는 다른 컨트롤러 테스트에서도 테스트와 관련없는 Validator 를 mocking 해주어야 하니 복잡도가 올라가고, 가독성이 떨어지게 됩니다. 또한 Validator 를 mocking 하지 않고, 컨트롤러 테스트에서 자연스럽게 사용하는것이 더 좋다고 생각하기 때문에 저의 고민은 깊어져만 갔습니다.

고민하다 정신을 거의 잃기 직전에 옛 (프로그래밍) 선인들의 말씀이 떠올랐습니다. 테스트 코드를 짜기 어렵다면 그것은 리팩터링의 신호이다.

이 구조가 잘못되었기 때문에 테스트 코드 작성이 어려운것은 아닐까 생각이 들었습니다. 따라서 검증 로직의 구조를 변경합니다.

컨트롤러에서 할 검증과 서비스에서 할 검증을 나누자

이전 구조에서 발생하는 2가지 문제는 다음과 같습니다.

• 검증 순서를 정하기 위해 group 정보를 하드코딩해야 한다.

• 컨트롤러 테스트 코드에서 리포지토리에 대한 의존성이 필요해진다.

이를 해결하기 위해 제가 선택한 방법은 책임 분리입니다.

컨트롤러 계층의 DTO 가 검증해야 할 내용은 사용자의 입력이 정규식을 만족하는지, 길이제한을 만족하는지만 검사합니다. 따라서 컨트롤러 계층에서 서비스 계층으로 넘겨주는 DTO는 위 검증을 통과해야만 합니다.

서비스 계층의 DTO가 검증해야 할 내용은 사용자의 입력이 DB에 이미 존재하는 중복된 값이 아닌지 중복 검증을 수행합니다. 이를 통해 이전 구조에서 발생하는 2가지 문제를 모두 해결할 수 있습니다.

@NoArgsConstructor
@AllArgsConstructor
@Getter
@Setter
public class SignUpForm {

    @EmailForm
    @EmailSize
    private String email;

    @NicknameForm
    private String nickname;

    @PasswordForm
    private String password;

    public UniqueSignUpForm toUnique() {
        return new UniqueSignUpForm(email, nickname, password);
    }

}

컨트롤러 계층에서 사용하는 DTO는 글자수, 정규식 만족 여부만 검증합니다.

@RestController
@RequiredArgsConstructor
public class MemberController {

    private final MemberService memberService;

    @PostMapping("/members")
    public ApiResponse<SignUpSuccessResponse> signUp(@RequestBody @Valid SignUpForm signUpForm) {
        SignUpSuccessResponse signUpSuccessResponse = memberService.signUp(signUpForm.toUnique());

        return ApiResponse.ok(ResponseMessage.SIGNUP_SUCCESS.getMessage(), signUpSuccessResponse);
    }

}

컨트롤러 계층에서 검증이 완료된 DTO는, 서비스 계층용 DTO 로 변환하여 넘겨줍니다.

@AllArgsConstructor
@Getter
public class UniqueSignUpForm {

    @EmailDuplicateCheck
    private String email;

    @NicknameDuplicateCheck
    private String nickname;

    private String password;

}

서비스 계층용 DTO에서 DB를 사용하는 중복 검사를 수행합니다.

@Service
@Transactional(readOnly = true)
@Validated
@RequiredArgsConstructor
public class MemberService {

    @Transactional
    public SignUpSuccessResponse signUp(@Valid UniqueSignUpForm signUpForm) {

        // 비즈니스 로직 ...
    }
}

• 서비스 계층에서 @Valid 를 하는 경우, 클래스 레벨에 @Validated 를 붙여주어야 합니다.

• @Transactional 과 유사하게 스프링 AOP 기반으로 검증 로직이 적용됩니다.
• 프로그래머는 이미 중복검증이 끝난 DTO를 가지고 비즈니스 로직에만 집중할 수 있습니다.

이때 서비스 계층에서 검증을 실패할 때 발생하는 예외는 MethodArgumentNotValidException 이 아닙니다. 해당 예외는 컨트롤러 계층에서 검증을 만족하지 못했을 때 ArgumentResolver에 의해 발생하는 예외입니다. 서비스 계층에서 발생하는 예외는 ConstraintViolationException 이므로 이를 숙지하고 GlobalExceptionHandler 를 작성하였습니다.

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(ConstraintViolationException.class)
    public ApiResponse<Object> handleConstraintViolationException(ConstraintViolationException exception) {
        return ApiResponse.of(HttpStatus.BAD_REQUEST, null,
            exception.getConstraintViolations().stream()
                .collect(Collectors.groupingBy(v -> parseFieldNameFrom(v.getPropertyPath())))
                .entrySet().stream()
                .map(error -> {
                    Map<String, Object> fieldError = new HashMap<>();
                    fieldError.put("field", error.getKey());
                    fieldError.put("message", error.getValue().stream()
                        .map(ConstraintViolation::getMessage)
                        .collect(Collectors.joining(", ")));
                    return fieldError;
                })
        );
    }

    private String parseFieldNameFrom(Path propertyPath) {
        String[] splitPath = propertyPath.toString().split("\\.");
        return splitPath[splitPath.length - 1];
    }

    // ...

}

이전에 작성에 실패하였던 컨트롤러 테스트 코드의 경우, 서비스 계층에서 ConstraintViolationException 을 던져주도록 mocking 하면 컨트롤러 테스트 코드를 작성할 수 있습니다. 이때 ConstraintViolationException 을 mocking 하는 과정이 다소 복잡하긴 하지만, 서비스 계층의 실패를 테스트하고 싶은 테스트 메서드에서만 복잡한 mocking 을 해주면 됩니다.

class MemberControllerTest extends RestDocsSupport {

    private final MemberService memberService = mock(MemberService.class);

    @Override
    protected Object initController() {
        return new MemberController(memberService);
    }

    @Test
    @DisplayName("회원가입 입력폼의 닉네임이나 이메일이 중복되어 회원가입 실패 시, 400 Bad Request를 반환하며, data엔 어떤 필드에서 실패하였는지 에러 메시지와 함께 응답한다.")
    void uniqueSignUpFail() throws Exception {
        // given
        SignUpForm signUpForm = new SignUpForm("ghkdgus29@naver.com", "hyun", "1234567a!");

        ConstraintViolationException exception = mock(ConstraintViolationException.class);
        Set<ConstraintViolation<?>> violations = new HashSet<>();
        ConstraintViolation mockedViolation = mock(ConstraintViolation.class);
        violations.add(mockedViolation);

        given(mockedViolation.getPropertyPath()).willReturn(PathImpl.createPathFromString("signUp.signUpForm.email"));
        given(mockedViolation.getMessage()).willReturn("이미 존재하는 이메일입니다.");
        given(exception.getConstraintViolations()).willReturn(violations);
        given(memberService.signUp(any(UniqueSignUpForm.class)))
            .willThrow(exception);

        // when & then
        mockMvc.perform(post("/members")
                .content(objectMapper.writeValueAsString(signUpForm))
                .contentType(MediaType.APPLICATION_JSON))
            .andDo(print())
            .andExpect(status().isBadRequest())
            .andDo(document("unique-signup-fail",
                preprocessRequest(prettyPrint()),
                preprocessResponse(prettyPrint()),
                requestFields(
                    fieldWithPath("email").type(JsonFieldType.STRING).description("이메일"),
                    fieldWithPath("nickname").type(JsonFieldType.STRING).description("닉네임"),
                    fieldWithPath("password").type(JsonFieldType.STRING).description("비밀번호")
                ),
                responseFields(
                    fieldWithPath("code").type(JsonFieldType.NUMBER).description("코드"),
                    fieldWithPath("status").type(JsonFieldType.STRING).description("상태"),
                    fieldWithPath("message").type(JsonFieldType.NULL).description("메시지"),
                    fieldWithPath("data[]").type(JsonFieldType.ARRAY).description("응답 데이터"),
                    fieldWithPath("data[].field").type(JsonFieldType.STRING).description("잘못 입력한 필드"),
                    fieldWithPath("data[].message").type(JsonFieldType.STRING).description("에러 발생 이유")
                )
            ));
    }

}

ConstraintViolationExceptionHandler 에서 사용하는 메서드들을 mocking 합니다.

ConstraintViolationExceptionHandler 에서 사용하는 메서드들은 다음과 같습니다. ConstraintException

• getConstraintViolations() ➔ Set<ConstraintViolation<?>> violations

ConstraintViolation

• getPropertyPath() ➔ Path 인터페이스의 구현체, PathImpl 의 정적 메서드를 사용하여 만들었습니다.

• getMessage() ➔ 에러 메시지

회고

이전의 프로젝트에선 크게 고민하지 않고 관성적으로 검증을 수행하였습니다. 이번 프로젝트에서는 더 좋은 구조가 무엇일까 고민하면서 검증 로직을 구성하였는데, 시간은 굉장히 많이 걸렸지만 배워간 것이 많아 좋았습니다.

참고

스프링 Custom Bean Validation 만들어서 사용해보기
Java Bean Validation 제대로 알고 쓰자
[Spring] @Valid와 @Validated를 이용한 유효성 검증의 동작 원리 및 사용법 예시
Bean Validation: How can I manually create a ConstraintViolation?
How to write Unit Test for below Exception Handler method using mockito?