앞선 게시글에서는 두 가지 방법으로 웹 설문 영상 응답 문항에서 사용할 영상에 대한 처리를 진행보았다.
썸네일 이미지 추출과 업로드와 동시에 자체적으로 인코딩을 시키는 방법이었는데, 두 가지 방법 모두 적절하지 못한 것으로 판단했다. 그렇기 때문에 새로운 방법을 강구하였고, 해결책으로 제시된 방법에 대하여 작성해보려고 한다.
요즘엔 대부분의 미디어 파일을 스마트폰에서 생성하고 소비한다.
웹 설문 응답 시에도 마찬가지일 것이다.
어차피 스마트폰으로 생성한 미디어 파일들을 usb든 클라우드 서비스든 한 번 거쳐서 pc로 옮긴 뒤 브라우저에서 업로드해야만 하는 불편함이 있다.
이런 불편함을 개선할 수 있다는 것이 이번 기능의 장점이 될 것이다.
카카오톡으로 영상을 주고 받아 본 경험이 있는 사람이라면, 아래의 전송 시 화질 옵션창을 본 적이 있을 것이다.
사진의 경우에는 일반, 고화질 혹은 원본으로 세 가지 옵션이 주어지는 것을 확인할 수 있다.
그런데, 동영상은 "원본" 옵션이 없다..?
일반화질이나 고화질 옵션을 선택하고 영상 파일을 전송하면, 압축중이라는 안내가 나타나면서 업로드되는 걸 볼 수 있다. 카카오톡이 제공하는 무료 동영상 압축 서비스나 마찬가지인 것이다.
그렇다면 카카오톡은 내가 전송할 파일을 어떤 형식으로 인코딩해서 보내주는 걸까?
테스트를 하기 위해서, 이전 게시글에서 사용하였던 h.265 코덱 파일을 다시 가져왔다.
카카오톡의 "나에게 보내기"를 통해 영상을 전달한 뒤 다운로드 받아 다시 한 번 정보를 확인해보았다.
파일 확장자는 mp4였고, 압축에 사용된 코덱은 고맙게도 가장 범용적이라고 할 수 있는 h.264였다!
그럼 이제부터 해줘야 할 작업은, 지금 참여중인 웹 설문과 영상 파일 인코딩용으로 사용할 카카오톡 챗봇을 서로 알 수 있게 연결해주는 작업이다.
진행중인 웹 설문과 카카오톡 챗봇을 이어주는 중간다리 역할이 필요한 것이다.
대략적인 데이터 흐름을 나타낸 아키텍처 도식을 아래에 나타내보았다.
웹 설문을 진행하는 경우, 이미지/영상 응답 문항의 경우에는 문항 고유 식별값이 생성되게 된다.
이 고유값은 데이터베이스에 기록되며 각 문항과 일대일로 데이터를 공유하게 된다.
웹 설문 내에서 데이터베이스와 문항을 잇는 식별값은 QR 코드에 포함되어 서버로부터 전달된다.
QR코드를 인식함과 동시에, 스마트 업로드 기능을 가진 카카오톡 챗봇으로 이동하게 된다. 챗봇은 식별값을 토대로 데이터베이스를 조회하여 응답해야 할 파일 유형이 이미지인지 영상인지를 판단하여 사용자에게 답변을 한다.
사용자가 유형에 맞는 파일을 업로드 하고 나면(영상의 경우), 압축이 끝난 파일을 s3로 옮겨준다. 이와 동시에 데이터베이스에는 식별값을 가진 테이블을 찾아, s3의 파일 위치를 알려주게 된다.
웹 설문 페이지의 이미지/영상 응답 문항은 현재 자신과 연결된 데이터베이스에 파일 정보가 들어있는지 계속해서 확인해야만 한다.
확인을 가능하게 하기 위해서는 서버와의 지속적은 통신이 필요한데, 이 때 사용하는 기법은 여러가지가 있다.
현재는 서비스의 규모나 동시 사용자수가 많지 않아서 polling 방식으로 구현되어 있다. polling 방식은 간단히 구현이 가능하지만, 불필요하게 네트워크 자원을 낭비한다는 단점을 가지고 있다.
간단히 설명해보자면 다음과 같다.
polling은 단순하게 생각하면, 지정된 주기에 따라 필요한 정보를 서버에게 요청하는 방법이다. 주기를 10초라고 한다면, 10초 한번씩 서버에게 되묻는 것이다.
이처럼 불필요하게 서버를 오가는 일이 계속해서 반복되는 것이 polling 기법의 문제이다.
이런 문제점을 해결하기 위해서 long polling 기법을 사용하기도 한다.
long polling 기법을 사용하게 될 때 얻게 되는 특징은 다음과 같다.
1.연결이 항상 유지
2.데이터 변경에 민감 -> 실시간 통신과 다름 없음
3.주기가 짧아진다면 polling보다 훨씬 데이터를 많이 보냄
long polling 방식을 사용하면 다소 서버 부하가 줄어든다. 클라이언트가 데이터를 요청한 뒤, 일정한 대기시간 이내에 돌려줄만한 데이터가 발생한 경우에만 서버가 응답을 하기 때문이다. 이는 데이터 변경히 빈번히 일어나는 경우에는 기본 polling 방식에 비해 크게 이점이 없다.
장기적으로 보았을 때는 socket 방식을 사용하는 것이 좋다. polling 방식의 경우 아주 많은 수의 클라이언트가 데이터 요청을 하는 경우 서버 부하가 극심해진다. 불필요하게 모든 클라이언트가 서버와의 연결 및 연결 종료를 반복하며 요청 및 응답을 하기 때문이다.
그에 비해 socket 방식은 polling처럼 요청 시 연결, 응답 시 연결 종료의 과정을 거치지 않는다. 지속적으로 연결을 유지하면서 데이터를 처리해주기 때문에 훨씬 부하가 적다.
[embedyt] https://www.youtube.com/watch?v=p57GyC2htWo[/embedyt]
이번 기능은 프론트엔드 개발자로 일하고 있는 내게 있어서는 새로운 도전이었다.
기존과는 달리 프론트에서 서버 작업까지 모두 내가 개발해내야하는 풀스택 프로젝트였기 때문이다.
python이라는 언어와 Django라는 새로운 프레임워크...
AWS와 kakao open builder(챗봇)까지...
다양한 기술들을 짧은 시간 안에 습득하며 나아가야했다.
모든 것이 새로웠기 때문에 개발이 순조롭지만은 않았다.
하지만 어려움을 겪었던만큼 결과물이 잘 나와서 만족스럽다.
첫 풀스택 프로젝트를 무사히 완결지은 덕분에 앞으로도 새로운 풀스택 프로젝트를 받게 되면 큰 두려움이나 부담감 없이 업무를 진행할 수 있겠다는 자신감을 얻을 수 있었다.
QR 스마트 업로드 기능은 기존에 다른 어느 곳에서도 볼 수 없었던 신규 기능이다. 마음으로 낳은 내 자식같은 녀석이라 하는 말이 아니라 진짜로 아직까지 본 적이 없어서 하는 말이다. 클라우드 서비스나 usb 연결 없이 파일의 이동성이 보장된다는 특장점을 살려, 앞으로도 더욱 활용성을 확대해나간다면 분명 차별화된 서비스로 거듭날 수 있을 것이다.
CSS의 현재와 미래, State of CSS 2022 - Google I/O (0) | 2022.05.30 |
---|---|
web의 현재 - Google IO 2022 [Google Chrome Developers] (0) | 2022.05.27 |
웹 설문 영상 미리보기 (video src에 사용되는 영상의 코덱) (0) | 2020.07.21 |
비동기 작업들(Async Processes)과 시한폭탄(timeout) (2) | 2020.07.15 |
Javascript 엔진 (0) | 2019.08.31 |
댓글 영역