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

채팅 앱은 중점적으로 다뤄야하는 문제에 따라 방향성이 달라질 수 있으므로, 요구사항을 확실히 파악하는것이 매우 중요하기 때문에, 어떤 채팅 앱을 설계하려는지 확실히 해 두는것이 중요하다.

• 1:1 채팅 중점
  • 페이스북 메신저, 위챗, 왓츠앱 등
• 그룹 채팅 중점
  • 슬랙 등
• 대규모 그룹의 소통과 음성 채팅
  • 디스코드 등

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

질문을 통해 의도를 파악한다.

• Q. 1:1 채팅, 그룹 채팅?
  • A. 둘 다.
• Q. 모바일? 웹?
  • A. 둘 다.
• Q. 트래픽 규모는?
  • A. DAU 5천만
• Q. 그룹 채팅의 인원 제한?
  • A. 최대 100명
• Q. 중요 기능으로는?
  • A. 1:1 채팅, 그룹 채팅, 사용자 접속 상태 표시, 텍스트 메시지만 허용
• Q. 메시지 길이 제한은?
  • A. 100,000자 이하
• Q. 종단 간 암호화(end-to-end encryption) 지원?
  • A. 현재로서는 불필요
• Q. 채팅 이력은 얼마나 보관?
  • A. 영원히.

위와 같은 질의응답을 통해 아래와 같은 요구사항을 찾을 수 있다.

• 응답지연이 낮은 일대일 채팅기능(DAU)
• 최대 100명까지 참여할 수 있는 그룹 채팅 기능
• 사용자의 접속상태 표시 기능
• 다양한 단말 지원, 하나의 계정으로 여러 단말에 동시 접속 지원(웹, 앱 둘다 고려)
• 푸시 알림

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

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

클라이언트는 서로 직접 통신하지 않는 대신, 각 클라이언트는 위에 나열한 모든 기능을 지우너하는 채팅 서비스와 통신한다.

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

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

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

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

위 예시에서는 송신 클라이언트가 수신 클라이언트에게 전달 할 메시지를 보낼 때, 오랜 세월 검증된 HTTP 프로토콜을 사용한다.

HTTP를 사용한다면, 채팅 서비스에서는 클라이언트가 지속적으로 메시지를 보낸다는 특성을 고려하여, keep-alive 헤더를 사용해 서버와 클라이언트가 연결을 끊지 않고 유지하는 것이 좋다.

하지만 메시지 발신에 비해 수신 시나리오는 이것보다 복잡하기 때문에 HTTP가 적절치 않을 수 있다.

• 서버가 채팅 발신 요청을 받게 되면, 서버가 수신자에게 메시지를 전달해야한다.
• HTTP는 클라이언트가 연결을 만드는 특성으로, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데 쉽게 쓰일 수 없다.

이러한 문제를 개선하기위해 서버가 연결을 만드는 것처럼 동작하는 많은 기법이 제안되었다.

• 폴링, 롱폴링, 웹소켓

폴링

폴링은 클라이언트가 주기적으로 서버에게 새 메시지가 있는냐고 물어보는 방법이다.

폴링 비용은 폴링을 자주하면 할수록 올라가므로, 답해줄 메시지가 없는 경우에는 서버 자원이 불필요하게 낭비된다.

롱 폴링

폴링의 비효율성을 개선하기위해 롱 폴링이 제안되었다.

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

이 방법은 다음과 같은 약점이 있다.

• 메시지를 보내는 클라이언트가 수신하는 클라이언트가 같은 채팅 서버에 접속하지 않을 수 있다.
  • HTTP 서버들은 보통 무상태이다. 즉 로드 밸런싱을 위해 라운드 로빈 알고리즘을 사용하는 경우(요청을 무작위로 분산하는 경우), 메시지를 받은 서버는 해당 메시지를 수신할 클라이언트와의 롱 폴링 연결을 가지고 있지 않은 서버일 수 있다.
• 서버는 클라이언트가 연결을 해제했는지 알 수 있는 좋은 방법이 없다.
• 여전히 비효율적이다.
  • 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속한다.

웹소켓

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

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

웹소켓은 메시지를 보내려는 클라이언트에게 준수한 HTTP 프로토콜의 특징에 더해 양방향 메시지 전송까지 가능하게 한다.

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

개략적 설계안

클라이언트와 서버 사이의 주 통신 프로토콜로 웹소켓을 사용하지만, 다른 부분에서는 굳이 웹소켓을 쓸 필요는 없다.

대부분의 기능인 회원가입, 로그인, 사용자 프로파일 등은 기존 HTTP상에서 구현하는 것이 더 좋다.

채팅 시스템은 세 부분으로 나눠볼 수 있다.

무상태 서비스

이 설계안에서 무상태 서비스는 로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스다.

• 일반적인 웹과 앱이 제공하는 기능들

무상태 서비스는 로드밸런서 뒤에 위치한다.

• 서비스 탐색(sevice discovery) 서비스
  • 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할을 한다.

