읽은 책/[책] 가상 면접 사례로 배우는 대규모 시스템 설계 기초 1권

12장. 채팅 시스템 설계

코드몬스터 2024. 7. 20. 12:51
728x90

 

 

1단계 설계 범위 확정

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

 

2단계 개략적 설계안

 

먼저, 채팅을 시작하려는 클라이언트는 네트워크 통신 프로토콜을 사용하여 서비스에 접속한다.

  • 대부분의 클라이언트/서버 애플리케이션에서 요청을 보내는 것은 클라이언트(사용자)이다.
  • 메세지 송신 클라이언트가 수신  클라이언트에게 전달할 메세지를 채팅 서브시에 보낼 때, HTTP 프로토콜을 사용한다.
  • 채팅 서비스와의 접속에는 keep-alive 헤더를 사용하면 효율적이다.
    => 클라이언트와 서버 사이의 연결이 끊지 않고 계속 유지할 수 있다.
    => TCP 접속 과정에서 발생하는 핸드 쉐이크 횟수도 줄일 수 있다.
  • 페이스북과 같은 대중적 채팅프로그램이 초기에 HTTP 를 사용했다.

 

하지만, HTTP는 클라이언트가 연결을 만드는 프로토콜이며, 서버에서 클라이언트로 임의 시점에 메세지를 보내는데 쉽게 게 사용할 수 없다.

 

  • 서버가 연결을 만드는 것처럼 동작할 수 있는 기법들이 있다
    => 풀링(polling), 롱 풀링(long polling), 웹소켓(WebSocket)

 

풀링(polling)

  • 클라이언트가 주기적으로 서버에게 새 메세지가 있는지 물어보는 방법이다.
  • 풀링을 자주할 수록 비용이 올라가고, 답해줄 메세지가 없는 경우에는 서버 자원이 불필요하게 낭비된다.

 

롱 풀링(long polling)

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

문제점

  • 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수 있다.
    => 로드밸런싱을 위해 라운드 로빈 알고리즘을 사용하는 경우, 메세지를 받은 서버는 해당 메세지를 수신하는 클라이언트와의 롱 풀링 연결을 가지고 있지 않는 서버일 수 있다.
  • 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 수 있는 좋은 방법이 없다.
  • 여전히 비효율적으로 타임아웃이 일어날때마다 주기적으로 서버에 다시 접속한다.

 

웹소켓(Web Socket)

  • 서버가 클라이언트에게 비동기 메세지를 보낼 때, 가장 널리 사용하는 기술
  • 연결은 클라이언트가 시작하지만, 한 번 맺어진 연결은 항구적(?)이며 양방향이다.
  • 처음에는 HTTP 연결이지만 특정 핸드쉐이크 절차를 거쳐 웹소켓 연결로 업그레이드 된다.
  • 일반적으로 80(HTTP)이나 443(HTTPS)처럼 기본 포트번호를 사용하기 때문에, 방화벽이 있는 환경에서도 잘 동작한다.

\

 

개략적 설계안

  • 클라이언트와 서버 사이의 주 통신 프로토콜로 웹소켓을 결정
  • 다른 부분에서는 웹소켓을 사용할 필요가 없다.
    => 회원가입, 로그인 등 일반적인 기능은 HTTP 프로토콜로 처리
  • 즉, 무상태 서비스, 상태유지 서비스 그리고 제3자 서비스로 나누어 개략적 설계

 

 

 

무상태 서비스

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

 

상태 유지 서비스

  • 상태 유지(stateful)가 필요한 서비스는 채팅 서비스이다.
    => 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하기 때문이다.
  • 클라이언트는 보통 서버가 살아 있는 한 다른 서버로 연결을 변경하지 않는다.
    => 서비스 탐색은 채팅 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 해준다.

제3자 서비스 연동

  • 새 메세지를 받았다면 앱이 실행 중이지 않더라도 알림을 받아야 한다.
  • 푸시 알림 서비스와의 통합은 중요하다.

 

