NLP Blog

채팅 시스템 설계

|

채팅 시스템 설계

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

채팅앱 유형 결정
  • 페이스북 메신저, 카톡과 같이 1:1 채팅에 집중하는 앱
  • slack 같은 그룹 채팅에 중점을 둔 앱
  • Discord와 같이 대규모 그룹의 소통과 latency가 낮은 음성 채팅에 집중하는 앱
  • 유형마다 시스템 설계가 달라지므로, 위 유형 중 어떤 앱을 설계 해야하는지 면접관과 소통을 해야 함
설계 범위 확인
  • 1:1 및 그룹 채팅 지원 필요
  • 모바일/웹 앱 지원
  • DAU (Daily Active User) 기준 50M 명 처리 필요
  • 100 명의 그룹채팅 인원 제한
  • 사용자 접속상태 지원, 텍스트 메시지만 처리
  • 메시지 길이는 최대 100.000자
  • 채팅 이력은 영원히 보관

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

  • 채팅 시스템의 경우 클라이언트는 서로 직접 통신 X
  • 위에 나열한 모든 기능을 지원하는 채팅 서비스와 통신

채팅 서비스가 지원하는 기능

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

통신 프로토콜 결정

  • 채팅 서비스의 경우 어떤 통신 프로토콜을 사용할 것인가는 아주 중요한 문제
  • 메시지 발신의 경우, HTTP 프로토콜을 사용하는 것이 검증되어있는 방법, Keep Alive 헤더를 사용하면 TCP 접속 과정에서 발생하는 핸드셰이크 횟수를 줄일 수 있어 효과적
  • 메시지 수신의 경우, 복잡함. HTTP는 클라이언트가 연결을 만드는 프로토콜이므로, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 것이 어려움
  • 여러 우회 방안이 제시되는데 다음과 같다.
    • 폴링 (polling)
    • 롱 폴링 (long polling)
    • 웹소켓 (WebSocket)

폴링

  • 그림 12-3
  • 클라이언트가 주기적으로 서버에게 새 미시지가 있냐고 물어봄
  • 자주하면 자원을 많이 씀, 메시지가 없는 경우 자원낭비

롱 폴링

  • 그림 12-4
  • 폴링의 개선안
  • 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지함
  • 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내어 모들 절차를 다시 시작
  • 약점
    • 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하지 않을 수 있음, HTTP 서버들은 보통 stateless 서버 이므로, load balancer에 의해 수신 클라이언트와 송신 클라이언트가 다른 서버에 할당될 수 있다.
    • 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 좋은 방법이 없음
    • 여전히 비효율적, 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속함

웹소켓

  • 그림 12-5
  • 서버가 클라이언트에게 비동기(async) 메시지를 보낼 때 가장 널리 사용하는 기술
  • 웹소켓 연결은 클라이언트가 시작, 한번 맺어진 연결은 항구적이며 양방향이다.
  • 처음에는 HTTP 연결이지만 특정 핸트셰이크 절차를 거쳐 웹소켓 연결로 업그레이드
  • 연결이 만들어지고 나면, 서버는 클라이언트에게 비동기적으로 메시지 전송 가능
  • HTTP 또는 HTTPS 프로토콜이 쓰는 포트번호를 쓰므로, 방화벽이 있는 환경에서도 잘 동작함
  • 메시지 발신 서비스 시에 HTTP 연결이 좋다고했지만, 웹소켓이 있는 이상, 수신 발신 서비스에 웹소켓을 사용하면 된다. (그림 12-6)
  • 유의할 점은 웹소켓 연결은 항구적으로 유지 (dedicated)되어야 하므로, 서버 측에서 연결 관리를 효율적으로 해야 함

개략적 설계안

  • 방금 클라이언트와 서버 사이의 주 통신 프로토콜로 웹소켓을 사용하기로 결정
  • 하지만 다른 부분에서는 굳이 웹소켓 필요 X
  • 회원가입, 로그인, 사용자 프로파일등의 대부분의 기능은 HTTP로 구현해도 무방함
  • 점체 시스템의 개략적 설계안은 그림 12-7 참고
    • stateless 서비스
    • stateful 서비스
    • 제3자 서비스 연동

