12장. 채팅 시스템 설계

채팅 앱의 종류가 많기 때문에 어떤 채팅앱을 설계해야 하는지 기능적 요구사항을 확실히 이해하는 것이 중요하다.

• 1:1 채팅
• 그룹 채팅
• 음성 채팅

 

개략적 설계

채팅 시스템의 경우 클라이언트는 모바일 앱 이거나 웹 애플리케이션이다.

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

 

메시지 송신 클라이언트(Sender)

수신 클라이언트에게 전달할 메시지를 채팅 서비스에 보낼 때 HTTP 프로토콜을 사용. 이때 keep-alive 헤더를 사용하면 클라이언트와 서버 사이의 연결을 끊지 않고 계속 유지할 수 있다. 또한 TCP 접속 과정에서 발생하는 핸드셰이크 횟수를 줄일 수 있는 장점도 있어서, 대중적 채팅 프로그램들은 초기에 HTTP 를 사용했었다.

 

그러나 메시지 수신 시나리오가 복잡해지고, HTTP 를 사용하면 서버에서 클라이언트로 임의 시점에 메시지를 보내는데 쓰일 수 없다는 단점이 드러났다. 이러한 문제를 해결하기 위해 다음의 방법들이 고안되었다.

 

폴링

클라이언트가 주기적으로 서버에 새 메시지가 있는지 물어보는 방법

 

단점

• 폴링 주기가 짧을수록 비용이 커지고, 답해줄 메시지가 없을 때는 서버 자원이 불필요하게 낭비됨

 

롱 폴링

폴링의 대체 방법. 클라이언트는 새 메시지를 받거나 타임아웃이 될 때까지 연결을 유지한다.

 

단점

• 수신과 발신 클라이언트가 같은 서버에 접속해있지 않을 수 있다.
• 서버 입장에서 클라이언트가 연결을 해재했는지 아닌지 알 수 있는 방법이 없다

 

웹 소켓

서버가 클라이언트에게 비동기적으로 메시지를 보낼 때 가장 널리 사용되는 기술

HTTP 연결이지만 핸드셰이크 절차를 거쳐 항구적인 연결을 만들고 서버가 클라이언트로 메세지를 보낼 수 있다.

또한 80, 443 처럼 HTTP 혹은 HTTPS 프로토콜이 사용하는 기본 포트번호를 그대로 쓰므로 방화벽이 있는 환경에서도 잘 동작함

 

단점

• 서버 측에서 웹 소켓 연결 관리를 효율적으로 해야 한다. -> 효율적으로 관리만 하면 되는 건가

 

 

개략적 설계안

클라이언트와 서버 사이 주 통신 프로토콜로 웹 소켓을 사용하고, 채팅 외 대부분의 기능(회원가입, 로그인 등)은 HTTP 로 구현해도 상관 없다.

 

 

무상태 서비스

• 로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스
• 로드밸런서 뒤에 위치한다.
• 로드밸런서는 요청을 그 경로에 맞는 서비스로 전달하는 역할을 한다.
• 서비스 탐색 서비스는 클라이언트가 접속할 채팅 서버의 DNS 호스트 명을 클라이언트에게 알려주는 역할을 함

 

상태 유지 서비스

• 유일하게 상태 유지가 필요한 서비스는 채팅 서비스이다. -> 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하므로
• 클라이언트는 보통 서버가 살아 있는 한 다른 서버로 연결을 변경하지 않는다.
• 서비스 탐색 서비스는 특정 서버에 부하가 몰리지 않도록 한다.

 

제3자 서비스 연동

• 채팅 앱에서 가장 중요한 제3자 서비스 = 푸시 알림
• 앱이 실행 중이지 않더라도 알림을 받아야 한다.

 

규모 확장성

이론적으로는 대량의 트래픽을 처리하는 경우에도 서버 한 대에서 처리 가능

그러나 예를 들어 동시 접속자가 1M, 접속당 10K 의 서버 메모리가 필요하다고 가정한다면 10 GB 가 필요하게 된다.

이럴 때 서버 한 대에서 처리한다고 한다면, 해당 서버가 SPOF 가 될 수 있어 좋지 못한 설계이다.

 

지금까지의 개략적 설계를 바탕으로 설계안을 만들면 다음과 같다.

 

• 채팅 서버: 클라이언트 사이 메시지를 중계
• 접속상태 서버: 사용자의 접속 여부를 관리
• API 서버: 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리
• 알림 서버: 푸시 알림 전송
• 키-값 저장소: 채팅 이력 보관 - 시스템에 접속한 사용자는 이전 채팅 이력을 전부 볼 수 있음

 

저장소

어떤 데이터베이스를 쓰느냐도 중요한 고려 사항 중 하나

RDBMS 와 NoSQL 을 선택하는 중요한 기준으로 데이터의 유형과 읽기/쓰기 연산의 패턴이 있다.

 

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

 

사용자 프로파일, 설정, 친구 목록처럼 일반적인 데이터

• 이런 데이터는 안정성을 보장하는 관계형 데이터베이스에 보관
• 다중화와 샤딩은 이런 데이터의 가용성과 규모 확장성을 보증하기 위해 보편적으로 사용되는 기술

 

채팅 이력 - 채팅 시스템에 고유한 데이터

