treecode

[스프링] Json 데이터 역직렬화 (ObjectMapper @JsonDeserializer)

tree code — Wed, 1 May 2024 16:06:06 +0900

지도 기반 프로젝트를 진행하면서 RestClient를 사용해서 카카오맵 API를 통해 리버스 지오코딩을 하고 있다.

지오코딩(geocoding)은 주소를 좌표로 변환하는 작업, 리버스 지오코딩은 반대로 좌표를 주소로 변환하는 것을 말한다.

카카오맵 API는 기본적으로 Json 형식으로 응답을 하는데 응답받은 데이터를 사용하기 위해 역직렬화하여 객체로 변환하는 작업이 필요하며 이를 위해 JsonDeserializer를 사용해보았다.

먼저 스프링에서 HTTP RequestBody, ResponseBody의 데이터를 직렬화, 역직렬화하는 기능은 메시지 컨버터가 처리한다.

아래 공식 문서 내용을 보면 RestClient를 builder()로 생성할 수 있고, 메시지 컨버터를 포함한 여러 설정을 할 수 있다.

스프링에서 제공하는 메시지 컨버터 인터페이스 HttpMessageConverter는 클라이언트 사이드(ex. RestClient)와 서버 사이드(ex. RestController)에서 HTTP 요청, 응답의 body를 읽고 쓰는 역할을 하며 다양한 구현체들이 있다.

RestClient는 기본적으로 등록되어있는 메시지 컨버터를 사용하고 추가로 확장할 수도 있다. 등록된 메시지 컨버터 중에 canRead()를 통해 변환이 가능한 컨버터를 찾아서 처리를 한다.

MappingJackson2MessageConverter는 기본적으로 내장된 컨버터로 json 데이터를 변환하는 작업을 해주며 내부적으로 ObjectMapper(Jackson 라이브러리)를 사용한다. ObjectMapper도 canDeserialize()를 통해 deserialize가 가능한지를 체크한다.

카카오맵 API의 Json 응답 예시를 보면 SnakeCase 표기법으로 되어 있는데 기본적으로는 CamelCase 표기법으로 읽기 때문에ObjectMapper에 별도로 setPropertyNamingStrategy()로 설정을 해줘야 한다.

Jackson 라이브러리는 이러한 설정을 간편하게 할 수 있도록 @JsonNaming과 같은 애노테이션을 지원해준다.

ObjectMapepr는 직렬화시 Getter가 있어야 하고 역직렬화 시 기본 생성자와 Setter가 있어야 하는 등의 조건이 있는데(필수는 아니지만) Jackson 2.12 버전부터 Record 타입을 지원해 주면서 편하게 불변으로 사용할 수 있다.

이런 식으로 key-value에 맞춰서 클래스를 생성해 주면 되는데 depth가 깊어지면 복잡해지기 때문에 JsonDeserializer를 구현해서 직접 역직렬화를 해줄 수 있다. JsonDeserializer를 extends하고 deserialize()을 Override해준다.

jsonParser.getCode()을 통해 ObjectCodec(ObjectMapper 부모 클래스)의 readTree()를 호출하면 트리 구조의 JsonNode를 받을 수 있다. (해당 노드는 Json 데이터를 파싱한 것이다)

_children은 Json 각 객체({}) 내부 key-value를 LinkedHashMap으로 관리하기 때문에 순서를 보장해 주며 같은 depth에 같은 key가 여러 개면 마지막 key만 담긴다.

findValue()는 특정 key의 value를 찾아서 가장 먼저 나오는 결과를 반환해 주는 메서드로 결과가 없으면 null을 반환한다.

하위 _children의 entry를 반복문으로 도는데 각각의 entry를 재귀 호출하기 때문에 depth 우선이 아닌 객체({}) 기준으로 가장 먼저 나오는 key의 value를 반환한다.

내 경우에는 가장 상단에 있는 값이 필요해서 findValue()를 사용했다.

마지막으로 위에서 구현한 JsonDeserializer를 필요한 클래스에 애노테이션으로 선언해 주면 된다.

이렇게 @JsonDeserialize 애노테이션을 선언해주면 MappingJackson2HttpMessageConverter에서 내부적으로 @JsonDeserialize 애노테이션을 찾아서 적용을 해준다.

[참고]

Jackson 라이브러리 기본기능 정리 - json 직렬화와 역직렬화

Jackson Annotation 예제 본 글은 다음 원문을 번역 및 수정한 글입니다. https://www.baeldung.com/jackson-annotations 전체 코드는 다음 레파지토리에 있습니다. 필요하다면 클론 받으셔서 test 패키지에 있는 Jack

pjh3749.tistory.com

Jackson Release 2.12

Main Portal page for the Jackson project. Contribute to FasterXML/jackson development by creating an account on GitHub.

github.com

Jackson Deserializer 코드 분석해보기 | 카카오페이 기술 블로그

Json 공백 문자 제거 및 파싱을 개발하면서 Jackson Deserializer 코드를 분석해봅니다.

tech.kakaopay.com

[Spring] 좋아요 개수 동시성 문제 해결 (Optimistic Lock, Spring AOP)

tree code — Tue, 19 Mar 2024 21:09:23 +0900

좋아요 기능의 동시성 문제를 낙관적 락(Optimistic Lock)과 Retry를 통해 해결하고 개선하는 과정을 정리해 보았다.

현재 진행 중인 프로젝트에는 방명록(Post)에 좋아요를 누를 수 있고 Post 목록 조회 시 좋아요 개수를 같이 보여주고 있다.

Post 목록 조회 시마다 방명록 좋아요 테이블을 join해서 좋아요 개수를 계산하는 것은 비효율적이라고 판단해서 반정규화로 Post에 별도의 likeCount 칼럼을 추가했다.

하지만 여러 사용자가 동시에 좋아요를 누를 경우 likeCount를 update 하면서 lost update 문제가 발생할 수 있다. 예를 들어 방명록의 좋아요가 5개에서 두 유저가 좋아요를 누르면 7개가 되어야 한다. 그런데 두 유저가 동시에 좋아요를 누르고 각각 조회 시점에 좋아요 개수가 5개로 보이면 둘 다 6으로 업데이트를 하게 된다. (업데이트를 어떻게 하냐에 따라 다르지만..)

이러한 문제를 해결하기 위해 낙관적 락(Optimistic Lock), 비관적 락(Pessimistic Lock)을 사용해 볼 수 있다.

낙관적 락은 충돌이 많이 발생하지 않는다고 가정하고 애플리케이션 레벨에서 락을 거는 방식이다.