Stateless 서비스

  • 로그인, 회원가입, 사용자 프로파일 표시등을 처리하는 전통적인 request/response 서비스
  • 무상태 서비스는 로드밸런서 뒤에 위치, monolithic 일수도, micro-service일수도 있음
  • 이 서비스들 가운데 상당수가 시장에 완제품으로 나와 있어서, 쉽게 사서 쓸 수 있음
  • 이들 가운데 주목할 서비스는 서비스 탐색 (service discovery) 서비스 : 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할

Stateful 서비스

  • 채팅 서비스만이 상태 유지가 필요한 서비스
  • 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 함
  • 보통 서버가 살아있는 한 다른 서버로 연결을 변경하지 않음
  • service discovery 서비스는 채팅 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 함

제3자 서비스 연동

  • 채팅 앱에서 가장 중요한 서드파티 서비스는 푸시 알림
  • 새 메시지를 받았다면 설사 앱이 실행 중이지 않더라도 알림을 받아야 함
  • 10장 알림 시스템 설계 참고

규모 확장성

  • 트래픽 규모가 얼마 되지 않을 때는 위 기능을 서버 한대로 구현 가능하나, SPOF 및 분산 처리등을 위해 다중 서버로의 규모확장을 해야 함
  • 그림 12-8 참고하여 개략적 설계안 확인
    • 채팅 서버는 클라이언트 사이에 메시지를 중계하는 역할
    • 접속상태 서버 (presence server)는 사용자의 접속 여부를 관리
    • API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리
    • 알림 서버는 푸시 알림을 보냄
    • key-value 저장소에는 채팅 이력(chat history)을 보관, 시스템에 접속한 사용자는 이전 채팅 이력을 전부 보게 될 것임

저장소

  • 어떤 데이터 베이스를 쓸까? - RDBMS vs NoSQL
  • 따져야 할 것은, 데이터의 유형과 읽기/쓰기 연산의 패턴
  • 채팅 시스템이 다루는 데이터는 보통 두가지
    • 사용자 프로파일, 설정, 친구 목록과 같은 일반적인 데이터
      • 다중화(replication)와 샤딩(sharding)은 이런 데이터의 가용성과 규모확장성을 보증하기 위해 보편적으로 사용
    • 채팅 시스템의 고유한 데이터인 채팅 이력 (chat history)
      • 채팅 이력 데이터의 양은 엄청남, 페이스북 메신저나 왓츠앱은 매일 60B 개의 메시지를 처리
      • 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지, 대부분의 사용자는 오래된 메시지는 들여다보지 않음
      • 하지만 검색 기능을 이용하거나, 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프하는 일도 있으므로 이도 지원해야함
      • 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1 정도
  • 이 모두를 지원하기 위해 본 설계안에서는 key-value 저장소를 추천함
    • key-value 저장소는 수평적 규모확장(horizontal scaling)이 쉬움
    • 데이터 접근 지연시간(latency)이 낮음
    • 관계형 데이터 베이스는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있음. 인덱스가 커지면 데이터에 대한 random access를 처리하는 비용이 늘어남
    • 페이스북 메신저 (HBase), 디스코드(Cassandra) 등이 이미 key-value 저장소 사용 중

데이터 모델

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

message
-------
message_id : bigint (PK)
messge_from : bigint 
message_to : bigint
content : text
created_at : timestamp
  • 위는 1:1 채팅을 지원하기 위한 메시지 테이블의 사례
  • PK (Primary Key)는 message_id, 메시지 순서를 쉽게 정할 수 있는 역할도 담당
  • created_at을 사용해서는 순서를 명확히 정할 수 없음, 서로 다른 두 메시지가 server time상으로 같은 시점에 생길 수도 있기 때문

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

group message
-------------
channel_id : bigint (PK)
message_id : bigint (PK)
message_to(from?) : bigint
content : text
created_at : timestamp
  • (channel_id, message_id)의 복합키(composite key)를 PK로 사용
  • 채널은 채팅 그룹과 같은 뜻, partition key로도 사용 : 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 할 것이기 때문 (exclusive)

메시지 ID

  • message_id를 만드는 기법은 자세히 논의할 만한 가치가 있는 흥미로운 주제 (분산환경의 key-value store의 경우)
    • message_id의 값은 고유해야 함 (uniqueness).
    • ID 값은 정령 가능해야 하며 시간 순서와 일치해야 함. 즉, 새로운 ID는 이전 ID보다 큰 값이어야 함
  • RDBMS는 auto_increment가 대안이나, NoSQL은 보통 해당 기능 제공 X
  • Snowflake 사용 (7장 참고)
  • 지역적 순서 번호 생성기 (local sequence number generator) 이용
    • 지역적 : ID의 유일성은 같은 그룹 안에서만 보증하면 충분
    • 메시지 사이의 순서는 같은 채널, 혹은 같은 1:1 채팅 세션 안에서만 유지되면 충분함
    • 구현하기 쉬운 접근법

