This repository has been archived by the owner on May 1, 2023. It is now read-only.
아키텍처
채팅 데이터(Message)를 RDBMS에 넣게 된다면?
짧은 시간에 많은 데이터 입력이 처리가 된다.
한정된 규모의 복잡성이 높은 데이터에서 단순한 대량의 데이터가 쌓이며 조회, 삽입이 빈번하게 일어난다.
Lock이 자주 발생
데이터가 쌓이게 되면 데이터베이스를 분산 시켜야한다.
RDBMS는 분산을 하기 쉽지 않다.
- RDBMS를 쓰되, Replication 하는 방법
- Master DBMS에는 데이터의 수정 사항을 반영만 하고 Replication을 하여 Slave DBMS에 실제 데이터를 복사한다
- RDBMS에 비해 읽기, 쓰기 작업의 성능을 높일 수 있다.
- 사용자가 늘어나도 수평적 규모 확장이 용이하기 때문에 대처가 가능
- join 연산이 불가능하다. 다른 테이블과 맵핑이 어렵다.
- 역시 데이터가 쌓일 수록 latency가 높아진다.
- application 측면에서 데이터를 결합하여 사용한다.
- 채팅 서버의 읽기 성능을 높히기 위해 redis를 사용.
- redis cache에서 읽기, 저장을 담당한다.
- 읽기, 쓰기 작업의 성능을 올리기 위해서
- 사용자 수에 따른 수평적 규모 확장을 용이하게 하기 위해서
- websocket을 통해 소통을하고 그 과정에 message queue를 넣는다.
어? 그러면 알림은 어떻게 처리하지?
- 접속 여부를 확인하는 로직을 두어서 확인한다.
- 접속중이면 클라이언트로 바로 메세지를 보낸다.
- 미접속이면 알림 서버로 push를 보낸다.
채팅 서버를 1개 둘거면 굳이 messege queue를 사용할 필요가 있나?
상태 관리를 기능으로 넣기에는 사용하는 부분이 너무 많아서 서버로 두기로 했다.
- 3개의 채팅 서버와 3개의 상태 관리 서버를 둔다.
채팅 채널을 각각의 웹 소켓으로 관리하기 때문에 유저간의 채팅 이슈가 발생할 수 있다.
- 메세지 로직을 거칠 때 상태 관리 서버를 통해 필터링을 해준다
상태 관리 서버의 동기화는?
- 상태 관리 서버의 세션은 redis에 저장하여 처리한다.
- redis replication을 통하여 동기화를 처리한다.
- 사용자 사이에 시그널링 서버를 두어 web RTC 연결을 시작한다.
- mesh 구조가 형성된다
- 소규모 연결을 생각 했을 때 적합하다.
- 인원이 많을 경우 부적합하다.
- 미디어 서버를 두어 다자간 커뮤니케이션을 적합하게 만든다.
- SFU 방식(중앙 서버를 통해 종단간 미디어 트래픽을 중계하는 중앙 서버 방식) 도입
- 채팅방에 접속된 유저 정보가 필요
- redis를 두어 세션을 관리
- 소수의 인원 , 다수의 인원에 따른 연결 방식 도입
- 소수일 경우 mesh 구조
- 다수일 경우 미디어 서버를 경유하는 방식
