채팅 시스템 설계
라인,카카오톡, 디스코드, 페이스북 등의 채팅 시스템을 구현해볼 예정이다.
채팅 시스템 설계 구조
1) 모바일 & 웹 여부
- 모바일, 웹 둘 다 가능
2) 중요 기능
- 1:1 채팅
- 그룹 채팅 제공 ( 100명까지 참여 가능 )
- 사용자 접속상태 표시
3) 사용 규모
- 일일 DAU 5천만명 사용
4) 데이터타입 및 규모
- 텍스트만 주고 받음. 메세지 길이 100,000자 이하
- 채팅 이력은 영원히 보관.
통신 프로토콜
폴링
폴링은 클라이언트가 주기적으로 서버에 새 메세지가 있냐고 물어보는 방식.
폴링은 메세지가 없는 경우에 자원이 불필요하게 낭비된다.
롱 폴링
폴링의 비효율을 개선한 기법.
클라이언트가 서버와 연결 후, 새 메세지가 반환되거나 타임아웃 될 때까지 연결을 유지.
롱 폴링도 여러 단점이 있다.
- 다중 서버에서 메세지를 받은 서버는 해당 메세지를 수신할 클라이언트와의 롱 폴링 연결을 가지고 있지 않은 서버일 가능성이 있음
- 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 좋은 방법이 없음
- 여전히 비효율적. 메세지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속
웹 소켓
웹 소켓은 클라이언트와 서버가 양방향 통신으로 연결된 구조이다.
http 핸드셰이크를 절차를 거치고 웹소켓 연결로 업그레이드된다.
항구적인 연결이 만들어지고 나면 서버와 클라이언트는 비동기적으로 메세지를 전송할 수 있다.
해당 채팅 시스템에선 웹 소켓이 가장 효율적이므로, 웹소켓을 통해 구현할 예정이다.
개략적 설계안
무상태 서비스
해당 채팅 서비스에서 무상태 서비스는 로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스이다.
해당 무상태 서비스는 로드 밸런서 뒤에서 요청을 그 경로에 맞는 서비스로 정확하게 전달되면 된다.
상태 유지 서비스
채팅 서비스는 상태가 유지될 필요가 있다.
각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야하기 때문이다.
클라이언트는 한번 연결된 서버를 서버가 유지되는 한 변경하지 않는다.
제 3자 서비스 연동
채팅 앱에서 가장 중요한 제3자 서비스는 푸시 알림이다.
새 메세지를 받았다면, 앱이 실행중이지 않더라도 알림을 받아야한다.
규모 확장성
- 채팅 서버는 클라이언트 사이에 메세지를 중계하는 역할을 담당
- 접속상태 서버는 사용자의 접속 여부를 관리
- API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리
- 알림 서버는 푸시 알림을 전송
- 키-값 저장소는 채팅 이력을 보관
저장소
채팅 시스템에서 다루는 데이터는 보통 2가지이다.
1) 사용자 프로파일, 설정, 친구 목록과 같은 일반적인 데이터.
2) 채팅 시스템의 고유한 데이터로, 채팅 이력.
채팅 이력 데이터의 양은 엄청나고,
이 데이터 가운데 빈번하게 조회되는 것은 최근 주고받은 메세지.
검색 기능을 이용하거나, 특정 사용자가 언급된 메세지를 보거나, 특정 메세지로 점프하거나 하여 무작위적인 데이터 접근도 있긴 함.
1:1 채팅 앱의 경우 읽기:쓰기의 비율은 대략 1:1
해당 읽기/쓰기 연산의 패턴으로 추천된는 데이터베이스는 키-값 저장소.
키-값 저장소는
- 수평적 규모확장이 쉬움
- 데이터 접근 지연시간이 낮음
- 관계형 데이터베이스는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있음.
데이터모델
1:1 채팅을 위한 메세지 테이블.
해당 테이블의 기본 키는 message_id로 메세지의 순서를 쉽게 정할 수 있도록 하는 역할도 담당한다.
| message_id | bigint |
| message_from | bigint |
| message_to | bigint |
| content | text |
| create_at | timestamp |
그룹 채팅을 위한 메세지 테이블.
해당 테이블의 기본 키는 channel_id, message_id로 복합키를 사용한다.
| channel_id | bigint |
| message_id | bigint |
| message_to | bigint |
| content | text |
| created_at | timestamp |
메세지 id
message_id의 값은 고유해야한다.
id 값은 정렬 가능해야 하며, 시간 순서와 일치해야 한다.
이 두 조건을 일치하는 것은,
rdbms라면 auto_increment가 대안.
nosql이라면, 스노플레이크나 time_based uuid를 사용해야함.
상세 설계
서비스 탐색
서비스 탐색 서비스의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것이다.
추천 시에 사용되는 데이터로는 클라이언트의 위치, 서버의 용량 등이 있다.
사용 간으한 모든 채팅 서버를 등록시켜두고, 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라 주면 된다.
( 오픈소스 솔루션으로 아파치 주키퍼가 존재 )
1) 사용자 a가 시스템에 로그인 시도
2) 로드밸런서가 로그인 요청을 api 서버 중 하나로 요청
3) api 서버가 사용자 인증 처리하고 나면 서비스 탐색 기능이 동작하여 최적의 채팅 서버를 찾음
4) 해당 채팅 서버와 사용자 a가 웹소켓 연결을 맺음
메세지 흐름
1:1 채팅 메세지 처리 흐름
사용자 a -> b로 보낸 메세지의 처리 경로
1) 사용자 a가 채팅 서버 1로 메세지 전송
2) 채팅 서버 1은 id 생성기를 사용해 해당 메세지의 id 결정
3) 채팅 서버 1은 해당 메세지를 메세지 동기화 큐로 전송
4) 메세지가 키-값 저장소에 보관됨
5)
사용자 b가 접속중인 경우
- 메세지는 사용자 b가 접속 중인 채팅 서버 2로 전송됨
사용자 b가 미접속중인 경우
- 푸시 알림 메세지를 푸시 알림 서버로 보냄
6) 채팅 서버 2는 메세지를 사용자 b에게 전송. 사용자 b와 채팅 서버 2 사이에는 웹소켓 연결이 되어있는 상태이므로 그것을 이용.
여러 단말 사이의 메세지 동기화
사용자 a가 전화기와 랩톱 2의 단말을 이용하고 있다.
사용자 a가 전화기에서 채팅 앱에 로그인한 결과로 채팅 서버 1과 해당 단말 사이에 웹소켓 연결이 만들어져 있고,
랩톱에서 로그인한 결과로 역시 별도 웹소켓이 채팅 서버 1에 연결되어있는 상황.
각 단말은 cur_max_message_id라는 변수를 유지하는데, 해당 단말에서 관측된 최신 메세지의 id를 추적하는 용도.
아래 2가지 조건을 만족하는 메세지는 새 메세지로 간주.
1) 수신자 id가 현재 로그인한 사용자 id와 같다.
2) 키-값 저장소에 보관된 메세지로서, 그 id가 cur_max_message_id보다 크다.
cur_max_message_id는 redis와 같은 캐시로 디바이스별로 저장해두고,
메세지목록을 불러와서 해당 id보다 크면서 메세지 수신자가 동일하면 해당 디바이스 웹소켓에 메세지 전송.
소규모 그룹 채팅에서의 메세지 흐름
그룹 채팅에선 사용자마다 메세지 큐가 존재.
사용자 a가 메세지 전달하면, 사용자 b,c,d의 메세지 큐에 전달됨.
새로운 메세지가 왔는지 확인하려면, 본인의 메세지 큐만 보면 되니 메세지 동기화 플로우가 단순.
그룹이 크지 않으면 메세지를 수신자별로 복사해서 전달하는 비용이 문제가 되지 않음.
하지만, 그룹이 큰 경우엔 사용자 각각의 메세지 큐에 복사하는 것은 바람직하지 않음.
동일 메세지큐에서 여러 사용자가 동기화할 수 있도록 처리해야함.
ex)
1. 클라이언트 A가 메시지를 보냄 → WebSocket 서버에서 Kafka에 Publish
2. Kafka의 특정 토픽/파티션으로 메시지가 들어감 ( 채팅방 단위로 파티션 지정[파티셔닝] )
3. Consumer들이 이 토픽을 구독
4. Consumer는 "이 방에 누가 접속해 있나?"를 Redis 등에서 확인
5. 각 접속 유저의 WebSocket 연결로 메시지를 Push
접속상태 표시
접속상태 서버를 통해 사용자의 상태를 관리할 수 있다.
접속 상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부.
사용자 로그인
클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버는 a의 상태와 last_active_at 타임스탬프 값을 키-값 저장소에 보관한다.
해당 데이터를 기반으로 사용자는 접속 중인 것으로 표시된다.
사용자 로그아웃
키-값 저장소에 보관된 사용자 상태를 online -> offline으로 변경 시킨다.
접속 장애
인터넷을 통한 연결은 항상 안정적이지만은 않다.
사용자의 인터넷 연결이 끊어지면 클라이언트와 서버 사이의 맺어진 웹소켓 같은 지속성 연결도 끊어진다.
짧은 시간 인터넷이 끊겼다가 연결될때마다 사용자의 상태가 변경되면 좋지 않다.
해당 해결방법으로 박동(heartbeat) 검사가 있다.
온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 하고,
마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메세지를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지하는 것이다.
ex)
5초마다 박동 이벤트 전송. 30초 이상 박동 이벤트가 안올 시, 오프라인으로 변경.
상태 정보의 전송
상태 정보 서버는 발행-구독 모델을 사용하는데, 각각의 친구관계마다 채널을 하나씩 두는 것이다.
가령 사용자 a의 접속상태가 변경되었다면, 그 사실을 3개의 채널 a-b,a-c,a-d에 쓰는 것이다.
채널 a-b는 b가 구독, a-c는 c가 구독, a-d는 d가 구독하도록 하는 것.
그룹 크기가 작을 땐 해당 방법으로 해결되지만, 그룹이 크면 상태변화 1건당 그룹의 크기만큼 이벤트 메세지가 발행되어서 성능이 저하됨.
그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 갱신하고 시으면 수동으로 하도록 유도하는 방법이 있음.
댓글