- 어떤 앱인지 확인하기
- 페이스북 메신저, 위챗, 왓츠앱: 1대 1 채팅에 집중
- 슬랙: 그룹 채팅에 집중
- 디스코드: 대규모 그룹의 소통과 응답지연이 낮은 음성 채팅에 집중
- 트래픽 규모 확인하기: 일별 능동 사용자 수 (Daily Active User) 기준 5천만명
- 인원 제한 확인하기: 최대 100명
- 중요 기능 확인하기: 1대 1채팅, 그룹 채팅, 사용자 접속상태 표시 지원, 텍스트만 주고받기, 메시지 길이 제한, 종단 간 암호화 지원, 채팅 이력 보관은 영원히 등
- 이번 장에서 설계해볼 내용
- 응답지연이 낮은 일대일 채팅 기능
- 최대 100명까지 참여할 수 있는 그룹 채팅 기능
- 사용자의 접속상태 표시 기능
- 다양한 단말 지원 (하나의 계정으로 여러 단말에 동시 접속 지원)
- 푸시 알림
- 5천만 DAU를 처리할 수 있도록 할 것
- 채팅 시스템의 경우 클라이언트는 모바일 앱 혹은 웹 애플리케이션
- 클라이언트들 끼리 직접 통신하지 않음
- 각 클라이언트는 아래의 기능을 지원하는 채팅 서비스와 통신함
- 클라이언트들로부터 메시지 수신
- 메시지 수신자 결정 및 전달
- 수신자가 접속 상태가 아닌 경우 접속할 때까지 해당 메시지 보관
- 채팅을 시작하려는 클라이언트는 네트워크 통신 프로토콜을 사용하여 서비스에 접속. 어떤 통신 프로토콜을 사용할 것인지 상의해야 함
- 대부분의 클라이언트/서버 애플리케이션에서 요청을 보내는 것은 클라이언트로 보통 HTTP 프로토콜을 사용
- 클라이언트는 채팅 서비스에 HTTP 프로토콜로 연결 후 메시지를 보내어 수신자에게 해당 메시지를 전달하라고 알림
- 채팅 서비스와의 접속에는 keep-alive 헤더를 사용하면 클라이언트와 서버 사이의 연결을 끊지 않고 계속 유지할 수 있어 TCP 접속 과정에서 발생하는 핸드셰이크 횟수를 줄일 수 있음.
- 페이스북 같은 대중적 채팅 프로그램이 초기에 HTTP를 사용했음
- 메시지 수신 시나리오는 송신 시나리오보다 복잡함
-
HTTP는 클라이언트가 연결을 만드는 프로토콜이기 때문에 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데에 쉽게 사용이 어려움
-
이 외에 폴링, 롱 폴링, 웹 소켓 등의 서버가 연결을 만드는 것처럼 동작할 수 있는 기능이 제안되어 왔음
-
폴링
- 클라이언트가 주기적으로 서버에게 새 메시지가 있는지 물어보는 방법
- 폴링을 자주 할수록 폴링 비용이 증가함
- 답해줄 메시지가 없는 경우 서버 자원이 불필요하게 낭비됨
-
롱 폴링
- 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지
- 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내어 모든 절차를 다시 시작
- 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수 있음: HTTP 서버들은 보통 무상태 서버로 로드밸런싱을 위해 라운드로빈 알고리즘을 사용하는 경우 메시지를 받은 서버는 해당 메시지를 수신할 클라이언트와의 롱 폴링 연결을 가지고 있지 않을 서버일 수 있음
- 서버 입장에서 클라이언트가 연결을 해제했는지 아닌지 알 수 있는 방법이 없음
-
웹 소켓
-
서버가 클라이언트에게 비동기 메시지를 보낼 때 가장 널리 사용하는 기술
-
웹소켓 연결은 클라이언트가 시작하며, 한번 맺어진 연결은 항구적이며 양방향임.
- 처음에는 HTTP 연결이지만, 특정 핸드셰이크 절차를 거쳐 웹소켓 연결로 업그레이드됨
- 항구적인 연결이 만들어지고 나면 서버는 클라이언트에게 비동기적으로 메시지를 전송할 수 있음.
- 80이나 443처럼 HTTP/HTTPS 프로토콜의 기본 포트번호를 쓰기 때문에 방화벽이 있는 환경에서도 잘 동작함
-
웹소켓은 양방향 메시지 전송까지 가능하게 하므로, 굳이 HTTP를 고집할 이유는 없음
- 웹소켓을 사용하면 메시지를 보낼 때나 받을 때나 동일한 프로토콜을 사용할 수 있어 설계와 구현이 단순하며 직관적
- 웹소켓 연결은 항구적으로 유지되어야 하기 때문에 서버 측에서 연결 관리를 효율적으로 해야 함
-
-
- 클라이언트와 서버 사이의 주 통신 프로토콜로 웹 소켓을 사용
- 대부분의 기능(회원가입, 로그인, 사용자 프로파일 등)은 일반적인 HTTP 상에서 구현해도 됨
무상태 서비스
- 로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스. 많은 웹사이트와 앱이 보편적으로 제공하는 기능.
- 무상태 서비스는 로드밸런서 뒤에 위치하며, 로드밸런서는 요청을 그 경로에 맞는 서비스로 정확하게 전달.
- 로드밸런서 뒤에 오는 서비스는 모놀리틱/마이크로서비스 일 수 있음.
- 서비스 탐색 서비스는 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할을 함
상태 유지 서비스
- 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하기 때문에 상태 유지가 필요함
- 클라이언트는 서버가 살아 있는 한 다른 서버로 연결을 변경하지 않음
- 서비스 탐색 서비스가 채팅 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 함
제 3자 서비스 연동
- 새 메시지를 받았다면 앱이 실행중이지 않더라도 알림을 받아야 하기 때문에 채팅 앱에서 가장 중요함
- 3장의 알림 시스템 설계를 참고
규모 확장성
- 대량 트래픽을 처리해야 하는 경우에도 이론적으로는 모든 사용자 연결을 클라우드 서버 한 대로 처리할 수 있음
- 서버 한 대로 얼마나 많은 접속을 동시에 하용할 수 있을까?
- 동시 접속사가 1M인 경우, 접속당 10K의 서버 메모리가 필요하다고 본다면 10GB의 메모리만 있으면 모든 연결을 다 처리할 수 있음
- 하지만 서버 한 대에 담은 설계안을 내밀면 면접에서 좋은 점수를 따기는 어려울 것. SPOF가 그 이유 중 하나
총정리
- 실시간으로 주고받기 위해 클라이언트는 채팅 서버와 웹소켓 연결을 끊지 않고 유지
- 채팅 서버는 클라이언트 사이에 메시지를 중계하는 역할을 담당
- 접속상태 서버는 사용자의 접속 여부를 관리
- API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리
- 알림 서버는 푸시 알림을 보냄
- 키-값 저장소는 채팅 이력을 보관. 시스템에 접속한 사용자는 이전 채팅 이력을 전부 볼 수 있음.
저장소
- 관계형 데이터베이스와 NoSQL 중 선택하기 위해서는 데이터의 유형과 읽기/쓰기 연산의 패턴이 중요함
- 채팅 시스템이 다루는 데이터는 보통 두 가지
- 사용자 프로파일, 설정, 친구 목록처럼 일반적인 데이터: 관계형 데이터베이스에 보관
- 채팅 시스템에 고유한 데이터로, 채팅 이력. 이 데이터를 어떻게 보관할지 결정하려면 읽기/쓰기 연산 패턴을 이해해야 함
- 채팅 이력 데이터의 양은 엄청남. 페이스북 메신저나 왓츠 앱은 매일 600억 개의 메시지를 처리
- 빈번하게 사용되는 데이터는 최근에 주고받은 메시지로 대부분의 사용자는 오래된 메시지는 들여다보지 않음
- 검색 기능, 특정 사용자가 언급, 특정 메시지로 점프 하여 무작위적인 데이터 접근을 지원해야 함
- 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1 정도
- 따라서 키-값 저장소를 추천
- 수평적 규모확장이 쉬움
- 데이터 접근 지연시간이 낮음
- 관계형 데이터베이스는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있음. 인덱스가 커지면 데이터에 대한 무작위적 접근을 처리하는 비용이 늘어남
- 많은 안정적인 채팅 시스템이 키-값 저장소를 채택
- 페이스북은 Hbase, 디스코드는 Cassandra 이용
1:1 채팅을 위한 메시지 테이블
- 기본키는 message_id로 메시지 순서를 쉽게 정할 수 있는 역할도 담당
- created_at을 사용하여 메시지 순서를 정할 수는 없음, 서로 다른 두 메시지가 동시에 만들어질 수 도 있기 때문
그룹 채팅을 위한 메시지 테이블
- (channel_id, message_id)의 복합키(composite key)를 기본 키로 사용
- channel은 채팅 그룹과 같은 뜻
- channel_id는 파티션 키(partition key)로도 사용할 것. 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 할 것이기 때문
메시지 ID
- message_id는 메시지들의 순서도 표현할 수 있어야 함
- message_id의 값은 고유해야 함
- ID 값은 정렬 가능해야 하며 시간 순서와 일치해야 함. 즉, 새로운 ID는 이전 ID보다 큰 값이어야 함
- 위의 조건은 RDBMS라면 auto_increment가 대안이 될 수 있겠지만 NoSQL은 보통 해당 기능을 제공하지 않음
- 스노플레이크같은 전역적 64-bit 순서 번호 생성기를 이용
- 지역적 순서 번호 생성기를 이용
- 지역적이라 함은, ID의 유일성 같은 그룹 안에서만 보증하면 충분함
- 이 방법이 통하는 이유는 메시지 사이의 순서는 같은 채널, 같은 1:1 채팅 세션 안에서만 유지되면 충분하기 떄문
- 전역적 ID 생성기에 비해 구현하기 쉬운 접근법
-
클라이언트에게 가장 적합한 채팅 서버를 추천하는 것이 주된 역할
-
이때 사용되는 기준으로는 클라이언트의 위치, 서버의 용량 등이 있음
-
서비스 탐색 기능을 구현하는 데 널리 쓰이는 오픈 소스 솔루션으로는 아파치 주키퍼가 있음
-
사용가능한 모든 채팅 서버를 여기 등록시켜 두고 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라주면 됨
-
주키퍼로 구현한 서비스 탐색 기능의 동작 방식
- 사용자 A가 시스템에 로그인을 시도
- 로드밸런서가 로그인 요청을 API 서버들 가운데 하나로 보냄
- API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능이 동작하여 해당 사용자를 서비스할 최적의 채팅 서버를 찾음. 여기서는 채팅 서버 2가 선택되어 사용자 A에게 반환됨
- 사용자 A는 채팅 서버 2와 웹소켓 연결을 맺음
1:1 채팅 메시지 처리 흐름
- 사용자 A가 채팅 서버 1로 메시지 전송
- 채팅 서버 1은 ID 생성기를 사용해 해당 메시지의 ID 결정
- 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
- 메시지가 키-값 저장소에 보관됨
- (a) 사용자 B가 접속 중인 경우 메시지는 사용자 B가 접속 중인 채팅 서버로 전송됨 (b) 사용자 B가 접속 중이 아닌 경우 푸시 알림 메시지를 푸시 알림 서버로 보냄
- 채팅 서버 2는 메시지를 사용자 B에게 전송. 사용자 B와 채팅 서버 2 사이에는 웹소켓 연결이 있는 상태이므로 그것을 사용
여러 단말 사이의 메시지 동기화
- 사용자 A는 전화기와 랩톱의 두 대 단말을 이용하고 있음
- 사용자 A가 전화기에서 채팅 앱에 로그인한 결과로 채팅 서버 1과 해당 단말 사이에 웹소켓 연결이 만들어져 있고, 랩톱에서 로그인한 결과로 역시 별도의 웹소켓이 채팅 서버 1에 연결되어 있음
- 각 단말은 cur_max_message_id라는 변수를 유지하는데, 해당 단말에서 관측된 가장 최신 메시지의 ID를 추적하는 용도
- 아래 두 조건을 만족하는 메시지는 새 메시지로 간주
- 수신자 ID가 현재 로그인한 사용자 ID와 같다
- 키-값 저장소에 보관된 메시지로서, 그 ID가 cur_max_message_id보다 크다
- cur_max_message_id는 단말마다 별도로 유지 관리하면 되는 값으로, 키-값 저장소에서 새 메시지를 가져오는 동기화 작업도 쉽게 구현 가능
소규모 그룹 채팅에서의 메시지 흐름
- 사용자 A가 그룹 채팅방에서 메시지를 보냈을 때 어떤 일이 벌어지는지 보여줌
- 해당 그룹에 3명의 사용자가 있다고 했을 때 사용자 A가 보낸 메시지가 사용자 B와 C의 메시지 동기화 큐에 복사됨
- 이 설계안은 소규모 그룹 채팅에 적합함
- 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되므로 메시지 동기화 플로가 단순
- 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않음.
- 많은 사용자를 지원해야 하는 경우라면 똑같은 메시지를 모든 사용자의 큐에 복사하는게 바람직하지 않음
- 한 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야 함.
- 각 사용자의 수신함인 메시지 동기화 큐는 여러 사용자로부터 오는 메시지를 받을 수 있어야 함.
- 접속상태 서버를 통해 사용자의 상태를 관리
- 접속상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부
사용자 로그인
- 클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버는 A의 상태와 last_active_at 타임스탬프 값을 키-값 저장소에 보관
- 이 절차가 끝나고 나면 해당 사용자는 접속 중인 것으로 표시됨
로그아웃
- 키-값 저장소에 보관된 사용자 상태가 online에서 offline으로 바뀜
- 이 절차가 끝나고 나면 해당 사용자는 접속 중이 아닌 것으로 표시됨
접속 장애
-
인터넷 연결은 항상 안정적이지 않기 때문에 대응할 수 있는 설계를 준비해야 함
-
사용자의 인터넷 연결이 끊어지면 클라이언트와 서버 사이에 맺어진 웹소켓같은 지속성 연결도 끊어짐
-
간단한 장애 대응 방법으로는 사용자를 오프라인 상태로 표시하고 연결이 복구되면 온라인 상태로 변경하는 것
- 짧은 시간 동안 인터넷 연결이 끊어졌다 복구되는 일이 매우 흔하기 때문에 자주 접속 상태를 변경한다면 사용자 경험 측면에서 바람직하지 않음
-
여기서는 박동 검사를 통해 문제를 해결
- 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 함
- 마지막 이벤트를 맏은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지.
- 그렇지 않은 경우에는 오프라인으로 변경
- 그림에서는 박동 이벤트를 5초마다 서버로 3번 보낸 뒤 30초동안 메시지를 보내지 않아 오프라인 상태로 변경됨
상태 정보의 전송
- 사용자 A와 친구 관계에 있는 사용자들은 해당 사용자의 상태 변화를 알기 위해서 상태 정보 서버는 발행 구독 모델을 사용
- 각각의 친구관계마다 채널을 하나씩 두는 것
- 사용자 A의 접속상태가 변경되었을 때 그 사실을 세 개 채널 A-B, A-C, A-D에 쓰는 것
- A-B는 B가 구독, A-C는 C가, A-D는 D가 구독
- 이렇게 하면 친구 관계에 있는 사용자가 상태 정보 변화를 쉽게 통지 받을 수 있게 됨
- 클라이언트와 서버 사이의 통신에는 실시간 웹소켓을 사용
- 이 방안은 그룹 크기가 작을 때는 효과적이나, 그룹 크기가 더 커지면 비용이나 시간이 많이 들게 됨
- 그룹 하나의 100,000 사용자가 있는 경우 상태 변화 1건 당 100,000개의 이벤트 메시지가 발생함
- 성능 문제를 해결하기 위한 방안은 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속 상태를 갱신하고 싶으면 수동으로 갱신하도록 유도
- 클라이언트와 서버 사이의 실시간 통신을 가능하도록 하기 위해 웹소켓을 사용
- 실시간 메시징을 지원하는 채팅 서버, 접속 상태 서버, 푸시 알림 서버, 채팅 이력을 보관할 키-값 저장소, 이를 제외한 나머지 기능을 구현하는 데 쓰일 API 서버가 주요 컴포넌트
- 면접 말미에 논의하면 좋을 내용
- 채팅 앱을 확장하여 사진이나 비디오 등의 미디어를 지원하도록 하는 방법: 미디어 파일은 텍스트에 비해 크기가 크므로 압축 방식, 클라우드 저장소, 썸네일 생성 등
- 종단 간 암호화: 메시지 발신인과 수신자 이외에는 아무도 메시지를 볼 수 없도록 적용
- 캐시: 클라이언트에 이미 읽은 메시지를 캐시해 두면 서버와 주고받는 데이터 양을 줄일 수 있음
- 로딩 속도 개선: 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축하여 앱 로딩 속도를 개선
- 오류 처리
- 채팅 서버 오류: 채팅 서버 하나에 수십만 사용자가 접속해 있는 상황에서 하나의 서버가 죽으면 서비스 탐색 기능이 동작하여 클라이언트에게 새로운 서버를 배정하고 다시 접속할 수 있도록 함
- 메시지 재전송: 재시도나 큐는 메시지의 안정적 전송을 보장하기 위해 흔히 사용되는 기법