-
Notifications
You must be signed in to change notification settings - Fork 0
서버 구조 설계에 대한 고민
스트리밍 데이터 수집은 RTMP 프로토콜
스트리밍은 HLS 프로토콜을 사용하기로 결정했다.
Twitch/AfreecaTV/Youtube Live 등 대부분의 스트리밍 플랫폼에서 RTMP 프로토콜을 사용해 데이터를 수집한다.
표준에 가까운 기술이기에 이를 채택했고 RTMP 방식으로 스트리밍 할 수도 있지만 대부분의 기기에서 사용 가능한 HLS를 채택했다.
RTMP 프로토콜로 스트리밍 데이터를 서버에 넘기는 오픈 소스 소프트웨어다.
대부분의 인터넷 방송에서 이를 사용하고 직접 만들어서 사용하는 건 프로젝트 의도에 맞지 않다고 판단해 그대로 사용하기로 결정했다.
유저 정보와 방송 정보 정도로 적은 데이터만 저장하게 될텐데
이는 명확한 스키마가 존재하는 RDBMS가 적합할 것 같다고 판단했다.
PostgreSQL과 MySQL을 고민했는데
복잡한 쿼리는 PostgreSQL이 성능이 좋지만, 간단한 쿼리만 사용할 거라 예상되고 특별한 기능이 필요하지 않기 때문에 MySQL을 채택했다.
API 서버를 위한 웹 프레임워크로는 NestJS를 선택했다.
Express 대신 NestJS를 사용하는 이유는
개발자의 자유를 어느 정도 제한해 가독성 좋고 일관성 있는 코드를 만들어내기 위함이다.
스트리밍 수신 서버와 인코딩 서버는 HTTP를 사용하지 않기 때문에
NodeJS의 Net 또는 Nginx를 사용해서 구현할 예정이다.
API (유저 관리) 를 severless로 하여 lambda → API Gateway 로 하는 것과 서버를 만들어서 NestJS를 사용하는 것을 고민하였다.
우리의 핵심기능은 스트리밍이고 그 외 유저 관리와 같은 것은 빠르게 끝내는 것이 중요하다고 생각했다.
그래서 대량 트래픽과 같은 것을 고려하지 않아도 된다고 생각했다. 빠르게 구현하는데 있어서 serverless 만큼 좋은게 없다고 생각했다.
그러나 부스트캠프에서 배운 것들을 적용해보고 학습하는 것 또한 중요했다. 이번 프로젝트는 물론 스트리밍이 중심 기능이지만, 학습 또한 중요하다. 그래서 NestJS를 사용하기로 결정하였다.
성격이 다른 서버들은 분리하려고 한다.
예를 들어 인코딩에 부하가 크면 인코딩 서버만 늘리고,
스트리밍 서버에 부하가 몰리면 스트리밍 서버만 늘릴 수 있도록 하기 위해서이다.
이 역시 Serverless로 구현할지 고민을 했다.
하지만, NCP의 API Gateway에서 데이터가 1GB당 요금이 100원으로 스트리밍 서비스 특성 상 용량이 많을 텐데, 이를 사용하면 주어진 20만원이 금방 없어질 것이라 생각했다.
그래서 아예 4개의 서버로 분리하려 하였다.
하지만, hls를 가져와 브라우저에 보내는 서버가 과연 필요할 지 의문이 들었다. Object Storage에서 프론트가 바로 가져올 수 있기 때문이다.
여기서 고려해야 할 점은 프론트에서 Object Storage에 접근할 때이다. 한번에 가져올 수 있는 object의 용량은 얼마인지, 가져오는데 시간을 얼마나 걸릴지를 고려해야 한다.