• 채팅 이력 데이터의 양은 엄청나다. (e.g 페이스북 메신저는 매일 600억 개의 메시지를 처리함)
• 최근 메시지가 상대적으로 빈번하게 사용됨
• 검색, 특정 사용자가 언급된 메시지, 특정 메시지로 점프 등 무작위적인 데이터 접근도 지원해야 함

 

이러한 채팅 이력 데이터를 저장하기 위해서 다음의 이유들로 키-값 저장소를 추천한다.

• 수평적 규모확장이 쉬움
• 데이터 접근 지연시간이 낮다
• 관계형 DB는 롱테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있다 (인덱스가 커지면 데이터에 대한 무작위적 접근을 처리하는 비용이 늘어난다)
• 페이스북 메신저는 HBase, 디스코드는 카산드라 를 사용 중

 

데이터 모델

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

• message_id 를 기본 키로 사용해, 메시지 순서를 쉽게 정할 수 있는 역할도 수행 가능

 

 

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

• (channel_id, message_id) 의 복합 키를 기본 키로 사용
• 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 할 것이기 때문

 

메시지 ID

메시지들의 순서를 표현할 수 있어야 하며, 고유해야 한다.

 

message_id 를 생성하는 기법 3가지

• RDBMS 의 auto_increment
• 스노플레이크 같은 전역적 64 bit 순서 번호 생성기를 이용
• 지역적 순서 번호 생성기
  • 채팅 message_id 의 유일성은 같은 그룹 안에서만 보증하면 됨
  • 같은 채널, 같은 1:1 채팅 세션 안에서만 유지되면 충분하기 때문에 비교적 구현하기 쉬운 접근법

 

상세 설계

서비스 탐색

• 클라이언트에게 가장 적합한 채팅 서버를 추천하는 서비스
• 클라이언트 위치, 서버의 용량 등을 기준으로 사용
• 아파치 주키퍼 - 사용 가능한 서버를 모두 등록 후 클라이언트가 접속 시도 시 사전에 정한 기준에 따라 최적의 서버를 골라줌

 

1. 사용자 A가 시스템에 로그인 시도

2. 로드밸런서가 로그인 요청을 API 서버들 가운데 하나로 보낸다.

3. API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능이 동작해 해당 사용자를 서비스할 최적의 채팅 서버를 찾음

4.사용자 A는 채팅 서버와 웹소켓 연결을 맺는다.

 

 

메시지 흐름

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

1. 사용자 A가 채팅 서버 1로 메시지 전송

2. 채팅 서버 1은 ID 생성기를 사용해 해당 메시지의 ID 결정

3. 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송

4. 메시지가 저장소에 보관됨

5. 사용자 B가 접속 중이면 접속 중인 채팅 서버를 통해서 전송되고, 아니라면 푸시 알림 서버로 보냄

 

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

단말 별로 cur_max_message_id 를 추적하는 용도로 변수를 유지 - 해당 단말에서 관측된 가장 최신 메시지의 ID 를 추적하는 용도로 사용

 

새 메시지로 간주하는 조건

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

 

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

사용자 별로 각각 메시지 큐를 갖고, 받아야 할 메시지가 각 큐에 복사된다.

• 새로운 메시지가 왔는지 자신의 큐만 보면 되므로 메시지 동기화 플로우가 단순하다.
• 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않는다.
• 많은 사용자를 지원해야 하는 경우라면 바람직하지 않음

 

접속상태 표시

접속상태 서버를 통해 사용자의 상태를 관리한다. 웹 소켓으로 통신하는 실시간 서비스의 일부이다.

 

사용자 로그인

클라이언트와 실시간 서비스 사이에 웹 소켓 연결이 맺어지고 나면 접속상태 서버는 상태와 last_active_at 타임스탬프 값을 저장소에 보관한다. 이 절차가 끝나고 나면 해당 사용자는 접속 중인 것으로 표시될 것임

 

사용자 로그아웃

로그아웃 시 키-값 저장소에 저장된 사용자 상태가 online -> offline 으로 변경되고, UI 상에서 접속 중이 아닌 것으로 표시될 것

 

접속 장애

인터넷 연결이 항상 안정적일 수 없기 때문에 대응할 수 있는 설계를 준비해야 한다.

• 사용자의 인터넷 연결이 끊어지면 클라이언트와 서버 사이에 맺어진 웹소켓 같은 지속성 연결도 끊어진다.
• 박동(heartbeat) 검사를 통해 이 문제를 해결할 수 있다.
  • 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트(heartbeat event)를 접속상태 서버로 보내도록 한다.
  • 마지막 이벤트를 받은 지 x 초 이내에 또 다른 박동 이벤트를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지
  • 그렇지 않은 경우 오프라인으로 변경

 

상태정보의 전송

친구 관계에 있는 사용자들에게 메시지를 전달하기 위해, 친구 관계 별 발행-구독 채널을 하나씩 두고 이를 각 사용자가 구독한다.

• 그룹 크기가 커지면 비용이나 시간이 많이 들게 되므로 좋지 않다.
• 대안으로 그룹 채팅 입장 시에만 상태 정보를 읽어가게 하거나, 갱신을 수동으로 하도록 유도할 수 있다.

 

추가로 논의하면 좋을 내용

• 사진이나 비디오 등의 미디어 지원 방법
• 종단 간 암호화
• 캐시
• 로딩 속도 개선
• 오류 처리
  • 채팅 서버 오류
  • 메시지 재전송 재시도 / 큐