점핑배틀외주 프로젝트3-비디오 프록시 서버의 문제

결론

• zappa의 메모리 제한으로 실패. 그러나 로컬에서는 돌아가는 차이를 보임
  
• 결과적으로는 signedUrl을 쓰고 uuid를 파일명에 직접적으로 드러내지 않는 방향으로 코드를 보완함

  과정

  지난 프록시 서버 1편을 통해서 로컬에서는 돌아가는 프록시 서버를 만들었다.
  그러나 flask run과 달리 zappa를 통해 코드를 올리는 순간 비디오 서버가 죽으면서 로그를 확인하니 zappa서버의 메모리 용량을 초과하였다는 에러였다.

  why?

  람다는 간편함+경제성에 특화된 서버인만큼 여러가지 제약이 따른다.
  그중 하나가 임시메모리 및 임시 저장소의 크기 제한인데 비디오 파일의 경우 람다의 기본셋팅인 512mb를 한참 초과하기 때문에 직접적인 스트리밍 방식으로 구현을 하면 서버가 폭발하는 것이 당연했다.

  해결책

  여기에서 우리가 채택할 수 있는 해결책은 크게 3가지 이지만, 람다환경을 유지하고싶어하는 경우 채택할 수 있는 것은 2가지이다.
  첫번째로는 어차피 동영상의 규모가 작아 10000mb는 넘지 않으니, 비용이 추가부과될 것을 감안하고서라도 수동으로 구성에 들어가 임시 저장소 및 메모리의 용량을 늘려주는 방법이다.
  그러나 이 방법의 경우 생각보다 접속자가 많아진 우리 서비스의 특성상 람다의 경제성을 살리기 어렵다는 생각이 들어 두번째 방법을 활용하였다.

  채택한 해결책

  signedUrl을 쓸 경우 문제점 중 하나가 우리가 수동으로 파이어베이스의 write와 read를 막아놓더라도, 파일명을 알면 무제한 접근을 요청함으로써 회사 측에 피해를 줄 수 있는 여지가 있었다.
  그래서 우리는 파이어베이스의 권한설정 및 uuid의 노출방지 그리고 다운로드와 스트리밍에 대한 signedUrl의 시간을 따로따로 부과함으로써(스트리밍의 경우 보다 긴 시간 가능하도록+혹시나 모르니 다운로드의 경우 그보다 짧은 시간으로)인위적인 봇의 접근 등을 임시적으로 막았다.
  그러나 만일 서비스가 아주 커질 것을 고려한다면 차라리 프록시 서버 1편에서 만든 프록시를 ec2를 통해 띄우는 것이 보다 적합한 해결책이라 생각된다.