3. 상세 설계

  • 채팅 시스템의 경우 가장 먼저 상세 설계를 진행할 부분은 서비스 탐색, 메시지 전달 흐름, 사용자 접속 상태 표시 방법 이다.

서비스 탐색

  • 서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것
  • 이 때 사용되는 기준
    • 클라이언트의 위치 (geographical location)
    • 서버의 용량 (capacity)
  • 널리 쓰이는 오픈 소스 솔루션 : 아파치 주키퍼 (Apache Zookeeper)
    • 사용 가능한 모든 채팅 서버를 여기 등록시켜 두고, 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라줄 수 있음
주키퍼로 구현한 서비스 탐색기능 (그림 12-11 참고)
  1. 사용자 A가 시스템에 고르인을 시도
  2. 로드밸런서가 로그인 요청을 API 서버들 가운데 하나로 보냄
  3. API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능 동작
  4. 해당 사용자를 서비스할 최적의 채팅 서버 탐색 (geological location, server capacity 고려) 예제에서는 서버 2가 선택됨
  5. 사용자 A는 채팅 서버 2와 웹소켓 연결을 맺음

메시지 흐름

  • 채팅 시스템에 있어 종단 간 (end to end) 메시지 흐름을 이해하는 것은 흥미로운 주제
    • 1:1 채팅 메시지 처리 흐름
    • 여러 단말 간 메시지 동기화
    • 그룹 채팅 메시지의 처리흐름
1:1 채팅 메시지 처리 흐름
  • 그림 12-12 참고
  1. 사용자 A가 채팅 서버 1로 메시지 전송
  2. 채팅 서버 1은 ID 생성기를 통해 해당 메시지의 ID 결정
  3. 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
  4. 메시지가 키-값 저장소에 보관됨
  5. 사용자 B의 접속 유무에 따라 a. 사용자 B가 접속중인 경우 : 메시지는 사용자 B가 접속 중인 채팅 서버 (예제에서는 채팅 서버 2)로 전송 b. 사용자 B가 접속중이 아닌 경우 : 푸시 알림 메시지를 푸시 알림 서버로 보냄
  6. 채팅 서버 2는 메시지를 사용자 B에게 전송. 사용자 B와 채팅 서버 2 사이는 웹소켓으로 연결되어 있음
여러 단말 사이의 메시지 동기화
  • 그림 12-13 참고
  • 그림 12-13에서 사용자 A는 전화기와 랩톱의 두 대 단말을 이용 중
  • 사용자 A가 전화기에서 채팅 앱에 로그인한 결과로 채팅 서버 1과 해당 단말 사이에 웹소켓 연결이 만들어져 있음
  • 랩톱도 로그인 결과로 채팅 서버 1에 웹소켓 연결이 되어 있음
  • 각 단말은 cur_max_message_id라는 변수 유지, 해당 단말에서 관측된 가장 최신 메시지의 ID를 추적하는 용도
  • 아래 두 조건을 만족하는 메시지는 새 메시지로 간주
    • 수신자 ID가 현재 로그인한 사용자 ID와 같다
    • 키-값 저장소에 보관된 메시지로서, 그 ID가 cur_max_message_id보다 크다
  • cur_max_message_id는 단말마다 별도로 유지 관리하면 되는 값이라, key-value 저장소에서 새 메시지를 가져오는 동기화 작업도 쉽게 구현할 수 있다.
소규모 그룹 채팅에서의 메시지 흐름
  • 발신자 입장 (그림 12-14 참고)
    • 사용자 A가 그룹 채팅 방에서 메시지를 보냈을 때 어떤 일이 벌어지는지 보여 줌
    • 해당 그룹에 3명의 사용자가 있다고 할 때
    • 사용자 A가 보낸 메시지가 사용자 B와 C의 메시지 동기화 큐 (message sync queue) 에 복사
    • 이 큐는 사용자 각각에 할당된 메시지 수신함 같은 것
    • 이 설계안은 소규모 그룹 채팅에 적합한데, 이유는 다음과 같음
      • 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되니까, 메시지 동기화 플로가 단순함
      • 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않음
    • 위챗(WeChat)이 이런 접근법을 쓰고 있음, 그룹의 크기는 500명으로 제한됨
  • 수신자 입장 (그림 12-15 참고)
    • 한 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야 함
    • 메시지 동기화 큐는 여러 사용자로부터 오는 메시지를 받을 수 있어야 함