규모 확장성

  • 트랙피 규모가 얼마 되지 않으면 서버 한대로 구현할 수 있고, 이론적으로 대량의 트래픽을 최신 클라우드 서버 한 대로 처리할 수 있다.
  • 한 대로 처리할 때 확인해야 하는 사항은 서버 한 대로 얼마나 많은 접속을 동시에 허용할 수 있는지이다.
    => 동시 접속자가 1M(밀리언?)이고 접속당 10k(kb?) 메모리가 필요하면, 10GB 메모리만 있으면 가능하다.
  • SPOF 문제가 있기 때문에, 처음에는 한 대 서버로 시작하여 점차 다듬어가자.

 

설명한 내용을 하나로 묶으면 아래 그림과 같이 개략적 설계안이 만들어진다.

개략적 설계안

 

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

 

저장소

  • 채팅 시스템이 다루는 데이터는 보통 두 가지 이다.
    • 첫 번째, 사용자 프로파일, 설정, 친구 목록과 같은 일반적 데이터
      => 안전성을 보장하는 관계형 데이터베이스에 보관한다.
    • 두 번째, 채팅 시스템에 고유한 데이터로 채팅 이력이다.
      => 해당 데이터를 어떻게 보관할지 경정하려면 읽기/쓰기 연산 패턴을 이해해야 한다.
  • 검색 기능을 이용하거나, 특정 사용자가 언급된 메세지를 보거나, 특정 메세지로 점프하거나 하여 무작위적인 데이터 접근을 하게 되는 일도 있는 이런 기능을 데이터 계층에서 지원해야한다.
  • 1:1 채팅 앱의 경우 읽기:쓰기 비율이 대략 1:1 정도다.

 

채팅 시스템의 데이터베이스는 키-값 저장소를 추천

  • 수평적 규모확장이 쉽다.
  • 데이터 접근 지연시간이 낮다.
  • 관계형 데이터베이스는 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있다.
  • 인덱스가 커지면 데이터에 대한 무작위 접근을 처리하는 비용이 늘어난다.
  • 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 채택하고 있다.

 

 

데이터 모델

메세지 데이터를 어떻게 보관할지 살펴보자.

 

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

  • 1:1 채팅을 지원하기 위한 메세지 테이블의 사례
  • 기본키는 message_id로, 메세지 순서를 정할 수 있도록 하는 역할을 담당
  • created_at을 사용하여 메세지 순서를 정할 수는 없다.
    => 서로 다른 메세지가 동시에 만들어질 수도 있기 때문이다.

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

  • channel_id, message_id의 복합키를 기본키로 사용한다.
  • 채널은 채팅 그룹과 같은 뜻이다.
  • channel_id는 파티션 키로도 사용할 것인데, 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 할 것이기 때문이다.

이미지 출처: https://azderica.github.io/til/docs/dev/system-design-interview/ch12/

 

메세지 ID

  • message_id는 메세지들의 순서도를 표현할 수 있어야한다.
  • 순서도를 표현을 하기 위해서는 아래 두 가지 조건을 만족해야한다.
    1. message_id는 고유해야 한다.(uniqueness)
    2. ID 값은 정렬 가능해야 하며 시간 순서와 일치해야 한다. 새로운 ID는 이전 ID보다 큰 값이어야 한다.
  • 해당 조건을 만족하는 방법
    • 첫 번째, RDBMS라면 auto_increment가 대안이지만, NoSQL은 해당 기능을 제공하지 않는다.
    • 두 번째, 스노플레이크 같은 전역적 64-bit 순서 번호 생성기를 이용한다.
    • 세 번째, 지역적 순서 번호 생성기를 이용하는 것이다.
      => ID의 유일성이 같은 그룹 안에서만 보증하면 충분하다.
      => 같은 채널, 혹은 같은 1:1 채팅 세션 안에서만 유지되면 충분하다.

 

3단계 상세 설계

서비스 탐색,  메세지 전달 흐름 그리고 사용자 접속 상태에 대해 상세하게 살펴본다.

 

서비스 탐색

