확장성

Liboo 프로젝트의 처음 구조를 설계할때는 아래 그림과 같은 구조였습니다.

image.png

저희 서버는 네이버 부스트캠프 최종 발표 시점에 생기는 부하를 감당할 수 있을 정도로 설계를 해보는 것이 목표였습니다.

그림이 다소 난잡하지만 주요한 부분은 RTMP 서버, 메인 (API) 서버, 그림에는 없지만 채팅 서버를 전부 분리했다는 점입니다.

이렇게 분리했던 이유는 RTMP 서버는 RTMP 스트림 데이터를 HLS 세그먼트와 index 파일로 트랜스파일링 하는, CPU intensive 한 작업을 많이 할 거라고 생각했기 때문입니다.

그에 반해 API 서버는 클라이언트의 요청을 처리하면서 메모리와 DB I/O 에 더 집중적이고,

채팅 서버는 사용자 수가 매우 많아진다면 동시에 처리 하는데 CPU 를 많이 쓸 수 있겠지만 기본적으로 메모리와 네트워크 처리량이 조금 더 집중적이라고 생각했습니다.

RTMP, API, 채팅 서버가 하나의 서버로 관리된다면 RTMP 스트림 처리 작업을 위해서 CPU 사용량이 과도하게 높아지면 서버를 스케일링할 때 API 와 채팅 서버도 같이 늘어나야 합니다.

저희는 서버를 각각의 역할에 맞게, 집중적으로 사용하는 부분에 맞게 분리를 해서 서버 스케일링이 효율적으로 이루어질 수 있도록, 확장성을 고려해보는 것이 이번 프로젝트의 가장 큰 목표였습니다.

image.png

전체적인 서버의 아키텍처 구조는 위와 같습니다.