프로젝트 개발 동기 및 개요
페이스타임같은 화상통신을 만들어보고자 하였습니다. WebRTC와 Socket.io를 이용하여 구성하였고, ICE(Interactive Connectivity Establishment)를 공유하기 위한 시그널링
서버입니다.
만약, 이용자가 많아진다면 어떻게 처리해야 하는가를 고민하다 로드밸런서에 대해 알게되었고, nginx와 같은 웹 서버 소프트웨어보다는 시놀로지 nas에서 기본제공하는 리버스
프록시를 이용하고 내부적으로 PM2의 클러스터를 늘려 라운드로빈 방식으로 로드밸런싱을 하였습니다.
클러스터를 늘린 후 발생한 문제는 각 클러스터는 각자의 독립적인 인스턴스이기에 소켓 이벤트를 공유하지 못하였고, 이를 해결하기 위해 가벼운 Redis를 어댑터로 끼워 메시지
브로커로 활용하며 무중단 배포와 다중 클러스터 간 이벤트 공유를 해결하였습니다.
프로젝트 스크린샷
WebRTC
WebRTC(Web Real-Time Communication)은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림할 뿐 아니라, 임의의 데이터도
교환할 수 있도록 하는 기술입니다. WebRTC를 구성하는 일련의 표준들은 플러그인이나 제 3자 소프트웨어 설치 없이 종단 간 데이터 공유와 화상 회의를 가능하게 합니다.
- 발췌: https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API
Socket.io & Redis
Socket.IO는 웹 소켓 연결을 통해 클라이언트와 서버간에 실시간 양방향 통신을 가능하게하는 JavaScript 라이브러리입니다.
하지만 싱글스레드인 node를 기반으로 한 환경에서 돌아가고 있기에 클러스터가 늘어나도 서로 인스턴스를 공유하지 못하고 각자의 인스턴스만 관리하게 됩니다. 하여, Redis를
어댑터로 끼워서 이벤트가 발생 시 다른 클러스터의 인스턴스도 공유할 수 있게 해 주었습니다.
프로젝트 코드 일부
깃허브 저장소 주소로 대체합니다. [Click Me!]
프로젝트 후기
Java에 비해 장점이자 단점인 싱글스레드 환경에서 스프링처럼 실행하려면 어떻게 해야 할까의 문제를 pm2를 활용하여 해결할 수 있었습니다. 하지만 클러스터를 늘린 후 이벤트가
서로 공유되지 못하는 것을 알아보다가 메시지 브로커에 대해 알게되었고, 평소 속도가 빠른 인메모리 DB의 용도로만 레디스를 사용하던 것을 pub/sub패턴으로 다른 인스턴스에서
공유시키도록 하는 것을 공부하며 MSA 환경에서 어떻게 처리해야 하는 지 많이 배웠습니다. 이후에는 Kafka, RabbitMQ등 새로운 메시지 브로커 활용에 도전해 볼 생각입니다.
또한, 시그널링 서버의 테스트를 위한 게이트웨이를 한개 더 생성하였는데, https를 따로 등록해주어야 하는 부분에서 많은 시간이 소요되었습니다. 발급된 인증서 자체는 도메인을
같이 쓰니 재사용하는게 맞고, 뷰페이지용 컨트롤러가 연결된 서버와 소켓 게이트웨이가 연결된 서버 각각에서 https를 따로 얹어 줘야 하는 부분을 알아보며 nest환경의 서버
구조, https인증에 있어 설정 방법 등 많은 배움이 있었습니다.
다른 기발한 아이디어가 있으신가요?
주니어 개발자로써 많은 것을 배우고 제작해보고싶습니다. 현재 프로젝트에 추가되었으면 하는 기능이나, 완전히 새 프로젝트에 대한 아이디어가 있으시면 저에게 연락주시면 감사하겠습니다.