원본

Intro

이 도전을 하기 전까지 우리의 프로세스를 생각해보아야 한다.

• 프론트엔드에서 webm파일로 영상을 녹화한 뒤, pre-signed url을 백엔드에서 받고, 영상을 저장한다.
• 저장한 영상의 url을 받은 뒤 백엔드에 해당 url과 영상에 대한 정보를 반환한다.
• 백엔드는 받은 영상의 정보를 테이블에 저장한다.

의 로직을 가지고 수행시키고 있었다.

여기에서 제일 큰 문제가 무엇일까???

WEBM 이 친구는 iOS, safari에서는 지원이 되지 않는다!!!

이런 문제로, 우리는 webm파일로 영상을 저장하면 안되겠다는 생각이 들었다.

이를 해결하기 위해 mp4파일로 인코딩을 처리하고 이를 백엔드에서 바로 저장하는 로직을 만들어봐야겠다는 생각이 들었다.

What do we need?

• ffmpeg : 리눅스 환경에서 파일을 인코딩해주는 역할을 한다.
• fluent-ffmpeg : nodejs환경에서 ffmpeg를 동작하게 해준다.(ffmpeg가 외부 환경에 존재해야 한다. 외부라고 말한 이유는 후에 보면 안다)
• multer-s3, multer, s3 : 대용량 파일을 처리하고, 이를 s3(클라우드 스토리지는 모두 s3 라이브러리를 통해 동작 가능하다)로 처리할 수 있다.

How can we do this?

ffmpeg의 공식 문서들을 보면서 이를 이해해보았다.

ffmpeg는 로컬에 존재하는 파일의 타입을 설정해주어 원하는 미디어타입으로 파일을 바꾸어줄 수 있다.

이렇게 된 김에, 썸네일도 같이 만들어서 사용하자는 생각이 들었다.

머리속으로 동작 플로우를 그리고, 이를 부분별로 구현해보기로 했다.

1. 클라이언트가 보내준 파일을 로컬에 받는다.
2. 로컬에 받은 파일을 mp4(인코딩된 영상), png(썸네일)로 만들어준다. (이 때 webm파일을 지운다)
3. 해당 파일들을 s3로 클라우드 스토리지에 저장해준다. (이 때 mp4, png파일을 지운다)
4. 저장된 경로로 객체를 만들어, type-orm으로 저장한다.

구현 과정

Webm파일 받기

1단계로 디렉토리가 존재하는지, 파일이 있는지 확인하고 webm파일을 저장하는 로직을 만들었다.

멘토님께 사전에 몇 가지 질문들을 드려본 결과, 모든 로직이 비동기처리되는 것이 좋다고 하셨고, 파일과 같은 대용량 처리과정은 모두 비동기로 돌렸다.

인코딩하기

이후에 파일을 인코딩하는 로직을 만들었다.

입력과 출력 모두${디렉토리주소}/${파일명}.${확장자}로 주었을 떄, ffmpeg(${입력})으로 존재하는 파일을 인코딩하게 된다.

인코딩 된 파일은 .output(${출력})에서 출력에 맞게 인코딩 된다.

이 때 썸네일을 어떻게 뽑을까를 생각하다가, 단순하게 첫 프레임만을 가져오게 했다.

