12장 채팅 시스템 설계

가상 면접 사례로 배우는 대규모 시스템 설계 기초 – System Design Interview

이번 장에서는 채팅 시스템을 설계해 볼 것이다.

채팅 앱이라고 했을 때 사람들이 떠올리는 것은 제각각이다. 그러니 요구사항을 확실하게 해 두는 것이 아주 중요하다.

1단계 문제 이해 및 설계 범위 확정

질문 예시

- 1:1 채팅 앱입니까? 아니면 그룹 채팅 앱입니까?
- 모바일 앱인가요? 아니면 웹 앱인가요?
- 처리해야 하는 트래픽 규모는 어느 정도입니까?
- 그룹 채팅의 경우에 인원 제한이 있습니까?
- 중요 기능으로는 어떤게 있을까요?
- 첨부파일도 지원할 수 있어야 하나요?
- 사용자 접속상태 표시도 필요한가요?
- 메시지 길이에 제한이 있나요?
- 종단 간 암호화(end-to-end encryption)를 지원해야 하나요?
- 채팅 이력은 얼마나 오래 보관해야 할까요?

이 책에서는 페이스북 메신저와 유사한 채팅 앱을 설계해본다.

이 앱은 다음과 같은 기능을 갖는다.

- 응답지연이 낮은 일대일 채팅 기능
- 최대 100명까지 참여할 수 있는 그룹 채팅 기능
- 사용자의 접속상태 표시 기능
- 다양한 단말 지원. 하나의 계정으로 여러 단말에 동시 접속 지원
- 푸시 알림
- 5천만 DAU 처리가 가능한 시스템

2단계 개략적 설계안 제시 및 동의 구하기

채팅 서비스는  아래 기능을 제공해야 한다.

- 클라이언트들로부터 메시지 수신
- 메시지 수신자(receipt) 결정 및 전달
- 수신자가 접속(online) 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관

채팅을 시작하려는 클라이언트는 네트워크 통신 프로토콜을 사용하여 서비스에 접속한다. 따라서 채팅 서비스의 경우 어떤 통신 프로토콜을 사용할 것인가도 중요한 문제다. 면접관과 상의하도록 하자.

대부분의 클라이언트/서버 애플리케이션에서 요청을 보내는 것은 클라이언트인데, 채팅 시스템의 경우에도 마찬가지다.

이 앱에서는 HTTP 프로토콜을 사용한다.

클라이언트는 채팅 서비스에 HTTP 프로토콜로 연결한 다음 메시지를 보내어 수신자에게 해당 메시지를 전달하라고 알린다.

채팅 서비스와의 접속에는 keep-alive 헤더를 사용하면 효율적인데, 클라이언트와 서버 사이의 연결을 끊지 않고 계속 유지할 수 있어서다. TCP 접속 과정에서 발생하는 핸드셰이크(hand-shake) 횟수를 줄일 수 있다.

페이스북 같은 서비스들도 초기에 HTTP를 사용했다.

https://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf

keep-alive는 http/1.1 에서만 사용 가능했던것으로 보임.

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Keep-Alive

하지만 메시지 수신 시나리오는 훨씬 복잡하다. HTTP는 클라이언트가 연결을 만드는 프로토콜이며, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데는 쉽게 쓰일 수 없다.

이를 해결하기 위해  서버가 연결을 만드는 것처럼 동작할 수 있도록 하기 위한 많은 기법이 제안되어 왔다.

폴링, 롱폴링, 웹소켓 등이 그런 기술이다.

폴링

클라이언트가 주기적으로 서버에게 새 메시지가 있냐고 물어보는 방식이다. 폴링(polling)을 자주하면 할수록 비용이 올라가며 답해줄 메시지가 없는 경우에도 서버 자원이 불필요하게 낭비되는 문제가 있다.

롱폴링

폴링의 단점을 해결하기 위해 나온것이 롱 폴링(long polling) 이다.

롱 폴링의 경우 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지한다. 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내어 모든 절차를 다시 시작한다.

롱폴링은 다음과 같은 약점이 있다.

