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

 

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

• 채팅의 종류 
  • 1:1 채팅, 그룹 채팅, 게임 채팅 등 
  • ex) WhatsApp : 1대1 채팅 
  • ex) Slack : 그룹 채팅 
  • ex) Discord : 게임 채팅 
    • 대규모 그룹의 소통과 응답 지연이 낮은 음성 채팅에 집중 
• 서비스 환경 
  • ex) 모바일, 웹 등 
• 트래픽 규모 
• 그룹 채팅의 인원 제한 여부 
• 중요 기능 
  • ex) 첨부파일, 접속 상태 표시 등 
• 메세지 길이 제한 여부 
• 종단 간 암호화 여부 (end to end encryption)
• 채팅 이력 보관 기간 
• 예시로 설계된 요구 사항 
  • 응답 지연이 낮은 일대일 채팅 기능 
  • 최대 100명 까지 참여할 수 있는 그룹 채팅 기능 
  • 사용자의 접속 상태 표시 기능 
  • 다양한 단말 지원
    • 하나의 계정으로 여러 단말 동시 접속 지원 
  • 푸시 알림 
  • 5000만 DAU

 

 

 

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

• 제공 기능
  • 클라이언트로부터 메세지 수신 
  • 메세지 수신자 결정 및 전달 
  • 수신자가 접속상태가 아닌 경우 접속할 때까지 해당 메세지를 보관 
• 메시지 송신 클라이언트 - 채팅 서비스 - 메시지 수신 클라이언트 관계 
  • 채팅을 시작하려는 클라이언트는 네트워크 통신 프로토콜을 사용하여 서비스에 접속 
    • 어떤 프로토콜을 사용할지는 면접관과 상의 
  • 메시지 송신 클라이언트가 채팅 서비스에 메시지 요청 보냄 
    • HTTP 프로토콜을 사용할 수 있음 
    • 채팅 서비스와의 접속에는 keep-alive 헤더를 사용하여 효율적으로 사용 가능 
      • 클라이언트와 서버 사이의 연결을 끊지 않고 계속 유지할 수 있음 
      • TCP 접속 과정에서 발생하는 핸드셰이크 횟수를 줄일 수 있음 
  • 단, HTTP의 경우 서버가 클라이언트로 임의 시점에 메시지를 보내는 데는 쉽게 쓰일 수 없음 
    • 서버가 연결을 만드는 것 처럼 동작할 수 있도록 polling, long polling, webSocket등을 사용할 수 있음 
    • 폴링 
      • 클라이언트가 주기적으로 서버에게 새 메시지를 질의 
      • 필링 비용은 폴리을 자주할 수록 올라감 
      • 답해줄 메세지가 없는 경우 서버 자원이 불필요하게 낭비됨 
    • 롱 폴링 
      • 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지 
      • 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내 모든 절차를 다시 시작 
      • 메세지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수 있음 
        • HTTP 서버들은 보통 무상태 서버로 로드밸런싱을 위해 라운드 로빈 알고리즘을 사용하는 경우 메시지를 받은 서버는 해당 메시지를 수신할 클라이언트와의 롱 폴링 연결을 가지고 있지 않은 서버일 수 있음 
      • 서버가 클라이언트가 연결을 해제했는지 알 방법이 없음 
      • 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속하여 비효율적 
    • 웹소켓
      • 서버가 클라이언트에게 비동기 메시지를 보낼 때 가장 널리 사용하는 기술 
      • 웹 소켓 연결은 클라이언트가 시작 
      • 한번 맺어진 연결은 항구적이며 양방향 
      • 처음에는 HTTP 연결이지만 특정 핸드셰이크 절차를 거쳐 웹 소켓 연결로 업그레이드 됨 
      • 항구적인 연결이 만들어지고 나면 서버는 클라이언트에게 비동기적으로 메시지 전송이 가능 
      • 웹 소켓은 일반적으로는 방화벽이 있는 환경에서도 잘 동작 
        • 80이나 443처럼 HTTP 혹은 HTTPS 프로토콜이 사용하는 기본 포트번호를 그대로 쓰기 때문 
      • 웹소켓을 이용하면 메시지를 보낼때나 받을 때 동일한 프로토콜을 사용할 수 있으므로 설계뿐 아니라 구현도 단순하고 직관적 
      • 단, 웹소켓 연결은 항구적으로 유지되어야 하기 때문에 서버 측에서 연결관리를 효율적으로 해야함 
