채팅에도 여러 종류와 여러 요건이 따른다
채팅 요구사항에 대한 체크리스트로 다음과 같은 것들이 있다.
| 채팅의 규모 | 1:1채팅인가(ex. 페이스북)? 그룹채팅인가(ex.디스코드)? 그룹채팅이라면 인원의 제한이 따르는가? 예상 트래픽, 처리 기준이 얼마나 되는가? (ft.DAU) |
| 플랫폼의 종류 | 모바일앱인가 웹앱인가? 하나의 계정이 여러 단말기로 접속할 수 있는가? |
| 채팅 메시지의 제한 | 텍스트 이외의 파일, 링크 첨부 가능성이 있는가? 메시지 개당 길이의 제한이 있는가? 암호화의 필요성이 있는가? |
| 부가기능 | 읽음 표시가 필요한가? 접속 상태를 관리해야하는가? |
요구사항을 정립했다면 이 요구사항을 충족시킬 시스템의 아키텍처를 그려보고 싶은데, 그 전에 사전적인 지식을 다시 상기시켜볼 필요가 있다.
채팅은 송신과 수신의 통신 시나리오가 다르다
송신 시의 시나리오
가장 널리 쓰이는 HTTP 프로토콜 통신을 기준으로, 사용자가 어떻게 '채팅 메시지'를 송신하는지를 생각해보자
Client는 Server에게 메시지를 보낸다
좀 더 효율적으로 생각해보면, 아래처럼 표준 HTTP Header 중 하나인 'keep-alive'를 통해서 TCP 핸드쉐이크 횟수를 줄이는 선택지가 있다.
GET /index.html HTTP/1.1
Host: www.example.com
Connection: keep-alive
Keep-Alive: timeout=5, max=100메시지 전송을 끝낸 sendClient는 제 할 일이 끝났다.
수신 시의 시나리오
송신은 서버에 찌르면 끝났다. 서버는 그럼 해당 요청에 대해 반응하여 DB에 메시지를 저장하고 Client에게 메시지를 전송시킬 예정이다.
하지만 어떻게 수신지인 특정 Client를 찾아서, 그 Client의 단말기에 푸쉬알람이라든지 실시간 전송을 할 수 있을까?
최초에 Client는 메시지 전송을 위한 Server와의 HTTP 연결을 만들었는데, 반대로 Server가 Client에게 연결을 만드는 방법은 따로 없다. 최소한, receiverClient가 먼저 연결을 하고 메시지 수신을 대기하는 상태라든지, 주기적으로 있냐고 뜨문뜨문 물어보든지 해야한다.
구체화 해보면 위처럼 어떻게든 Client가 먼저 접근해야 하는 것이다.
이제 여기서 Polling, Long Polling, WebSocket 방식의 선택지가 있는데 길지 않은 고민으로 WebSocket을 선택하게 된다
Polling, Long Polling의 기대 상황
- HTTP 통신 바탕이므로, 다중화 서버를 관리하는 로드밸런서가 메시지를 전송해줄 서버를 잘못 선택할 가능성이 있다
(ft. 이중화된 서버에서의 Socket 통신)
- 서버는 Client가 연결을 해제했는지를 알 수가 없다
- 메시지를 주기적으로 받을 일이 없는 사용자임에도 필요이상의 주기적인 서버 접속이 일어난다
WebSocket의 기대상황
- 최초에는 HTTP 통신이긴 하나, TCP 핸드셰이크 절차 이후 웹소켓 연결로 업그레이드 된 이후엔 항구적인 연결이 된다
특성상 양방향 연결이니 송신, 수신 구분없이 동일한 통신 방식을 쓸 수가 있게 된다.
메시지에 대한 데이터베이스 선정
두괄식으로 말해, Key-Value형태의 NoSQL을 권장한다
상세히 말하면, 일반적인 데이터(User, Board, Group 등)는 RDBMS로 관리하되, '채팅메시지'에 대해서는 No-SQL(key-value) 저장소를 택하는 것이다. 그 이유는 채팅메시지 데이터의 특성에 따른다
채팅메시지 데이터의 특징
1. 데이터량이 독보적으로 많다
국내 메인 메신저인 카카오톡은 알림톡만 해도 1억 건을 넘는다고하며, 5년 전 기준으로 송수신 건은 100억건을 넘는다.
카톡 하루 평균 송수신 100억건...가장 많았던 날은?
카카오가 지난해 이용자들이 카카오톡 대화를 가장 많이 나눈 날을 뽑았다. 전체 수발신 메시지 수를 기준으로 선정했다. 순위만 보고 있어도 지난해 있었던 큰 이벤트들이 주마등처럼 스쳐 지
zdnet.co.kr
출시 8년째 맞은 카톡 알림톡…"하루 최대 1억건 발송" | 연합뉴스
(서울=연합뉴스) 홍국기 기자 = 카카오톡 알림톡이 오는 22일로 출시 8년을 맞은 가운데 하루 최대 발송량이 1억건을 돌파한 것으로 나타났다.
www.yna.co.kr
2. 가장 최근에 생성된 메시지가 많이 읽힌다
사용자는 오래된 메시지를 볼일이 많지 않다. 최근일 수록 메시지를 빈번하게 조회한다
3. 검색 등으로 인해 무작위 데이터 접근이 일어날 수도 있다
4. 읽기 행위가 빈번하게 일어난다
쓰기도 있지만, 특히나 읽기 빈도가 더욱 빈번하다
Key-Value 데이터베이스 저장소의 특징
빠른 무작위 접근
키값저장소의 특성상, 특정 키에 대한 데이터의 빠른 검색이 지원된다
또한 사용자가 검색 등으로 채팅 메시지 중간의 어느 특정 메시지로 이동하고자 한다면, 이 비순차적 접근을 최적할 수 있게된다
높은 읽기 성능
빈번한 읽기 행위에 대하여, 키 값은 우수한 성능을 보인다
특히나 분산 시스템이기에 쉬운 확장을 통하여 데이터가 증가하더라독 성능 저하를 줄여 처리가 가능하다
효율적인 데이터 저장
채팅 메시지가 단순한 구조를 가지므로, 고유 ID를 통해 저장을 하고, 빠르게 접근이 가능해진다
분산 시스템에서도 데이터의 일관성을 유지할 수 있다
무엇보다 실시간 데이터 처리가 핵심인 채팅메시지에서 그 지연을 최소화할 수 있다는 장점이 독보적이고, 실제로 디스코드나 페북 메신저에서도 HBase, 카산드라 등의 저장소를 택한 이유 중 하나일테다.
끝으로, 현재 서버는 모놀리식처럼 보인다. 다음에는 이 서버를 기존보다 효율적으로 설계하는 방법을 파헤쳐볼 것이다.