상태 유지 서비스

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

• 클라이언트는 보통 다른 서버로 연결을 변경하지 않는다.
• 서비스 탐색 서비스가 채팅 서버스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 한다.

써드파티 서비스 연동

채팅 앱에서 가장 중요한 써드파티 서비스는 푸시 알림이다.

• 새 메시지 수신시 앱이 실행중이지 않더라도 알림을 받아야한다.

따라서 푸시 알림 서비스와의 통합은 아주 중요하다.

규모 확장성

이번 장에서 다루는 시스템은 동시 접속자가 1M 이라고 가정하는데, 접속당 10K 서버 메모리가 필요하다면, 10GB 메모리만으로도 처리 가능하다.

하지만 이정도 규모의 트래픽을 서버 한대로 처리하는 것은 SPOF 등의 이유로 적절치 않다.

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

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

저장소

채팅 시스템의 기술 스택중 가장 중요한 부분 중 하나는 데이터 계층으로, 이 계층을 올바르게 만드는 데는 노력이 필요하다.

중요한 선택 중 하나는 어떤 데이터베이스를 쓰는가(관계형, NoSQL 등)이며, 고려해야 할 핵심 요인은 데이터의 유형과 읽기/쓰기 연산의 패턴 이다.

채팅 시스템에서는 보통 두 가지다.

사용자 프로파일, 설정, 친구 목록과 같은 일반적인 데이터
안정성을 보장하는 관계형 데이터베이스가 적절하다.

• 다중화(replication)와 샤딩(sharding)으로 이러한 데이터의 가용성과 규모확장성을 보증할 수 있다.

채팅 시스템에 고유한 데이터(채팅 이력)
이러한 유형의 데이터를 어떻게 보관할 지 결정하려면 읽기/쓰기 연산 패턴을 이해해야한다.

• 채팅 이력 데이터 양은 엄청나다.
  • 페이스북 메신저나 왓츠앱은 매일 600억개 메시지를 처리함
• 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지이다.
  • 대부분 사용자는 오래된 메시지는 확인하지 않는다.
• 검색 기능, 언급(mention)된 메시지, 특정 메시지로 점프 하는 등 무작위적인 데이터 접근을 하는 경우도 있다.
• 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1

키-값 저장소가 이러한 패턴을 지원할 수 있는 데이터베이스이다.

• 수평적 규모 확장이 쉽다.
• 데이터 접근 지연시간이 낮다.
• 관계형 데이터베이스는 롱 테일에 해당하는(넓고 적게 분포하는) 데이터를 잘 처리하지 못하는 경향이 있다.
  • 인덱스가 커지면 무작위 접근을 처리하는 비용이 늘어난다.
• 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 채택하고있다.
  • 페이스북: Hbase, 디스코드: 카산드라 등

롱테일 효과란?

파레토 법칙에 의한 80:20 집중 현상을 그래프에 나타냈을 때 꼬리처림 긴 부분을 형성하는 80%의 부분

데이터 모델

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

erDiagram
    Message {
        message_id bigint
        message_from bigint
        message_to bigint
        content text
        created_at timestamp
    }

Message 테이블의 기본키는 message_id로, 메시지 순서를 쉽게 정할 수 있도록 하는 역할도 담당한다.

• created_at은 메시지가 동시에 만들어 질 수 있으므로 순서를 정할 수 없다.

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

erDiagram
    GroupMessage {
        channel_id bigint
        message_id bigint
        message_to bigint
        content text
        created_at timestamp
    }

(channel_id, message_id) 복합키를 기본 키로 사용한다.

• 채널은 채팅 그룹과 같은 뜻
• 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 하기 때문에 channel_id는 파티션 키로 사용할 수 있다.

메시지 ID

위에서 언급한 것 처럼 메시지 ID는 메시지들의 순서도 표현할 수 있어야한다.

• messege_id는 고유해야한다.
• ID는 정렬 가능해하하며, 시간 순서와 일치해야한다.
  • 새로운 ID는 이전 ID 보다 큰 값이어야 한다.

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

• 스노 플레이크 같은 전역적 순서 번호 생성기를 이용한다.
• 지역적 순서 번호 생성기를 이용한다.

지역적 순서 번호 생성기(Local sequence number generator) 유일성은 같은 그룹 안에서만 보증하면 충분하다는 의미이다.

• 채팅 서비스의 특징에 따라 메시지의 순서는 같은 채널, 혹은 1:1 채팅 세션 안에서만 유지되면 충분하다.
• 전역적 ID 생성기에 비해 구현이 쉽다.

3단계: 상세 설계

채팅 시스템의 서비스 탐색(service discovery), 메시지 전달 흐름, 사용자 접속 상태 표시하는 법 정도가 세부적으로 살펴보기 적절하다.

서비스 탐색

서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것으로 아래의 기준을 활용하여 추천하게된다.

• 클라이언트의 위치(Geographical location)
• 서버의 용량 등