비관적 락은 충돌이 많이 발생한다고 가정하고 DB에서 락을 거는 방식이다.

DB에서 락을 거는 방식은 레코드를 SELECT로 읽으면서 FOR SHARE, FOR UPDATE를 사용하면 직접 잠금을 걸 수 있다.

(select .. from .. where .. for share)

FOR SHARE는 읽기 잠금(공유 잠금, Shared lock)으로 다른 세션에서 해당 레코드를 읽는 것은 가능하고 변경할 수 없게 한다.
FOR UPDATE는 쓰기 잠금(배타 잠금, Exclusive lock)으로 다른 트랜잭션에서 그 레코드를 변경하는 것뿐만 아니라 읽기(FOR SHARE 절을 사용하는 SELECT 쿼리)도 사용할 수 없다.

참고로 InnoDB 스토리지 엔진의 경우 MVCC(Multi Version Concurrency Control)를 통해 잠금 없는 읽기(Non Locking Consistent Read)를 지원하기 때문에 단순 SELECT문은 아무런 대기 없이 실행된다.

비관적 락은 높은 데이터 무결성을 보장하고 충돌이 많이 발생하는 경우 낙관적 락보다 효율적일 수 있지만 일반적으로 DB에 락을 걸기 때문에 동시 처리 성능이 떨어지고 데드락 위험이 있다. 좋아요 기능에 비관적 락을 거는 것은 성능면에서도 적절하지 않은 것 같고 현재 상황에서 충돌이 거의 발생하지 않는다고 판단해서 낙관적 락을 사용하기로 했다.

낙관적 락은 애플리케이션에서 락을 거는 방식으로 JPA는 @Version 애노테이션으로 version 칼럼을 통해 버전을 관리할 수 있다.

version 자료형으로는 Integer(int), Long(long) , Short(short) , timestamp가 있다.

@Getter
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Post extends BaseEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Long likeCount;

    @Version
    private Integer version;
}

방명록 좋아요 로직은 아래와 같이 작성했다. 방명록의 likeCount는 JPA의 변경 감지(dirty checking)으로 update 한다.

@Transactional
public void likePost(Long postId, Long userId) {
    final User user = findLoginUser(userId);
    final Post post = findPost(postId);
    if (postQueryRepository.existsPostLike(post, user)) {
        throw new ApiException(PostErrorCode.ALREADY_LIKE);
    }
    final PostLike postLike = post.likeFrom(user);
    postLikeRepository.save(postLike);
}

락 모드는 LockModeType로 설정할 수 있는데 version이 있는 Entity는 락 옵션을 적용하지 않아도 기본적으로 낙관적 락을 사용한다.

NONE
- 조회한 엔티티를 수정할 때 다른 트랜잭션에 의해 변경(삭제)되지 않아야 한다. 엔티티를 수정할 때 version을 체크하면서 version을 증가시킨다. 만약 version 값이 다르면 예외가 발생한다.
- update에 성공한 thread(pool-4-thread-2)은 추가 쿼리가 발생하지 않았다. 반면 update에 실패한 thread(pool-4-thread-1)은 select 쿼리를 한번 더 날리는 것으로 봐서 updated row가 없으면 select 쿼리로 조회해보고 예외를 던지는 것 같다.

OPTIMISTIC
- 엔티티를 조회만 해도 버전을 체크해서 한 번 조회한 엔티티는 트랜잭션을 종료할 때까지 다른 트랜잭션에서 변경하지 않음을 보장한다.
- 트랜잭션을 커밋할 때 update와 상관없이 version을 조회해서 현재 엔티티의 버전과 같은지 체크한다.
- 만약 version이 바뀌어 update에 실패하면 NONE인 경우랑 마찬가지로 version 조회 대신 엔티티를 조회해 보고 예외를 던진다.

OPTIMISTIC_FORCE_INCREMENT
- 엔티티를 수정하지 않아도 version을 증가시키고, 엔티티를 수정하면 version이 2번 나타날 수 있다.

Optimistic Lock 예외 상황을 테스트해보았다. CountDownLatch를 사용해서 첫 번째 Thread를 작업 중간에 wait 시키고, 두번째 Thread가 version을 update 시킨다. 그러면 첫번째 Thread는 바뀐 version으로 인해 update에 실패하고 예외가 발생한다.

var waitingLatch = new CountDownLatch(1);
// 낙관적 락 version이 업데이트가 될때까지 대기
var waitWorker = CompletableFuture.runAsync(() -> waitPostLikeAndNoRetry(post, likeFailUser, waitingLatch));
// 낙관적 락 version을 업데이트하고 countDown
CompletableFuture.runAsync(() -> postService.likePost(post.getId(), likeSuccessUser.getId()))
    .thenRun(waitingLatch::countDown);
// 두번째 작업의 완료로 인해 version이 변경 되어 OptimisticLockingFailureException 예외 발생
assertThatThrownBy(waitWorker::join)
    .extracting("cause")
    .isInstanceOf(OptimisticLockingFailureException.class);

Hibernate에서 발생한 StaleObjectStateException 예외를 스프링에서 OptimisticLockingFailureException으로 감싸서 던진다.

Optimistic Lock 예외를 클라이언트한테 에러로 응답해 주면 클라이언트는 매우 불편할 것이다. 그래서 Optimistic 예외 발생 시 재시도를 위해 스프링 AOP로 Retry를 추가해 줬다.

AOP란?

애플리케이션 로직은 크게 핵심 기능과 부가 기능으로 나눌 수 있는데 부가 기능은 핵심 기능을 보조하기 위해 제공되는 기능이다.
여기서 핵심 기능은 좋아요 기능이고 부가 기능은 재시도 기능이 되겠다. 좋아요를 처리하는 로직 외에 예외를 try-catch 해서 재시도하는 로직이 들어가면 가독성도 떨어지고 다른 기능에서도 재시도가 필요한 경우 거의 동일한 로직을 사용한다.
AOP(Aspect-Oriented Programming)은 관점 지향 프로그래밍으로, Aspect는 부가 기능과 해당 부과 기능을 어디에 적용할지 선택하는 기능을 하나의 모듈로 만든 것이며 핵심 기능에서 부가 기능을 분리하기 위해 나온 것이다.
애플리케이션을 바라보는 관점을 하나하나의 기능에서 횡단 관심사(cross-cutting-concerns) 관점으로 보면 여러 모듈에서 공통적으로 사용되는 부가 기능들이 있을 것이다.