서비스 탐색의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것이다.

 

  • 채팅 서버를 추천하는 기준은 클라이언트의 위치, 서버의 용량 등이 있다.
  • 서비스 탐색 기능을 구현하는데 사용되는 오픈 소스는 아파치 주키퍼가 있다.
  • 모든 서버를 등록하고, 클라이언트가 접속을 시도할 때 사전에 정한 기준에 따라 최적의 채팅 서버를 골라 주면 된다.

 

 

 

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

 

메세지 흐름

1:1 채팅 메세지의 처리 흐름과 연러 단말 간 메세지 동기화 과정을 살펴본다.

 

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

사용자 A가 B에게 보낸 메세지가 어떤 경로로 처리되는지 보자.

 

  1. 사용자 A가 채팅 서버 1로 메세지 전송
  2. 채팅 서버 1은 ID 생성기를 사용해 해당 메세지의 ID 결정
  3. 채팅 서버 1은 해당 메세지를 메세지 동기화 큐로 전송
  4. 메세지가 키-값 저장소에 보관
  5. 사용자 B가 접속중이면, 채팅 서버로 전송 / 사용자 B가 미접속중이면, 푸시 알림 서비스로 전송
  6. 채팅 서버 2는 사용자 B와 채팅 서버 2 사이의 웹소켓으로 메세지를 보냄.

 

1:1 채팅 메세지 흐름

 

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

 

사용자 A는 전화기와 랩톱 두 대 단말기를 이용하고 있다.

 

현재 상황

  • 전화기에서 채팅 서버 1과 웹소켓 연결이 되어있다.
  • 랩톱에서도 채팅 서버 1과 웹소켓 연결이 되어있다.

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

=> 해당 변수는 단말에서 관측된 최신 메세지의 ID를 추적하는 용도이다.

 

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

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

 

여러 단말 메세지 동기화

 

 

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

 

사용자 A가 그룹 채팅 방(사용자 A, B, C)에서 메세지를 보냈을 때 상황이다.

 

사용자 A가 보낸 메세지가 사용자 B와 C의 메세지 동기화 큐에 복사된다.

=> 해당 큐를 사용자 각각에 할당된 메세지 수신함 같은 것으로 생각해도 된다.

 

아래 설계안이 소규모 그룹 채팅방에 적합하다.

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

소규모 그룹 채팅방 설계

 

 

메세지 흐름을 수신자 관점에서 살펴본다.

 

한 명의 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야한다.

=> 메세지 동기화 큐가 여러 사용자로부터 오는 메세지를 받을 수 있어야 한다.

 

수신자 관점에서 본 구조

 

접속상태 표시

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

 

사용자 로그인

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

 

 

 

로그아웃

키-값 저장소에 보관된 사용자 상태가 online에서 offline으로 바뀌게 된다는 점에 유의.

해당 절찰가 끝나면 UI 상에서 사용자의 상태는 접속 중이 아닌 것으로 표시 된다.

 

 

 

접속 장애

인터넷 연결이 항상 안정적이면 좋겠지만 그렇지 못하다.

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

 

박동 검사(heartbeat)를 사용해서 이러한 문제를 해결한다.

즉, 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 하고,

마지막 이벤트를 받은지 x초 이내에 또 다른 박동 이벤트 메세지를 받으면 해당 사용자의 접속상태를 온라인으로 유지

그렇지 않으면, 오프라인으로 바꾼다.

 

상태 정보의 전송

사용자 A와 친구 관계에 있는 사용자들은 어떻게 해당 사용자의 상태 변화를 알 수 있을까?

=> 각각의 친구관계마다 채널을 하나씩 두는 것이다.

 

예를 들어, A-B, A-C, A-D 와 같이 세 개 채널에서 사용자 A의 상태가 전달된다.

A-B 채널은 B가 구독하고, A-C 채널은 C가 구독하고, A-D 채널은 D가 구독한다.

 

그룹 크기가 작을 때는 효과적이지만, 그룹 크기가 커지면 접속상태 변화를 알리는 비용과 시간이 많이들게 된다.

 

따라서, 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가거나, 친구 리스트에 있는 사용자의 접속 상태를 갱신하고 싶으면 수동으로 유도하는 것이다.

 

 

4단계 마무리

시간이 남으면 아래와 같은 내용을 논의하자.

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