AWS S3 이미지 관련 로직과 DB로직 트랜잭션 분리 (DB 커넥션 문제)

코드를 짜다보면 게시글과 같은 엔터티를 등록할 때 파일을 추가로 업로드하는 경우가 매우 많다.

 

이번 프로젝트에서도 공연 포스트를 DB에 저장하면서 썸네일 이미지와 내용에 들어갈 이미지 등이 AWS S3에 함께 저장되었다. 

마찬가지로 조회할 때도 AWS S3에서 조회하는 로직과 DB에서 포스트를 조회하는 로직이 함께 수행된다. 

 

 

 

이때 외부에서 리소스를 조회해오는 로직과 DB에서 조회해오는 로직을 한 트랜잭션에 묶으면 안 좋지 않을까?? 문득 이런 생각이 들었고 구글링 해보니 역시나 다른 사람들도 이미 고민했던 흔적들이 보였다.

 

 

 

왜 한 트랜잭션에 묶으면 좋지 않을까?? 

트랜잭션의 특징에 주목할 필요가 있다. 

한 트랜잭션이 시작되면 DB와의 커넥션을 맺고 트랜잭션이 끝날때까지 커넥션을 끊지 않는다.  

 

아래 코드에서 이를 검증할 수 있었다.

 

@Service
@RequiredArgsConstructor
public class MemberService {

    private final MemberRepository memberRepository;
    private final MemberResourceService resourceService;
    private final DataSource dataSource;

    @Transactional
    public Member create(CreateMemberRequest request) {
        printConnectionStatus();

        Member member = new Member(request.getUsername());
        memberRepository.save(member);

        resourceService.upload(request.getUserImage());

        printConnectionStatus();
        return member;
    }

    private void printConnectionStatus() {
        final HikariPoolMXBean hikariPoolMXBean = ((HikariDataSource) dataSource).getHikariPoolMXBean();
        System.out.println("################################");
        System.out.println("현재 active인 connection의 수 : " + hikariPoolMXBean.getActiveConnections());
        System.out.println("현재 idle인 connection의 수 : " + hikariPoolMXBean.getIdleConnections());
        System.out.println("################################");
    }

}

 

 

 

트랜잭션 진입 직후 커넥션 풀 상황과 트랜잭션 종료 직전의 커넥션 풀 상황을 출력하면 아래와 같은 결과가 나온다.

 

 

 

즉, 업로드할 파일의 크기가 크다면 DB 커넥션을 불필요하게 점유하면서 자원을 크게 낭비하게 된다.

 

 

이를 해결하기 위해 몇몇 방법들을 봤지만 나는 트랜잭션 분리를 시켜 해결을 시도했다. 

 

 

시도 1) 트랜잭션을 달지 않은 메소드에서 트랜잭션을 단 DB 저장 메소드를 호출하여 저장할 때만 트랜잭션 사용 - 실패

 

내 코드는 아니지만 비슷한 좋은 예제가 있어서 가져왔다.

 

public Member create(CreateMemberRequest request) {
    printConnectionStatus();

    Member member = createEntity(request.getUsername());

    resourceService.upload(request.getUserImage());

    printConnectionStatus();
    return member;
}

@Transactional
public Member createEntity(String username) {
    Member member = new Member(username);
    memberRepository.save(member);
    return member;
}

 

위 코드에선 @Transactional  어노테이션이 적용된 createEntity 메서드가 사실 트랜잭션이 적용되지 않는다. 

이유는 Spring AOP는 프록시 패턴을 기반으로 동작하기 때문이다. 

즉, A빈에서 B빈을 호출하기 전에 B의 프록시 객체를 호출하게 된다.

하지만 A 인스턴스에서 자신을 호출한다 해도 프록시 객체는 호출되지 않고 @Transactional도 동작하지 않는다. 

 

 

시도 2) 메소드 단에서 분리하지 말고 빈을 분리해보자

위 문제를 해결하기 위해선 서비스 클래스를 분리하는 방법이 있다. 빈이 분리되므로 트랜잭션을 정삭 동작 시킬 수 있는 것이다.

 

분리된 서비스 클래스들을 Facade 패턴을 사용해서 계층을 하나 더 만드는 방법도 좋아보였다.

 

 

퍼사드 패턴(Facade Pattern)은 구조 패턴(Structural Pattern)의 한 종류로써, 복잡한 서브 클래스들의 공통적인 기능을 정의하는 상위 수준의 인터페이스를 제공하는 패턴이다.

 

 

 

여러 SubSystem들의 기능을 하나의 Facade Object로 정의하고, Client가 Facade Object를 사용하는 형태이다.

 

 

내 상황에선 이미지 업로드와 DB에 엔티티 저장 기능을 하나의 Facade Object로 정의하고 컨트롤러에서 이를 호출하는 것이다. 이때 Facade Object에는 트랜잭션이 당연히 붙지 않아야 하고 엔티티를 다루는 부분에만 트랜잭션을 붙여 사용하면 된다.

 

 

 

이렇게 하면 짧은 트랜잭션을 유지하면서 제 기능을 할 수 있게 구현 가능하다. 

하지만 한가지 문제점이 있다.

AWS S3에 이미지는 업로드 되었지만 엔티티 저장 중에 에러가 나서 롤백이 되었다면 업로드된 이미지는 쓰레기 값이 되는 것이다.

이 문제는  DB 저장에서 실패하면 에러를 던지고 이 에러를 Facade 인스턴스에서 catch로 잡아서 바로 해당 이미지를 S3 저장소에서 삭제하면 좋을 것 같았다.