가상 면접 사례로 배우는 대규모 시스템 설계 기초 Study [12장] 채팅 시스템 설계

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

요구사항

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

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

• 채팅 시스템의 경우 클라이언트는 모바일 앱이거나 웹 애플리케이션이다.
• 클라이언트는 서로 직접 통신하지 않는다.
• 제공해야하는 기능
  • 클라이언트들로부터 메세지 수신
  • 메시지 수신자(recipient) 결정 및 전달
  • 수신자가 접속 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관

2.1 서버 연결을 위한 프로토콜 결정하기

HTTP 프로토콜

• 오랜 세월 검증된 프로토콜
• 클라이언트는 채팅 서비스에 HTTP 프로토콜로 연결한 다음 메세지를 보내어 수신자에게 해당 메세지 전달
• 채팅 서비스와 접속시 keep-alive 헤더를 사용하여 클라이언트와 서버사이 연결을 유지하고 TCP 접속과정에서 생기는 핸드쉐이크 횟수를 줄임
• HTTP는 클라이언트가 연결을 만드는 프로토콜이고 서버에서 임의 시점에 클라이언트로 메시지를 보내기 어려움

폴링

• 폴링은 클라이언트가 주기적으로 서버에게 새 메시지가 있는지 물어보는ㅂ ㅏㅇ법
• 폴링을 자주하면 폴링비용이 증가
• 답할 메세지가 없을 경우 서버 자원이 불필요하게 낭비

롱폴링

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

롱폴링의 약점

• 송신 클라이언트와 수신 클라이언트가 같은 채팅서버에 접속하지 않을 수도 있다.
• HTTP 서버들은 보통 무상태서버이며 로드밸런싱을 위해 라운드로빈 알고리즘에 의해 같은 서버에 연결을 갖고 있지 않을 수 있다.
• 서버 입장에서 클라이언트가 연결을 해제 했는지 알 방법이 없음
• 메세지를 많이 받지 않는 클라이언트의 타임아웃이 발생할 때 마다 주기적으로 서버에 재접속하므로 비효율적

웹소켓

• 웹소켓은 서버가 클라이언트에게 비동기(async) 메세지를 보낼 때 가장 널리 사용하는 기술
• 연결은 클라이언트에 시작하며 한번 맺어진 연결은 항구적이며 양방향
• HTTP 연결이지만 특정 핸드셰이크 절차를 거쳐 웹소켓 연결로 업그레이드
• 방화벽이 있는 환경에서도 잘 동작
• HTTP/HTTPS의 기본 포트 번호를 그대로 사용
• 메세지 송신 수신 시 동일한 프로토콜을 사용하므로 설계 및 구현이 단순
• 메세지 연결을 항구적으로 유지되어야 하기 때문에 서버 측에서 연결 관리를 효율적으로 해야함

2.2 개략적 설계안

• 채팅 기능 이외에 굳이 웹소켓을 사용할 필요는 없다.
• 무상태 서비스, 상태유지(stateful) 서비스, 제3자서비스 로 나눈다.

무상태 서비스

• 무상태 서비스는 로그인, 회원가입, 사용자 프로파일 표시 등을 처리
• 보편적으로 제공하는 기능
• 무상태 서버 앞에는 로드밸런서를 위치시켜 요청을 그 경로에 맞는 서비스로 정확하게 전달
• 서비스 탐색(service discovery) 서비스 - 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할

상태 유지 서비스

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

제3자 서비스 연동

• 앱이 실행중이 아니어도 새 메세지를 수신받으면 푸시 알림을 전송한다.

규모 확장성

• 서버 한 대로 얼마나 많은 동시접속을 허용할 수 있는지 확인해야함

ex) 동시접속자를 1M 이라 가정, 접속당 10K의 서버 메모리 필요하다 본다면 10GB 메모리만 있으면 모든 연결을 처리가능

• SPOF(Single Point Of Failure) 문제로 서버 한대로 처리하지는 않음

  

• 채팅 서버 : 클라이언트 사이에 메시지를 중개하는 역할

• 접속상태 서버(presence server) : 사용자의 접속 여부 관리

• API 서버 : 채팅 이외의 기능을 처리

• 알림 서버 : 푸시 전송

• 키-값 저장소 : 채팅 이력을 보관하며 시스템에 접속한 사용자는 이전 채팅이력을 전부 볼 수 있음

저장소

• 데이터 유형과 읽기/쓰기 연산 패턴을 파악하여 데이터베이스 유형을 정의

일반적 데이터

• 사용자 프로파일, 설정, 친구 목록 등 일반적 데이터는 관계형 데이터베이스에 보관

채팅 이력 데이터

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

키-값 저장소

