TIL

12장 채팅 시스템 설계

설계 범위 예시

• 페이스북 메신저와 유사한 채팅 앱을 설계한다고 가정
• 아래와 같은 기능을 갖는다.
  • 응답 지연이 낮은 일대일 채팅 기능
  • 최대 100명까지 참여 가능한 그룹 채팅 기능
  • 사용자의 접속 상태 표시 기능
  • 다양한 단말 지원, 하나의 계정으로 여러 단말 동시 접속 지원
  • 푸시 알림
  • 5000만 DAU를 처리 가능

채팅 서비스 프로토콜

메시지 송신 클라이언트 → 채팅 서비스 (메시지 저장 및 전달) → 메시지 수신 클라이언트 (사용자 단말기)

• 채팅 서비스의 기능
  • 클라이언트로부터 메시지 수신
  • 메시지 수신자 결정 및 전달
  • 수신자가 접속 상태가 아닌 경우 접속할 때까지 메시지 보관
• 메시지 송신 클라이언트
  • 송신 클라이언트는 수신 클라이언트에게 HTTP 프로토콜을 사용해 메시지를 전달한다.
  • keep-alive 헤더를 사용해 지속 연결을 할 수 있으며 핸드셰이크 횟수를 줄일 수 있다.
• 메시지 수신 클라이언트
  • 메시지 수신 과정은 좀 더 복잡하다.
  • HTTP는 주로 클라이언트가 연결을 만드는 프로토콜이며 서버에서 클라이언트로 임의 시점에 메시지를 보내기는 어렵다.
  • 서버가 연결을 만드는 것처럼 동작하게 하는 많은 기법들이 있다.
    • 폴링, 롱 폴링, 웹소켓 등

폴링 (polling)

• 클라이언트가 주기적으로 서버에세 메시지가 있는지 물어보는 기법
  • 폴링을 자주 할 수록 비용 상승
  • 메시지가 없다면 불필요한 자원 낭비

롱 폴링 (long polling)

• 폴링을 효율적으로 개선하여 나온 기법
• 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지
  • 메시지를 받으면 연결을 종료하고 서버에 새로운 요청을 보낸다.
• 문제점
  • 분산 서버 환경에서 송신 클라이언트와 수신 클라이언트가 같은 채팅 서버에 접속하지 않을 수도 있다.
  • 서버 입장에선 클라이언트가 연결을 해제했는지 아닌지 알 좋은 방법이 없다.
  • 메시지를 많이 받지 않는 클라이언트인 경우 타임아웃이 날 때마다 다시 서버에 접속해야하므로 비효율적

웹소켓 (WebSocket)

• 서버가 클라이언트에게 비동기 메시지를 보낼 때 사용하는 기술
  1. 클라이언트가 서버에 HTTP 핸드셰이크 요청
  1. 한 번 맺어진 연결은 항구적이며 양방향
     1. 처음에 맺어진 HTTP 연결이 웹소켓 연결로 업그레이드
     2. 서버는 클라이언트에게 비동기적으로 메시지를 전송할 수 있게 된다.
• 웹소켓은 방화벽이 있는 환경에서도 잘 동작한다.
  • HTTP 혹은 HTTPS가 사용하는 기본 포트 번호를 그대로 쓰기 때문
• 웹소켓으로 메시지를 보내고 받을 때 동일한 프로토콜을 사용하게 된다.
  • 구현이 단순, 직관적
• 연결이 항구적이기에 서버 측에셔 연결 관리를 효율적으로 해야한다.

채팅 서비스 개략적 설계안

• 채팅 서비스는 세 부분으로 나누어 살펴볼 수 있다.
  • 무상태 서비스
  • 상태유지 서비스
  • 제3자 서비스 연동

무상태 서비스

• 로그인, 회원가입 등을 처리하는 전통적인 요청/응답 서비스
• 무상태 서비스는 로드밸런서 뒤에 위치
• 모놀리틱 서비스일 수도, 마이크로서비스일 수도 있다.

상태 유지 서비스

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

제3자 서비스 연동

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

규모 확장성

• 위에 설명한 기능을 서버 한 대로 처리할 수도 있다.
  • 하지만 트래픽과 SPOF를 생각하면 여러 서버를 두는 설계를 고려해야 한다.

• 지금까지의 설계를 그림으로 나타내면 아래와 같다.

  

  • 채팅 서버 - 클라이언트 사이에 메시지를 중계
  • 접속 상태 서버 - 사용자의 접속 여부 관리
  • API 서버 - 로그인, 회원가입 등 나머지 전부를 처리
  • 알림 서버 - 푸시 알림 전송
  • 키-값 저장소 - 채팅 이력을 보관

저장소

• 채팅 시스템에서 다루는 데이터는 보통 두 가지
  • 사용자 프로필, 친구 목록 등의 일반적인 데이터 → 보통 RDB에 보관
  • 채팅 이력
• 채팅 이력 데이터의 읽기/쓰기 패턴
  • 채팅 이력 데이터 양은 엄청 많다.
  • 빈번하게 사용되는 것은 주로 최근에 주고 받은 메시지
  • 최근 메시지를 자주 보지만 검색 기능 등으로 특정 메시지로 점프하여 무작위적 데이터 접근을 하는 경우도 존재
  • 1:1 채팅 앱의 경우 읽기/쓰기 비율은 대략 1:1
• 채팅 이력에 키-값 저장소를 추천하는 이유
  • 키-값 저장소는 수평적 규모 확장이 용이
  • 데이터 접근 지연 시간이 낮다.
  • RDB는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못한다.
    • 인덱스가 커지면 데이터에 대한 무작위 접근을 처리하는 비용이 늘어난다.
  • 이미 많은 채팅 시스템이 키-값 저장소를 채택하고 있다.
    • 페이스북 메신저는 HBase, 디스코드는 카산드라