- 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수 있다.
- 서버 입장에서 클라이언트가 연결을 해제했는지 아닌지 알수 있는 좋은 방법이 없다.
- 여전히 비효율적이다. 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속할 것이다.

결론적으로 폴링과 롱폴링은
단방향 통신을 양방향 통신처럼 사용하기 위한 우회법이다.

근본적으로 한계가 있을 수밖에 없다.

그렇기 때문에 아래의 웹 소켓을 웹 표준으로 만든 것이라 생각된다.

웹소켓

웹 소켓(WebSocket)은 서버가 클라이언트에게 비동기(async) 메시지를 보낼 때 가장 널리 사용하는 기술이다.

웹소켓 연결은 클라이언트가 시작한다. 한번 맺어진 연결은 항구적(변하지 아니하고 오래가는 것)이며 양방향이다. 이 연결은 처음에는 HTTP 연결이지만 특정 핸드셰이크 절차를 거쳐 웹소켓 연결로 업그레이드된다. 일단 연결이 만들어지고 나면 서버는 클라이언트에게 비동기적으로 메시지를 전송할 수 있다. 웹소켓은 HTTP(80), HTTPS(443) 프로토콜이 사용하는 기본 포트번호를 그대로 쓰기 때문에 방화벽이 있는 환경에서도 일반적으로 잘 동작한다.

웹 소켓을 사용하면 메시지를 보낼 때나 받을 때 동일한 프로토콜을 사용할 수 있으므로 설계뿐 아니라 구현도 단순하고 직관적이다. 유의할 것은 웹소켓 연결은 항구적으로 유지되어야 하기 때문에 서버 측에서 연결 관리를 효율적으로 해야 한다.

개략적 설계안

대부분의 기능들은 일반적인 HTTP상에서 구현하고 채팅과 관련된 부분만 웹소켓을 사용한다.

이 책에서 다루는 채팅 시스템은 세 부분으로 나누어 볼 수 있다.

무상태 서비스, 상태유지(stateful) 서비스, 그리고 제 3자 서비스 연동의 세 부분이다.

무상태 서비스

일반적인 기능을 다룬다.

여기서 중요한 부분은 “서비스 탐색(service discovery)” 서비스다. 이 서비스는 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할을 한다.

상태 유지 서비스

각 클라이언트는 채팅 서버와 독립적인 네트워크 연결을 유지해야 한다.

서비스 탐색 서비스는 채팅 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 해야 한다.

제3자 서비스 연동

채팅 앱에서 가장 중요한 제3자 서비스는 푸시 알림이다. 새 메시지를 받았다면 설사 앱이 실행 중이지 않더라도 알림을 받아야 해서다. 따라서 푸시 알림 서비스와의 통합은 아주 중요하다.

규모 확장성

트래픽 규모가 얼마 되지 않을 때는 방금 설명한 모든 기능을 서버 한 대로 구현할 수 있다. 이때 따져봐야할 것은 서버 한 대로 얼마나 많은 접속을 동시에 허용할 수 있느냐다. 이번 장에서 다루는 시스템의 경우에는 동시 접속자가 1M이라고 가정할 것인데, 접속당 10K의 서버 메모리가 필요하다고 본다면(아주 개략적으로 추정한 수치다) 10GB 메모리만 있으면 모든 연결을 다 처리할 수 있을 것이다.

하지만 모든 것을 서버 한 대에 담은 설계안을 내밀면 면접에서 좋은 점수를 따기는 어려울 것이다. 누구도 그 정도 규모의 트래픽을 서버 한 대로 처리하려 하지 않을 것이기 때문이다. 거기에는 여러 가지 이유가 있는데 SPOF(Single-Point-Of-Failure)도 그 가운데 하나다.

하지만 서버만 한 대 갖는 설계안에서 출발하여 점차 다듬어 나가는 것은 괜찮다. 면접관에게 ‘이 것은 그저 시작일 뿐’이라는 것을 정확하게 전달해 놓으면 된다.

실시간으로 메시지를 주고받기 위해 클라이언트는 채팅 서버와 웹소켓 연결을 끊지 않고 유지한다.