스프링 AOP는 프록시를 통해 AOP를 적용하는데 메서드에만 적용할 수 있는 등의 한계와 주의점들이 있지만 비교적 간단하고 유연하게 AOP를 적용할 수 있다.

AOP 간단 용어

조인 포인트(Join point)
- 추상적인 개념으로 AOP를 적용할 수 있는 지점
- 스프링 AOP는 프록시 방식의 한계로 조인 포인트가 메소드 지점으로 제한된다.

포인트컷(Pointcut)
- 어디에 부가 기능을 적용할지, 적용하지 않을지 판단하는 필터링 로직이다.
- 주로 AspectJ 표현식, 애노테이션으로 지정
어드바이스(Advice)
- 프록시가 호출하는 부가 기능, 즉 프록시 로직
애스펙트(Aspect)
- Advice + Pointcut를 모듈화 한 것
- 여러 Advice와 Pointcut이 함께 존재
어드바이저(Advisor)
- 하나의 Advice와 Pointcut으로 구성
- 스프링 AOP에서만 사용되는 용어

스프링 AOP 라이브러리를 추가하면 AnnotationAwareAspectJAutoProxyCreator 라는 빈 후처리기(BeanPostProcessor)가 스프링 빈에 자동으로 등록된다. (BeanPostProcessor는 스프링이 객체를 생성하여 Bean 저장소에 등록하기 전에 조작하기 위해 사용한다.)

AnnotationAwareAspectJAutoProxyCreator는 스프링 빈으로 등록된 Advisor들을 자동으로 찾아서 프록시가 필요한 곳에 자동으로 프록시를 적용, @AspectJ 와 관련된 AOP 기능도 자동으로 찾아서 처리한다.

스프링이 bean 대상이 되는 객체를 생성해서 AnnotationAwareAspectJAutoProxyCreator에 전달하면 스프링 컨테이너에서 모든 Advisor를 조회해서 Pointcut을 통해 프록시 적용 대상인지를 판단하고 프록시 적용 대상이라면 프록시를 생성하고 반환해서 프록시를 스프링 빈으로 등록한다. @Aspect 애노테이션을 찾아서 Advisor로 변환해서 저장하는 기능도 한다.

BeanFactoryAspectJAdvisorBuilder는 내부 저장소에 @Aspect 정보를 기반으로 생성된 Advisor를 캐시 한다. 캐시에 어드바이저가 이미 만들어져 있는 경우 캐시에 저장된 어드바이저 반환한다.

Advice 종류

@Around : 메서드 호출 전후 수행, JoinPoint 실행 여부 선택, 반환 값 변환, 예외 변환 등이 가능
@Before: JoinPoint 실행 이전에 실행
@AfterReturning : JoinPoint 정상 완료 후 실행
@AfterThrowing : 메서드가 예외를 던지는 경우 실행
@After : JoinPoint가 정상 또는 예외에 관계없이 실행

Retry 로직은 다음과 같이 추가했다. Advisor는 기본적으로 순서를 보장하지 않아서 필요시 Order 애노테이션으로 순서를 적용해줘야 한다. (클래스 단위로 적용)

@Transactional은 @EnableTransactionManagement를 보면 Order가 가장 낮은 순위로 되어있다.

Order를 지정해주지 않으면 Transactional이 Retry보다 먼저 실행되는 경우 변경 감지가 커밋 시점에 발생하기 때문에 변경 감지 update 쿼리가 나가기 전에 retry 로직이 성공으로 return 되고OptimisticLockingFaulureExceptuon을 catch 할 수 없다.

Retry를 통해 정상적으로 좋아요가 처리되는 테스트를 해보았다.

//given
final ExecutorService executorService = Executors.newFixedThreadPool(postLikeCount);
final CountDownLatch completeLatch = new CountDownLatch(postLikeCount);
//when
users.forEach(user -> executorService.submit(() -> {
    postService.likePost(post.getId(), user.getId());
    completeLatch.countDown();
}));
completeLatch.await();
//then
assertThat(postRepository.findById(post.getId()))
    .isPresent().get()
    .satisfies(updatedPost -> assertThat(updatedPost.getLikeCount()).isEqualTo(postLikeCount));

추가로 낙관적 락을 사용할 때 외래키가 있으면 데드락(DeadLock)으로 인해 CannotAcquireLockException 예외가 발생할 수 있다.

show engine innodb status; 로 데드락 체크를 해보면 아래와 같다.(최대한 생략시킨 결과)

------------------------
LATEST DETECTED DEADLOCK
------------------------
*** (1) TRANSACTION:
TRANSACTION 1068786, ACTIVE 0 sec starting index read

*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 36000 page no 4 n bits 72
index PRIMARY of table `photospot`.`post`
trx id 1068786 lock mode S locks rec but not gap

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 36000 page no 4 n bits 72
index PRIMARY of table `photospot`.`post` trx id 1068786
lock_mode X locks rec but not gap waiting

*** (2) TRANSACTION:
TRANSACTION 1068787, ACTIVE 0 sec starting index read

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 36000 page no 4 n bits 72
index PRIMARY of table `photospot`.`post`
trx id 1068787 lock mode S locks rec but not gap

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 36000 page no 4 n bits 72
index PRIMARY of table `photospot`.`post` trx id 1068787
lock_mode X locks rec but not gap waiting

*** WE ROLL BACK TRANSACTION (2)

(참고로 InnoDB는 인덱스의 레코드에 대해 락을 건다.)

트랜잭션 1, 2가 post 테이블의 primary index에 대한 S-Lock을 점유하고 있는 상태에서 X-lock을 대기하면서 결국 하나의 트랜잭션이 롤백되었다.

PostLike 테이블은 Post의 PK를 FK로 가지고 있다. 그래서 좋아요를 insert 할 때 FK 제약 조건을 체크하기 위해 S-Lock을 건다. (S-Lock은 여러 트랜잭션에서 걸 수 있다.)

그다음 Post의 좋아요 개수를 Update 할 때 X-Lock을 획득하는데 트랜잭션 1,2가 각각 S-Lock을 점유하고 있어서 서로 X-Lock을 획득하지 못하고 대기한다. (X-Lock은 읽기 잠금도 제한하기 때문에 이미 읽기 잠금이 걸려있으면 대기한다.)

PostLike의 FK를 제거하니 CannotAcquireLockException 예외가 발생하지 않았다.

사실 update는 한 번에 하나의 트랜잭션만 레코드를 변경하기 때문에 Atomic 하게 동작한다. 그래서 이런 단순 count를 증가시키는 쿼리는 직접 likeCount = likeCount + 1로 update 하면 동시성 문제를 해결할 수 있다.