• 키-값 저장소는 수평적 규모확장이 쉽다
• 데이터 접근 지연시간이 낮다
• 관계형 데이터베이스는 롱 테일에 해당하는 부분을 잘 처리하지 못하며 인덱스가 커지면 데이터에 대한 무작위적 접근을 처리하는 비용이 늘어남
• 안정적인 채팅 서비스가 키-값 저장소를 사용중
  • 페이스북 메신저 : HBase
  • 디스코드 : Cassandra

데이터 모델

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

• 테이블의 기본 키는 message_id로 메세지 순서를 쉽게 정할 수 있도록 하는 역할을 담당한다.
• 두 메세지가 동시에 만들어 질 수도 있으므로 created_at을 사용하여 메시지 순서를 정할 수 없다.

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

• channel_id, message_id의 복합키를 기본키로 사용한다.
• 채널은 채팅 그룹을 의미
• 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 한다.

메세지 아이디

• message_id는 고유해야 한다.
• ID는 정렬 가능해야하며 시간 순서와 일치해야 한다.
• auto_incrment (RDBMS 인 경우)
• 스노플레이크 같은 전역적 64-bit 순서 번호 생성기를 이용
• 지역적 순서 번호 생성기 이용
• ID의 유일성은 같은 그룹 안에서만 보증하면 충분하다

3. 상세설계

3.1 서비스 탐색

• 서비스 탐색의 기능은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것
• 기준은 클라이언트의 위치, 서버의 용량 등
• 아파치 주키퍼 등의 오픈 소스 솔루션

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

3.2 메세지 흐름

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

1. 사용자 A가 채팅서버 1로 메시지 전송
2. 채팅 서버 1은 ID 생성기를 사용해 해당 메시지 ID 결정
3. 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
4. 메시지가 키-값 저장소에 보관
5. (a) 사용자 B가 접속 중인 경우 메시지는 사용자 B가 접속중인 채팅 서버로 전송 (b) 사용자 B가 접속중이 아니라면 푸시 알림 메시지를 푸시 알림 서버로 전송
6. 채팅 서버 2는 메시지를 사용자 B에 전송. 사용자 B와 채팅 서버 2사이에는 웹소켓 연결이 있는 상태이므로 그것을 이용

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

• 각 단말은 cur_max_message_id라는 변수를 유지. 해당 단말에서 관측된 가장 최신 메시지의 ID를 추적하는 용도
• 수신자 ID가 현재 로그인한 사용자 ID와 같다.
• 키-값 저장소에 보관된 메시지로서 그 ID가 cur_max_message_id보다 크다
• cur_max_message_id 단말마다 별도로 유지 관리하면 되는 값

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

• A가 보낸 메시지가 사용자 B, C의 메시지 동기화 큐에 복사
• 소규모 그룹 채팅에 적합한 이유
  • 새로운 메시지 여부는 자기 큐만 보면 되니까 메시지 동기화 플로가 단순
  • 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업 비용이 크게 문제 되지 않음
• 그룹의 크기를 제한해야 한다.(위챗의 경우 500명으로 제한)
• 많은 사용자를 지원해야하는 경우 모든 메세지를 사용자 큐에 복사하는 것은 바람직하지 않음

3.2 접속상태 표시

• 접속상태 서버를 통해 사용자의 상태를 관리
• 접속상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부

사용자 로그인

• 클라이언트와 실시간 서비스 사이의 웹소켓 연결이 맺어지고 나면 접속상태 서버는 A의 상태와 last_active_at을 저장

로그아웃

• 키-값 저장소엡 보관된 사용자 상태가 online에서 offline으로 변경
• UI 상 사용자 상태는 접속중이 아닌 것으로 표시

접속장애

• 인터넷 연결이 원활하지 않을 경우 사용자를 오프라인 상태로 표시하고 연결이 복구되면 온라인 상태로 변경
• 클라이언트의 접속상태를 서버로 보내고 마지막 이벤트를 받은이 x초 이내에 주기적으로 박동 이벤트를 보내 접속상태를 서버로 전송
• 마지막 이벤트를 받은지 x초 이내 또다른 박동 이벤트 메시지를 받으면 온라인 상태로 유지

상태 정보의 전송

• 그룹 크기가 작을 때
  • 상태정보는 서버의 발행-구독 모델을 사용할 수 있음
  • 각각의 친구 관계마다 채널을 하나씩 두어 사용자 상태 변화를 쉽게 통지 받을 수 있다.
• 그룹 크기가 큰 경우
  • 사용자가 채팅 그룹에 입장하는 순간에 상태 정보를 읽어감
  • 친구 리스트에 사용자 접속상태를 갱신하면 수동으로 하도록 유도

4. 마무리

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