- 채팅 서버는 클라이언트 사이에 메시지를 중계하는 역할을 담당한다.
- 접속상태 서버(presence server)는 사용자의 접속 여부를 관리한다.
- API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리한다. 
- 알림 서버는 푸시 알림을 보낸다.
- 키-값 저장소(key-value)에는 채팅 이력(chat history)을 보관한다. 시스템에 접속한 사용자는 이전 채팅 이력을 전부 보게 될 것이다.

여기서의 API 서버는 이전에서 언급한 무상태 서비스를 모아서 설명한 것이라 생각된다.

저장소

어떤 데이터 베이스를 사용해야 할까?

이 질문에 대한 올바른 답을 하기 위해 중요하게 따져야 할 것은, 데이터 유형과 읽기/쓰기 연산의 패턴이다.

채팅 시스템이 다루는 데이터는 보통 두 가지 이다.

첫 번째는 사용자 프로파일, 설정, 친구 목록처럼 일반적인 데이터다. 이런 데이터는 안정성을 보장하는 관계형 데이터베이스에 보관한다.

두 번째는 채팅 시스템에 고유한 데이터로, 바로 채팅 이력(chat history)이다. 이 데이터를 어떻게 보관해야할지 결정하려면 읽기/쓰기 연산 패턴을 이해해야 한다.

