문제 이해 및 설계요구사항개략적 설계안 제시 및 동의 구하기폴링롱 폴링웹 소켓개략적 설계안무상태 서비스상태 유지 서비스제3자 서비스 연동저장소데이터 모델메시지 ID상세 설계서비스 탐색메시지 흐름1:1 채팅 메시지 처리 흐름여러 단말 사이의 메시지 동기화소규모 그룹 채팅에서의 메시지 흐름접속상태 표시사용자 로그인로그아웃접속 장애상태 정보의 전송마무리
문제 이해 및 설계
현재 시장에 나와 있는 앱들을 보면 페이스북 메신저, 위챗, 왓츠앱 처럼 1:1 채팅에 집중하는 앱들이 있는가 하면
슬랙 같은 그룹 채팅에 중점을 둔 업무용 앱이나
게임 채팅에 쓰이는 디스코드 같이 대규모 그룹의 소통과 응답지연이 낮은 음성 채팅에 집중하는 앱도 있다.
따라서 초반에 던져야 하는 질문들은 면접관이 원하는 앱이 정확히 무엇인지 알아내기 위한 것이어야 한다. 설계 대상이 1:1 채팅 앱인지, 그룹 채팅 앱인지.
요구사항
- 1:1 채팅 , 그룹 채팅 둘다 지원 가능해야 함
- 모바일 앱, 웹 앱 둘다 지원 가능
- 처리해야 하는 트래픽 규모 : DAU(Daily Active User) 기준으로 5천만(50million)명
- 그룹 채팅 인원 제한 : 최대 100명
- 중요 기능
- 1:1 채팅
- 그룹 채팅
- 사용자 접속상태 표시
- 텍스트 메시지만 주고 받을 수 있음
- 메시지 길이 제한 : 100,000자 이하
- 종단간 암호화는 꼭 지원할 필요 없음
- 채팅 이력은 영원히 보관
개략적 설계안 제시 및 동의 구하기
기본 기능
- 클라이언트들로부터 메시지 수신
- 메시지 수신자 결정 및 전달
- 수신자가 접속 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관
위 그림에서 메시지 송신 클라이언트는 수신 클라이언트에게 전달할 메시지를 채팅 서비스에 보낼 때, HTTP 프로토콜을 사용한다.
채팅 서비스와의 접속에는 keep-alive 헤더를 사용하면 효율적임. 클라이언트와 서버 사이의 연결을 끊지 않고 계속 유지할 수 있기에
HTTP 는 메시지 전송 용도로는 괜찮은 선택이며, 페이스북 같은 많은 대중적 채팅 프로그램이 초기에는 http를 사용했다.
하지만 메시지 수신 시나리오는 이것보다 복잡함. HTTP는 클라이언트가 연결을 만드는 프로토콜이며, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데 쉽게 쓰일 수 없음 → 서버가 연결을 만드는 것처럼 동작할 수 있도록 하기 위해
폴링, 롱 폴링, 웹 소켓 기술이 있음폴링
- 클라이언트가 주기적으로 서버에게 새 메시지가 있느냐고 물어보는 방법
- 폴링 비용은 폴링을 자주하면 할수록 올라감
- 답해줄 메시지가 없는 경우에는 서버 자원이 불필요하게 낭비된다는 문제도 있음
롱 폴링
- 폴링은 여러가지로 비효율적일 수 있어서 나온 기법이 롱 폴링임
- 롱 폴링의 경우 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지함
- 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내어 모든 절차를 다시 시작함
- 단점
- 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수 있다. http 서버들은 보통 무상태 서버이기에 로드밸런싱이 라운드 로빈 알고리즘을 사용하는 경우, 메시지를 받은 서버가 해당 메시지를 수신할 클라이언트와의 롱 폴링 연결을 갖고 있지 않은 서버일 수 있음
- 서버 입장에서는 클라이언트가 연결을 해제 했는지 아닌지 알수 있는 방법이 없음
- 여전히 비효율적. 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속함
웹 소켓
웹 소켓은 서버가 클라이언트에게 비동기 메시지를 보낼 때 가장 널리 사용하는 기술임
- 웹 소켓연결은 클라이언트가 시작하며, 한번 맺어진 연결은 항구적이며 양방향임
- 이 연결은 처음에는 HTTP 연결이지만 특정 핸드쉐이크 절차를 거쳐 웹소켓 연결로 업그레이드 됨
- 앞에서 HTTP 프로토콜이 메시지를 보내려는 클라이언트에게 썩 괜찮은 프로토콜임을 설명했지만 웹소켓은 이에 더해 양방향 메시지 전송까지 가능하게 하므로, 웹소켓 대신 HTTP를 굳이 고집할 이유는 없다.
- 유의할 것은 웹소켓 연결은 항구적으로 유지되어야 하기에 서버 측에서 연결 관리를 효율적으로 해야 함
Q.
- 대규모 서비스에서는 웹소켓 커넥션만 관리하는 서버를 따로 두고 비즈니스 로직은 다른곳에서 처리. 왜냐면 웹소켓 커넥션만 관리해도 메모리를 엄청 많이 잡아먹기 때문에. (erlang, microprocess?)
- 근데 notification 만 주는거라면 클라이언트 앱에서 FCM 쪽에 subscribe 만 하고 있으면(토픽 구독) 서버에서 발행하면 따로 커넥션 필요 없이 줄수 있는데.
개략적 설계안
위에서 클라이언트와 서버 사이의 주 통신 프로토콜로 웹소켓을 사용하기로 결정했음
그러나 다른 부분에서는 굳이 웹소켓을 쓸 필요는 없다. 사실 대부분의 기능(회원가입, 로그인, 사용자 프로파일 등)은 일반적인 HTTP 상에서 구현해도 된다.
무상태 서비스
로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스
무상태 서비스는 로드밸런서 뒤에 위치하고, 로드밸런서가 하는 일은 요청을 그 경로에 맞는 서비스로 정확하게 전달함
로드밸런서 뒤에 오는 서비스는 모놀리틱 서비스일 수도 있고 마이크로서비스일 수도 있다.
이 서비스들 중
서비스 탐색 서비스는 클라이언트가 접속할 채팅 서버의 DNS 호스트 명을 클라이언트에게 알려주는 역할을 함상태 유지 서비스
본 설계안에서 유일하게 상태 유지가 필요한 서비스는 채팅 서비스다. 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하기 때문
클라이언트는 보통 서버가 살아 있는 한 다른 서버로 연결을 변경하지 않는다.
서비스 탐색 서비스는 채팅 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 한다.제3자 서비스 연동
채팅 앱에서 가장 중요한 제3자 서비스는 푸시 알림. 새 메시지를 받았다면 설사 앱이 진행중이지 않더라도 알림을 받아야 하기 때문
Q.
- 알림을 받으면 앱에서 해당 메시지에 대한 동기화를 진행?
- 채팅 서버는 클라이언트 사이에 메시지를 중개하는 역할을 담당
- 접속상태 서버는 사용자의 접속 여부를 관리
- API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리한다.
- 알림 서버는 푸시 알림을 보낸다
- 키-값 저장소는 채팅 이력을 보관한다. 시스템에 접속한 사용자는 이전 채팅 이력을 전부 보게 될 것
저장소
채팅 시스템이 다루는 데이터는 보통 두 가지
- 사용자 프로파일, 설정, 친구 목록 처럼 일반적인 데이터 → 안정성을 보장하는 RDB에 보관
- 다중화와 샤딩은 이런 데이터의 가용성과 규모확장성을 보증하기 위해 보편적으로 사용되는 기술
- 채팅 시스템에 고유한 데이터, 채팅 이력. 이 데이터를 어떻게 보관할지 결정하려면 읽기/쓰기 연산 패턴을 이해해야 함
- 채팅 이력 데이터의 양은 엄청남. 페이스북 메신저나 왓츠앱은 매일 600억 개의 메시지를 처리
- 이 데이터 가운데 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지. 대부분의 사용자는 오래된 메시지는 들여다보지 않음
- 사용자는 대체로 최근에 주고받은 메시지 데이터만 보게 되는 것이 사실이나, 검색기능을 이용하거나 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프하거나 하여 무작위적 데이터 접근을 하게 되는 일도 있음. 데이터 계층은 이런 기능도 지원해야 함
- 1:1 채팅 앱의 경우 읽기/쓰기 비율은 대략 1:1
⇒ 본 설계안의 경우 키-값 저장소를 추천
- 키값 저장소 선택 이유
- 수평적 규모 확장이 쉬움
- 데이터 접근 지연시간이 낮음
- 관계형 DB는 데이터 가운데 롱 테일(사소한 80%가 중요해지는 경우)에 해당하는 부분을 잘 처리하지 못하는 경향이 있음. 인덱스가 커지면 데이터에 대한 무작위적 접근(random access)을 처리하는 비용이 늘어남.
Q.
- mongoDB 보다 높은 QPS를 버티기 위해서는 Cassandra나 Hbase [ 블로그 글 참고 ]
데이터 모델
1:1 채팅을 위한 메시지 테이블
message
- message_id : bigint
- message_from : bigint
- message_to : bigint
- content: text
- created_at : timestamp
기본키는 message_id로 메시지 순서를 쉽게 정할 수 있도록 하는 역할을 담당. created_at은 메시지 순서 정할 수 없는게, 동시에 만들어질 수 있기 때문
그룹 채팅을 위한 메시지 테이블
group_message
- channel_id : bigint
- message_id: bigint
- message_to: bigint
- content: text
- created_at: timestamp
(channel_id, message_id) 의 복합키를 기본 키로 사용. 채널은 채팅 그룹과 같은 뜻이며, channel_id는 파티션 키로도 사용할 것
메시지 ID
message_id는 메시지들의 순서도 표현할 수 있어야 한다. 그러기 위해서는 다음과 같은 속성을 만족해야 한다
- message_id 의 값은 고유해야 한다.
- ID 값은 정렬 가능해야 하며 시간 순서와 일치해야 한다. 즉 새로운 ID는 이전 ID 보다 큰 값이어야 한다.
방법
- 스노플레이크 같은 전역적 64-bit 순서 번호 생성기
- 지역적 순서 번호 생성기 (같은 그룹, 같은 채널, 1:1 채팅 세션 안에서만 유지)
상세 설계
서비스 탐색
서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것.
이때 사용되는 기준으로는 클라이언트의 위치(geolocation), 서버의 용량(capacity) 등이 있다.
서비스 탐색 기능을 구현하는 데 널리 쓰이는 오픈 소스 솔루션으로는 아파치 주키퍼(Zookeeper) 같은 것이 있음
사용가능한 모든 채팅 서버를 여기 등록시켜 두고, 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라주면 됨
메시지 흐름
채팅 시스템에 있어 종단 간 메시지 흐름을 이해하는 것은 흥미로운 주제임
1:1 채팅 메시지 처리 흐름
- 사용자 A가 채팅서버 1로 메시지 전송
- 채팅 서버 1은 ID 생성기를 사용해 해당 메시지의 ID 결정
- 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
- 메시지가 키-값 저장소에 보관
- 사용자 B가 접속 중인 경우 메시지는 사용자 B가 접속 중인 채팅 서버로 전송
- 사용자 B가 접속중이 아니라면 푸시 알림 메시지를 푸시 알림 서버로 보냄 . 그후 종료
- 채팅 서버 2는 메시지를 사용자 B에게 전송. 사용자 B와 채팅 서버 2 사이에는 웹소켓 연결이 있는 상태이므로 그것을 이용
여러 단말 사이의 메시지 동기화
사용자 A는 전화기와 랩톱의 두 대 단말을 이용하고 있음. 사용자 A가 전화기에서 채팅 앱에 로그인한 결과로 채팅서버 1과 단말 사이에 웹소켓 연결이 있고, 랩톱에서 로그인한 결과로 역시 별도 웹소켓이 채팅서버1에 연결되어 있음
각 단말은
cur_max_message_id 라는 변수를 유지하는데, 해당 단말에서 관측된 가장 최신 메시지의 ID 를 추적하는 용도. 아래 두 조건을 만족하는 메시지는 새 메시지로 간주- 수신자 ID가 현재 로그인한 사용자 ID와 같다
- 키-값 저장소에 보관된 메시지로서, 그 ID가
cur_max_message_id보다 크다
cur_max_message_id 는 단말마다 별도로 유지관리하면 되는 값이라 키-값 저장소에서 새 메시지를 가져오는 동기화 작업도 쉽게 구현 가능
소규모 그룹 채팅에서의 메시지 흐름
사용자 A가 그룹 채팅 방에서 메시지를 보냈을 때, 해당 그룹에 3명의 사용자가 있으면(사용자 A,B,C) 우선 사용자 A 가 보낸 메시지가 사용자 B와 C의 메시지 동기화 큐에 복사된다.
이 설계안은 소규모 그룹 채팅에 적합한데, 이유는 다음과 같다
- 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되니까 메시지 동기화 플로가 단순함
- 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않는다.
- 위챗이 이런 접근법을 쓰고 있으며, 그룹의 크기는 500명으로 제한하고 있다.
하지만 많은 사용자를 지원해야 하는 경우에는 똑같은 메시지를 모든 사용자의 큐에 복사하는게 바람직하지 않음
수신자 관점에서 살펴보면 한 수신자는 여러 사용자로부터 오는 메시지를 수신해야 하는데, 그 메시지 들을 사용자의 수신함, 메시지 동기화 큐에서 받으면 된다.
Q.
- 많은 사용자의 경우 어떻게 하는지? Discord 의 예시 보면서 다시 보기
- 디스코드에서는 많은 사용자에 대해 message를 전송하기 위해 전송 작업을 분산처리하고 보내는데 걸리는 작업 자체를 최적화 하는 과정을 거쳤음
When anything is published in a guild, it is fanned out to every session connected to it.
When a user comes online, they connect to a guild, and the guild publishes a presence to all other connected sessions.
접속상태 표시
사용자의 접속 상태를 표시하는 것은 상당수 채팅 어플리케이션의 핵심적 기능이다.
개략적 설계안에서는 접속상태 서버를 통해 사용자의 상태를 관리한다고 했었다. 접속 상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부라는 점에 유의.
사용자 로그인
클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버는 A의 상태와 last_active_at 타임스탬프 값을 키-값 저장소에 보관함.
이 절차가 끝나고 나면 해당 사용자는 접속 중인 것으로 표시됨
로그아웃
사용자 로그아웃은 키-값 저장소에 보관된 사용자 상태가 online → offline으로 바뀌게 됨
접속 장애
인터넷을 통한 연결이 항상 안정적일 수 없기에 그런상황에 대응할 수 있는 설계를 준비해야 함
사용자의 인터넷 연결 끊어지면 웹소켓 연결도 끊어지고 이때, 사용자를 오프라인 상태로 표시하고 연결 복구되면 온라인 상태로 변경할 수 있다. 그러나 이 방식의 문제점은 짧은 시간 동안 끊어졌다 복구되는 일을 계속적으로 변경하여 사용자 경험 측면에서 바람직하지 않다는 점임 ⇒ heartbeat 검사를 통해 문제 해결
온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 하고, 마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지. x 초 이내에 받지 못한다면 오프라인으로 바꿈
상태 정보의 전송
접속상태 서버는 발행-구독 모델을 사용하여 각각의 친구관계마다 채널을 하나씩 두고, 사용자 A의 접속상태가 변경되었을 때, 각 채널에 변경 이벤트를 모두 쓰는 것임. → 이 방안은 그룹 크기가 작을때는 효과적임. 그룹 크기가 더 커지면 이런식으로 접속상태 변화를 알리면 비용이나 시간이 많이 들게 되므로 좋지 않음
예를 들어 그룹 하나에 100,000 사용자가 있다고 하면 상태변화 1건당 100,000개 이벤트 메시지가 발생할 것이기에, 이 성능 문제를 해소하는 방법은 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도하는 것
Q.
- Redis Pub/sub
- Zookeeper 작동원리(서비스 탐색)
마무리
더 이야기하면 좋을 내용
- 채팅 앱을 확장하여 사진이나 비디오 등의 미디어를 지원하도록 하는 방법
- 미디어 파일은 크기가 크기에 그와 관련한 압축방식, 클라우드 저장소, 섬네일 생성 등을 논의해보면 재밌을것
- 종단 간 암호화 : 메시지 발신인과 수신인 이외에는 아무도 메시지 내용을 볼 수없다
- 캐시 : 클라이언트에 이미 읽은 메시지를 캐시해 두면 서버와 주고받는 데이터 양을 줄일 수 있다.
- 로딩 속도 개선 : 슬랙은 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축하여 앱 로딩 속도를 개선하였다.
- 오류 처리
- 채팅 서버 오류: 채팅 서버 하나에 수십만 사용자가 접속해 있는 상황을 생각하면, 그 서버가 죽으면 서비스 탐색기능(주키퍼 같은)이 동작하여 클라이언트에게 새로운 서버를 배정하고 다시 접속할 수 있도록 해야 함
- 메시지 재전송 : 재시도(retry)나 큐(queue)는 메시지의 안정적 전송을 보장하기 위해 흔히 사용되는 기법