본문 바로가기
IT

[AWS] S3 Mount vs Storage

by 뽀리님 2024. 11. 3.

프로젝트 진행하다가, 같은 팀 직원이 동영상을 S3에 올렸는데 중간 재생이 안된다는 이슈가 있었다.

팀내 직원의 추측으론 .mp4 동영상 Content Type 이 binary/oct-stream 으로 올라가서 중간재생이 안되는거 같다고 하여...

마운트 시키는 폴더에 올리는 파일의 Content Type을 지정할 수 있도록 옵션을 다시 지정해 보았다.

(참고로 Content Type은 mp4이므로 viedo/mp4 형식으로 올라가야 한다)

 

서치한 결과 goofys를 이용하여 마운트 설정을 할 수 있었다.

 

 

✔️ goofys 

goofys는 Go언어로 작성된 고성능 POSIX 방식의 Amazon S3 파일 시스템이다.
s3fs보다 빠른 속도를 자랑한다고 벤치마크를 통해 광고하는 글을 봤던 기억만 있었다. goofys가 압도적으로 빠르다고 한다.

 

혹시나 회사서버에 깔려있는지 확인해보니 깔려있었다.(햅삐-)

 

아래와같이 명령어를 입력하여 다시 설정해 주었다.

 

goofys -o allow_other --uid=1001 --debug_fuse --debug_s3 --use-content-type --file-mode=0777 --dir-mode=0777 [버킷 이름] [디렉토리 경로]

 

하지만 설정이 뭔가 Denied 되서 서칭해보니 user_allow_other 를 해제해줘야 한다.

 

vim /etc/fuse.conf

 

아래 경로로 가서 주석이 되어있다면 해제해주자

 

참고로 설정해주려면, 해당 디렉토리에 경로에 파일이 하나도 없어야 하므로 다른곳에 백업해두고 설정해주자.

 

하지만....... 이렇게 해도 되지 않았다.. Content-type 자체를 변경할 수 가 없었다. ㅜ.ㅜ

 

동영상 중간재생은 이게 문제가 아닌거 같은데?

 

 

 

알아보니 동영상은 마운트가 아니라 스토리지에 직접 올려야 한단 것이었다.

 

어쩐지 왜 마운트를 하나 싶었는데... 이번기회로 확실히 개념을 알게되었다.

 

☑️ S3 마운트는 Fuse시스템으로 이루어져 있다.

동영상 파일의 중간 재생, 스트리밍, 특정 구간 접근과 같은 세밀한 제어가 필요한 경우에는 FUSE 기반 S3 마운트보다는 AWS SDK나 AWS CLI를 통한 직접 업로드가 더 적합하다.

 

FUSE 기반으로 S3를 파일 시스템처럼 마운트하는 방식은 주로 일반 파일의 저장이나 간단한 읽기/쓰기 작업에 적합하며, 미디어 파일과 같이 세밀한 제어가 필요한 작업에서는 한계가 있다.

 


☑️ FUSE 기반 S3 마운트의 한계

1. HTTP Range 요청 미지원 또는 제한

중간 재생이 필요한 동영상 파일은 클라이언트에서 HTTP Range 헤더를 통해 특정 범위의 데이터를 요청하게 된다. FUSE 마운트는 S3의 HTTP Range 요청을 파일 시스템 호출로 매핑하기 어려워 중간 재생 지원이 제한적이다.

 

2. Content-Type 설정 제한

`goofys`나 `s3fs` 같은 FUSE 도구는 파일 확장자에 따라 기본 `Content-Type`을 자동으로 설정할 수 있지만, 이를 명확하게 `video/mp4`와 같은 미디어 타입으로 설정하여 스트리밍에 최적화하는 데 한계가 있다.

 

3. 성능 이슈

FUSE는 네트워크를 통해 S3와 통신하기 때문에, 대규모 파일의 경우 네트워크 I/O가 빈번해지면서 파일의 특정 구간에 빠르게 접근하는 데 한계가 있다. 반면, 직접 업로드한 파일은 S3의 HTTP API를 통해 클라이언트가 빠르게 구간 접근을 요청할 수 있다.

 

 

✔️ AWS SDK 또는 CLI를 통한 직접 업로드

동영상과 같은 미디어 파일을 다루면서 중간 재생, 스트리밍, 빠른 구간 접근이 필요하다면 FUSE 기반 마운트 대신 AWS SDK 또는 CLI를 통해 S3에 직접 업로드하는 방법을 사용하는 것이 좋다. 이를 통해 S3의 객체 스토리지 특성을 최대한 활용하고, 필요한 미디어 제어 기능을 안정적으로 지원할 수 있다.

 

 

참조 :

https://dev-logs.tistory.com/20
https://engmisankim.tistory.com/67