Hacker News 의견
  • 한 스타트업이 "충분히 괜찮은" 지름길을 선택하고 나중에 최적화하는 전형적인 이야기임.

    • 한 회사에서 CPU 사용량이 높은 VM 클러스터가 있었고, 이를 최적화하기 위해 프로파일러를 사용했음.
    • 오래된 데이터를 삭제하고 쿼리에 필터를 추가하여 CPU 사용량을 줄였음.
  • 원시 비디오 데이터의 높은 대역폭이 놀랍다는 의견이 있음.

    • WebSockets의 설계 결정을 비판하며 CPU 사용량 문제를 예상하지 못했음.
  • AWS 문제가 아니라 CPU 사이클을 낭비한 문제라는 의견이 있음.

    • WebSockets는 데이터 전송이나 API 게이트웨이 비용과 관련이 있음.
  • TCP/IP 네트워크의 MTU와 MSS가 비디오 프레임 크기에 비해 작다는 점을 지적함.

    • 기술적 지식 부족을 지적하며 개발자를 고용할 필요가 있다고 주장함.
  • Chromium의 Mojo를 사용하여 플랫폼별 코드를 걱정할 필요가 없다는 의견이 있음.

    • 커스텀 링 버퍼 구현도 괜찮다고 생각함.
  • 네트워크 문제가 아니라 비디오 코덱에 대한 이해 부족이 문제라는 의견이 있음.

    • RDP와 같은 비디오 스트리밍 프로토콜을 사용하지 않는 이유를 이해할 수 없다고 함.
  • 투명성을 칭찬하며 제품 가격에 대한 투명성도 원한다고 함.

  • WebSocket 프로토콜의 마스킹이 중간자의 문제를 해결하려는 시도라고 설명함.

    • 관련 RFC를 읽어볼 가치가 있다고 함.
  • 비디오 데이터를 압축하지 않고 전송하는 방식이 이상하다고 지적함.

    • 압축된 스트림을 전송하지 않는 이유를 이해할 수 없다고 함.
  • 원시 비디오를 WebSocket으로 전송하는 초기 접근 방식이 놀랍다고 함.

    • 비효율성이 제품 개발에 방해가 되지 않았다고 함.
    • 데이터의 양을 고려하지 않는 접근 방식을 이해할 수 없다고 함.
  • 제품 개발 시 성능에 대한 고려는 전혀 없었다고 본다.
  • 이 문제는 결국 대량 데이터를 어떻게 IPC 할것 인지의 문제로 귀결됨.
  • 차이점은 일반적인 IPC가 아닌, 크롬 브라우져와 IPC 한다는 것이고
  • 크롬 브라우져 내부 방식은 그리 쉽지는 않겠지만, 오픈되어 있으니 수정은 가능
  • 그럼 결국 IPC 선택의 문제임

첨부터 개발을 잘못 했구만..

"원시 비디오를 WebSocket으로 전송하는 초기 접근 방식이 놀랍다고 함." 이 말에 공감.