데이터 모델

• 1:1 채팅을 위한 메시지 테이블
  • 기본 키로 message_id를 사용
  • message_id로 메시지 간 순서를 판단 가능
• 그룹 채팅을 위한 메시지 테이블
  • (channel_id, message_id) 복합키를 기본키로 사용
  • channel_id는 파티션 키로도 사용 가능
• 메시지 ID
  • message_id 값은 고유해야 한다.
  • 정렬 가능해야하며 시간 순서와 일치해야 한다.
  • NoSQL에선 보통 auto_increment를 지원하지 않기 때문에 스노플레이크 같은 전역적 순서 번호 생성기를 사용하는 방법이 있다.
  • 지역적 순서 번호 생성기를 이용하는 방법도 있다.
    • 메시지 순서는 같은 그룹 안에서만 보증되면 충분하기 때문
    • 채팅 그룹, 혹은 1:1 방 내부에서만 순서가 보증되면 충분
    • 전역적 ID 생성기 보다는 단순

채팅 시스템 상세 설계

서비스 탐색

• 서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것
• 기준
  • 클라이언트의 위치
  • 서버의 용량
• 아파치 주키퍼(Apache Zookeeper)
  • 서비스 탐색 기능을 구현하는 데 널리 쓰이는 오픈 소스 솔루션

• 서비스 탐색 기능 동작

  

  1. 사용자 A가 시스템에 로그인 시도
  2. 로드밸런서가 로그인 요청은 API 서버 중 하나로 라우팅
  3. API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능이 동작하여 최적의 채팅 서버 탐색
  4. 탐색된 서버와 사용자 A가 웹소켓으로 연결됨

메시지 흐름

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

1. 사용자 A가 채팅 서버1로 메시지 전송
2. 채팅 서버1은 ID 생성기로 메시지 ID 결정
3. 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
4. 메시지가 키-값 저장소에 보관됨

5. a. 사용자 B가 접속 중인 경우 사용자 B가 접속 중인 채팅 서버2로 전송됨

   b. 사용자 B가 접속 중이 아니라면 푸시 알림 메시지를 푸시 알림 서버로 전송

6. 채팅 서버2는 메시지를 사용자 B에게 전송 (웹소켓 사용)

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

• 각 단말은 cur_max_message_id라는 변수를 유지
  • 해당 단말에서 관측된 가장 최신 메시지 ID를 추적하는 용도
  • 단말마다 별도로 유지 관리되는 값
• 아래 조건을 만족하는 메시지는 새 메시지로 간주
  • 수신자 ID가 현재 로그인한 사용자 ID와 같다.
  • 키-값 저장소에 보관된 메시지로서, 그 ID가 cur_max_message_id보다 크다.
• cur_max_message_id로 키-값 저장소에서 새 메시지를 가져오는 동기화를 쉽게 구현할 수 있다.

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

• 위 방법은 사용자마다 메시지 큐를 두고 메시지를 각 큐에 복사하여 각 사용자에게 전달한다.
• 위 방법은 소규모 그룹 채팅에 적합
  • 자기 큐만 보면 새로운 메시지가 왔는지 확인할 수 있어 메시지 동기화가 단순
  • 그룹에 크지 않으면 메시지를 수신자 별로 복사하여 큐에 넣는 작업 비용이 작음
• 하지만 많은 사용자를 지원해야하는 경우 메시지를 모든 사용자 큐에 복사하는 것은 비용이 크다.
  • 즉 각 사용자는 메시지 동기화 큐에서 여러 사용자로부터 오는 메시지를 받을 수 있어야 한다.

  

접속 상태 표시

• 사용자 접속 상태를 표시하는 기능은 상당수 채팅 애플리케이션의 핵심 기능이다.
• 개략적 설계안에선 접속 상태 서버를 통해 사용자 상태를 관리한다고 했다.
• 사용자 로그인
  • 클라이언트와 실시간 서비스 사이에 웹소켓 연결
  • 접속 상태 서버가 사용자 상태와 last_active_at 타임 스탬프를 키-값 저장소에 보관
  • 사용자가 접속 중인 것으로 표시됨
• 로그아웃
  • 키-값 저장소에 보관된 사용자 상태가 online에서 offline으로 변경
  • 사용자가 접속 중이 아닌 것으로 표시
• 접속 장애
  • 클라이언트와 서버 사이 웹소켓 연결이 항상 원할한 것은 아니다.
    • 인터넷 연결이 항상 안정적인 것은 아니기 때문
  • 대응 1. 사용자를 오프라인 상태로 표시하고 연결이 복구되면 온라인 상태로 변경
    • 사용자 경험 상 좋지 않다.
    • 인터넷 연결이 잠시 끊어지는 상황은 흔하기 때문에 그 때마다 접속 상태를 변경하는 것은 지나치다.
  • 대응 2. 박동(heartbeat) 검사 사용
    • 클라이언트가 주기적으로 박동 이벤트를 접속 상태 서버로 전송
    • 마지막 이벤트를 받은 지 x초 이내 또 다른 박동 이벤트를 받으면 접속 상태를 유지 (or 오프라인 상태로 변경)

• 상태 정보의 전송

  

  • 상태 정보 서버는 발행-구독 모델을 사용
  • 각각의 친구 관계마다 채널을 하나씩 두고 상태 정보를 발행한다.
  • 클라이언트와 서버 사이엔 웹소켓을 사용
  • 위 방법은 그룹 크기가 작을 때는 효과적이지만 그룹 크기가 커지면 비용과 시간이 많이 든다.
    • 방안 1. 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하기
    • 방안 2. 사용자가 수동으로 친구 리스트 접속 상태를 갱신하도록 하기

더 생각해볼 점

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