[System Design Interview] 12장 채팅 시스템 설계

채팅 시스템은 하나쯤 사용하지 않는 사람이 드물다.

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

어떤 종류의 채팅 앱을 설계하려는지 확실히 해 두는 것이 면접에서 가장 중요함

요구사항

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

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

클라이언트와 서버의 통신 방법에 대한 기본적 지식이 있어야 함

• 메시지 전송 (클라이언트 → 서버): keep-alive 헤더를 사용한 HTTP 프로토콜이 꽤 괜찮음
• 메시지 수신 (서버 → 클라이언트): HTTP 프로토콜은 클라이언트가 연결을 만드는 프로토콜이기 때문에, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데는 쉽게 쓰일 수 없음 ⇒ 서버가 연결을 만드는 것처럼 동작할 수 있도록 하는 기법(폴링, 롱 폴링, 웹소켓)을 사용해야 함

폴링 (poling)

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

폴링을 자주 하면 비용이 올라가고, 답해줄 메시지가 없는 경우 서버 자원이 불필요하게 낭비됨

롱 폴링(long polling)

기존 폴링의 비효율성을 개선하기 위해 나온 기법

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

단점

• 무상태 서버인 경우, 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수도 있음
• 서버 입장에서는 클라이언트가 연결을 해제했는지 알 수 없음
• 여전히 비효율적 (메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속함)

웹소켓(WebSocket)

서버가 클라이언트에게 비동기(async) 메시지를 보낼 때 가장 널리 사용하는 기술

연결 과정

1. 클라이언트가 HTTP 기반의 특정 핸드셰이크를 통해 서버에 연결을 맺는다
2. 연결이 맺어지면 웹소켓 연결로 업그레이드되어 항구적이며 양방향인 연결이 맺어짐
3. 이후 서버는 클라이언트에게 비동기적으로 메시지를 전송할 수 있다

유의점

• 방화벽이 있는 환경에서도 잘 동작함 (HTTP, HTTPS가 사용하는 기본 포트번호를 씀)
• 웹소켓 연결은 항구적으로 유지되어야 하기 때문에, 서버 측에서 연결 관리를 효율적으로 해야 함

개략적 설계안

무상태 서비스

HTTP 기반으로 로그인, 회원가입, 프로필 표시 등을 처리하는 전통적인 요청/응답 서비스, 앞단의 로드밸런서가 요청에 맞는 서비스로 요청을 라우팅해줌

서비스 탐색(service discovery) 서비스: 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할 수행

상태 유지 서비스

웹소켓 기반으로 클라이언트가 채팅 서버와 지속적인 네트워크 유지를 하는 서비스

제3자 서비스 연동

푸시 알림 등의 연동으로 앱이 실행 중이 아니여도 알림을 받을 수 있도록 연동

규모 확장성

접속당 10k의 메모리가 든다고 가정하면 동시 접속자 수가 1M이라고 할 때 서버 한 대로, 10GB의 메모리만 있으면 충분하지만, SPOF의 이유 등으로 단일 서버를 구성하는 것은 좋지 않음

개략적 설계안

구성 컴포넌트

• 채팅 서버: 클라이언트 사이에 메시지를 중계하는 역할
• 접속 상태 서버(presence server): 사용자의 접속 여부를 관리
• API 서버: 로그인, 회원가입, 프로필 관리 등을 처리
• 알림 서버: 푸시 알림을 보냄
• 키-값 저장소(key-value store): 채팅 이력(chat history)를 보관 (이전 채팅 이력을 볼 수 있도록)

저장소

어떤 데이터베이스를 쓸 것인가? → 데이터의 유형과 읽기/쓰기 연산의 패턴에 따라 선택

채팅 시스템의 데이터 유형

1. 사용자 프로필, 친구 목록 등의 일반적인 데이터: 안정성을 보장하기 위해 관계형 데이터베이스에 보관 (다중화 및 샤딩 등으로 가용성과 규모확장성 보증)
2. 채팅 이력: 특징은 다음과 같음

키-값 저장소를 사용하는 이유

• 수평적 규모확장이 쉬움
• 데이터 접근 지연시간이 낮음
• 관계형 데이터베이스 데이터 가운데 롱 테일(long tail)에 해당하는 부분을 잘 처리하지 못하고, 인덱싱의 비용이 큼
• 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 채택중 (페이북은 HBase, 디스코드는 Cassandra 사용 중)

데이터 모델

1:1 채팅을 위한 메시지 테이블: message_id를 기본 키로 하는 테이블로 구성

