Presigned URL 로 파일 업로드 기능을 왜 적용했냐면요.

해당 내용은 파일 업로드 기능을 구현하기 위해 검토했던 기술과 비즈니스 로직에 관한 내용에 관한 기록이다.

 

1. 파일 업로드를 위한 기술 검토

 게시글  파일 업로드를 위해 파일을 미리 업로드하고 게시글에 관한 메타 데이터를 저장하는 방식으로 비즈니스 로직을 구성했다.

게시글을 저장하는 시점에 파일 일괄 업로드를 하면 응답 지연으로 사용자 경험에 악영향이 있을 수 있는 점이 그 이유였다.

 

이를 위해 Multipart file 와 Presigned URL 두 가지 방식의 동작 방식과 장단점을 비교했다.

 

2. Multipart File?

multipart 는 하나의 HTTP 요청 바디에 여러 개의 파트(부분) 를 포함할 수 있게 해주는 MIME 타입이다.

하나의 메시지 본문 안에 여러 파트를 경계로 구분해서 데이터를 전송하는 방식이다.

주로 파일 업로드 시, 텍스트 데이터와 바이너리 데이터를 동시에 전송하는데 사용한다. 

 

모든 multipart 타입은 데이터를 구분하기 위해 boundary parameter 가 필요하다.

바운더리 하단에 컨텐츠 타입을 명시하고, 요청 바디에 첨부할 데이터를 입력하여 데이터를 전송한다.

만약 동영상, 이미지 파일인 경우 바이너리 형태로 변환되어 데이터를 전송한다. 

 

아래 예시를 한번 확인해보자.

상단의 Content-type 이 multipart/form-data 을 선언해 여러 파일을 업로드할 것임을 명시한다.

 

각 업로드 할 파일들은 boundary를 통해 데이터를 구분한다.

boundary 하단에 업로드할 파일 타입을 Content-type 헤더를 정의한 후, 전달할 타입의 파일을 첨부해 전송한다.

 

하지만, Multipart 는 서버가 파일을 전송하기 위해 서버에서파일을복사해서임시보관해야 한다. 

이는 서버 부하와 트래픽 처리에 있어 영향을 미칠 수 있는 단점이 있다.

Multipart/form-data 방식 HTTP 요청 메시지

 

 

3. Presigned URL?

Presigned URL 은 클라우드 스토리지(예: AWS S3, Google Cloud Storage 등)에서 인증된 사용자가 다른 사람에게 제한된 시간 동안 리소스에 접근을 허용하는 일시적인 URL 이다.

인증된 URL를 통해 해당 데이터를 조회 또는 업로드하고, 제한 시간이 지나면 URL이 만료되어 보안 측면에서 장점이 있다.

 

Presigned URL을 동작 방식을 확인해보자.

클라리언트는 클라우드로 부터 조회 또는 업로드 목적의 URL을 요청하면 올바른 사용자임을 획인한 후에 Presigned URL 을 반환한다.

 

Presigned URL 을 사용하면 파일 업로드에 관한 서버의 부하를 줄일 수 있다.

임시 링크를 통해 클라이언트가 S3로 파일 업로드를 하여 API서버에 파일 업로드를 위한 리소스가 발생하지 않기 때문이다.

 

API 서버는 인증된 값을 통해 S3 로 부터 임시 링크를 전달받아 클라이언트에게 전달만 하고,

클라이언트는 임시 링크를 통해 직접 S3 로 업로드한다. 아래에서 실제 테스트 결과를 통해 확인해보도록 하자.

Presigned URL 시퀀스

 

 

 

4. Multipart File vs Presigned URL 테스트 해보자.

(1) 테스트 위한 의존성 설정

 테스트를 위해 spring 에서 제공하는 Spring Cloud AWS 를 사용했다. Spring Cloud AWS 는 AWS SDK 를 기반으로 S3 와 관련된 기능을 제공하며 연결 설정과 관련된 프로퍼티를 기본적으로 제공해 편리하게 AWS 기능을 사용할 수 있다.

dependencies {
   implementation 'io.awspring.cloud:spring-cloud-aws-starter-s3:3.0.0'
}

 

(2) 테스트 비즈니스 로직

