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

• 1:1 채팅에 집중한 앱: 페이스북 메신저, 위챗, 왓츠앱
• 그룹채팅에 중점을 둔 업무용 앱: 슬랙
• 대규모 그룹 소통과 latency가 낮은 음성 채팅에 집중한 앱: 디스코드

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

• 응답지연이 낮은 일대일 채팅 기능
• 최대 100명까지 참여할 수 있는 그룹 채팅 기능
• (첨부파일은 지원하지 않아도 됨. 텍스트 메시지만)
• 사용자 접속상태 표시 기능
• 메시지 길이 제한 - 100,000자 이하
• [시간 가능하다면] 종단 간 암호화 지원
• 채팅 이력은 영원히 보관되어야 함
• 다양한 단말 지원. 하나의 계정으로 여러 단말에 동시 접속 지원 (아무래도 웹/앱 모두 지원되려면 ..)
• 푸시 알림
• 5천만 DAU 처리 가능해야 함

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

• 기본 기능
  • 클라이언트로부터 메시지 수신
  • 메시지 수신자 결정 및 전달
  • 수신자가 접속(online) 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관
• 사용할 네트워크 통신 프로토콜을 결정해야 함
  • HTTP
    • 현재 웹에서 가장 널리 사용되는 프로토콜
    • keep alive 헤더를 사용함으로써 클라이언트와 서버 사이의 연결을 끊지 않고 계속 유지할 수 있어 효율적이고, TCP 핸드셰이크 횟수를 줄일 수 있음
    • 대중적인 채팅 프로그램들이 초기 HTTP 를 사용했음
  • 그러나, HTTP는 클라이언트가 연결을 만드는 프로토콜로, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데에 쉽게 쓰일 수 없음
    • 서버가 연결을 만드는 것처럼 동작할 수 있도록 하기 위한 기법들 → 폴링(polling), 롱 폴링(log polling), 웹소켓 등

폴링

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

롱 폴링

• 폴링을 개선한 방법
• 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결 유지
• 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내어 모든 절차를 다시 시작
• 단점
  • 서버 로드밸런서로 인해, 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수도 있음
  • 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 좋은 방법이 없음
  • 여전히 비효율적. 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속해야 함

웹 소켓

• 서버가 클라이언트에게 비동기(async) 메시지를 보낼 때 가장 널리 사용
• 처음에는 HTTP 연결이지만, 특정 핸드셰이크 절차를 거쳐 웹 소켓 연결로 업그레이드 됨
  • 지속적인 연결이 만들어지고 나면 서버는 클라이언트에게 비동기적으로 메시지를 전송할 수 있음
• HTTP/HTTPS 기본 포트번호를 그대로 사용하기 때문에, 방화벽이 있는 환경에서도 잘 동작함
• 양방향 메시지 전송 가능
• 유의할 점은 지속적으로 유지되어야 하기 때문에, 서버 측에서 연결 관리를 효율적으로 해야 함

개략적 설계안

• 통신 프로토콜: 웹 소켓 사용
• 회원가입, 로그인, 사용자 프로파일 등 대부분의 기능은 HTTP
• 구현할 채팅 시스템을 3개의 부분으로 나눌 수 있음 → 무상태, 상태유지(stateful), 제3자 서비스 연동

무상태 서비스

• 로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스
• 로드밸런서 뒤에 위치. 상당수가 시장에 완제품으로 나와있어 직접 구현하지 않아도 쉽게 사서 쓸 수 있음
  • 서비스 탐색(service discovery) 서비스: 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할

상태 유지 서비스

• 채팅 서비스
• 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 함
• 서비스 탐색 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 함

제3자 서비스 연동

• 푸시 알람
• 새 메시지를 받았다면, 설사 앱이 실행 중이지 않더라도 알람을 받아야 함

규모 확장성

• 동시 접속자: 1M(100만) 라고 가정
• 접속 당 10K(1만) 의 서버 메모리가 필요하다면, 10GB 메모리만 있으면 모든 연결을 다 처리할 수 있음
• 초반 설계안에 서버 1대로 구성하는 것은 괜찮으나, SPOF(Single Point Of Failure) 과 같이 장애 대응을 위해서라도, 점차 다듬어가며 서버 여러 대로 트래픽 처리하기 위해 검토하기

