하루하루가 너무 바쁘게 흘러가고있다.
핑계라면 핑계지만 블로그에 글을 쓰지 못하고있는 이유도 그 때문이기도하다.
강박이 좀 있는지라 내가 모르는 것이나 뭔가 찝찝한 기분이 계속 든다면 해결이 될때까지 붙잡고있어야 마음이 편한데 결과가 꼭 좋은 것만은 아니다.
그 날로 중단하고 해야 할 것이 있다면 다른 일을 해야하는데 그것이 나와의 약속이라면 쉽지가 않다. 절제하는 연습을 늘려가야겠다.
여기까진 내 속마음이었고 드디어 내가 항해99를 해야겠다고 다짐한 이유이기도한 실전프로젝트가 시작되었다.
항해 초반 멘토님이 실전프로젝트에서는 서비스보단 챌린지 프로젝트를 진행하는 것이 포트폴리오에서 더 유리 할 것이다라는 말씀을 하셨고 나 또한 그 생각에 크게 동의했다.
서버 개발자는 사용자의 경험을 중요하게 생각해야하기 때문에 성능을 최적화하는데 능력이 뛰어나야한다고 생각을 했기 때문이다.
그래서 지금 진행하고 있는 것이 라이브 스트리밍 프로젝트를 진행하고 있는데 나는 맨 처음에 생각한 주제가 티켓을 예매하는 프로젝트를 통해 순식간에 몰리는 대용량 트래픽과 동시성 문제를 다룰수 있다는 점에서 매력적으로 느꼈는데 팀원 분들과 회의를 하다보니 라이브 스트리밍을 구현하다보면 결국엔 이 주제 또한 대규모 트래픽과 동시성을 경험 할 수 있으며 그 외의도우리 일상에는 흔하지만 개발에 있어서는 살짝 낯선 느낌이 있는 스트리밍이 매력적으로 다가왔다.
아키텍쳐 설계
처음 MSA를 구상했지만 MSA를 적용하기에는 규모가 너무 작기 때문에
MSA를 적용했을때의 이점이 없다. 그렇다고 Monolithic을 적용하기에는 적절하지않다는 생각이 들었다. 그래서 멘토님이 말씀해주신 서비스를 분리할 수 있는 SOA를 적용하기로했다.
실시간 스트리밍 하고있는 데이터를 rtmp프로토콜을 이용하여 ffmpeg으로 보낸 후 이 데이터들을 .ts파일과 .m3u8파일로 인코딩 한 후 s3로 업로드하는 방식을 선택했다.
채팅 기능에서는 mvc가 아닌 webflux프레임워크와 websocket 데이터의 빠른 전송이 가능한 redis, 대규모 트래픽에 용이한 kafka를 사용할 예정이다.
스트리밍은 동기식이아닌 비동기방식으로 구현해야 적합한 주제이기때문에 webflux를 선택하게됐다.
webflux를 경험해본 적이 없는지라 학습하는데 시간을 많이 사용했다.
2주동안 학습하는 시간을 가졌는데 아직 mvc만큼 이해가되지 않는다.
redis는 동시성 문제를 제어하기 위해 잠깐 사용해본적이 있고 websocket과 kafka는 이번이 처음인지라 배우고 학습하는데도 시간이 꽤 걸렸다. 이걸 어떻게 구현해야할까 막막하지만 이런 막막함을 통해 성장하기 위해 도전한 부트캠프이기 때문에 긍정적으로 생각해야겠다.
