HLS 관련

• m3u8에서 .ts 내용을 두 개 지웠는데, EXT-X-MEDIA-SEQUENCE:2는 왜 2로 바꾸는 건가요? 지우면 0이 아닌가요?

  • SEQUENCE는 시작할 ts 번호를 뜻합니다. 따라서, 0, 1이 지워졌으니 2로 시작합니다

• 사용자에게 m3u8을 계속 파싱해서 주면, 서버의 오버헤드가 커지지 않을까요?

  • 현재의 방식은 캐시에 저장된 원본 m3u8 파일을 가져와서 사용자마다 다른 m3u8 파일을 파싱해줘서 내려주고 있는 상황인데,
  • 그 문제를 인지했고, 다른 방법을 찾아본 결과, 파싱 과정이 없으려면, 원본 생성 시에 모든 시간대 별로 파싱된 m3u8을 한 번에 저장하고 바로바로 꺼내오는 방식을 사용해야했는데,
  • 이는 빠르긴 하나, Object Storage의 리소스 낭비가 심할 뿐더러, 생성 시 오래걸린다는 단점이 있었습니다.
  • 또한, 기존처럼 그때그때마다 파싱해서 주는 방식의 응답 시간을 측정해본 결과, 사용자 입장에서는 크게 차이가 나지 않아서 이 방식을 선택하게 되었습니다.

• 캐시 매니저를 쓰면서 얼마나 향상되었는지

  • artillery(아틸러리)로 부하테스트를 해본 결과, 응답 평균 값이 1초에서 100~200ms로 감소가 된 것을 확인할 수 있었습니다. 테스트한 것 이외에도 서비스 안정성과, 리소스를 덜 낭비한다는 측면에서 이점을 기대할 수 있었던 것 같습니다

• 몇 명까지 입장 가능한지

  • 일단 hls와 소켓을 나눠서 테스트를 진행했는데, hls에 대한 테스트는 200명 정도 테스트를 진행해봤고, 소켓은 1000명 정도까지 테스트를 진행했는데, 사용자 경험 측면에서는 채팅이 살짝은 밀리지만 실시간성이 그렇게 크게 떨어지는 것 같지 않아서 괜찮다고 생각을 하고 있습니다.

소켓 관련

• WebSocket 안쓰고 socket.io를 사용한 이유는?
  • 한정된 시간 안에 결과물을 산출하려면, 아무래도 편리하고, nest와 잘 호환되는 소켓io를 쓰는 편이 좋을 것 같아 선택, 소켓 io는 강력한 자동 재연결 시스템이 구축되어 있어, 배포를 해도 끊어지지 않는 점에서도 선택
  • 또한 Socket io에서 제공하는 room 기능을 사용했기에 이 부분도 편하게 구현 할 수 있었음

CICD 관련

• 소켓이 끊어지지 않게 처리할 수 있지 않았는지?
  • 충분히 nginx를 사용해서 처리가 가능한 문제라고 생각합니다.
  • 다만, 메인 기능을 구현하는 데에 치중하여 이번에는 거기까지 문제를 해결하려고 하지 못했습니다.
  • 이후에 있을 리팩토링 기간이나 그 전에 이를 적용해볼 계획입니다.
• 코드 스타일을 맞추기 위해 CI 작업도 들어갔는지?
  • CI도 서로의 코드 스타일을 맞추고 일관적으로 코드를 작성할 수 있는 중요한 부분 중 하나라고 생각했습니다만, 처음 시도해본 배포에 대해 많은 시간을 사용해서, CI까지는 적용하지 못했습니다.

서비스 관련

• 협업 과정에서 빚은 마찰이나, 이를 해결했던 경험이 있나요? (너무 면접질문인가)
  • 일단 먼저 말씀드리고 싶은 것은, 저희는 항상 온라인 가상 환경에 모여 있으며, 즉각적인 커뮤니케이션을 바탕으로 협업을 해왔습니다.
  • 저희는 마찰이라고 부르기도 애매하지만, 생각하는 의견이 다르면 무조건 가상 회의실에서 해결책을 도출할 때까지 회의를 진행했습니다.
  • 의견을 주고 받을 때에는 항상 상대방에 대한 존중이 전제가 되며, 회의의 목적은 이기는게 아니라 모두의 의견을 충족시킴에 있음을 항상 상기하면서 진행하기 때문에, 빠른 시간 내에 서로의 의견이 상이한 부분들을 해결할 수 있었던 것 같습니다.