1단계 문제 이해 및 설계 범위 확정
- 응답지연이 낮은 일대일 채팅 기능
- 최대 100명까지 참여할 수 있는 그룹 채팅 기능
- 사용자의 접속상태 표시 기능
- 다양한 단말 지원, 하나의 계정으로 여러 단말 동시 접속 지원
- 푸시 알림
- 5천만 DAU 처리 가능
2단계 개략적 설계안 제시 및 동의 구하기
채팅 시스템의 경우 -> 클라이언트는 모바일 앱, 웹 애플리케이션
클라이언트는 서로 직접 통신 X
각 클라이언트는 모든 기능을 지원하는 채팅 서비스와 통신함
기본 제공 기능
- 클라이언트들로부터 메시지 수신
- 메시지 수신자 결정 및 전달
- 수신자가 접속 상태가 아닌 경우 접속할 때까지 해당 메시지 보관
메시지 송신(Sender -> Server)
메시지 보내는 역할은 송신 클라이언트(Sender)가 담당하며, 이 경우 오랜 세월 검증된 HTTP 프로토콜이 메시지 전송 용도로 괜찮은 선택
- 프로토콜: HTTP
- 작동 방식: 송신 클라이언트가 채팅 서비스 서버에 HTTP 요청을 보내 메시지를 전달하고, 서버는 해당 메시지를 수신자에게 전달하도록 알림
- 효율성 극대화: HTTP 요청 시
keep-alive헤더를 사용하면 효율적keep-alive는 클라이언트와 서버 사이의 TCP 연결을 끊지 않고 계속 유지시켜 줌
- 이를 통해 TCP 연결 과정에서 발생하는 핸드셰이크 횟수를 줄여 네트워크 오버헤드를 감소시킬 수 있음
메시지 수신(Server -> Receiver)
HTTP는 기본적으로 클라이언트가 연결을 시작하고 요청을 보내는 프로토콜이기 때문에, 서버가 클라이언트에게 임의의 시점에 비동기적으로 메시지를 보낼 땐 사용하기 애매함
서버가 클라이언트에게 능동적으로 메시지를 보내는 것처럼 동작할 수 있도록 하기 위해, 시스템 설계에서 여러 기법이 제안됨
| 기술 | 특징 | 사용 시나리오 |
|---|---|---|
| 폴링 (Polling) | 클라이언트가 주기적으로 서버에 새 메시지가 있는지 요청하는 방식 | 새 메시지 확인 주기가 길면 지연이 발생하고, 짧으면 서버 부하가 커짐 |
| 롱 폴링 (Long Polling) | 클라이언트가 서버에 요청을 보내면, 서버는 새 메시지가 도착할 때까지 연결을 유지했다가 메시지 도착 시 응답하고 연결을 끊는 방식 | 일반 폴링보다 지연이 적고 효율적이지만, 여전히 연결 생성/종료 오버헤드가 있음 |
| 웹소켓 (WebSocket),클라이언트와 서버 사이에 영구적인 양방향 통신 채널을 구축하는 프로토콜 | 실시간성이 가장 높고 효율적이지만, 서버/클라이언트 측에서 특별한 구현이 필요함 |
개략적 설계안
- 클라이언트-서버 사이 주 통신 프로토콜: 웹소켓 사용
- 대부분의 기능: HTTP로 구현
무상태 서비스
로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스로, 무상태 서비스가 제공하는 기능은 많은 웹사이트와 앱이 보편적으로 제공하는 기능
- 무상태 서비스는 로드밸런서 뒤에 위치
- 로드밸런서는 요청을 그 경로에 맞는 서비스로 정확하게 전달하는 기능 수행
- 로드밸런서 뒤에 오는 서비스는 모놀리틱 서비스도, 마이크로서비스도 가능
- 자세하게 살펴볼 것 => 서비스 탐색
- 서비스 탐색: 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할
상태 유지 서비스
- 본 설계안에서 유일하게 상태 유지가 필요한 서비스는 채팅 서비스
- 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하기 때문
- 클라이언트는 보통 서버가 살아 있는 한 다른 서버로 연결을 변경하지 않음
- 서비스 탐색 서비스는 채팅 서비스와 긴밀히 협력하여 특정 서버에 부하가 몰리지 않도록 함
제3자 서비스 연동
- 채팅 앱에서 가장 중요한 제3자 서비스는 푸시 알림
- 새 메시지를 받았으면 설사 앱이 실행 중이지 않아도 알림을 받아야 하기 때문
- 따라서 푸시 알림 서비스와 통합은 아주 중요하며, 3장 알림 시스템 설계를 참고하자
규모 확장성
따져봐야 할 부분: 서버 한 대로 얼마나 많은 접속을 동시에 허용할 수 있는가?
=> 서버 한 대만 갖는 설계안에서 출발하여 점차로 다듬어 나가는 것은 ㄱㅊ
해당 그림에선 실시간으로 메시지를 주고받기 위해 클라이언트는 채팅 서버와 웹소켓 연결을 끊지 않고 유지한다는 점 유의
- 채팅 서버는 클라이언트 사이에 메시지 중계 역할 담당
- 접속상태 서버는 사용자의 접속 여부 관리
- API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부 처리
- 알림 서버는 푸시 알림을 보냄
- 키-값 저장소에는 채팅 이력 보관 -> 시스템에 접속한 사용자는 이전 채팅 이력을 전부 보게 될 것
저장소
- 서버, 제3자 서비스 연동을 했으므로 다음으로 챙길 것은 데이터 계층
- 데이터 계층을 올바르게 만드는 일에는 노력이 필요함 => 어떤 데이터베이스를 쓰느냐?
=> RDBMS VS NoSQL에서 따질 것은 데이터의 유형과 읽기/쓰기 연산 패턴임
채팅 시스템이 다루는 데이터는 보통 2가지
1. 사용자 프로파일, 설정, 친구 목록처럼 일반적인 데이터
- 이런 데이터는 안정성을 보장하는 관계형 데이터베이스에 보관
- 다중화, 샤딩은 이런 데이터의 가용성과 규모확장성을 보증하기 위해 보편적으로 사용되는 기술
- 채팅 시스템의 고유한 데이터로 채팅 이력 => 어떻게 보관할지 결정하려면 읽기/쓰기 연산 패턴 이해 필요
- 채팅 이력 데이터 양은 엄청 많음, 페북 메신저나 왓츠앱은 매일 600억 개의 메시지 처리
- 이 데이터 가운데 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지, 대부분의 사용자는 오래된 메시지는 보지 않음
- 하지만 검색 기능을 이용하거나 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프하거나 하여 무작위적인 데이터 접근을 하게 되는 일도 있음 => 데이터 계층은 이런 기능도 지원해야 함
-1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1
본 설계안의 경우에는 키-값 저장소를 추천할 것
- 키-값 저장소는 수평적 규모확장이 쉬움
- 키-값 저장소는 데이터 접근 지연시간이 낮음
- 관계형 데이터베이스는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있음 -> 인덱스가 커지면 데이터에 대한 무작위적 접근을 처리하는 비용이 늘어남
- 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 사용하고 있음 => 페이스북 메신저는 HBase를 쓰고 디스코드는 카산드라를 이용함
데이터 모델
키-값 저장소를 데이터 계층 기술로 사용하기로 함 => 메시지 데이터를 어떻게 보관할 것인가?
1:1 채팅을 위한 메시지 테이블
- 기본 키는
message_id-> 메시지 순서를 쉽게 정할 수 있도록 하는 역할도 당당 create_at을 사용하여 메시지 순서 정할 수 없음 -> 서로 다른 메시지가 동시에 만들어질 수 있기 때문
그룹 채팅을 위한 메시지 테이블
- 기본 키는
(channel_id, message_id)의 복합 키(composite key) - 채널은 채팅 그룹과 같은 뜻
channel_id는 파티션 키(partition key)로도 사용할 것 -> 그룹 채팅에 즉용될 모든 질의는 특정 채널을 대상으로 할 것이기 때문
메시지 ID
message_id를 만드는 기법은 논의할 가치가 있는 주제임
message_id는 메시지들의 순서도 표현할 수 있어야 함- ID 값은 정렬 가능해야 하며 시간 순서와 일치해야 함 -> 새로운 ID는 이전 ID보다 큰 값이어야 함
=> 이 조건을 만족할 방법?
1. RDBMS라면 auto_increment가 대안이 될 수 있게지만, NoSQL은 보통 해당 기능 X
2. 스노플레이크 같은 전역적 64-bit 순서 번호 생성기를 이용하는 것 (7장 유일 ID 생성기 설계 참고)
3. 지역적 순서 번호 생기(local sequence number generator) 이용
- 지역적: ID의 유일성 같은 그룹 안에서만 보증하면 충분함
- 이 방법이 통하는 이유는 메시지 사이의 순서는 같은 채널 혹은 같은 1:1 채팅 세션 안에서만 유지되면 충분하기 때문
- 전역적 ID 생성기에 비해 구현하기 쉬운 접근법
3단계 상세 설계
채팅 시스템의 경우 서비스 탐색, 메시지 전달 흐름, 사용자 접속 상태를 표시하는 방법 정도 더 알아보면 좋음
서비스 탐색
- 주 역할: 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것
- 사용되는 기준: 클라이언트 위치(geographical location), 서버의 용량(capacity)
- 서비스 탐색 기능을 구현하는 데 널리 쓰이는 오픈 소스 솔루션으로는 아파치 주키퍼 같은 게 있음
=> 사용 가능한 모든 채팅 서버를 여기 등록시켜 두고, 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라 주면 됨 - 아래는 주키퍼로 구현한 서비스 탐색 기능이 어떻게 동작하는지 보여 줌
- 사용자 A가 시스템에 로그인 시도
- 로드밸런서가 로그인 요청을 API 서버들 중 가운데 하나로 보냄
- API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능이 동작하여 해당 사용자를 서비스할 최적의 채팅 서버를 찾음 -> 이 예제의 경우 채팅 서버 2가 선택되어 사용자 A에게 반환되었다고 가정
- 사용자 A는 채팅 서버 2와 웹소켓 연결을 맺음
메시지 흐름
채팅 시스템에서 종단 간 메시지 흐름을 이해하는 것은 흥미로운 주제
=> 1:1 채팅 메시지 처리 흐름과 여러 단말 간 메시지 동기화 과정을 살펴보고, 그룹 채팅 메시지의 처리 흐름도 살펴보자
1:1 채팅 메시지 처리 흐름
1:1 채팅에서 사용자 A가 B에게 보낸 메시지가 어떤 경로로 처리되는지
여러 단말 사이의 메시지 동기화
소규모 그룹 채팅에서의 메시지 흐름
접속 상태 표시
사용자 로그인
- 클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버는 A의 상태와
last_active_at타임스탬프 값을 키-값 저장소에 보관함 - 이 절차가 끝나면 해당 사용자는 접속 중인 것으로 표시될 것
로그아웃
접속 장애
인터넷을 통한 연결을 항상 안정적일 수 없기 때문에 그런 상황에 대응할 수 있는 설계를 준비해야 함
=> 사용자의 인터넷 연결이 끊어지면 클라이언트와 서버 사이에 맺어진 웹소켓 같은 지속성 연결도 끊어짐
=> 이 설계안에서는 박동 검사를 통해 이 문제를 해결할 것
온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 하고, 마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 해당 사용자의 접속 상태를 계속 온라인으로 유지하는 것, 그렇지 않을 경우에만 오프라인으로 바꾼다
상태 정보의 전송
그렇다면 사용자 A와 친구 관계에 있는 사용자들은 어떻게 해당 사용자의 상태 변화를 알게 될까?
상태 정보 서버는 발행/구독 모델을 사용하는데, 각 친구관계마다 채널을 하나 두는 것
=> 그룹 크기가 작을 땐 효과적이지만 그룹 커지면 다른 방안을 모색해야 함
=> 그룹 채팅에 입장하는 순간만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도
4단계 마무리