• 개략적 설계안 
  • 무상태 서비스
    • 로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스 
    • 무상태 서비스가 제공하는 기능은 많은 웹사이트와 앱이 보편적으로 제공하는 기능 
    • 로드밸런서 뒤에 위치 
    • 서비스 탐색 서비스 
      • 클라이언트가 접속할 채팅 서버의 DNS 호스트 명을 클라이언트에게 알려주는 역할 
  • 상태 유지 서비스 
    • 채팅 서비스로 클라이언트가 서버와 독립적인 네트워크를 유지해야 하는 서비스 
    • 클라이언트는 보통 서버가 살아있는 한 다른 서버로 연결을 변경하지 않음 
    • 서비스 탐색 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 구성 
  • 제3자 서비스 연동 
    • ex) 푸시 알림 
      • 앱이 실행중이지 않더라도 알림을 받아야 함 
  • 규모확장성 
    • 트래픽 규모가 얼마 되지 않을 떄는 방금 설명한 모든 기능을 서버 한대로 구현 가능 
    • 대량의 트래픽을 처리해야 하는 경우 서버 한대로 얼마나 많은 접속을 동시에 처리할 수 있는지에 집중 
    • 서버가 한대일 경우 SPOF등의 여러 문제 가능성 있음 
  • 컴포넌트  
    • 채팅 서버는 클라언트 사이에 메시지를 중계하는 역할 담당 
    • 접속상태 서버(presence server)는 사용자의 접속 여부를 관리 
    • API서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리 
    • 알림서버는 푸시 알림을 전송 
    • 키-값 저장소는 채팅 이력을 보관 
      • 시스템에 접속한 사용자는 이전 채팅 이력을 전부 보게 됨 
  • 저장소 
    • 데이터의 유형과 읽기/쓰기 연산의 패턴에 유의 
    • 채팅 시스템이 다루는 데이터
      • 1) 사용자 프로파일, 설정, 친구 목록 처럼 일반적인 데이터 
        • 안정성을 보장하는 관계형 데이터베이스에 보관
        • 다중화와 샤딩으로 데이터의 가용성과 규모 확장성을 보증 
      • 2) 채팅 시스템에 고유한 데이터 
        • 채팅 이력 
          • 채팅 이력 데이터의 양은 엄청남 
          • 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지 
            • 대부분의 사용자는 오래된 메시지는 들여다보지 않음 
          • 단, 검색 기능을 사용하거나 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프하거나 하여 무작위적인 데이터 접근을 하게 되는 일도 있음
          • 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1정도 
        • 본 설계에서는 키-값 저장소를 사용 
          • 수평적 규모확장이 쉬움 
          • 데이터 접근 지연시간이 낮음 
          • 관계형 데이터베이스는 데이터 가운데 롱테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있음 
            • 인덱스가 커지면 데이터에 대한 무작위적 접근을 처리하는 비용이 늘어남 
          • 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 채택함 
            • ex) 페이스북, 디스코드
  • 데이터 모델 
    • 1:1 채팅을 위한 메시지 테이블 
      • 기본키 = message_id
      • 메시지 순서를 쉽게 정할 수 있도록 하는 역할도 담당 
        • 서로 다른 메시지가 동시에 만들어질 수 있으므로 created_at을 사용하여 메시지 순서를 정할수는 없음 
    • 그룹 채팅을 위한 메시지 테이블 
      • 복합키 = message_id, channel_id
        • 채널은 채팅 그룹과 같은 뜻으로 파티션 키로도 사용됨
          • 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 하기 때문에 
    • 메시지 ID 
      • 메시지들의 순서도 표현할 수 있어야 함 
      • 고유해야함 
      • 정렬가능해야함 
        • 시간 순서와 일치해야 함 
      • 1) NoSQL의 경우 auto_increment를 사용할 수 없기 때문에 스노플레이크같은 전역적 64-bit 순서 번호(sequence number) 생성기를 이용할 수 있음 
      • 2) 지역적 순서 번호 생성기(local sequence number generator)를 이용해 같은 그룹안에서만 ID의 유일성을 보장하도록 구성 

 

 

