WebRTC를 연결하기 위한 사용자의 미디어 정보와 ICE 프레임워크를 통해 나온 네트워크 정보들을 중계해주는 역할을 하는 시그널링 서버를 구축했다.
이때 다수의 사용자들이 서버에 접속하기 위한 트래픽을 견디기 위해서는 Scale out이 필요했는데,
이를 위해서는 다중 인스턴스를 고려해야했었다.
TCP를 연결하는 소켓 서버이기 때문에 다중 인스턴스로 설계할때 어떤 방식으로 설계해야하는지가 정말 중요했다.
만약 제대로 설계하지 않는다면 세션 컨트롤에 많은 문제점이 생겼을 것이다.
우선 우리 팀이 생각한 방식은 아래 그림과 같다.
그림을 설명하자면,
각 시그널링 서버의 인스턴스에서 사용자와 연결된 세션 수를 Redis에 캐싱을 하고, Channel 서버에서는 캐시를 확인해서 사용자가 새로운 음성 채팅 룸을 생성할 때 가장 적은 세션 수를 갖고 있는 인스턴스로 세션이 연결될 수 있도록 해당 음성 채팅 룸에 해당 인스턴스의 고정 URL을 부여해주는 방식이다.
이러한 방식을 사용했을 때 한 음성 채널의 사용자들은 하나의 인스턴스로 몰리기 때문에 한 채널에서 사용자간의 이벤트 발생 시 다른 인스턴스를 건너 찾을 필요가 없어지며, 관리하기도 편해졌다.
그러나 이 방법의 단점으로는 scale out을 계속 실행할때면 해당 인스턴스의 맞는 URL을 Channel Server와 사전 협의해야한다는 번거로움이 있었다.
반응형