인코딩이 끝났을 때, .on('end', ()=> {//webm파일 삭제})의 플로우를 구현하게 되었다.

클라우드에 저장하기

로컬에 존재하는 s3파일도 전송해주어서, 저장하는 로직을 수행시켰다.

이 때 ContentType이라는 파라미터가 인식되지 않고, 저장된 클라우드 스토리지를 찾아보면 계속해서 application/octet-stream이라는 확장자가 존재할 때가 있었다.

이러한 확장자로는 저장된 url로 조회해도 영상과 썸네일이 웹에서 재생되는 것이 아닌, 저장의 방식으로 동작하는 문제가 있었다.

이를 위해 multer-s3를 설치하고 ContentType를 설정하니 제대로 저장되었다.

저장이 완료되었을 때, deleteFile을 진행시켜주었고 저장된 스토리지의 경로를 반환하게 했다.

s3객체에 들어가는 정보는 각 클라우드 스토리지마다 다르게 되어있다. (그런데, AWS의 S3라는 라이브러리를 모든 클라우드 스토리지에서 지원한다. 이게맞아...?)

또한, 해당 로직에 params가 존재하는데, 이를 간단하게 정리해보았다.

{
    Bucket // 저장할 버킷의 이름,
    ACL //해당 파일의 공개여부,
    ContentType //저장할 확장자,
    Key //스토리지에서 파일을 저장할 이름,
    Body //저장할 데이터
}

이제 다 모아버리기

기존의 pre-signed url을 보내고 그 다음과정인 테이블화 시키는 로직을 재사용했다.

이렇게 진행한 이유는, 기존 로직을 그대로 재사용하는게 Time Cost가 더 싸니까!!!

이런 비즈니스 로직을 만든 다음, 컨트롤러에서 해당 로직을 사용해야 한다.

이렇게 해서 컨트롤러에서 파일을 받아 저장을 진행했다.

미들웨어를 등록해, 토큰을 파싱해 회원 정보로 만들어주는 로직도 이전에 등록해두었다.

성공을 하게 되었다!!! 아래의 로그를 보면 정상적으로 파일을 삭제했다는 것도 확인할 수 있었다.

끝난줄 알았지??

이전 게시물, 도커에서 우리가 잊지 말아야 할 것이 있다.

도커라는 독립된 환경에서 프로젝트를 실행시키고,

즉, 도커라는 독립된 환경에서 ffmpeg라는 라이브러리를 받아서 사용한다는 것을 설명서(이미지)에 써주고, 가상 컴퓨터(컨테이너)가 가지고 있어야 한다는 것이다.

도커 환경에서, 자신의 상황에 맞게 ffmpeg를 등록해주자.

이렇게 해서 배포 서버의 도커 환경에서도 진행이 가능하게 되었다.

성공? 아니!

로컬 환경에서 약 20mb로 2분의 영상을 인코딩하고 클라우드 스토리지에 저장하는데에는 12초의 시간이 걸렸다.

하지만, 배포된 환경에서는 30초 이상의 시간이 소요되었다.

성능적으로 단일 영상 인코딩 기준으로 2.5배의 성능차이가 존재했다.

비동기적으로 동작하게 만들어서인지, 매 요청이 들어올때 이를 병렬적으로 처리하게 할 수 있었다.

하지만, CPU모니터링 결과 99.9%를 넘어버리며 서버가 꺼지는 사태가 발생했다.

이유를 생각해보았을 때,

• 단일 프로세스로 동작시키기엔 너무 대용량 작업이다. (한 사람이 약 30초마다 20MB의 영상을 보낸다면, 10명만 해도 30초마다 200MB씩 인코딩을 하게 한다. 그리고 우리는 프리티어다!)
• 서버 부하의 한계점
• nestjs에서 멀티 스레드로 작업하게 만들지 않았다.

이를 해결하기 위한 방안들을 생각해보았다.

• 큐를 구현해서, 하나씩 태스크를 처리하는 식으로 진행시킨다.
• 서버에 오토 스케일링을 달아서 요청이 많아질 때 마다 스케일업, 요청이 적어질 때 마다 스케일 다운을 진행한다.

여기에서 큐를 구현해, 하나씩 처리한다는 방식이 우리가 추가적인 과금 없이 클린한 무과금 토이 프로젝트를 진행하는 방법이라고 생각했다.

하지만 이것마저도, 요청이 많아졌을 때, 큐가 얼마나 받을 수 있는지, 그리고 받는다 하더라도 인코딩되고 테이블에 저장되기까지 얼마나 걸릴지가 문제가 되었다.

이러한 문제의 해결을 프론트엔드에서 ffmpegwasm을 통해 인코딩을 지원하게 했다.

하지만 이것마저도, 클라이언트 백그라운드에서 각자의 브라우저 메모리로 동작하기 때문에,

이를 아주 작게 잡는 모바일 브라우저에서는 동작하기 힘들다는 단점이 있다.

이를 최적화 시키고 더 나은 결과의 다음 포스팅을 쓰는 것이 앞으로의 가장 큰 과제이지 않을까 싶다.

그럼...twenty thousand...🔥