접속상태 표시

  • 사용자의 접속 상태를 표시하는 것은 채팅 어플리케이션의 핵심적 기능 (카톡은 안됨…)
  • 채팅 프로필에 녹색 점이 붙어있는 기능을 어떻게 구현할 수 있는지 살펴본다.
  • 개략적 설계안에서는 접속상태 서버 (presense server)를 통해 사용자의 상태를 관리한다고 했었음
  • 접속상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부라는 점 유의
사용자 로그인
  • 그림 12-16 참고
  • 사용자 로그인 절차에 대해서는 “서비스 탐색” 절에서 설명한 바 있음
  • 클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속샅애 서버는 A의 상태와 las_active_at 타임스탬프 값을 key-value 저장소에 보관
  • 이 절차가 끝나고 나면 해당 사용자는 접속 중인 것으로 표시될 것
로그 아웃
  • 그림 12-17 참고
  • key-value 저장소에 보관된 사용자 상태가 online에서 offline으로 바뀌게 됨
접속 장애
  • 인터넷 연결은 언제든지 끊길 수 있음, 따라서 그런 상황에 대응할 수 있는 설계를 준비해야 함
  • Naive하게 생각해보았을 때, 연결이 끊기면 offline, 다시 접속하면 online으로 바꾸면 됨
  • 하지만, 연결이 짧은 시간 동안 끊기는 일은 너무 흔하다. 이럴 때마다 접속 상태가 변경된다면 UX적으로 좋지 않음
  • 본 설계안에서는 heartbeat 검사를 통해 이 문제를 해결 (그림 12-18)
  • 온라인 상태의 클라이언트로 하여근 주기적인 heartbeat event를 접속상태 서버로 보내도록 함
상태 정보의 전송
  • 그림 12-19 참고
  • 사용자 A의 친구들은 어떻게 해당 사용자의 상태 변화를 알게 될 것인가?
  • 상태정보 서버는 publish-subscribe model을 사용, 즉 각각의 친구관계마다 채널을 하나씩 둔다.
  • 위 방안은 그룹 크기가 작을 때는 효과적임, 위챗은 그룹 크기 상한을 500으로 제한하고 있어서 이 접근법 사용할 수 있으나, 그룹 크기가 더 커지면 이런 식으로 접속상태 변화를 알려서는 비용이나 시간이 많이 들게 됨
  • 위 문제를 해소하는 방법은 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도

4. 마무리

정리

  • 1:1 채팅과 그룹 태칭을 전부 지원하는 채팅 시스템의 아키텍처를 살펴 봄
    • 클라이언트 - 서버 사이의 실시간 통신을 가능하도록 웹소켓 사용
    • 실시간 메시징을 지원하는 채팅 서버
    • 접속 상태 서버
    • 푸시 알림 서버
    • 채팅 이력을 보관할 key-value 저장소
    • 이를 제외한 나머지 기능을 구현하는 데 쓰일 API 서버

추가 논의 가능 사항

  • 사진이나 비디오 등의 미디어를 지원하도록 하는 방법 : 미디어 파일은 크기 크므로, 압축 방식, 클라우드 저장소, 썸네일 생성 등을 논의 가능
  • 종단 간 암호화 : 왓츠앱은 메시지 전소엥 있어 종단 간 암호화 지원, 메시지 발신인과 수신자 이외에는 아무도 메시지 내용을 볼 수 없다
  • 캐시 : 클라이언트에 이미 읽은 메시지를 캐시해 두면 서버와 주고받는 데이터 양을 줄일 수 있음
  • 로딩 속도 개선 : slack은 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축하여 앱 로딩 속도를 개선 함 (참고)
  • 오류 처리
    • 채팅 서버 오류 : 채팅 서버 하나가 죽으면 서비스 탐색 기능이 동작하여 클라이언트에게 새로운 서버를 배정하고 다시 접속할 수 있도록 해야 함
    • 메시지 재전송 : 재시도(retry)나 큐(queue)는 메시지의 안정적 전송을 보장하기 위해 사용되는 기법

참고자료

  • 알렉스 쉬, 가상 면접 사례로 배우는 대규모 시스템 설계 기초 12장

Comments