개요
H사 면접을 보면서, 라이브 비디오 스트리밍에 대한 질문을 받았다.
비디오 라이브 스트리밍을 한다면 어떤 DB를 사용하실 건가요?
제대로 답변을 못했던 것 같아서, 면접이 끝난 후 고민을 해보았다.
서버를 어떻게 구성할까?
일단, 원시 비디오 데이터의 경우 바이너리 형태로 저장될테지만 HEX Data로 표현할 수도 있다.
용량이 매우 크고, 이를 일반적인 RDB나 NoSQL에 냅다 적재하기에는 매우매우 비효율적이라고 생각했다.
또한 라이브 스트리밍에는 보통 채팅도 있어야하고, 로그도 있어야 한다.
그래서 생각한 방법은 다음과 같다.
1. 비디오 데이터는 스토리지에 저장한다.
비디오는 대용량 파일이므로, 고성능 및 확장성을 제공하는 오브젝트 스토리지에 저장하는게 맞다고 생각했다.
선택지는 AWS S3, GCS, Azure Blob Storage 가 있을 것 같다.
2. 비디오 메타데이터 & 채팅 로그를 RDB에 저장한다.
ACID를 준수하고 데이터 무결성을 보장하므로, 비디오에 대한 메타데이터는 정형데이터이므로 RDB에 저장하는게 맞을 것 같다.
3. 채팅 메세지 데이터는 NoSQL에 저장한다.
채팅 메세지와 같은 비정형 데이터는 NoSQL에 저장하는게 좋다고 생각했다.(채팅 형식이 정해져있지 않기 때문)
아니면, 데이터레이크와 같은 원시형태로 저장하는 것도 좋은 방법일 것 같다.
4. 실시간 채팅 데이터 처리
실시간 채팅의 경우는 인메모리 DB인 레디스로 처리하면 좋을 것 같다.
실시간 이라는 단어에 맞으려면 빠른 처리속도를 가져야 하기 때문이다.
5. 모니터링
실시간 모니터링의 경우 시계열 데이터를 다루므로, InfluxDB, Prometheus 등을 사용하면 좋을 것 같다.
물론 엄연히 말하면 Prometheus는 DB는 아니지만 내장형 시계열 데이터베이스를 가지고 있으므로 포함시켰다.
마지막으로
회고를 해보니 정말 잘못 대답했다는 것을 깨달았다.
비디오 라이브 스트리밍을 한다면, 서버내부에선 이런 절차로 될 것 같다.
인코딩 -> 세그먼트로 쪼개기 -> 비디오 패키징(HLS프로토콜) -> 컨텐츠 배포(CDN) -> 메타데이터 생성(m3u8)
전체적인 프로세스는 이럴 것 같다.
요청 -> 서버 내부 처리 -> 메타 데이터 반환 -> 비디오 세그먼트 url목록 얻음 -> 비디오 세그먼트 요청 & 재생 -> 다음 세그먼트 미리 요청 -> 반복
이제와서 생각하면 비디오 데이터 자체는 스토리지에 저장해야 한다고 생각하는데 그때 당시에는 Rdb만 생각났으니.. ㅠㅠㅠ
