Backend
부하 테스트 및 성능 개선 여행기
본 포스트는 부스트캠프에서 진행한 벽전 프로젝트의 서버 성능을 개선해보고자 진행한 내용을 정리한 포스트입니다. 들어가며 부하 테스트 툴로는 nGrinder를 사용하였고, 진행 방식은 다음과 같다. 대상 API - 메인 페이지의 랜덤 전시회 조회 API Vuser - 1000명 에러 개선기 부하 테스트를 진행해보았더니 여러 에러가 발생하여 정확한 성능 측정을 할 수 없었다. 따라서 성능 개선을 하기 전에 우선적으로 발생한 에러들에 대해 다루어보려고 한다. Error: worker_connections are not enough 처음으로 발생한 에러는 worker_connections are not enough 였다. 해당 에러는 Nginx의 worker connection이 부족하여 1000명의 가상 유저..
AOP와 빈 후처리기를 이용한 부가 기능 분리
들어가며 다이내믹 프록시를 이용한 부가 기능 분리 포스트에서 트랜잭션이라는 부가 기능을 비즈니스 로직으로부터 분리하기 위해 다이내믹 프록시를 도입해보았고, 이러한 다이내믹 프록시를 스프링 빈으로 등록해서 사용하기 위해 팩토리 빈 방식을 사용해보았다. 하지만 이러한 프록시 팩토리 빈 방식은 부가 기능을 담당하는 InvocationHandler를 구현한 오브젝트가 프록시 팩토리 빈의 개수(부가 기능을 사용하는 빈의 개수)만큼 만들어진다는 문제점과 여러 개의 클래스에 부가 기능을 적용해야 한다면 프록시 팩토리 빈을 생성하는 설정 코드가 중복되는 것을 막을 수 없다는 문제점이 존재하였다. 이번 포스트에서는 앞서 언급한 문제점들을 조금 더 살펴본 뒤, AOP와 빈 후처리기를 이용하여 해당 문제점들을 해결해보도록 ..
다이내믹 프록시를 활용한 JPA QueryCounter 구현기
들어가며 JPA와 같은 ORM을 사용할 때, 지연 로딩과 같은 기능을 무분별하게 이용하다보면 원래 의도했던 개수보다 더 많은 쿼리가 발생하기도 한다. ORM에서 흔히 발생하는 N + 1 문제도 개발자의 의도와 다르게 N번의 쿼리가 더 발생하게 된다. 이렇듯 ORM을 사용하다보면 예상하지 못한 개수의 쿼리가 발생하기도 하는데, 이를 한눈에 파악하기는 쉽지 않다. 물론 JPA의 show-sql 기능을 사용하면 로그에 쿼리가 출력되기는 하지만, 좀 더 쉽게 알아볼 수 있는 방법이 필요하다는 생각이 들었고, 이를 위해 다이내믹 프록시를 활용하여 JPA QueryCounter를 구현해보기로 하였다. 여기서는 Spring Data JPA를 기반으로 설명한다는 점을 알고가도록 하자. 기본 원리 JPA QueryCou..
다이내믹 프록시를 이용한 부가 기능 분리
부가 기능 분리 부가 기능(Ex. 트랜잭션)은 비즈니스 로직과 성격이 다르기 때문에 분리해줄 필요가 있다. 이러한 분리는 프록시를 사용하여 진행할 수 있는데, 일반적인 프록시를 사용하게 되면 몇 가지 문제점과 마주하게 된다. 어떠한 문제점이 있는지 알아보고, 이를 다이내믹 프록시로 개선시켜보도록 하자. 프록시 적용해보기 먼저 다음은 프록시를 적용하여 부가 기능과 핵심 기능을 분리한 예제이다. public interface UserService { void add(User user); void upgradeLevels(); } public class UserServiceTx implements UserService { private UserService userService; private Platform..