UPDATE post SET like_count = like_count + 1 where id = 1;

JPA의 변경 감지 기능에 너무 의존하다 보니 이런 부분을 놓친 것 같다. 그래도 낙관적 락 사용하고 테스트해보면서 배운 게 많아서 나름 만족스럽다.

[참고]

트랜잭션 동시성 문제 해결- Optimistic Lock과 AOP활용

0. 배경 서로 다른 API요청이 거의 동시에 들어올 경우 동시성 문제가 발생할 수 있는 기능이 있어서 이를 해결하기 위한 부분을 고민하게 되었습니다. 0-1. 기능 설명 해당 프로젝트는 사람들을

velog.io

좋아요 개수 조회 최적화하기

속닥속닥 프로젝트(https://github.com/woowacourse-teams/2022-sokdak…

tecoble.techcourse.co.kr

Optimistic Lock in JPA

junhyunny.github.io

MySQL 낙관적 락과 데드락(dead lock) With JPA Hibernate

프로젝트에서 모임 가입 기능을 구현하면서, 동시성 문제와 데드락까지 경험한 내용 그리고 어떻게 해결하였는지 고민과정과 해결방법을 정리하려고 합니다. 프로젝트 버전 SpringBoot 2.7.8 MySQL 8.

0soo.tistory.com

스프링 핵심 원리 - 고급편 강의 - 인프런

스프링의 핵심 원리와 고급 기술들을 깊이있게 학습하고, 스프링을 자신있게 사용할 수 있습니다., 핵심 디자인 패턴, 쓰레드 로컬, 스프링 AOP스프링의 3가지 핵심 고급 개념 이해하기 수강

www.inflearn.com

자바 ORM 표준 JPA 프로그래밍 | 김영한 - 교보문고

자바 ORM 표준 JPA 프로그래밍 | 자바 ORM 표준 JPA는 SQL 작성 없이 객체를 데이터베이스에 직접 저장할 수 있게 도와주고, 객체와 관계형 데이터베이스의 차이도 중간에서 해결해준다. 이 책은 JPA

product.kyobobook.co.kr

RealMySQL8.0

[Spring] AWS SSM Parameter Store 환경 변수 관리 (SpringBoot 3.2)

tree code — Tue, 30 Jan 2024 14:12:43 +0900

환경 변수를 서버내에 하드 코딩하지 않고 외부에서 관리하면서 안전하게 사용할 수 있는 방법을 찾다가 AWS에서 key, value 기반으로 관리할 수 있는 SSM Parameter Store를 찾았다. 현재 프로젝트 규모나 관리할 환경 변수가 많지는 않아서 적절하다고 생각되었다. 비용도 standard는 무료로 사용할 수 있다.

먼저 AWS 웹 콘솔 Parameter Store에서 key, value를 추가하면 되는데 민감한 데이터의 경우 KMS로 암호화해서 보관할 수도 있다.

계층 구조로 프로필, 용도에 따라 prefix(ex. "/config/photosot_dev")를 추가하고 뒤에 환경 변수를 추가해주면 된다.

이제 Spring Boot 설정을 보면 먼저 지속적으로 버전 관리가 되고 있는 awspring.io를 사용했고 spring boot 3 버전대에서는 설정이 바뀐 부분이 좀 있는데 공식 문서에 잘 나와있고 블로그에도 정리해주신 분이 있어서 편하게 설정할 수 있었다.

Spring Cloud AWS

Secrets Manager helps to protect secrets needed to access your applications, services, and IT resources. The service enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. Spring Clo

docs.awspring.io

Gradle에서 Spring Cloud AWS BOM(Bill of Materials)을 사용해서 의존성 관리를 간편하게 할 수 있다. platform() dependencies를 추가하고 하위 의존성은 버전 없이 spring-cloud-aws-starter-xx 만 입력해주면 된다. (-s3, -parameter-store 등)

application.properties, application.yml 설정 파일에 Parameter Store의 key prefix를 아래와 같이 spring.config.import에 맞춰서 추가해준다.

prefix를 추가해서 자동으로 바인딩 시킬 수도 있는데 오히려 헷갈리는 것 같아서 prefix 부분은 직접 명시해줬다.

마지막으로 EC2에서 Parameter Store에 값을 가져올 수 있도록 EC2 인스턴스에 IAM Role로 AmazonSSMReadOnlyAccess 를 추가해준다. (Systems Manager의 기능이므로 SSM Access를 추가)

EC2 터미널에서 aws configure list를 입력하면 IAM-Role로 발급 받은 access, secret key를 볼 수 있다. 스프링 부트를 실행하면 해당 key를 이용해서 Parameter Store에서 값을 가져와서 환경 변수를 주입해준다.

나의 경우 로컬 default 프로필에서 S3 업로드를 할때 IAM User를 생성해서 access, secret key를 환경 변수로 사용하고 있었는데 default 프로필이다보니 dev 프로필에서도 적용이 되어서 문제가 생겼다.

그래서 dev 프로필에서는 instance-profile을 true로 설정하고 access, secret key를 빈 값으로 덮어씌웠다. instance-profile은 EC2 인스턴스의 key를 사용하겠다는 것이다.

CredentialsProperties를 보면 access,secret key가 nullable하고 instanceProfile 기본값은 false로 되어있다. access, secret key가 있으면 해당 키를 사용하고 없는 경우 ec2 인스턴스의 키를 사용한다.

[참고]

[Spring] - Spring Boot 2.4 이상 환경에서 AWS Parameter Store 적용하기

회사 소스코드 application.yml 설정파일을 보면 데이터베이스 접속정보, api키값 등 보안에 민감한 데이터가 있어서 이러한 데이터를 외부에서 직접 주입 할 수 있도록 구성하려고 이것 저것 알아보

kim-jong-hyun.tistory.com

spring boot 3.2에서 aws parameter store 적용하기

최근에 사이드 프로젝트를 하나 진행하고 있다.배포도 생각중이라 DB 정보를 어떻게 관리해야 하나 고민을 하던 와중에 우연치 않게 aws parameter store에 대해서 듣게 되었다.가격도 공짜에 사이드

velog.io

SpringBoot & AWS S3 연동하기

안녕하세요? 이번 시간엔 SpringBoot & AWS S3 연동하기 예제를 진행해보려고 합니다. 모든 코드는 Github에 있기 때문에 함께 보시면 더 이해하기 쉬우실 것 같습니다. (공부한 내용을 정리하는 Github와

jojoldu.tistory.com

AWS Instance Profile doesn't work with Spring Cloud AWS

I have a small Spring Boot app, using Spring Cloud AWS (1.0.0.RELEASE) to access SQS queue. It is beeing deployed on an EC2 instance with Instance Profile set. It appears that AWS side of things is

stackoverflow.com

[SpringBoot 3.2] RestClientTest에서 여러개의 RestClient, RestTemplate 사용시 주의점 (MockRestServiceServer)

tree code — Tue, 16 Jan 2024 13:47:27 +0900

외부 API 테스트를 위해 RestClientTest 사용시 일반적으로 MockRestServiceServer를 @Autowired로 주입 받아서 사용하는데 RestTemplate 또는 RestClient가 2개 이상인 경우 에러가 발생한다.

찾아보니 관련 이슈가 있었다.

If you have two RestTemplate beans or two RestClient beans in your application, you can't use an auto-wired MockRestServiceServer in your test

MockRestServiceServerAutoConfiguration does not support RestTemplate and RestClient together · Issue #38820 · spring-projects

It should be possible to have together RestTemplate and RestClient in application and test them independently. Unfortunately, currently if RestTemplate is used, RestClient cannot be tested: org.spr...

github.com

고칠 예정이라고 하는데 일단 질문자의 샘플에 대한 예시는 이런식으로 사용하라고 나와있다.

    @Test
    void test(@Autowired RestClient restClient, @Autowired MockServerRestClientCustomizer customizer) {

        // given
        customizer.getServer().expect(requestTo("/")).andRespond(withSuccess());

        // when then
        restClient.get()
                .uri("/")
                .retrieve();
    }

@RestClientTest의 메타 애노테이션중 @AutoConfigureMockRestServiceServer를 보면 여러 Clients를 쓰는 경우 MockServerRestXXXCustomizer를 주입 받아서 getServer()를 사용하거나 MockRestServiceServer에 직접 bind 하라고 나와있다.

나는 HttpInterface를 쓰고 있어서 아래와 같이 직접 bind()해주는 방식으로 수정했다. MockRestServiceServer에 먼저 bindTo()를 해준 뒤에 HttpClient 프록시를 Bean으로 등록하는 부분에 restClientBuilder를 넣어줘야한다.

Build the MockRestServiceServer and set up the underlying RestTemplate with a ClientHttpRequestFactory that creates mock requests.

[MySQL] 단일값 IN vs equals 차이점

tree code — Tue, 16 Jan 2024 13:10:53 +0900

단일 비교를 하는 경우 IN()절로 작성한 SQL을 재사용해도 좋을지 궁금해서 찾아봤는데 괜찮아보이는 글이 보였다. 대체로 차이가 없다는 의견이지만 공식 문서는 없는 것 같아서 간단하게 테스트를 해봤다.

Performance differences between equal (=) and IN with one literal value

How does SQL engines differ when we use equal sign and IN operator have same value? Does execution time changes? 1st one using equality check operator WHERE column_value = 'All' 2nd one using IN

stackoverflow.com

spot_id IN(1), spot_id = 1 모두 동등 비교를 하고 실행 계획 type도 ref로 나왔다. ref는 동등 조건으로 검색할 때의 접근 방법을 나타낸다.

IN 절에 여러 id가 들어가는 경우에는 id = 1 or id = 2.. 형태로 된다.

[Real MySQL] 실행 계획

tree code — Mon, 15 Jan 2024 15:52:02 +0900

데이터를 안전하게 저장, 관리하고 효율적으로 조회하려면 옵티마이저가 어떻게 동작할지, 쿼리의 실행 계획에 대해 알아야한다.

실행 계획은 쿼리를 실행할때 EXPLAIN 키워드를 붙여서 실행하면 된다. 실행 계획도 그때그때 찾아보는 것이 좋을 것 같은데 자주 보이고 알면 좋은 부분만 정리해봤다.

실행 계획 결과는 기본적으로 테이블(json, tree 같은 포맷도 있다)로 여러 정보를 알려준다.

1. id

- 단위 select 쿼리(select 키워드 단위로 구분한 것)의 식별자로 테이블을 조인하면 조인되는 테이블의 개수만큼 실행 계획 레코드가 생기지만 같은 id 값을 가진다. (id 값이 같으면 조인된 경우)

- id가 테이블의 접근 순서를 의미하지는 않는다.

2. select_type

- 단위 select 쿼리가 어떤 타입의 쿼리인지 나타낸다.

- 서브쿼리를 사용하지 않는 단순 쿼리를 나타내는 SIMPLE, 서브 쿼리를 가지는 select 쿼리의 가장 바깥쪽에 있는 쿼리를 나타내는 PRIMARY 등의 키워드가 있다.

- DERIVED는 단위 SELECT 쿼리의 실행 결과로 메모리나 디스크에 임시 테이블(파생 테이블)을 생성하는 것을 의미하는데 주로 from절 서브쿼리를 사용하는 경우를 나타낸다. (성능상 주의깊게 볼 부분)

3. type

- MySQL 서버가 각 테이블을 어떤 방식으로 읽을지를 나타낸다.

- 주로 쓰이는 타입으로는 all < index < range < index_subquery < unique_subquery < ref < eq_ref < const 의 순서대로 빠른 순서를 보인다.

- const(Unique index scan)는 where절로 PK 또는 유니크 키로 1건만 조회하는 쿼리로 많이 사용하는 방식이다.

- eq_ref는 join에서 처음 읽은 테이블의 컬럼값을, 그 다음 읽어야 할 테이블의 PK나 유니크 키 컬럼의 검색 조건에 사용할 때 나타낸다.

- ref는 인덱스 종류와 관계없이 동등 조건으로 검색할 때를 나타낸다.

- index_subquery, unique_subquery는 where 조건절에서 사용되는 in(subquery) 형태의 쿼리를 나타낸다. MySQL8.0 버전은 in subquery 형태의 세미 조인의 최적화된 기능이 많이 도입 되어서 실제 테스트 해보니 ref로 실행 된다거나 하는 경우가 많았다. (책에서도 최적화 옵션을 비활성화 하고 테스트를 하고 있다)

- range는 인덱스 레인지 스캔 형태의 접근 방법으로 인덱스를 범위로 검색하는 경우 (<, >, IS NULL, BETWEEN, IN, LIKE)등의 연산자로 검색시 사용된다. 속도는 생각보다 낮지만 range로 조회만 하더라도 어느정도 최적의 성능이 보장된다고 한다.

- index는 인덱스를 처음부터 끝까지 읽는 인덱스 풀 스캔방식이다

- all은 풀 테이블 스캔 방식으로 InnoDB는 풀 스캔시 대량의 디스크 I/O를 유발하는 작업을 위해 한번에 많은 페이지를 읽어 들이는 기능(Read AHead)을 제공한다. 대용량 레코드 처리시 잘못 튜닝된 인덱스 쿼리보다는 풀 테이블 스캔이 더 나은 경우도 있다.

4. keys

- 실행 계획에서 사용하는 인덱스를 의미하며 쿼리를 튜닝할 때는 key 컬럼에 의도한 인덱스가 표시되는지 확인하는 것이 중요하다.

5. rows

- 얼마나 많은 레코드를 읽고 체크해야 하는지 예측한 레코드 건수를 의미한다.

- 스토리지 엔진이 가지고 있는 통계 정보를 참조해서 MySQL 옵티마이저가 산출해 낸 예상값이라서 정확하지는 않다.

6. filtered

- 필터링되고 남은 레코드의 비율을 의미한다.

7. extra

- 성능에 중요한 부분, 처리 방식등을 보여준다.

- Using where은 MySQL 엔진에서 스토리지 엔진으로부터 받은 데이터를 별도의 가공을 해서 필터링 작업을 처리한 경우에 나타난다. (검색 조건에 따라 스토리지 엔진에서 필터링을 할 수도, MySQL 엔진에서 필터링을 할 수도 있다.)

- Using index(커버링 인덱스)는 인덱스만 읽어서 쿼리를 처리할 수 있는 경우 나타난다. 인덱스를 이용해 처리하는 쿼리에서 가장 큰 부하는 인덱스 검색에서 일치하는 키 값들의 레코드를 읽기 위해 데이터 파일을 검색하는 작업이다. InnoDB의 세컨더리 인덱스는 데이터 레코드를 찾아가기 위한 논리 주소로 사용하기 위해 PK를 같이 저장하는데 이는 추가 컬럼을 하나 더 가지는 인덱스 효과도 얻을 수 있다. 하지만 너무 과도하게 인덱스 컬럼이 많아지면 메모리 낭비가 심해지고 레코드 저장, 변경 작업이 매우 느려질 수 있어서 주의해야한다.

-Using index condition는 (MySQL 5.6 버전부터) 인덱스를 범위 제한 조건으로 사용하지 못한다고 하더라도 인덱스에 포함된 컬럼의 조건이 있다면 모두 같이 모아서 스토리지 엔진으로 전달하는 것을 말한다. 만약 스토리지 엔진에서 범위 제한 조건으로 10000건을 조회해서 MySQL엔진으로 전달했는데 MySQL 엔진에서 체크 조건으로 1건만 필터링이 된다면 매우 비효율적이다.

- Using filesort는 order by를 처리하기 위해 적절한 인덱스를 이용하지 못해서 조회된 레코드를 메모리 버퍼에 복사해 다시 한번 정렬하는 경우를 말한다. (성능상 주의해야 될 부분)

explain analyze로 검색하면 쿼리의 실행 계획과 단계별 소요된 시간 정보를 확인할 수 있다.

- 들여쓰기가 같은 레벨에서는 상단 라인이 먼저 실행

- 들여쓰기가 다른 레벨에서는 가장 안쪽 라인이 먼저 실행

- actual time=0.007..0.009 : 첫번째 레코드를 가져오는 데 걸린 평균 시간(ms), 두번째는 마지막 레코드를 가져오는 데 걸린 평균 시간

- rows 처리한 레코드 건수

- loops 반복 횟수

실행 계획과 더불어 쿼리 시간을 측정하는 경우 주의할 부분이 있다.

MySQL 서버는 운영체제의 파일 시스템 관련 기능(시스템 콜)을 이용해 데이터 파일을 읽어온다. 그런데 일반적으로 대부분의 운영체제는 한 번 읽은 데이터는 운영체제가 관리하는 별도의 캐시 영역에 보관해 뒀다가 다시 해당 데이터가 요청되면 디스크를 읽지 않고 캐시의 내용을 바로 MySQL 서버로 반환한다. InnoDB 스토리지 엔진은 일반적으로 파일 시스템의 캐시나 버퍼를 거치지 않는 Direct I/O를 사용하므로 운영체제의 캐시가 큰 영향을 미치지 않는다.

하지만 MySQL 서버에서도 데이터 파일의 내용을 페이지 단위로 캐시하는 기능을 제공한다. InnoDB 스토리지 엔진이 관리하는 캐시를 버퍼 풀이라고 하는데 이는 인덱스 페이지는 물론이고 데이터 페이지까지 캐시하며, 쓰기 작업을 위한 버퍼링 작업까지 겸해서 처리한다.

MySQL 서버가 한번 시작되면 InnoDB의 버퍼 풀을 강제로 삭제할 수 있는 방법이 없다.

InnoDB 버퍼 풀은 MySQL 서버가 종료될 때 자동으로 덤프됐다가 다시 시작될 때 자동으로 적재된다.

SET GLObAL innodb_buffer_pool_dump_at_shutdown=OFF
SET GLObAL innodb_buffer_pool_load_at_startup=OFF

그래서 실제 쿼리의 성능 테스트를 MySQL 서버의 상태가 워밍업된 상태(캐시나 버퍼등의 데이터가 준비된 상태)로 할지 아니면 콜드 상태(캐시나 버퍼가 모두 초기화된 상태)에서 진행할지도 고려해야 한다. 일반적으로 쿼리의 성능 테스트는 워밍업된 상태를 가정하고 테스트한다고 한다.

MySQL의 버퍼 풀은 크기가 제한적이라서 쿼리에서 필요로 하는 데이터나 인덱스 페이지보다 크기가 작으면 플러시 작업과 캐시 작업이 반복해서 발생하므로 쿼리를 6~7번 정도 반복해서 실행한 후, 처음 한두 번의 결과는 버리고 나머지 결과의 평균값을 기준으로 비교하는 것이 좋다.

[참고]

RealMySQL 8.0

[AWS] CodeDeploy 사용시 주의점

tree code — Wed, 10 Jan 2024 18:05:55 +0900

1. CodeDeploy Agent 설치를 하고 이후에 EC2에 CodeDeploy 관련 Role을 추가해주는 경우 CodeDeploy Agent Restart를 해줘야 적용이 된다.

AWS Systems Manager를 사용하여 CodeDeploy 에이전트 설치 - AWS CodeDeploy

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

2. ApplicationStop 단계에서 실행되는 스크립트가 수정이 되더라도 적용이 안 될 수가 있다. 아래 경로를 찾아서 제거해줘도 되지만 aws deploy create-deployment시 --ignore-application-stop-failures 옵션을 추가해주는 것이 확실하다.

CodeDeploy에서 ApplicationStop 에러날때

Gitlab에서 CodeDeploy를 이용해 EC2 개발서버에 배포하던중 최초 성공 이후, 그 다음 배포에서 계속 CodeDeploy의 ApplicationStop에서 에러가 지속적으로 발생하였습니다.. Appspec.yml에 ApplicationStop에 해당하

jaykos96.tistory.com

3. AppSpec의 hook에 추가한 스크립트가 실행 되는 경로는 Code Deploy Agent가 설치된 경로이다. docker compose를 사용하면 경로를 체크한다. (cd $PATH로 이동해서 실행 등)

AWS Code Deploy를 통한 배포 자동화 - DRAMA&COMPANY

서버 배포는 단순하고 반복작업이지만 절차가 적지 않아 실수를 할 가능성이 높습니다. 또 한번의 실수는 커다란 시스템 장애로 이루어질 수 있기 때문에 많은 분들에게 배포란 꽤나 부담스럽

blog.dramancompany.com

[Spring] Multipart 전송 시 Json 데이터 같이 보낼 경우 주의점

tree code — Thu, 4 Jan 2024 17:43:48 +0900

스프링에서 이미지 업로드를 할때 Json 데이터를 Multipart로 같이 보내는 경우 Content-Type을 application/json으로 명시해줘주지 않으면 application/octet-stream not supported 예외가 발생한다.

multipart/form-data를 받을 경우 @RequestPart 애노테이션을 사용하는데 애노테이션의 주석을 보면 method argument가 String or MultipartFile이 아닌 경우 HttpMessageConverter에서 각 request part의 content-type을 체크한다고 나와있다.

@RequestPart 애노테이션이 붙은 파라미터를 처리하는 RequestPartMethodArgumentResolver는 AbstracMessageConverterMethodArgumentResolver를 extends 하고 있다. 그래서 resolveMultipartArgument()로 Multipart를 처리하고 Multipart가 아닌 경우에는 AbstracMessageConverterMethodArgumentResolver의 readWithMessageConverters()에서 messageConvert로 revolve 한다.

이때 Content-Type이 없는 경우 default로 application/octet-stream가 설정이 된다.

application/octet-stream는 보통 unknown binary file에 대해 default로 사용이 된다.

이제 등록된 MessageConverter를 돌면서 convert가 가능한지 체크를 한다.

ByteArrayHttpMessageConverter가 application/octet-stream을 처리하지만 Controller에서는 byte[]가 아닌 json을 mapping하려고 하기 때문에 supports()에서 false를 반환한다.

그래서 json을 mapping해주기 위해 AbstractJackson2HttpMessageConverter를 extends해서 application/octet-stream 타입을 받아서 변환하도록 해줄 수도 있지만 request 전송시 content-type을 명시해주면 해결이 된다.

[Spring Rest Docs] Enum, 예외 코드 문서화를 위한 Custom Snippet 생성(AbstractFieldsSnippet)

tree code — Thu, 28 Dec 2023 16:46:00 +0900

Spring Rest Docs에서 Error Code나 Enum의 문서를 보여주기 위해서는 Custom Snippet을 사용하는 것이 좋다.

기본 템플릿도 수정해서 사용할 수 있는데 일반적으로 optional, default, constraints 같은 column을 추가해서 사용한다.

Error Code나 Enum을 나타내기 위한 템플릿은 column이 아예 달라서 새로 추가하는 것이 좋다. restdocs-core의 default snippet 템플릿이 있는 경로대로 테스트의 resources 하위에 test/resources/org/.. 디렉토리를 생성하고 템플릿을 추가하면 된다.

나는 error code를 문서화하기 위해 errorcde-response-fields.snippet을 생성했는데 xxx-response-fields처럼 네이밍을 지키면서 추가하면 된다. 그 다음 Custom Snippet을 적용하기 위해 AbstractFieldsSnippet를 상속받는 클래스를 구현한다.

추상 메서드인 getContentType(), getContent()를 구현해줘야 하는데 실수로 그냥 지나쳤다가 문서가 제대로 생성 되지 않았다.

getContent()로 body를 꺼내서 veriftContent()를 할 때 length가 0이면 SnippetException body is empty 예외가 발생한다. ㅠㅠ

그래서 아래와 같이 수정을 해주었다.

이제 custom snippet, CustomResponseFieldSnippet 클래스를 추가했으면 test 디렉토리 내부에 Enum 값들을 반환해 주는 Controller를 생성하고 해당 Controller에서 문서화하려는 Enum 값들을 반환해 준다

아래와 같이 Rest Docs용으로 생성한 Controller에 요청을 보내면 Enum 값들을 Map으로 반환해 줘서 key는 문서의 row로 사용하고 value는 column으로 사용한다. (column에서 보여줄 status, code, message 등을 DTO로 생성한다,)

그러면 아래와 같이 response가 생성이 되는데 key를 fieldWithPath()의 path로 지정하고 type, code, status, message는 attributes에 값을 넣어주면 column으로 보여줄 수 있다.

기존에는 responseFIelds(fieldWithPath()...)의 형태로 추가를 하면 response-fields.snippet을 찾아서 문서가 생성이 되었다.

하지만 이번에는 custom으로 생성을 하기 때문에 아까 생성해 놓은 CustomResponseFieldSnippet의 생성자를 사용해야 한다.

ignoreUndocumentedFields를 true로 줘서 문서화하지 않은 필드는 무시하도록 한다.

이제 Rest Docs 테스트 코드를 작성하면 되는데 나는 document()의 공통 부분을 restDocsTemplate() 메서드로 빼두었다.

createErrorCodeFieldDescriptors()에서 Map<String, ErrorCodeResponse>를 받아서 FieldDescriptor를 생성한다.

path에는 Map의 key가 들어가고

attributes에는 Map의 value인 ErrorCodeResponse의 type, code, status, message 필드들을 추가해 주면 된다.

이렇게 하면 Error Code를 테이블 형태로 보여줄 수 있다. ErrorCode를 하나의 Enum 클래스에서 관리한다면 자동으로 Error Code 동기화가 돼서 좋은 것 같다!

[참고]

RestDocs - Custom Error Code Enum 문서화

RestDocs - Custom Error Code Enum 문서화 Enum으로 Custom ErrorCode 관리시 Enum 문서 자동화 방법 SpringBoot 버전 2.7.8 restdocs 버전 2.0.7 개요 데브코스에서 프로젝트를 하다 고민이 생겼습니다. 프론트엔드와의

0soo.tistory.com

Spring Rest Docs 적용 | 우아한형제들 기술블로그

{{item.name}} 안녕하세요? 우아한형제들에서 정산시스템을 개발하고 있는 이호진입니다. 지금부터 정산시스템 API 문서를 wiki 에서 Spring Rest Docs 로 전환한 이야기를 해보려고 합니다. 1. 전환하는

techblog.woowahan.com

Spring REST Docs 적용 및 최적화 하기

Java, JPA, Spring을 주로 다루고 공유합니다.

backtony.github.io

[SpringBoot 3.2] RestClient, HttpInterface 사용법 (RestClientTest 및 HttpComponents 라이브러리 주의)

tree code — Mon, 18 Dec 2023 18:29:15 +0900

스프링에서 외부 API 호출을 위해 RestTemplate, WebClient을 제공하는데 스프링 부트 3.2 버전부터 정식으로 RestClient가 추가되었다.

RestClient - synchronous client with a fluent API.
WebClient - non-blocking, reactive client with fluent API.
RestTemplate - synchronous client with template method API.
HTTP Interface - annotated interface with generated, dynamic proxy implementation.

WebClient, HttpInterface를 사용하면 직관적이고 깔끔하게 구현할 수 있지만 webflux 의존성을 추가해야 되는 단점이 있다. RestClient는 새로운 동기식 HTTP 클라이언트로 WebClient와 유사한 API로 사용할 수 있다. 이전에는 HttpInterface를 사용하려면 WebClient를 사용했어야 했는데 스프링 6.1부터 HttpExchangeAdapter의 구현체로 RestClientAdapter와 RestTemplateAdapter 둘 다 사용할 수 있게 되었다.

이번에 카카오맵 API를 사용하면서 RestClient, HttpInterface를 사용했는데 RestClient는 create() 혹은 builder를 통해 생성할 수 있고 builder를 사용하면 추가로 baseUrl, header, statusHandler 등 여러 설정을 할 수 있다.

build() 내부를 보면 설정이 없는 경우 여러 초기화 작업을 해준다. RestTemplate, RestClient는 내부적으로 HTTP 통신을 위해 Apache HttpComponents를 사용한다.

RestClient 설정시 ClientRequestFactory를 추가할 수 있는데 ClientHttpRequestFactory는 HttpClient, ConnectionManager 등의 설정을 할 수 있다.

RestClient.Builder에서 HttpComponents5 라이브러리를 직접 추가하지 않으면 SimpleClientHttpRequestFactory가 default로 들어간다. SimpleClientHttpRequestFactory를 그대로 사용하면 운영 환경에서 많은 문제가 생길 수 있어서 HttpComponentsClientHttpRequestFactory를 사용하는 것이 좋다.

(원래 HttpComponentsClientHttpRequestFactory가 default인데 라이브러리를 따로 추가하지 않은 경우 발생하는 문제이다.)

HttpComponentsClientHttpRequestFactory를 생성할 수가 없어서 주석을 보니 스프링 부트3 버전대에서 HttpComponents 5.1 이상 라이브러리를 추가로 필요로 한다고 나와있다.

HttpComponents 5.2.x 버전을 추가하고 다시 보면 default가 HttpComponentsClientHttpRequestFactory로 바뀌고 HttpComponentsClientHttpRequestFactory 또한 직접 생성해서 설정할 수도 있다.

하지만..! 스프링 부트 3.2 기준으로 HttpComponents 5.2.x 버전을 추가하면 HttpInterface Proxy 생성이 안 되는 문제가 있어서 최신 버전인 5.3으로 추가해야 한다

HttpComponentsClientHttpRequestFactory 내부에는 httpClient의 default ConnectionManager로 PoolingHttpClientConnectionManager가 주입이 되어 있다. PoolingHttpClientConnectionManager는 커넥션 풀을 사용하여 커넥션 관련 설정을 custom 할 수 있다.

HttpComponentsClientHttpRequestFactory는 상황에 따라 타임 아웃, 커넥션 풀 등의 설정을 통해 변경할 수 있다.

HttpInterface는 아래와 같이 인터페이스, 애노테이션 기반으로 정의를 해서 직관적으로 사용할 수 있다.

현재는 직접 해당 인터페이스의 프록시 구현체를 만들어서 Bean으로 등록해주어야 한다.

이렇게 설정한 외부 API 호출을 테스트하려면 @RestClientTest를 활용할 수 있다. 주의점은 RestTemplate, RestClient를 주입받는 Bean에서 파라미터로 RestTemplateBuilder or RestClient.Builder를 사용해야 한다. 그래서 위에 HttpInterface를 Bean으로 등록할 때 RestClient.Builder를 파라미터로 사용했다.

RestClientTest는 최소한의 Context로 테스트를 실행하기 때문에 테스트할 HttpInterface를 value에 추가해 주었다. MockRestServiceServer는 외부 API를 테스트하기 위한 Mock 서버이다

테스트는 간단하게 예상 Response 등을 설정해 주고 mockServer에 설정을 해준 뒤에 예상 경로로 요청이 가는지, 바인딩이 제대로 되는지 등의 테스트를 검증한다.

RestClient는 custom 메시지 컨버터를 추가할 수 있지만 default로 등록된 컨버터 중 MappingJackson2HttpMessageConverter가 json 응답을 객체에 바인딩해 준다.

[참고]

Spring Boot에서 외부 API 테스트하기

안녕하세요? 이번 시간엔 Spring Boot의 @RestClientTest 예제를 진행해보려고 합니다. 모든 코드는 Github에 있기 때문에 함께 보시면 더 이해하기 쉬우실 것 같습니다. 1. 문제 상황 예를 들어 외부 API를

jojoldu.tistory.com

RestTemplate 사용시 주의사항 - Incheol's TECH BLOG

ResponseEntity response = restTemplate.exchange(" ", HttpMethod.GET, requestEntity, String.class);

incheol-jung.gitbook.io

Apache HttpComponent 제대로 사용하기

Java 어플리케이션에서 일반적으로 http호출을 할때 Apache HttpClient를 사용하며 http client가 버전업을 하여 Apache HttpComponent로 변경된것은 아마 다들 알고있는 사항일것입니다. (아주 옛날에 바꼈으니

inyl.github.io