그룹 채팅을 위한 메시지 테이블: (channel_id, message_id)의 복합 키를 기본 키로 하는 테이블로 구성

메시지 ID

message_id의 값은 고유해야 하고, 정렬 가능해야 하며, 시간 순서와 일치해야 함

솔루션 목록

1. Snowflake 같은 전역적 64-bit 순서 번호 생성기 이용
2. 지역적 순서 번호 생성기 이용 (지역성: ID의 유일성은 같은 그룹 안에서만 보증하면 됨)

3단계 상세 설계

서비스 탐색

클라이언트에게 가장 적합한 채팅 서버를 추천

기준으로는 클라이언트의 위치(geographical location), 서버의 용량 등이 있음

서비스 탐색 기능을 구현하기 위해 사용하는 오픈 소스 솔루션으로 Apache ZooKeeper가 있음

동작 흐름

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

메시지 흐름

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

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

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

두 단말 모두 웹소켓 통신으로 채팅 서버와 연결되어 있음

각 단말은 cur_max_message_id라는 변수를 유지함 (가장 최신 메시지의 ID)

아래 조건을 만족하는 메시지는 새 메시지로 간주함

• 수신자 ID가 현재 로그인한 사용자 ID와 같다
• 키-값 저장소에 보관된 메시지로서, 그 ID가 cur_max_message_id보다 크다

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

사용자가 보낸 메시지는 해당 그룹 채팅 방의 각각의 사용자들의 메시지 동기화 큐(message sync queue, 메시지 수신함)에 복사됨, 이 방식은 소규모 그룹 채팅에 적합함

• 새로운 메시지가 왔는지 확인하려면 자신의 큐만 보면 됨
• 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 작음

수신자 관점에서 본대면 여러 사용자로부터 오는 메시지를 수신할 수 있어야 함 → 메시지 동기화 큐는 여러 사용자로부터 오는 메시지를 받을 수 있어야 함

접속상태 표시

사용자 로그인

클라이언트와 실시간 서비스(real-time service0 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버가 클라이언트의 status와 last_active_at 등의 값을 키-값 저장소에 보관

사용자 로그아웃

로그인과 같은 절차를 거친다

접속 장애

짧은 시간 동안 인터넷 연결이 끊어졌다 복구되는 상황에서 사용자의 접속 상태를 변경하는 작업은 서버 입장에서도 지나치고, 사용자 경험 측면에서도 바람직하지 못함

⇒ 박동(heartbeat) 검사를 통해 이 문제를 해결할 수 있음

클라이언트가 지속적으로 박동 이벤트(heartbeat event)를 접속상태 서버로 보내면 온라인, 마지막 이벤트를 받은 지 x초 이내에 박동 이벤트가 오지 않는다면 오프라인으로 변경

상태 정보의 전송

상태 정보를 사용자의 친구에게 전송해주기 위해서, 발행-구독 모델(publish-subscribe model) 사용

1. 사용자의 친구들은 각각 채널에 구독
2. 사용자의 접속상태가 변경될 경우 해당 이벤트를 채널에 발행
3. 각 사용자 친구들은 각자의 채널에서 해당 이벤트 수신

소규모 그룹에서는 효과적이지만, 대규모 그룹에서는 비효율적 (그룹의 모든 인원에게 이벤트 메시지를 발행해야 하기 때문)

4단계 마무리

논의한 내용

• 클라이언트와 서버 사이의 실시간 통신을 가능하도록 하기 위한 웹소켓
• 실시간 메시징을 지원하는 채팅 서버
• 접속 상태 서버, 푸시 알림 서버
• 채팅 이력을 보관할 키-값 저장소
• 나머지 기능을 구현한 API 서버

추가로 논의하면 좋을 것들

• 채팅 앱을 확장하여 사진이나 비디오 등의 미디어를 지원하도록 하는 방법: 미디어 파일은 텍스트에 비해 크기가 크기 때문에, 압축/클라우드 저장/썸네일 생성 등을 수행해야 함
• 종단 간 암호화: 메시지 발신인과 수신자 이외에는 아무도 메시지 내용을 볼 수 없음
• 캐시: 클라이언트에 이미 읽은 메시지를 캐시해 두면 서버와 주고받는 데이터 양을 줄일 수 있음
• 로딩 속도 개선: Slack은 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축해서 앱 로딩 속도를 개선하였음
• 오류 처리

 

Reference: http://www.yes24.com/Product/Goods/102819435

가상 면접 사례로 배우는 대규모 시스템 설계 기초 - YES24