채팅 시스템 설계
10 Feb 2022 | System Design
채팅 시스템 설계
1. 문제 이해 및 설계 범위 확정
채팅앱 유형 결정
- 페이스북 메신저, 카톡과 같이 1:1 채팅에 집중하는 앱
- slack 같은 그룹 채팅에 중점을 둔 앱
- Discord와 같이 대규모 그룹의 소통과 latency가 낮은 음성 채팅에 집중하는 앱
- 유형마다 시스템 설계가 달라지므로, 위 유형 중 어떤 앱을 설계 해야하는지 면접관과 소통을 해야 함
설계 범위 확인
- 1:1 및 그룹 채팅 지원 필요
- 모바일/웹 앱 지원
- DAU (Daily Active User) 기준 50M 명 처리 필요
- 100 명의 그룹채팅 인원 제한
- 사용자 접속상태 지원, 텍스트 메시지만 처리
- 메시지 길이는 최대 100.000자
- 채팅 이력은 영원히 보관
2. 개략적 설계안 제시 및 동의 구하기
- 채팅 시스템의 경우 클라이언트는 서로 직접 통신 X
- 위에 나열한 모든 기능을 지원하는 채팅 서비스와 통신
채팅 서비스가 지원하는 기능
- 그림 12-2 참고
- 클라이언트들로부터 메시지 수신
- 메시지 수신자 (recipient) 결정 및 전달
- 수신자가 online 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관
통신 프로토콜 결정
- 채팅 서비스의 경우 어떤 통신 프로토콜을 사용할 것인가는 아주 중요한 문제
- 메시지 발신의 경우, HTTP 프로토콜을 사용하는 것이 검증되어있는 방법, Keep Alive 헤더를 사용하면 TCP 접속 과정에서 발생하는 핸드셰이크 횟수를 줄일 수 있어 효과적
- 메시지 수신의 경우, 복잡함. HTTP는 클라이언트가 연결을 만드는 프로토콜이므로, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 것이 어려움
- 여러 우회 방안이 제시되는데 다음과 같다.
- 폴링 (polling)
- 롱 폴링 (long polling)
- 웹소켓 (WebSocket)
폴링
- 그림 12-3
- 클라이언트가 주기적으로 서버에게 새 미시지가 있냐고 물어봄
- 자주하면 자원을 많이 씀, 메시지가 없는 경우 자원낭비
롱 폴링
- 그림 12-4
- 폴링의 개선안
- 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지함
- 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내어 모들 절차를 다시 시작
- 약점
- 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하지 않을 수 있음, HTTP 서버들은 보통 stateless 서버 이므로, load balancer에 의해 수신 클라이언트와 송신 클라이언트가 다른 서버에 할당될 수 있다.
- 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 좋은 방법이 없음
- 여전히 비효율적, 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속함
웹소켓
- 그림 12-5
- 서버가 클라이언트에게 비동기(async) 메시지를 보낼 때 가장 널리 사용하는 기술
- 웹소켓 연결은 클라이언트가 시작, 한번 맺어진 연결은 항구적이며 양방향이다.
- 처음에는 HTTP 연결이지만 특정 핸트셰이크 절차를 거쳐 웹소켓 연결로 업그레이드
- 연결이 만들어지고 나면, 서버는 클라이언트에게 비동기적으로 메시지 전송 가능
- HTTP 또는 HTTPS 프로토콜이 쓰는 포트번호를 쓰므로, 방화벽이 있는 환경에서도 잘 동작함
- 메시지 발신 서비스 시에 HTTP 연결이 좋다고했지만, 웹소켓이 있는 이상, 수신 발신 서비스에 웹소켓을 사용하면 된다. (그림 12-6)
- 유의할 점은 웹소켓 연결은 항구적으로 유지 (dedicated)되어야 하므로, 서버 측에서 연결 관리를 효율적으로 해야 함
개략적 설계안
- 방금 클라이언트와 서버 사이의 주 통신 프로토콜로 웹소켓을 사용하기로 결정
- 하지만 다른 부분에서는 굳이 웹소켓 필요 X
- 회원가입, 로그인, 사용자 프로파일등의 대부분의 기능은 HTTP로 구현해도 무방함
- 점체 시스템의 개략적 설계안은 그림 12-7 참고
- stateless 서비스
- stateful 서비스
- 제3자 서비스 연동
Stateless 서비스
- 로그인, 회원가입, 사용자 프로파일 표시등을 처리하는 전통적인 request/response 서비스
- 무상태 서비스는 로드밸런서 뒤에 위치, monolithic 일수도, micro-service일수도 있음
- 이 서비스들 가운데 상당수가 시장에 완제품으로 나와 있어서, 쉽게 사서 쓸 수 있음
- 이들 가운데 주목할 서비스는 서비스 탐색 (service discovery) 서비스 : 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할
Stateful 서비스
- 채팅 서비스만이 상태 유지가 필요한 서비스
- 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 함
- 보통 서버가 살아있는 한 다른 서버로 연결을 변경하지 않음
- service discovery 서비스는 채팅 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 함
제3자 서비스 연동
- 채팅 앱에서 가장 중요한 서드파티 서비스는 푸시 알림
- 새 메시지를 받았다면 설사 앱이 실행 중이지 않더라도 알림을 받아야 함
- 10장 알림 시스템 설계 참고
규모 확장성
- 트래픽 규모가 얼마 되지 않을 때는 위 기능을 서버 한대로 구현 가능하나, SPOF 및 분산 처리등을 위해 다중 서버로의 규모확장을 해야 함
- 그림 12-8 참고하여 개략적 설계안 확인
- 채팅 서버는 클라이언트 사이에 메시지를 중계하는 역할
- 접속상태 서버 (presence server)는 사용자의 접속 여부를 관리
- API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리
- 알림 서버는 푸시 알림을 보냄
- key-value 저장소에는 채팅 이력(chat history)을 보관, 시스템에 접속한 사용자는 이전 채팅 이력을 전부 보게 될 것임
저장소
- 어떤 데이터 베이스를 쓸까? - RDBMS vs NoSQL
- 따져야 할 것은, 데이터의 유형과 읽기/쓰기 연산의 패턴
- 채팅 시스템이 다루는 데이터는 보통 두가지
- 사용자 프로파일, 설정, 친구 목록과 같은 일반적인 데이터
- 다중화(replication)와 샤딩(sharding)은 이런 데이터의 가용성과 규모확장성을 보증하기 위해 보편적으로 사용
- 채팅 시스템의 고유한 데이터인 채팅 이력 (chat history)
- 채팅 이력 데이터의 양은 엄청남, 페이스북 메신저나 왓츠앱은 매일 60B 개의 메시지를 처리
- 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지, 대부분의 사용자는 오래된 메시지는 들여다보지 않음
- 하지만 검색 기능을 이용하거나, 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프하는 일도 있으므로 이도 지원해야함
- 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1 정도
- 이 모두를 지원하기 위해 본 설계안에서는 key-value 저장소를 추천함
- key-value 저장소는 수평적 규모확장(horizontal scaling)이 쉬움
- 데이터 접근 지연시간(latency)이 낮음
- 관계형 데이터 베이스는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있음. 인덱스가 커지면 데이터에 대한 random access를 처리하는 비용이 늘어남
- 페이스북 메신저 (HBase), 디스코드(Cassandra) 등이 이미 key-value 저장소 사용 중
데이터 모델
1:1 채팅을 위한 메시지 테이블
message
-------
message_id : bigint (PK)
messge_from : bigint
message_to : bigint
content : text
created_at : timestamp
- 위는 1:1 채팅을 지원하기 위한 메시지 테이블의 사례
- PK (Primary Key)는
message_id, 메시지 순서를 쉽게 정할 수 있는 역할도 담당
created_at을 사용해서는 순서를 명확히 정할 수 없음, 서로 다른 두 메시지가 server time상으로 같은 시점에 생길 수도 있기 때문
그룹 채팅을 위한 메시지 테이블
group message
-------------
channel_id : bigint (PK)
message_id : bigint (PK)
message_to(from?) : bigint
content : text
created_at : timestamp
(channel_id, message_id)의 복합키(composite key)를 PK로 사용- 채널은 채팅 그룹과 같은 뜻, partition key로도 사용 : 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 할 것이기 때문 (exclusive)
메시지 ID
- message_id를 만드는 기법은 자세히 논의할 만한 가치가 있는 흥미로운 주제 (분산환경의 key-value store의 경우)
- message_id의 값은 고유해야 함 (uniqueness).
- ID 값은 정령 가능해야 하며 시간 순서와 일치해야 함. 즉, 새로운 ID는 이전 ID보다 큰 값이어야 함
- RDBMS는 auto_increment가 대안이나, NoSQL은 보통 해당 기능 제공 X
- Snowflake 사용 (7장 참고)
- 지역적 순서 번호 생성기 (local sequence number generator) 이용
- 지역적 : ID의 유일성은 같은 그룹 안에서만 보증하면 충분
- 메시지 사이의 순서는 같은 채널, 혹은 같은 1:1 채팅 세션 안에서만 유지되면 충분함
- 구현하기 쉬운 접근법
3. 상세 설계
- 채팅 시스템의 경우 가장 먼저 상세 설계를 진행할 부분은 서비스 탐색, 메시지 전달 흐름, 사용자 접속 상태 표시 방법 이다.
서비스 탐색
- 서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것
- 이 때 사용되는 기준
- 클라이언트의 위치 (geographical location)
- 서버의 용량 (capacity)
- 널리 쓰이는 오픈 소스 솔루션 : 아파치 주키퍼 (Apache Zookeeper)
- 사용 가능한 모든 채팅 서버를 여기 등록시켜 두고, 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라줄 수 있음
주키퍼로 구현한 서비스 탐색기능 (그림 12-11 참고)
- 사용자 A가 시스템에 고르인을 시도
- 로드밸런서가 로그인 요청을 API 서버들 가운데 하나로 보냄
- API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능 동작
- 해당 사용자를 서비스할 최적의 채팅 서버 탐색 (geological location, server capacity 고려) 예제에서는 서버 2가 선택됨
- 사용자 A는 채팅 서버 2와 웹소켓 연결을 맺음
메시지 흐름
- 채팅 시스템에 있어 종단 간 (end to end) 메시지 흐름을 이해하는 것은 흥미로운 주제
- 1:1 채팅 메시지 처리 흐름
- 여러 단말 간 메시지 동기화
- 그룹 채팅 메시지의 처리흐름
1:1 채팅 메시지 처리 흐름
- 그림 12-12 참고
- 사용자 A가 채팅 서버 1로 메시지 전송
- 채팅 서버 1은 ID 생성기를 통해 해당 메시지의 ID 결정
- 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
- 메시지가 키-값 저장소에 보관됨
- 사용자 B의 접속 유무에 따라
a. 사용자 B가 접속중인 경우 : 메시지는 사용자 B가 접속 중인 채팅 서버 (예제에서는 채팅 서버 2)로 전송
b. 사용자 B가 접속중이 아닌 경우 : 푸시 알림 메시지를 푸시 알림 서버로 보냄
- 채팅 서버 2는 메시지를 사용자 B에게 전송. 사용자 B와 채팅 서버 2 사이는 웹소켓으로 연결되어 있음
여러 단말 사이의 메시지 동기화
- 그림 12-13 참고
- 그림 12-13에서 사용자 A는 전화기와 랩톱의 두 대 단말을 이용 중
- 사용자 A가 전화기에서 채팅 앱에 로그인한 결과로 채팅 서버 1과 해당 단말 사이에 웹소켓 연결이 만들어져 있음
- 랩톱도 로그인 결과로 채팅 서버 1에 웹소켓 연결이 되어 있음
- 각 단말은
cur_max_message_id라는 변수 유지, 해당 단말에서 관측된 가장 최신 메시지의 ID를 추적하는 용도
- 아래 두 조건을 만족하는 메시지는 새 메시지로 간주
- 수신자 ID가 현재 로그인한 사용자 ID와 같다
- 키-값 저장소에 보관된 메시지로서, 그 ID가
cur_max_message_id보다 크다
cur_max_message_id는 단말마다 별도로 유지 관리하면 되는 값이라, key-value 저장소에서 새 메시지를 가져오는 동기화 작업도 쉽게 구현할 수 있다.
소규모 그룹 채팅에서의 메시지 흐름
- 발신자 입장 (그림 12-14 참고)
- 사용자 A가 그룹 채팅 방에서 메시지를 보냈을 때 어떤 일이 벌어지는지 보여 줌
- 해당 그룹에 3명의 사용자가 있다고 할 때
- 사용자 A가 보낸 메시지가 사용자 B와 C의 메시지 동기화 큐 (message sync queue) 에 복사
- 이 큐는 사용자 각각에 할당된 메시지 수신함 같은 것
- 이 설계안은 소규모 그룹 채팅에 적합한데, 이유는 다음과 같음
- 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되니까, 메시지 동기화 플로가 단순함
- 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않음
- 위챗(WeChat)이 이런 접근법을 쓰고 있음, 그룹의 크기는 500명으로 제한됨
- 수신자 입장 (그림 12-15 참고)
- 한 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야 함
- 메시지 동기화 큐는 여러 사용자로부터 오는 메시지를 받을 수 있어야 함
접속상태 표시
- 사용자의 접속 상태를 표시하는 것은 채팅 어플리케이션의 핵심적 기능 (카톡은 안됨…)
- 채팅 프로필에 녹색 점이 붙어있는 기능을 어떻게 구현할 수 있는지 살펴본다.
- 개략적 설계안에서는 접속상태 서버 (presense server)를 통해 사용자의 상태를 관리한다고 했었음
- 접속상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부라는 점 유의
사용자 로그인
- 그림 12-16 참고
- 사용자 로그인 절차에 대해서는 “서비스 탐색” 절에서 설명한 바 있음
- 클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속샅애 서버는 A의 상태와
las_active_at 타임스탬프 값을 key-value 저장소에 보관
- 이 절차가 끝나고 나면 해당 사용자는 접속 중인 것으로 표시될 것
로그 아웃
- 그림 12-17 참고
- key-value 저장소에 보관된 사용자 상태가 online에서 offline으로 바뀌게 됨
접속 장애
- 인터넷 연결은 언제든지 끊길 수 있음, 따라서 그런 상황에 대응할 수 있는 설계를 준비해야 함
- Naive하게 생각해보았을 때, 연결이 끊기면 offline, 다시 접속하면 online으로 바꾸면 됨
- 하지만, 연결이 짧은 시간 동안 끊기는 일은 너무 흔하다. 이럴 때마다 접속 상태가 변경된다면 UX적으로 좋지 않음
- 본 설계안에서는 heartbeat 검사를 통해 이 문제를 해결 (그림 12-18)
- 온라인 상태의 클라이언트로 하여근 주기적인 heartbeat event를 접속상태 서버로 보내도록 함
상태 정보의 전송
- 그림 12-19 참고
- 사용자 A의 친구들은 어떻게 해당 사용자의 상태 변화를 알게 될 것인가?
- 상태정보 서버는 publish-subscribe model을 사용, 즉 각각의 친구관계마다 채널을 하나씩 둔다.
- 위 방안은 그룹 크기가 작을 때는 효과적임, 위챗은 그룹 크기 상한을 500으로 제한하고 있어서 이 접근법 사용할 수 있으나, 그룹 크기가 더 커지면 이런 식으로 접속상태 변화를 알려서는 비용이나 시간이 많이 들게 됨
- 위 문제를 해소하는 방법은 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도
4. 마무리
정리
- 1:1 채팅과 그룹 태칭을 전부 지원하는 채팅 시스템의 아키텍처를 살펴 봄
- 클라이언트 - 서버 사이의 실시간 통신을 가능하도록 웹소켓 사용
- 실시간 메시징을 지원하는 채팅 서버
- 접속 상태 서버
- 푸시 알림 서버
- 채팅 이력을 보관할 key-value 저장소
- 이를 제외한 나머지 기능을 구현하는 데 쓰일 API 서버
추가 논의 가능 사항
- 사진이나 비디오 등의 미디어를 지원하도록 하는 방법 : 미디어 파일은 크기 크므로, 압축 방식, 클라우드 저장소, 썸네일 생성 등을 논의 가능
- 종단 간 암호화 : 왓츠앱은 메시지 전소엥 있어 종단 간 암호화 지원, 메시지 발신인과 수신자 이외에는 아무도 메시지 내용을 볼 수 없다
- 캐시 : 클라이언트에 이미 읽은 메시지를 캐시해 두면 서버와 주고받는 데이터 양을 줄일 수 있음
- 로딩 속도 개선 : slack은 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축하여 앱 로딩 속도를 개선 함 (참고)
- 오류 처리
- 채팅 서버 오류 : 채팅 서버 하나가 죽으면 서비스 탐색 기능이 동작하여 클라이언트에게 새로운 서버를 배정하고 다시 접속할 수 있도록 해야 함
- 메시지 재전송 : 재시도(retry)나 큐(queue)는 메시지의 안정적 전송을 보장하기 위해 사용되는 기법
참고자료
- 알렉스 쉬, 가상 면접 사례로 배우는 대규모 시스템 설계 기초 12장
채팅 시스템 설계
1. 문제 이해 및 설계 범위 확정
채팅앱 유형 결정
- 페이스북 메신저, 카톡과 같이 1:1 채팅에 집중하는 앱
- slack 같은 그룹 채팅에 중점을 둔 앱
- Discord와 같이 대규모 그룹의 소통과 latency가 낮은 음성 채팅에 집중하는 앱
- 유형마다 시스템 설계가 달라지므로, 위 유형 중 어떤 앱을 설계 해야하는지 면접관과 소통을 해야 함
설계 범위 확인
- 1:1 및 그룹 채팅 지원 필요
- 모바일/웹 앱 지원
- DAU (Daily Active User) 기준 50M 명 처리 필요
- 100 명의 그룹채팅 인원 제한
- 사용자 접속상태 지원, 텍스트 메시지만 처리
- 메시지 길이는 최대 100.000자
- 채팅 이력은 영원히 보관
2. 개략적 설계안 제시 및 동의 구하기
- 채팅 시스템의 경우 클라이언트는 서로 직접 통신 X
- 위에 나열한 모든 기능을 지원하는 채팅 서비스와 통신
채팅 서비스가 지원하는 기능
- 그림 12-2 참고
- 클라이언트들로부터 메시지 수신
- 메시지 수신자 (recipient) 결정 및 전달
- 수신자가 online 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관
통신 프로토콜 결정
- 채팅 서비스의 경우 어떤 통신 프로토콜을 사용할 것인가는 아주 중요한 문제
- 메시지 발신의 경우, HTTP 프로토콜을 사용하는 것이 검증되어있는 방법, Keep Alive 헤더를 사용하면 TCP 접속 과정에서 발생하는 핸드셰이크 횟수를 줄일 수 있어 효과적
- 메시지 수신의 경우, 복잡함. HTTP는 클라이언트가 연결을 만드는 프로토콜이므로, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 것이 어려움
- 여러 우회 방안이 제시되는데 다음과 같다.
- 폴링 (polling)
- 롱 폴링 (long polling)
- 웹소켓 (WebSocket)
폴링
- 그림 12-3
- 클라이언트가 주기적으로 서버에게 새 미시지가 있냐고 물어봄
- 자주하면 자원을 많이 씀, 메시지가 없는 경우 자원낭비
롱 폴링
- 그림 12-4
- 폴링의 개선안
- 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지함
- 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내어 모들 절차를 다시 시작
- 약점
- 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하지 않을 수 있음, HTTP 서버들은 보통 stateless 서버 이므로, load balancer에 의해 수신 클라이언트와 송신 클라이언트가 다른 서버에 할당될 수 있다.
- 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 좋은 방법이 없음
- 여전히 비효율적, 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속함
웹소켓
- 그림 12-5
- 서버가 클라이언트에게 비동기(async) 메시지를 보낼 때 가장 널리 사용하는 기술
- 웹소켓 연결은 클라이언트가 시작, 한번 맺어진 연결은 항구적이며 양방향이다.
- 처음에는 HTTP 연결이지만 특정 핸트셰이크 절차를 거쳐 웹소켓 연결로 업그레이드
- 연결이 만들어지고 나면, 서버는 클라이언트에게 비동기적으로 메시지 전송 가능
- HTTP 또는 HTTPS 프로토콜이 쓰는 포트번호를 쓰므로, 방화벽이 있는 환경에서도 잘 동작함
- 메시지 발신 서비스 시에 HTTP 연결이 좋다고했지만, 웹소켓이 있는 이상, 수신 발신 서비스에 웹소켓을 사용하면 된다. (그림 12-6)
- 유의할 점은 웹소켓 연결은 항구적으로 유지 (dedicated)되어야 하므로, 서버 측에서 연결 관리를 효율적으로 해야 함
개략적 설계안
- 방금 클라이언트와 서버 사이의 주 통신 프로토콜로 웹소켓을 사용하기로 결정
- 하지만 다른 부분에서는 굳이 웹소켓 필요 X
- 회원가입, 로그인, 사용자 프로파일등의 대부분의 기능은 HTTP로 구현해도 무방함
- 점체 시스템의 개략적 설계안은 그림 12-7 참고
- stateless 서비스
- stateful 서비스
- 제3자 서비스 연동
Stateless 서비스
- 로그인, 회원가입, 사용자 프로파일 표시등을 처리하는 전통적인 request/response 서비스
- 무상태 서비스는 로드밸런서 뒤에 위치, monolithic 일수도, micro-service일수도 있음
- 이 서비스들 가운데 상당수가 시장에 완제품으로 나와 있어서, 쉽게 사서 쓸 수 있음
- 이들 가운데 주목할 서비스는 서비스 탐색 (service discovery) 서비스 : 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할
Stateful 서비스
- 채팅 서비스만이 상태 유지가 필요한 서비스
- 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 함
- 보통 서버가 살아있는 한 다른 서버로 연결을 변경하지 않음
- service discovery 서비스는 채팅 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 함
제3자 서비스 연동
- 채팅 앱에서 가장 중요한 서드파티 서비스는 푸시 알림
- 새 메시지를 받았다면 설사 앱이 실행 중이지 않더라도 알림을 받아야 함
- 10장 알림 시스템 설계 참고
규모 확장성
- 트래픽 규모가 얼마 되지 않을 때는 위 기능을 서버 한대로 구현 가능하나, SPOF 및 분산 처리등을 위해 다중 서버로의 규모확장을 해야 함
- 그림 12-8 참고하여 개략적 설계안 확인
- 채팅 서버는 클라이언트 사이에 메시지를 중계하는 역할
- 접속상태 서버 (presence server)는 사용자의 접속 여부를 관리
- API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리
- 알림 서버는 푸시 알림을 보냄
- key-value 저장소에는 채팅 이력(chat history)을 보관, 시스템에 접속한 사용자는 이전 채팅 이력을 전부 보게 될 것임
저장소
- 어떤 데이터 베이스를 쓸까? - RDBMS vs NoSQL
- 따져야 할 것은, 데이터의 유형과 읽기/쓰기 연산의 패턴
- 채팅 시스템이 다루는 데이터는 보통 두가지
- 사용자 프로파일, 설정, 친구 목록과 같은 일반적인 데이터
- 다중화(replication)와 샤딩(sharding)은 이런 데이터의 가용성과 규모확장성을 보증하기 위해 보편적으로 사용
- 채팅 시스템의 고유한 데이터인 채팅 이력 (chat history)
- 채팅 이력 데이터의 양은 엄청남, 페이스북 메신저나 왓츠앱은 매일 60B 개의 메시지를 처리
- 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지, 대부분의 사용자는 오래된 메시지는 들여다보지 않음
- 하지만 검색 기능을 이용하거나, 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프하는 일도 있으므로 이도 지원해야함
- 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1 정도
- 사용자 프로파일, 설정, 친구 목록과 같은 일반적인 데이터
- 이 모두를 지원하기 위해 본 설계안에서는 key-value 저장소를 추천함
- key-value 저장소는 수평적 규모확장(horizontal scaling)이 쉬움
- 데이터 접근 지연시간(latency)이 낮음
- 관계형 데이터 베이스는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있음. 인덱스가 커지면 데이터에 대한 random access를 처리하는 비용이 늘어남
- 페이스북 메신저 (HBase), 디스코드(Cassandra) 등이 이미 key-value 저장소 사용 중
데이터 모델
1:1 채팅을 위한 메시지 테이블
message
-------
message_id : bigint (PK)
messge_from : bigint
message_to : bigint
content : text
created_at : timestamp
- 위는 1:1 채팅을 지원하기 위한 메시지 테이블의 사례
- PK (Primary Key)는
message_id, 메시지 순서를 쉽게 정할 수 있는 역할도 담당 created_at을 사용해서는 순서를 명확히 정할 수 없음, 서로 다른 두 메시지가 server time상으로 같은 시점에 생길 수도 있기 때문
그룹 채팅을 위한 메시지 테이블
group message
-------------
channel_id : bigint (PK)
message_id : bigint (PK)
message_to(from?) : bigint
content : text
created_at : timestamp
(channel_id, message_id)의 복합키(composite key)를 PK로 사용- 채널은 채팅 그룹과 같은 뜻, partition key로도 사용 : 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 할 것이기 때문 (exclusive)
메시지 ID
- message_id를 만드는 기법은 자세히 논의할 만한 가치가 있는 흥미로운 주제 (분산환경의 key-value store의 경우)
- message_id의 값은 고유해야 함 (uniqueness).
- ID 값은 정령 가능해야 하며 시간 순서와 일치해야 함. 즉, 새로운 ID는 이전 ID보다 큰 값이어야 함
- RDBMS는 auto_increment가 대안이나, NoSQL은 보통 해당 기능 제공 X
- Snowflake 사용 (7장 참고)
- 지역적 순서 번호 생성기 (local sequence number generator) 이용
- 지역적 : ID의 유일성은 같은 그룹 안에서만 보증하면 충분
- 메시지 사이의 순서는 같은 채널, 혹은 같은 1:1 채팅 세션 안에서만 유지되면 충분함
- 구현하기 쉬운 접근법
3. 상세 설계
- 채팅 시스템의 경우 가장 먼저 상세 설계를 진행할 부분은 서비스 탐색, 메시지 전달 흐름, 사용자 접속 상태 표시 방법 이다.
서비스 탐색
- 서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것
- 이 때 사용되는 기준
- 클라이언트의 위치 (geographical location)
- 서버의 용량 (capacity)
- 널리 쓰이는 오픈 소스 솔루션 : 아파치 주키퍼 (Apache Zookeeper)
- 사용 가능한 모든 채팅 서버를 여기 등록시켜 두고, 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라줄 수 있음
주키퍼로 구현한 서비스 탐색기능 (그림 12-11 참고)
- 사용자 A가 시스템에 고르인을 시도
- 로드밸런서가 로그인 요청을 API 서버들 가운데 하나로 보냄
- API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능 동작
- 해당 사용자를 서비스할 최적의 채팅 서버 탐색 (geological location, server capacity 고려) 예제에서는 서버 2가 선택됨
- 사용자 A는 채팅 서버 2와 웹소켓 연결을 맺음
메시지 흐름
- 채팅 시스템에 있어 종단 간 (end to end) 메시지 흐름을 이해하는 것은 흥미로운 주제
- 1:1 채팅 메시지 처리 흐름
- 여러 단말 간 메시지 동기화
- 그룹 채팅 메시지의 처리흐름
1:1 채팅 메시지 처리 흐름
- 그림 12-12 참고
- 사용자 A가 채팅 서버 1로 메시지 전송
- 채팅 서버 1은 ID 생성기를 통해 해당 메시지의 ID 결정
- 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
- 메시지가 키-값 저장소에 보관됨
- 사용자 B의 접속 유무에 따라 a. 사용자 B가 접속중인 경우 : 메시지는 사용자 B가 접속 중인 채팅 서버 (예제에서는 채팅 서버 2)로 전송 b. 사용자 B가 접속중이 아닌 경우 : 푸시 알림 메시지를 푸시 알림 서버로 보냄
- 채팅 서버 2는 메시지를 사용자 B에게 전송. 사용자 B와 채팅 서버 2 사이는 웹소켓으로 연결되어 있음
여러 단말 사이의 메시지 동기화
- 그림 12-13 참고
- 그림 12-13에서 사용자 A는 전화기와 랩톱의 두 대 단말을 이용 중
- 사용자 A가 전화기에서 채팅 앱에 로그인한 결과로 채팅 서버 1과 해당 단말 사이에 웹소켓 연결이 만들어져 있음
- 랩톱도 로그인 결과로 채팅 서버 1에 웹소켓 연결이 되어 있음
- 각 단말은
cur_max_message_id라는 변수 유지, 해당 단말에서 관측된 가장 최신 메시지의 ID를 추적하는 용도 - 아래 두 조건을 만족하는 메시지는 새 메시지로 간주
- 수신자 ID가 현재 로그인한 사용자 ID와 같다
- 키-값 저장소에 보관된 메시지로서, 그 ID가
cur_max_message_id보다 크다
cur_max_message_id는 단말마다 별도로 유지 관리하면 되는 값이라, key-value 저장소에서 새 메시지를 가져오는 동기화 작업도 쉽게 구현할 수 있다.
소규모 그룹 채팅에서의 메시지 흐름
- 발신자 입장 (그림 12-14 참고)
- 사용자 A가 그룹 채팅 방에서 메시지를 보냈을 때 어떤 일이 벌어지는지 보여 줌
- 해당 그룹에 3명의 사용자가 있다고 할 때
- 사용자 A가 보낸 메시지가 사용자 B와 C의 메시지 동기화 큐 (message sync queue) 에 복사
- 이 큐는 사용자 각각에 할당된 메시지 수신함 같은 것
- 이 설계안은 소규모 그룹 채팅에 적합한데, 이유는 다음과 같음
- 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되니까, 메시지 동기화 플로가 단순함
- 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않음
- 위챗(WeChat)이 이런 접근법을 쓰고 있음, 그룹의 크기는 500명으로 제한됨
- 수신자 입장 (그림 12-15 참고)
- 한 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야 함
- 메시지 동기화 큐는 여러 사용자로부터 오는 메시지를 받을 수 있어야 함
접속상태 표시
- 사용자의 접속 상태를 표시하는 것은 채팅 어플리케이션의 핵심적 기능 (카톡은 안됨…)
- 채팅 프로필에 녹색 점이 붙어있는 기능을 어떻게 구현할 수 있는지 살펴본다.
- 개략적 설계안에서는 접속상태 서버 (presense server)를 통해 사용자의 상태를 관리한다고 했었음
- 접속상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부라는 점 유의
사용자 로그인
- 그림 12-16 참고
- 사용자 로그인 절차에 대해서는 “서비스 탐색” 절에서 설명한 바 있음
- 클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속샅애 서버는 A의 상태와
las_active_at타임스탬프 값을 key-value 저장소에 보관 - 이 절차가 끝나고 나면 해당 사용자는 접속 중인 것으로 표시될 것
로그 아웃
- 그림 12-17 참고
- key-value 저장소에 보관된 사용자 상태가 online에서 offline으로 바뀌게 됨
접속 장애
- 인터넷 연결은 언제든지 끊길 수 있음, 따라서 그런 상황에 대응할 수 있는 설계를 준비해야 함
- Naive하게 생각해보았을 때, 연결이 끊기면 offline, 다시 접속하면 online으로 바꾸면 됨
- 하지만, 연결이 짧은 시간 동안 끊기는 일은 너무 흔하다. 이럴 때마다 접속 상태가 변경된다면 UX적으로 좋지 않음
- 본 설계안에서는 heartbeat 검사를 통해 이 문제를 해결 (그림 12-18)
- 온라인 상태의 클라이언트로 하여근 주기적인 heartbeat event를 접속상태 서버로 보내도록 함
상태 정보의 전송
- 그림 12-19 참고
- 사용자 A의 친구들은 어떻게 해당 사용자의 상태 변화를 알게 될 것인가?
- 상태정보 서버는 publish-subscribe model을 사용, 즉 각각의 친구관계마다 채널을 하나씩 둔다.
- 위 방안은 그룹 크기가 작을 때는 효과적임, 위챗은 그룹 크기 상한을 500으로 제한하고 있어서 이 접근법 사용할 수 있으나, 그룹 크기가 더 커지면 이런 식으로 접속상태 변화를 알려서는 비용이나 시간이 많이 들게 됨
- 위 문제를 해소하는 방법은 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도
4. 마무리
정리
- 1:1 채팅과 그룹 태칭을 전부 지원하는 채팅 시스템의 아키텍처를 살펴 봄
- 클라이언트 - 서버 사이의 실시간 통신을 가능하도록 웹소켓 사용
- 실시간 메시징을 지원하는 채팅 서버
- 접속 상태 서버
- 푸시 알림 서버
- 채팅 이력을 보관할 key-value 저장소
- 이를 제외한 나머지 기능을 구현하는 데 쓰일 API 서버
추가 논의 가능 사항
- 사진이나 비디오 등의 미디어를 지원하도록 하는 방법 : 미디어 파일은 크기 크므로, 압축 방식, 클라우드 저장소, 썸네일 생성 등을 논의 가능
- 종단 간 암호화 : 왓츠앱은 메시지 전소엥 있어 종단 간 암호화 지원, 메시지 발신인과 수신자 이외에는 아무도 메시지 내용을 볼 수 없다
- 캐시 : 클라이언트에 이미 읽은 메시지를 캐시해 두면 서버와 주고받는 데이터 양을 줄일 수 있음
- 로딩 속도 개선 : slack은 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축하여 앱 로딩 속도를 개선 함 (참고)
- 오류 처리
- 채팅 서버 오류 : 채팅 서버 하나가 죽으면 서비스 탐색 기능이 동작하여 클라이언트에게 새로운 서버를 배정하고 다시 접속할 수 있도록 해야 함
- 메시지 재전송 : 재시도(retry)나 큐(queue)는 메시지의 안정적 전송을 보장하기 위해 사용되는 기법
참고자료
- 알렉스 쉬, 가상 면접 사례로 배우는 대규모 시스템 설계 기초 12장
fig1-1
fig1-2
fig1-3
fig1-4
fig1-5 (TODO:)
fig1-6 (TODO:)
fig1-8 (TODO:)
fig1-9 (TODO:)
fig1-10 (TODO:)
fig1-11 (TODO:) CDN과 캐시가 추가된 설계
fig1-12 (TODO:)
fig1-13 (TODO:)
fig1-14 (TODO:) 기존 설계 -> stateless 아키텍처
fig1-15 (TODO:)
fig1-16 (TODO:)
fig1-17 (TODO:)
fig1-19 (TODO:)
fig1-20 (TODO:)
fig1-23 (TODO:)