3단계 상세 설계 

• 서비스 탐색 
  • 클라이언트에 가장 적합한 채팅 서버를 추천 
    • 클라이언트의 위치, 서버의 용량 등에 따라서 추천 
  • 아파치 주키퍼와 같은 오픈 소스 솔루션이 사용될 수 있음 
    • 사용 가능한 모든 채팅 서버를 등록하고 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라주면 됨 
• 메시지 흐름 
  • 1:1 채팅 메시지 처리 흐름 
    • 1) 사용자 A가 채팅 서버 1로 메시지 전송 
    • 2) 채팅 서버 1은 ID 생성기를 사용해 해당 메시지의 ID 결정 
    • 3) 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송 
    • 4) 메시지가 키-값 저장소에 보관 
    • 5) 사용자 B가 접속중인 경우 메시지는 사용자 B가 접속중인 채팅 서버(채팅 서버 2)에 전송, 접속중이 아니라면 푸시 알림메시지를 푸시알림 서버로 전송 
    • 6) 채팅 서버 2는 메시지를 사용자 B에게 전송 
      • 사용자 B와 채팅 서버 2 사이에는 웹 소켓 연결 상태이므로 이를 이용 
  • 여러 단말 사이의 메시지 동기화 
    • 사용자가 여러 단말을 사용하는 경우 여러 단말이 각각의 웹소켓 연결을 특정 서버(채팅서버 1)에 맺게 됨 
    • 각 단말은 cur_max_message_id라는 변수를 유지하고 해당 단말에서 관측된 가장 최신 메시지의 ID를 추적하는 용도로 사용됨 
    • 새 메시지 조건 
      • 수신자 ID가 현재 로그인한 사용자 ID와 같음 
      • 키-값 저장소에 보관된 메시지로 그 ID가 cur_max_message_id보다 큼
    • cur_max_message_id는 단말마다 별도로 유지관리하면 되는 값이기 때문에 키-값 저장소에서 새 메시지를 가져오는 동기화 작업도 쉽게 구현 가능 
  • 소규모 그룹 채팅에서의 메시지 흐름 
    • 사용자 A가 보낸 메시지가 사용자 B, C의 메시지 동기화 큐에 복사됨 
      • 사용자 각각에게 할당된 메시지 수신함 같은 존재 
      • 단, 해당 방식은 소규모 그룹 채팅에 적합 
        • 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되어 동기화 플로우가 단순 
        • 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않음 
        • ex) WeChat
          • 그룹의 크기가 500명으로 제한됨 
      • 수신자 관점 
        • 한 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야 함 
        • 각 사용자의 수신함 (메시지 동기화 큐)은 여러 사용자로부터 오는 메시지를 받을 수 있어야 함 
• 접속 상태 표시 
  • 사용자의 상태를 관리 
  • 접속 상태 서버는 클라이언트와 웹 소켓으로 통신하는 실시간 서비스의 일부 
  • 사용자 로그인 
    • 접속 상태 서버는 사용자의 상태와 last_active_at 타임스탬프 값을 키-값 저장소에 보관 
    • 사용자는 접속 중인 것으로 표시됨 
  • 로그아웃 
    • 사용자의 상태가 offline으로 변경됨ㅁ 
  • 접속장애 
    • 사용자의 인터넷 연결이 끊어지면 클라이언트와 서버 사이에 맺어진 웹소켓 같은 지속성 연결도 끊김 
    • 박동 검사를 통해 (heartbeat) 문제를 해결 
      • 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트 (heartbeat event)를 접속상태 서버로 보내고 마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 해당 사용자의 접속 상태를 계속 온라인으로 유지 
      • 지정된 시간동안 이벤트를 미수신하면 오프라인 상태로 변경 
  • 상태 정보의 전송 
    • 상태 정보 서버는 발행-구독 모델(publish-subscribe model)사용 
      • 1) 각각의 친구관계마다 채널을 하나씩 두는 방안
        • 그룹 크기가 작을 때는 효과적 
      • 2) 사용자가 그룹 채팅에 입장하는 순간에만 상태정보를 읽어가게 하거나 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도 

 

 

4단계 마무리 

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