import java.io.IOException;
import java.net.URL;
import java.time.Duration;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;
import org.springframework.web.multipart.MultipartFile;

import io.awspring.cloud.s3.S3Resource;
import io.awspring.cloud.s3.S3Template;
import lombok.RequiredArgsConstructor;

import com.cooper.presigned_url.service.FileHandler;

@Component
@RequiredArgsConstructor
public class AwsS3FileHandler implements FileHandler {

	@Value("${aws.bucket.name}")
	private String bucketName;

	private final S3Template s3Template;

	@Override
	public URL createSignedUrl(final Long postId, final String fileName) {
		final String filePath = String.format("%s/%s", postId, fileName);
		return s3Template.createSignedPutURL(bucketName, filePath, Duration.ofMinutes(1));
	}

	@Override
	public URL getSignedUrl(final Long postId, final String path) {
		String key = path.replaceFirst("^/", ""); // object key 는 path 앞에 / 를 제거해야 한다.
		return s3Template.createSignedGetURL(bucketName, key, Duration.ofMinutes(1));
	}

	@Override
	public URL uploadFile(final Long postId, final MultipartFile file) throws IOException {
		final String fileName = file.getOriginalFilename();
		final String filePath = String.format("%s/%s", postId, fileName);
		final S3Resource s3Resource = s3Template.upload(bucketName, filePath, file.getInputStream());
		return s3Resource.getURL();
	}
}

 

 

(3) AWS 테스트 환경

Multipart Filter 과 Presigned URL 의 CPU 사용량 비교를 위해 AWS EC2 t3.micro 를 기반으로 테스트를 진행했다. 

 

 

(4) CPU Utilization, Packet 전송량 비교

5MB 사이즈의 pdf 파일을 업로드하고 Cloudwatch 를 통해 결과를 비교했다.

 

단일 요청의 단일 파일 업로드 비교 결과,

CPU Utilization 에서 10배 적은 CPU 사용했고, Network I/O 패킷 수가 400배 적게 패킷을 송수신하는 것을 확인했다.

 

비록, 클라이언트에서 S3 로 파일 업로드하는 과정에서 전송된 패킷이 포함되지 않았지만

해당 서버가 다량의 요청을 처리하는 경우를 고려해보았을 때 Presigned URL 이 Multipart File 에 비해 적은 CPU 리소스 장점이 있다.

cloudwatch 대시보드 기반 EC2 사용량 비교

 

 

(5) 응답 시간 비교

실제 응답 시간 또한 Presigned URL 에서 좋은 결과가 있었다.

 

이전에 확인했듯이 Network I/O 전송 패킷의 갯수 차이가 약 400배 차이가 있었다. 업로드 파일의 송수신을 위한 대량의 패킷 전송과 서버에서 파일을 임시 보관하기 위한 리소스 사용으로 인해 응답 지연 발생했을 것으로 예상된다.

 

두 데이터를 비교했을 때 CPU 사용량과 Network I/O 관점에서 Presigned URL 가 리소스를 효율적으로 사용하고 낮은 응답 속도를 기대할 수 있다.

Presigned URL vs Multipart File 응답 시간 비교

 

5. 결론

 파일 업로드를 위한 두가지 방식을 검토해보았다.

 

멀티파트 파일의 경우,

서버에 파일을 임시 보관해야 하는 이유로 서버로 전송하는 패킷의 양과 CPU 리소스사용 관점에서 인한 단점이 있지만

직접 파일을 검증하는 로직을 추가할 수 있어 보안상의 장점이 있다.

 

Presigned URL 의 경우,

클라이언트에게 임시 URL 을 제공해 S3 에 직접 업로드 하는 방식으로 서버의 부하를 줄일 수 있는 장점이 있다.

하지만 파일 이름의 동일 여부를 검증만 가능하므로 멀티파트 파일에 비해 파일 검증 로직이 상대적으로 빈약한 단점이 존재한다.

 

이와 같은 두가지 방식의 장단점과 방향성을 고려하여 파일 업로드 방식을 적용해보자.

 

 

Reference

• 테스트 샘플 코드 : https://github.com/pbg0205/BE-tutorials/tree/main/presigned_url
• S3 Presigned URL  https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/using-presigned-url.html