주제 선정
가장 먼저 주제선정이 되어야 어떤 아키텍쳐, 기술 스택 등등 상세히 결정할 수 있는데, 우리 팀의 경우는 MSA, 부하 테스트 및 분석, 오토스케일링 등을 학습하고 경험해보고 싶었기에 기술을 위한 주제를 고려해보았다.
채팅방이나 표 예매 등의 주제는 부하가 걸리는 하나 혹은 두개의 작업에 대해서 부하 테스트를 진행하게 된다고 생각하여, 병목현상이 발생하는 지점, 부하가 걸리는 원인 등을 거의 알고 테스트를 진행하게 될 것 같다는 생각에 아쉬운 면이 있었다. 그런 중 개인 방송 스트리밍 서비스에 대한 얘기를 나누다가 외부 라이브러리(FFMPEG 등)을 포함하며 일련의 작업들 중 어디서 부하가 걸리는지 테스트를 통해 분석해가야한다는 점이 매력적이라서 선택하게되었다.
MSA? SOA? MA?
기존에 알고 있던 내용과 더불어 사실 MSA는 Monolithic한 서비스가 개선을 이루기 위해서 변경되는 것이지, 처음부터 그 구조를 잡을 필요가 없다는 매니저님들의 따듯한 피드백을 받으며 기가 꺾일 무렵, 아무리 생각해봐도, 우리 프로젝트의 구조상 Monolithic하게 개발하는 것이 실시간 스트리밍 서비스와는 맞지 않는다고 생각했다. (겪어보진 않았지만) 스트리머의 방송이 송출되는 순간부터 시청자가 그 영상 조각들을 웹 브라우저에서 받아 시청할 때 까지 비동기식으로 처리해야한다고 생각했다. 하지만 개발 초기부터 어떤 서비스를 어떤 수준으로까지 분리해야 좋은지 좋지 않은지에 대한 의사결정들을 할 수가 없기 때문에 MSA 이전에 큼직하게 서비스를 분리하여 먼저 SOA로 진행하며 더 분리될 서비스가 없는지, 어떤 서비스에서 부하가 많이 걸리는지 파악하기로 했다.
아키텍쳐
또한 시청자, 스트리머를 위한 api 서버, 스트리밍 인코딩 서버, ts파일로 변환하는 서버 크게 3개의 서버로 나누어생각했는데, 하나의 어플리케이션에서 모두 구동시키는 것이 좋아보이지 않았기 때문이다. 먼저 아키텍쳐를 위한 개발을 하기보다 개요만 잡아놓고 개발을 진행하자고 의견이 통합되어서 틀리더라도 아키텍쳐에 대해서 더 고민하지 않고 개발을 진행하기로 했다.
아래는 MSA, SOA를 겪어보지 않은 내가 추측한 아키텍쳐이다. RTMP 서버에 부하가 집중된다고 가정한 그림이며 실제로는 어떤 서비스에 부하가 걸릴 지 모르는 일이다.
멋진 팀장님이 FE BE CI/CD 파이프라인을 하루만에 구축해놓은 덕에 빠르게 개발을 진행할 수 있을 것 같다.
앞으로 Spring MVC 대신 WebFlux, JPA대신 R2DBC, 소켓까지 다뤄야하니까 머리가 좀 아플듯..