개략적 설계안

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

저장소

• 데이터의 유형과 읽기/쓰기 연산의 패턴을 바탕으로, 관계형 데이터베이스를 쓸지, NoSQL을 채택할지 결정
• 채팅 시스템이 다루는 데이터 2가지
  • (1) 사용자 프로파일, 설정, 친구 목록처럼 일반적인 데이터
    • 안정성을 보장하는 관계형 DB에 저장
    • 다중화(replication)와 샤딩(sharding) 기술 사용
  • (2) 채팅 시스템에 대한 고유 데이터인 채팅 이력 데이터
    • (채팅 이력 데이터에 대한) 읽기/쓰기 패턴
      • 채팅 이력 데이터의 양은 엄청나다. 페이스북 메신저/WhatsApp 기준 매일 600억 개의 메시지
      • 이 데이터 가운데 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지이며, 대부분의 사용자는 오래된 메시지를 들여다보지 않음
      • 사용자는 대체로 최근에 주고받은 메시지 데이터만 보게 되는 것이 사실이나, 검색 기능을 이용하거나, 특정 사용자가 멘션된 메시지를 보거나, 특정 메시지로 점프 하거나 하여 무작위적인 데이터 접근을 하게되는 일도 있음. → 전부 지원해야 함
      • 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1
    • 위 모두를 지원하는 저장소인 <키-값 저장소>를 채택
      • 키-값 저장소는 수평적 규모확장이 쉬움
      • 키-값 저장소는 데이터 접근 지연시간(latency)이 낮음
      • 관계형 데이터베이스는 데이터 가운데 long tail에 해당하는 부분을 잘 처리하지 못하는 경향이 있다. 인덱스가 커지면 데이터에 대한 무작위적 접근(random access)을 처리하는 비용이 늘어남
      • 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 채택
        • 페이스북 메신저: `HBase`, 디스코드: `카산드라`

데이터 모델

• 메시지 데이터를 어떻게 보관할 것인지

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

• 기본 키(primary key): message_id
• created_at 으로는 메시지 순서를 정할 수 없음 → 두 메시지가 동시에 만들어지는 경우

 

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

• 복합 키(composite key): (channel_id, message_id)
• 파티션 키: channel_id

message_id

• message_id 는 메시지들의 순서도 표현할 수 있어야 하기 때문에, 아래와 같은 속성을 만족해야 함
  • message_id 의 값은 고유해야 함
  • ID 값은 정렬 가능해야 하며 시간 순서와 일치해야 함. 즉, 새로운 ID는 이전 ID보다 큰 값이어야 함
• 위 속성을 만족시키기 위한 방법
  • (1) auto_increment 사용 (RDBMS만 제공, NoSQL X) → NoSQL인 키-값 저장소에서는 못 사용함
  • (2) 스노플레이크 같은 전역적 64-bit 순서 번호 생성기 이용
  • (3) 지역적 순서 번호 생성기
    • 지역적 → ID의 유일성이 같은 그룹 안에서만 보증하면 됨
    • 메시지 사이의 순서는 같은 채널, 혹은 1:1 채팅 세션 안에서만 유지되면 충분함

3단계: 상세 설계

• 서비스 탐색(service discovery)
• 메시지 전달 흐름
• 사용자 접속 상태 표시

서비스 탐색

• 서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천
• 이 때 사용되는 기준으로는 클라이언트의 위치, 서버 용량 등이 있음
• ex. 아파치 주키퍼
• 동작 순서
  • 
  •  
  • 1. 사용자가 시스템에 로그인 시도
  • 2. 로드밸런서가 로그인 요청을 API 서버들 가운데 하나로 보냄
  • 3. API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능이 동작하여 해당 사용자를 서비스할 최적의 채팅 서버를 찾는다 (위 예제의 경우, 최적 채팅서버로 2번을 선택. 그림 참고)
  • 4. 사용자는 채팅서버 2와 웹소켓 연결을 맺음

메시지 흐름

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

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

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

