Spring REST Docs 적용

들어가며 API 문서화는 원활한 협업을 위해 꼭 필요한 작업 중 하나로, Swagger 혹은 Spring REST Docs 등으로 진행할 수 있다. 이 중 Swagger의 경우, 운영 코드에 어노테이션을 붙여야 하므로 코드가 지저분해질 수 있다는 아쉬운 점이 존재한다. 반면 Spring REST Docs는 운영 코드에 영향을 주지 않고, 테스트 코드를 기반으로 생성되기 때문에 운영 코드를 그대로 보존할 수 있으면서 API 문서화를 진행할 수 있다. 또한 테스트를 기반으로 생성되므로, 테스트 코드 작성을 강제화할 수 있다는 장점도 있다. 이번 포스트를 통해 이러한 Spring REST Docs를 어떻게 적용하는지에 대해 알아보도록 하자. Spring REST Docs 문서화 과정 Spring REST Do..

Redis를 활용한 캐싱 적용기

들어가며 현재 성능 개선 작업을 진행하고 있는 협업 툴 서비스 Colla에서는 칸반 보드 페이지로 이동 시 해당 프로젝트 정보와 함께 프로젝트에 속한 테스크가 조회된다. 특정 프로젝트와 테스크를 조회하는 쿼리는 여러 엔티티들을 함께 조회해야 하므로 복잡하며, 발생하는 쿼리의 개수도 많다. 결국 칸반 보드 페이지로 이동할 때마다 이러한 복잡하고 많은 개수의 쿼리가 발생하게 된다는 것인데, 만약 테스크의 개수가 많고 동시에 여러 사용자가 칸반 보드 페이지에 접근한다면, 그 부하는 상당할 것이다. 따라서 이러한 문제점을 개선할 필요가 있으며, 여기서는 Redis를 활용한 캐싱을 통해 프로젝트와 테스크를 조회하는 작업을 개선해보고자 한다. 테스트 환경 구축 캐싱을 도입하기 전과 후를 비교하기 위해 부하 테스트 ..

테스트 격리하기

들어가며 @SpringBootTest를 이용하여 테스트 코드 작성 시 기본적으로 효과적인 테스트를 위해 최초에 생성한 ApplicationContext를 캐싱하여 재사용한다. 이렇게 하지 않으면 매번 새로운 ApplicationContext를 만들고, Bean들을 생성해야 하기 때문에 속도가 매우 느려진다. 하지만 이러한 Context의 재활용은 테스트들 간에 서로 영향을 주는 원인이 되기도 한다. 테스트가 진행되면서 DB의 상태는 계속해서 변경되는데, Context를 재활용하게 되면 변경된 DB의 상태가 다른 테스트에도 반영되게 되므로, 모든 테스트를 한꺼번에 실행할 때 테스트가 실패할 수 있다. 즉, 나중에 수행된 테스트가 먼저 수행된 테스트의 영향을 받게 되는, 테스트들이 완벽하게 격리되지 않은 상..

트랜잭션 전파 알아보기

들어가며 웹 애플리케이션을 개발할 때, 흔히 비즈니스 로직이 시작되는 서비스 계층에 @Transactional 어노테이션을 적용해주어 트랜잭션의 경계를 설정하곤 한다. 좀 더 구체적으로는 보통 공통적으로 적용할 트랜잭션 속성을 @Transactional과 함께 작성하여 클래스 레벨에 부여하고, 보다 세밀하게 트랜잭션 속성을 적용해야 할 경우라면 메서드 레벨에 @Transactional을 부여한다. 그렇다면 @Transactional 어노테이션은 매번 새로운 트랜잭션을 생성하는 것일까? 이러한 의문이 들었을 때 트랜잭션 전파에 대해 정리해볼 필요가 있다고 느꼈고, 이에 대해 알아보려고 한다. 트랜잭션 전파 트랜잭션 전파는 트랜잭션의 경계에서 이미 진행 중인 트랜잭션이 있을 때, 또는 없을 때 어떻게 동작할..