12장 : 채팅 시스템 설계

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

  • 응답지연이 낮은 일대일 채팅 기능

  • 최대 100명까지 참여할 수 있는 그룹 채팅 기능

  • 사용자의 접속상태 표시 기능

  • 다양한 단말 지원. 하나의 계정으로 여러 단말에 동시 접속 지원

  • 푸시 알림

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

  • 클라이언트들로부터 메시지 수신

  • 메시지 수신자(recipient) 결정 및 전달

  • 수신자가 접속(online) 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관

HTTP는 클라이언트가 연결을 만드는 프로토콜이며, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데는 쉽게 쓰일 수 없다. 서버가 연결을 만드는 것처럼 동작할 수도 있도록 하기 위해 많은 기법이 제안되어 왔는데, 폴링(polling), 롱 폴링(long polling), 웹소켓(WebSocket) 등이 있다.

폴링

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

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

롱 폴링

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

웹소켓

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

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

개략적 설계안

  • 무상태 서비스

  • 상태 유지 서비스

  • 제 3자 서비스 연동

  • 규모 확장성

    • 채팅 서버는 클라이언트 사이에 메시지를 중게하는 역할을 담당한다.

    • 접속상태 서버는 사용자의 접속 여부를 관리한다.

    • API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리한다.

    • 알림 서버는 푸시 알림을 보낸다.

    • 키-값 저장소에는 채팅 이력을 보관한다. 시스템에 접속한 사용자는 이전 채팅 이력을 전부 보게 될 것이다.

  • 저장소

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

      • 첫 번째는 사용자 프로파일, 설정, 친구 목록처럼 일반적인 데이터다. 이런 데이터는 안정성을 보장하는 관계형 데이터베이스에 보관한다. 다중화(replication)과 샤딩(sharding)은 이런 데이터의 가용성과 규모확장성을 보증하기 위해 보편적으로 사용되는 기술이다.

      • 두 번째 유형의 데이터는 채팅 시스템에 고유한 데이터로, 바로 채팅 이력(chat history)이다. 이 데이터를 어떻게 보관할지 결정하려면 읽기/쓰기 연산 패턴을 이해해야 한다.

        • 채팅 이력 데이터의 양은 엄청나다.

        • 이 데이터 가운데 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지다.

        • 사용자는 대체로 최근에 주고받은 메시지 데이터만 보게 되는 것이 사실이나, 검색 기능을 이요아거나, 특정 사용자가 언급된 메시지를 모거나, 특정 메시지로 점프라거나 하여 무작위적인 데이터 접근을 하게 되는 일도 있다.

        • 1 : 1 채팅 앱의 경우 읽기 : 쓰기 비율은 대략 1 : 1 정도다.

  • 데이터 모델

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

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

    • 메시지 ID

3단계 : 상세 설계

서비스 탐색

  • 서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것이다. 이때 사용되는 기준으로는 클라이언트의 위치, 서버의 용량 등이 있다. 서비스 탐색 기능을 구현하는 데 널리 쓰이는 오픈 소스 솔루션으로는 아파치 주키퍼 같은 것이 있다.

메시지 흐름

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

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

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

접속상태 표시

  • 사용자 로그인

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

  • 로그아웃

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

  • 접속 장애

    • heartbeat 검사 : 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 하고, 마지막 이벤트를 받은지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지하는 것이다. 그렇지 않은 경우에만 오프라인으로 바꾸는 것이다.

  • 상태 정보의 전송

    • 상태 정보 서버는 발행-구독 모델을 사용한다.

    • 즉 각각의 친구관계마다 채널을 하나씩 둔다.

4단계 : 마무리

1 : 1 채팅과 그룹 채팅을 전부 지원하는 채팅 시스템의 아키텍처를 살펴보았다. 클라이언트와 서버 사이의 실시간 통신을 가능하도록 하기 위해 웹소켓을 사용하였으며, 실시간 메시징을 지원하는 채팅 서버, 접속 상태 서버, 푸시 알림 서버, 채팅 이력을 보관할 키-값 저장소, 그리고 이를 제외한 나머지 기능을 구현하는 데 쓰일 API 서버 등이 그 주요 컴포넌트였다.

  • 채팅 앱을 확장하여 사진 및 비디오 등의 미디어 지원 방법 : 미디어 파일은 텍스트에 비해 크기가 크다. 그롸 관련하여 압축 방식, 클라우드 저장소, 섬네일 생성 등을 논의해보면 재미있을 것이다.

  • 종단 간 암호화

  • 캐시

  • 로딩 속도 개선

  • 오류 처리

    • 채팅 서버 오류

    • 메시지 재전송

Last updated