12월 15일 - boostcampwm2023/web07-GBS GitHub Wiki

예상 질문

  1. 왜 서버를 여러 대 사용하셨나요?

    1. 서버 수평 확장을 위해 여러대 사용했습니다.

    서버를 기능 별로 분리해 서버를 각각 확장하기 위해서 입니다.

    예를 들어 인코딩에 부하가 크면 인코딩 서버만 늘리고,

    스트리밍 서버에 부하가 몰리면 스트리밍 서버만 늘릴 수 있도록 하기 위해서 입니다.

  2. 혹시 최대 접속 사용자 목표치가 있나요?

    1. 1000명

  3. OBS를 도입한 이유가 궁금해요!

    1. 스트리밍 데이터를 전송하는 툴로 OBS가 많이 쓰이고 직접 만들기엔 시간이 부족했습니다.

  4. zoom은 전송 지연시간이 짧은것같은데 15초 걸리는 이유는 뭘까요??

    1. Zoom은 WebRTC를 사용해서 P2P 방식으로 동작해서 딜레이가 적을 수 있습니다.
    2. RTMP + HLS 방식은 구조상 딜레이를 없앨 수는 없습니다.
      1. 추가 개선사항 : 직접 모듈 개발하기

  5. 부하테스트 툴 중에서 nGrinder를 선택하신 이유는 뭔가요

    1. 구현에 많은 시간을 써서 익숙한 것을 선택했습니다.
    2. 시간이 많지 않았는데 이미 배웠던 기술이라 새로 배울 필요 없이 바로 적용할 수 있었습니다. → 기술적 도전하겠다고 했는데 이미 배운거 사용 ㅋㅋㅋ

  6. Pub/Sub이랑 웹소켓은 다른 개념인가요?

    1. 네 다릅니다.
    2. WebSocket
      1. 양방향 통신: WebSocket은 클라이언트와 서버 간의 지속적인 양방향 통신 채널을 제공합니다. 클라이언트와 서버는 언제든지 서로에게 데이터를 보낼 수 있습니다.
    3. Pub/Sub
      1. 단 방향 통신: 이 모델에서는 '발행자(Publisher)'가 메시지를 발행하고 '구독자(Subscriber)'가 이 메시지를 받습니다. 보통 서버가 메시지를 발행하고 클라이언트가 이를 구독합니다.
      2. 분산 통신: PUB/SUB은 분산 시스템에서 사용하기에 적합합니다. 여러 구독자가 특정 주제의 메시지를 구독할 수 있으며, 서버는 해당 메시지를 모든 구독자에게 전송합니다.
  • 실시간 스트리밍 트러블 슈팅 부분에서 왜 호환성 문제라고 생각을 하셨나요
    • 인코딩 방식을 바꾸니 에러가 해결됐기 때문
  • 왜 이런 기술적 도전과제를 선정했나요?
    • 저희 모두 스트리밍 서비스가 어떻게 동작하는지 궁금했고, 다른 크롤링, CRUD 같은 것들은 다른 프로젝트에서 많이 해봤기 때문입니다.
  • 기술 스택을 선택한 이유는 무엇인가요? 어떤 대안이 있었나요?
    • 장단점을 비교해보고 저희 상황에 적합하다고 판단되는 기술 스택을 선택했습니다.
    • 어떤거 비교했지?
      • TypeORM vs Sequelize.js ⇒ 함수 실행 속도도 TypeORM이 더 빠르고 쿼리 빌더 문법도 익숙한 QueryDSL과 비슷하고 비교적 깔끔하다고 생각해 선택했습니다.
      • Redis vs Kafka vs RabbitMQ
        • 스트리밍 플랫폼의 대규모 트래픽을 처리하기 위해서는 성능이 가장 뛰어나고 채팅이 디스크에 저장될 수도 있기에 Kafka가 적절하다. 하지만 Kafka의 러닝 커브가 좀 높아 Redis로 결정했습니다.
          Message Broker Scale Data Persistency
          Redis 초당 최대 백만 개 기본적으로는 불가능
          Kafka 초당 최대 수백만 개 영속성 지원
          RabbitMQ 초당 약 5만개 둘 다 가능
      • WebRTC vs RTMP
        • WebRTC는 딜레이가 거의 없긴 하지만 P2P 방식이라 시청자가 무한히 많아질 수 있는 스트리밍 플랫폼엔 적합하지 않습니다.
      • NoSQL vs RDBMS
        • 유저 정보와 방송 정보 정도만 저장하게 될텐데 유저 정보를 저장하는 데는 데이터 구조를 명확히 정의하며 일관성을 지키기 위해서는 RDBMS가 적합합니다.
      • WebSocket vs Polling
        • 채팅을 딜레이 없이 실시간으로 사용자에게 보여주는 좋은 사용자 경험을 위해 Polling 보단 WebSocket을 사용하는 게 좋겠다고 판단했습니다.
    1. 팀문화
    2. 비대면으로 진행할 때 어려운 점

최종발표

멘토 질문

  • test code 를 어떤기준으로 했는지
  • 회고를 통해 어떤 것을 새로 시도하려고 했는지

멘토 감상평

  • PR, commit 수가 적고, 리뷰도 간단하더라
  • 주제 선정이유 및 ui와 관련한 고민이 있는지?
  • 팀멘토: “저는 발표 너무 재밌게 잘 들었어요. 보통 데모를 영상으로 많이 준비하는데 이렇게 라이브로 공유하면서 하는 방식이 신선하고 좋았습니다. 중간중간에 작은 사고(?) 가 있긴 했지만 크게 발표를 듣는데 지장을 주지는 않았습니다 ㅋㅋ 한 가지 피드백은 발표 스크립트를 읽는 느낌이 조금 들었는데, 그 부분은 개선이 조금 되면 좋을 것 같아요. 예를 들면 장표에 있는 내용을 그대로 읽는 건 피하면 좋겠어요. 더 자세한 내용은 최종일지 작성하는 부분에서 작성드려볼께요! ㅎㅎ 넘넘 고생 많으셨습니다”