• 다음 두 조건을 만족하는 메시지는 새 메시지로 간주
  • 수신자ID가 현재 로그인한 사용자ID와 같음
  • 키-값 저장소에 보관된 메시지로서, 그 ID가 cur_max_message_id 보다 큼

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

• 사용자 별로 메시지 동기화 큐(message sync queue) 로 구현
  • 새로운 메시지가 왔는지 확인하려면 본인 큐만 보면 되기 때문에, 메시지 동기화 플로가 단순함
  • 그룹이 크지 않으면 수신자별로 복사하여 큐에 넣는 작업의 비용이 문제되지 않음
  • → 해당 방법은 사용자가 많으면 (똑같은 메시지를 모든 사용자의 큐에 복사하기 때문에) 바람직하지 않음

접속상태 표시

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

사용자 로그인

• 클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면, 접속상태 서버는 사용자의 status(online)와 timestamp 값을 키-값 저장소에 보관
• 이 절차가 끝나고 나면 해당 사용자는 접속 중인 것으로 표시

로그아웃

• 키-값 저장소에 보관된 사용자 status 가 online → offline 으로 바뀜

접속 장애

• 사용자의 인터넷 연결이 끊어지면 클라이언트와 서버 사이에 맺어진 웹소켓 같은 지속성 연결이 끊김
  • 간단한 해결 방법: 사용자를 오프라인 상태로 표시한 후, 연결이 복구되면 온라인 상태로 변경
    • 짧은 시간 동안 인터넷 연결이 끊어졌다 복구되는 일은 흔하기 때문에, 그 때마다 상태를 변경한다면 지나친 일이고, 사용자 경험 측면에서도 바람직하지 않음
  • heartbeat 검사를 통해 해결
    • 온라인 상태의 클라이언트에게 주기적으로 heartbeat event를 접속상태 서버로 보내도록 하고, 마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지
    • x초 이후에는 오프라인으로 바꿈

상태 정보의 전송

• 사용자 A와 친구 관계에 있는 사용자들이 어떻게 상태변화를 알게 하는지
• 발행-구독 모델(publish-subscribe model)을 사용하여 각각의 친구관계마다 채널을 하나씩 둠
  • 사용자 A 기준으로 B,C,D 친구가 있다면
    • 채널 개수: 3개 (A-B, A-C, A-D)
    • A의 구독자: B, C, D
    • 해당 채널을 통해 상태정보 변화 통지 받을 수 있음
  • 클라이언트와 서버 사이의 통신에는 실시간 웹소켓 사용
• 위 방법은 그룹 크기가 작을 때 효과적. 성능 문제를 해소하는 방법으로는, 사용자가 그룹 채팅에 입장하는 순간에만 상태정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도

4단계: 마무리

• [정리] 1:1 채팅, 그룹 채팅을 지원하는 채팅 시스템
  • 실시간 통신을 위한 웹소켓 사용
  • 실시간 메시징을 지원하는 채팅 서버
  • 접속상태 서버
  • 푸시 알림 서버
  • 채팅 이력을 보관할 키-값 저장소
  • 이를 제외한 나머지 기능을 구현하는 데 쓰일 API 서버 등
• 이후에 논의해봐도 좋을 것
  • 채팅 앱을 확장하여 사진이나 비디오 등의 미디어를 지원하도록 하는 방법
    • 사진, 비디오는 텍스트에 비해 크기가 크기 때문에, 이와 관련하여 압축 방식, 클라우드 저장소, 썸네일 생성 등을 논의
  • 종단 간 암호화
    • 메시지 발신인과 수신자 이외에는 아무도 메시지를 볼 수 없도록
  • 캐시
    • 클라이언트에 이미 읽은 메시지를 캐시해두어 서버와 주고받는 데이터의 양을 줄임
  • 로딩 속도 개선
    • 사용자의 데이터, 채널 등을 지역적으로 분산하여 앱 로딩속도 개선 가능
  • 오류 처리
    • 채팅 서버 오류: 서버 하나가 죽으면, 해당 서버에 할당되어있는 클라이언트들에게 새로운 서버를 배정하고 다시 접속할 수 있도록 해야 함
    • 메시지 재전송: 재시도나 큐는 메시지의 안정적 전송을 보장