- 채팅 이력 데이터의 양은 엄청나다. 페이스북 메신저나 왓츠앱은 매일 600억(60b) 개의 메시지를 처리한다. (https://www.theverge.com/2016/4/12/11415198/facebook-messenger-whatsapp-number-messages-vs-sms-f8-2016)

- 이 데이터 가운데 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지다. 대부분 사용자는 오래된 메시지는 들여다보지 않는다.

- 사용자는 대체로 최근에 주고받은 메시지 데이터만 보게 되는 것이 사실이나, 검색 기능을 이용하거나, 특정 사용자가 언급(mention)된 메시지를 보거나, 특정 메시지로 점프(jump)하거나 하여 무작위적인 데이터 접근을 하게 되는 일도 있다. 데이터 계층은 이런 기능도 지원해야 한다.

- 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1 정도다.

본 책의 설계안 에서는 키-값 저장소를 추천할 것인데, 이유는 다음과 같다.

- 수평적 규모확장(horizontal scaling)이 쉽다.
- 접근 지연시간(latency)이 낮다.
- 관계형 데이터베이스는 데이터 가운데 롱 테일(long tail)에 해당하는 부분을 잘 처리하지 못하는 경향이 있다. 인덱스가 커지면 데이터에 대한 무작위적 접근(random access)을 처리하는 비용이 늘어난다.
- 이미 많은 채팅 시스템이 키-값 저장소를 채택하고 있다. 페이스북 메신저는 HBase를 이용하고 있고 디스코드는 카산드라를 이용하고 있다.

https://engineering.fb.com/2010/11/15/core-data/the-underlying-technology-of-messages/
https://discord.com/blog/how-discord-stores-billions-of-messages

[참고]
Long tail : https://en.wikipedia.org/wiki/Long_tail 

전통적인 시장에서는 어느 한 종목에서는 보통 잘 팔리는 상위 20%가 전체 매출의 80%를 차지한다.
여기서 롱테일은 나머지 80%를 의미한다. (위 이미지에서 노란 영역)

데이터 모델

1:1 채팅을 위한 메시지 테이블

그룹 채팅을 위한 메시지 테이블

channel_id, message_id의 복합키(composite key)를 기본 키로 사용한다.
channel_id는 파티션 키(partition key)로도 사용한다.

그룹 채팅을 위한 메시지 테이블에서 책에서는 message_to 로 나와있는데 원문에서는 user_id로 나와있어 수정하여 정리하였다.
어떤 대상에게 보낼 것인지는 channel_id 로 지정이 되기 때문에 누가 작성했는지에 대한 정보가 필요하지 누구에게 보낼 것인지(message_to)가 다시 입력될 필요는 없다.

메시지 ID

message_id는 메시지들의 순서도 표현할 수 있어야 한다.
그러기 위해서는 다음과 같은 속성을 만족해야 한다.

- message_id의 값은 고유해야 한다(uniqueness)
- ID 값은 정렬 가능해야 하며 시간 순서와 일치해야한다. 즉, 새로운 ID는 이전 ID보다 큰 값이어야 한다. 즉, 새로운 ID는 이전보다 큰 값이어야 한다.

RDBMS 라면 auto_increment가 대안이 될 수 있겠지만 NoSQL은 보통 해당 기능을 제공하지 않는다.

스노플레이크 같은 전역적 생성기를 사용하는 것도 가능하다.

하지만 채팅 시스템의 경우 지역적 순서 번호 생성기를 사용하는 것으로도 해결이 가능한데, 이 방법이 통하는 이유는 메시지 사이의 순서는 같은 채널, 혹은 같은 1:1 채팅 세션 안에서만 유지되면 충분하기 때문이다. 전역적 생성기에 비해 구현하기도 쉽다.

3단계 상세 설계

서비스 탐색

서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것이다. 이때 사용되는 기준으로는 클라이언트의 위치(geographical location), 서버의 용량(capacity) 등이 있다.

서비스 탐색 기능을 구현하는데 널리 쓰이는 오픈 소스 솔루션으로는 아파치 주키퍼(Zookeeper) 같은 것이 있다. 사용 가능한 모든 채팅 서버를 여기 등록시켜 두고, 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라주면 된다.

다음과 같이 동작하게 된다.

1. 사용자 A가 시스템에 로그인을 시도한다.
2. 로드밸런서가 로그인 요청을 API 서버들 가운데 하나로 보낸다.
3. API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능이 동작하여 해당 사용자를 서비스할 최적의 채팅 서버를 찾는다.
4. 사용자는 반환된 서버와 웹소켓 연결을 맺는다.

스터디를 진행하던 중에 "로드밸런서와 주 키퍼의 차이" 에 대한 질문이 나왔다.

정리해본 결과 다음과 같았다.

로드밸런서와 주키퍼는 모두 분산 시스템의 성능과 안정성을 향상시키는 데 사용되는 도구이지만 서로 다른 목적을 가지고 있다.

로드밸런서는 트래픽이 분산되도록 요청을 여러 서버들에 전달하는 역할을 하고 주키퍼는 시스템의 구성과 상태를 관리하는 용도이다.

위 동작 플로우를 보면 서비스 탐색 기능(주키퍼)은 추천 채팅 서버를 반환해 줄 뿐이지 직접 요청을 전달하거나 하지는 않는것을 볼 수 있다.

메시지 흐름

1:1 채팅 메시지 처리 흐름

1. 사용자 A가 채팅 서버 1로 메시지 전송
2. 채팅 서버 1은 ID 생성기를 사용해 해당 메시지의 ID 결정
3. 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
4. 메시지가 키-값 저장소에 보관됨
5-a. 사용자 B가 접속 중인 경우 메시지는 사용자 B가 접속 중인 채팅 서버로 전송됨
5-b. 사용자 B가 접속 중이 아니라면 푸시 알림 메시지를 푸시 알림 서버로 보냄
6. 채팅 서버는 메시지를 사용자 B에게 전송. 사용자 B와 채팅 서버 2 사이에는 웹소켓 연결이 있는 상태이므로 그것을 이용.

사용자가 어떤 서버에 접속중인지는 어떻게 알 수 있을까? 라는 생각이 처음에는 들었는데
조금 더 생각해보니 사용자 입장에서 어떤 서버에 접속중인지는 중요하지 않다는 것을 알 수 있었다.
메시지 큐를 통해서 통신하기 때문이다.

그러면 어떤 메시지 큐를 통해서 통신을 진행할지는 어떻게 알 수 있을까? 
조금 더 넓게 봤을 때 위의 내용을 다시 돌아보면 그룹 관리라는 API 기능이 있다. 여기서 해당 그룹의 정보를 얻으면 메시지 큐에 대한 내용도 알 수 있지 않을까 추측된다.

여러 단말 사이의 메시지 동기화

각 단말은 cur_max_message_id 라는 변수를 유지하여 해당 단말에서 관측된 가장 최신 메시지의 ID를 추적한다.

아래 두 조건을 만족하는 메시지는 새 메시지로 간주한다.

- 수신자 ID가 현재 로그인한 사용자 ID와 같다.
- 키-값 저장소에 보관된 메시지로서, 그 ID가 cur_max_message_id보다 크다.

cur_max_message_id는 단말마다 별도로 유지 관리하면 된다.

소규모 그룹 채팅에서의 메시지 흐름

먼저는 각각의 사용자마다 메시지 동기화 큐가 있다고 가정해보자.

이 설계는 소규모 그룹 채팅에 적합한데

이유는 다음과 같다.

- 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되므로 메시지 동기화가 단순하다.
- 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐를 넣는 작업의 비용이 문제가 되지 않는다.

위챗이 이런 접근법을 쓰고 있으며, 그룹의 크기는 500명으로 제한하고 있다고 한다.

https://www.infoq.cn/article/the-road-of-the-growth-weixin-background
(당연히도 중국 기업이기에 중국어 블로그다)

수신자의 입장에서 보면 다음과 같다.

수신자의 메시지 동기화 큐는 여러 사용자로부터 오는 메시지를 받을 수 있어야 한다.

대규모 그룹 채팅에서의 메시지 흐름

해당 부분은 책에 나와있지 않다. 고려를 해보면 좋을 것 같다.

접속상태 표시

사용자 로그인

클라이언트와 실시간 서비스(real-time service) 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버는 A의 상태(status: online)와 last_active_at 타임스탬프 값을 키-값 저장소에 보관한다. 이 절차가 진행되면 해당 사용자는 접속 중인 것으로 표시될 것이다.

사용자A - (웹소켓 연결) - 접속상태 서버 - 키-값 저장소

로그아웃

로그아웃을 하게 되면 사용자 상태가 online에서 offline으로 바뀌게 된다.

사용자A - (로그아웃) - API 서버 - 접속상태 서버 - 키-값 저장소

접속 장애

인터넷을 통한 연결이 항상 안정적이지는 못하다.

따라서 실시간으로 사용자의 접속 상태를 변경한다면 그것은 지나친 일일 것이고, 사용자 경험 측면에서도 바람직하지 않을 것이다.

본 설계안에서는 박동(heartbeat) 검사를 통해 이 문제를 해결할 것이다. 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 하고, 마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지하는 것이다. 그렇지 않을 경우에만 오프라인으로 바꾸는 것이다.

상태 정보의 전송

그러면 다른 사용자들은 어떻게 해당 사용자의 상태 변화를 알게 될까? 상태정보 서버는 발행-구독(publish-subscribe model)을 사용하는데 각각의 사용자와 채널을 만들어 구독하도록 한다.

클라이언트와 서버 사이의 통신에는 실시간 웹소켓을 사용한다.

이 방안은 그룹 크기가 작을 때는 효과적이다. 위챗은 그룹 크기 상한을 500으로 제한하고 있어서 이와 유사한 접근법을 사용할 수 있었다.

성능이슈를 해결하고 싶다면 입장하는 순간에만 상태 정보를 읽어가게 하거나, 수동으로 갱신할 수 있도록 유도하는 것도 방법이 될 수 있을 것이다.

4단계 마무리

추가적으로 다루면 좋은 것들

- 채팅앱을 확장하여 사진이나 비디오 등의 미디어를 지원하도록 하는 방법 : 압축 방식, 클라우드 저장소 사용, 섬네일 생성 등

- 종단 간 암호화

- 캐시: 클라이언트에 이미 읽은 메시지를 캐시해 두면 서버와 주고 받는 데이터 양을 줄일 수 있다.

- 로딩 속도 개선: 슬랙은 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축하여 앱 로딩 속도를 개선하였다.
https://slack.engineering/flannel-an-application-level-edge-cache-to-make-slack-scale/

- 오류처리 
채팅 서버 오류: 서버가 죽으면 서비스 탐색 기능(주키퍼 같은)이 동작하여 클라이언트에게 새로운 서버를 배정하고 다시 접속할 수 있도록 해야 한다.
메시지 재전송: 재시도(retry)나 큐(queue)는 메시지의 안정적 전송을 보장하기 위해 흔히 사용되는 기법이다.

fin.