개발/영상통화

webrtc 서버 구축 3편 -시그널링 서버 분산처리(세션정보 관리)

키드 뮤지션 2021. 10. 22. 21:20

이어지는 시리즈이기 때문에

https://kid-dev.tistory.com/4

 

[언택트 기술 시리즈]webrtc 서버 구축 1편 -기초

아자르, 스무디, 행아웃 언택트 시대하면 위 서비스들을 한번쯤은 들어보거나 사용해봤을 것이다. 맞다. 위 서비스들은 webrtc로 만들어진 서비스 들이다. 'webrtc = 영상통화,화상회의'라고 말할수

kid-dev.tistory.com

https://kid-dev.tistory.com/5

 

[언택트 기술 시리즈]webrtc 서버 구축 2편 -시그널링 서버를 구축 하자.

드디어 webrtc 서버 구축 2탄~~ 시그널링 서버를 구축하자!! webrtc 시그널링 서버가 무엇인지 모르겠다면 시리즈 전편을 확인하자. https://kid-dev.tistory.com/4 [언택트 기술 시리즈]webrtc 서버 구축 1편 -

kid-dev.tistory.com

 

두개를 꼭 읽고 오길 권장합니다. 

 

그럼 시작~~

 

"webrtc 시그널링 서버 분산처리를 어떻게 할수 있을까?"

 

2편에서 시그널링 서버 구축 기초를 설명하며 마지막으로 던졌던 질문이었다. 물론 여기에 해답이 아하 하고 떠오른 사람이 있을수도 있다.(대단한 사람~~) 그중에는 LB 달면 되지 않나요? 라고 말하는 사람도 있을수 있다. 물론, 세션서버(http 서버)는 그렇게 분산처리 할수 있다. 하지만 문제는 채널 서버(websocket 서버)이다. 세션서버와 채널서버가 무엇인지 모르겠다면 시리즈 전편(https://kid-dev.tistory.com/5)을 읽고 오길 바란다. websoket 서버는 LB 또는 http gateway 가지고는 분산처리를 할수가 없다. 그럼 어떻게 분산처리를 하면 될까? 

 

 

위 그림처럼, 세션서버에서 어떤 채널서버로 가야 할지 정해주면 된다. 그렇다면 세션서버는 각 채널서버에 몇명의 user가 접속하고 있는지에 대한 정보를 저장해야만 한다. 뿐만 아니라, channel server에 새로운 user가 들어왔을때, 또는 나갔을때, session server에게 해당 정보를 알려줘야만 한다. 그역할을 위해 redis와 zookeeper가 필요하다. 

 

redis: 세션 정보 저장 역할

zookeeper: channel server의 생사 여부및 새로운 유저가 들어왔거나 나갈때, session server에 알려주는 역할

 

 

redis

여기서 세션 정보란 무엇일까? 

 

각 room에 누가 접속해 있는지

어떤 room이 있는지

각 room은 어떤 channel server에 접속해 있는지

(결국 자원의 낭비이기 때문에 큰이유가 없다면 같은 room이라면 같은 channel server에 접속해 있는것이 좋다. ) 

 

그럼 위 정보를 이용해서 redis를 정규화 해보면 다음과 같다.

이름 key value
userinfo roomId userIds(list)
serverinfo roomId serverName(string)

roominfo 각 각 room에 어떤 user가 있는지를 저장하고 있는 key-value이다.

serverinfo는 각 room이 어떤 server에 있는지를 저장하고 있는 key-value이다.

 

그럼 정규화가 끝났는데 위 데이터 구조를 가지고 어떻게 세션 정보를 쌓고 어떻게 세션을 관리 하는 걸까?

다음 시퀀스 다이어그램을 한번 살펴보자.

 

1. room이 생성될때

 

1. Alice가 createRoom을 session server에게 요청한다.(roomId: roomA)

2. session server는 어떤 채널이 부하가 가장 적은지를 확인하고 CserverA로 결정한다(해당 내용은 다음 챕터에서 자세히 설명 예정이다.)

3. session server는 redis의 serverinfo에 key-value(roomA-CserverA)를 저장한다.

4. session server는 redis의 저장이 끝나면 roomId와 serverInfo를 Alice에게 return 한다.

5. Alice가 channel server에 입장하면, userinfo에 roomA-Alice를 추가한다.(in redis)

 

 

2. room에 들어갈때

1. Bob은 Alice에 만든 roomA에 들어가길 session server에 요청한다.

2. session server는 roominfo와 serverinfo를 조회해, room에 누가 있는지 그리고 어떤서버에 접속해 있는지를 Bob에게 return 한다.

3. Bob은 해당 채널서버에 roomA 채널에 들어간다. 

4. channel server는 redis에게 Bob을 추가 할것을 요청한다.

 

 

유저가 나갈때, 방이 폭파될때는 해당 db에 데이터를 지워주면 된다. 그럼 redis에 '각 room에 어떤 유저가 있는지', '각 room은 어떤 channel server에 있는지' 와 같은 세션 정보를 유지할수 있다.

 

세션정보를 어떻게 관리하는지에 대해서 다이어그램을 통해서 알아보았다. 

redis의 역할과 세션정보의 관리에 대해서 설명은 이정도면 충분한것 같다. 물론 redis도 분산처리해줘야만 한다. 실제로 redis가 가장 많은 부하를 받기때문에 여기저기 손이 많이 간다. 그 내용은 다음에 redis만 따로 설명을 하는 시간을 갖도록 하겠다.

 

내용이 너무 길어져 남은 내용들은 다음으로 내용을 넘겨야 할것 같다. 다음 챕터에서는

 

zookeeper의 역할

채널서버의 분산처리

 

에 대해서 중심적으로 다룰 예정이다. 정말 도움이 많이 될거니깐 꼭 시간내서 정독하길 바란다.