서비스 탐색 기능을 구현하는 데 널리 쓰이는 오픈 소스 솔루션으로 아파치 주키퍼같은 것이 있다.

• 사용 가능한 모든 채팅 서버를 등록시켜 두고, 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라준다.

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

메시지 흐름

채팅 시스템에 있어서 종단 간 메시지 흐름을 이해하는 것은 흥미로운 주제이다.

1:1 채팅 메시지의 처리 흐름과 여러 단말 간 메시지 동기화 과정을 살펴본 후, 그룹 채팅 메시지의 처리 흐름을 살펴본다.

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

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

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

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

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

위 조건을 만족하는 메시지는 새 메시지로 간주된다.

cur_max_message_id는 단말마다 별도로 유지 관리하면 되는 값이라 키-값 저장소에서 새 메시지를 가져오는 동기화 작업도 쉽게 구현할 수 있다.

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

1:1 채팅에 비해 조금 더 복잡하다.

사용자 A가 그룹 채팅방에서 메시지를 보내면, 사용자 B, C의 메시지 동기화 큐에 복사된다.

이러한 설계는 소규모 그룹 채팅에 적합하다.

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

많은 사용자를 지원해야 하는 경우라면 똑같은 메시지를 모든 사용자의 큐에 복사하는 게 바람직하지 않다.

위와 같은 흐름을 메시지 수신자 관점에서 살펴보면, 한 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야 한다.

접속 상태 표시

사용자 접속 상태를 표시하는 것은 상당수 채팅 애플리케이션의 핵심 기능이다.

개략적 설계안의 접속 상태 서버(presense server)를 통해 사용자의 상태를 관리하는데, 접속상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부라는 점에 유의해야한다.

사용자 로그인

클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버는 A의 상태와 last_active_at 타임스탬프 값을 키-값 저장소에 보관한다.

이 절차가 끝나면 해당 사용자는 접속 중인 것으로 표시될 것이다.

로그아웃

키-값 저장소에 보관된 사용자 상태가 online에서 offline으로 바뀐다.

접속 장애

인터넷 연결이 끊어지는 상황에 대응할 수 있는 설계를 준비해야한다.

사용자의 인터넷 연결이 끊어지면 클라이언트와 서버 사이에 맺어진 웹소켓 같은 지속성 연결도 끊어진다.

이러한 경우 사용자를 오프라인 상태로 표시하고 연결이 복구되면 온라인 상태로 변경하는 방법을 고려할 수 있지만, 짧은 시간 동안 인터넷 연결이 끊어졌다 복귀되는 현상이 흔하기 때문에 적절하지 않다.

• 이런 현상마다 사용자의 접속 상태를 변경하는 것은 지나치며, 사용자 경험 측면에서도 바람직하지 않다.

이에 따라 박동(heartbeat) 검사를 통해 이 문제를 해결한다.

1. 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보낸다.
2. 마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 해당 사용자의 접속 상태를 계속 온라인으로 유지한다.

상태 정보의 전송

상태정보 서버는 각각의 친구관게마다 채널을 하나씩 두는 발행-구독 모델을 사용한다.

이러한 구조를 통해 친구 관계에 있는 사용자가 상태정보 변화를 쉽게 통지 받을 수 있게 된다(웹소켓 사용).

이러한 방안은 그룹의 크기가 커지면 비용이나 시간이 많이 들게되므로 좋지 않다.

• 그룹 하나의 100,000명이 있다면, 상태변화 1건당 100,000개의 이벤트 메시지가 발생한다.

이런 성능 문제를 해소하는 방법은

• 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 만든다.
• 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도한다.

4단계: 마무리

1:1 채팅과 그룹 채팅을 전부 지원하는 채팅 시스템의 아키텍처를 살펴보았다.

• 클라이언트와 서버 사이의 통신을 가능하도록 하기 위해 웹소켓을 사용했다.
• 주요 컴포넌트
  • 실시간 메시징을 지원하는 채팅 서버
  • 접속 상태 서버
  • 푸시 알림 서버
  • 채팅 이력을 보관할 키-값 저장소
  • 이를 제외한 나머지 기을을 구현하는 데 쓰을 API 서버 등

시간이 남는다면 다음과 같은 내용을 논의해도 좋다.

• 사진이나 비디오 등의 미디어를 지원하도록 하는 방법
  • 압축 방식, 클라우드 저장소, 섬네일 생성 등
• 종단 간 암호화
• 캐시
  • 이미 읽은 메시지를 캐시해 두면 서버와 주고받는 데이터 양을 줄일 수 있다.
• 로딩 속도 개선
  • 슬랙은 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축하여 앱 로딩 속도를 개선하였다.
• 오류 처리
  • 채팅 서버 오류
    • 서버 하나가 죽으면 서비스 탐색 기능이 동작하여 클라이언트에게 새로운 서버를 배정하고 다시 접속할 수 있도록 한다.
  • 메시지 재전송
    • 재시도나 큐는 메시지의 안정적 전송을 보장하기 위해 흔히 사용되는 기법이다.