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

✅ 문제 이해 및 설계 범위 확정

어떤 채팅앱을 설계하는지 확실히 해두는 것이 중요하다.

• 1:1 채팅에 집중하는 앱
• 그룹 채팅에 중점을 둔 업무용 앱
• 대규모 그룹의 소통과 응답지연이 낮은 음성 채팅에 집중하는 앱

 

📖 요구사항

1. 1:1 채팅과 그룹 채팅 둘 다 지원
2. 모바일 앱, 웹 앱 모두 지원
3. 일별 능동 사용자 수 DAU: 5천만명
4. 그룹 채팅 인원 제한: 최대 100명
5. 1:1 채팅, 그룹 채팅, 사용자 접속상태 표시 지원
6. 텍스트 메시지만 주고받을 수 있음
7. 메시지 길이는 100,000자 이하
8. 채팅 이력은 영구적으로 보관

 

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

채팅 시스템의 경우 클라이언트는 모바일 앱이거나 웹 애플리케이션이다.

클라이언트는 서로 직접 통신하지 않는다.

 

채팅 서비스는 다음 기능을 제공해야 한다.

• 클라이언트들로부터 메시지 수신
• 메시지 수신자 결정 및 전달
• 수신자가 접속 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관

 

 

HTTP는 웹에서 가장 널리 사용되는 프로토콜이지만 HTTP는 클라이언트가 연결을 만드는 프로토콜이며 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데 쉽게 사용할 수 없다.

• 서버가 연결을 만드는 것처럼 동작하기 위한 기법이 제안되는데 폴링, 롱 폴링, 웹 소켓 등이 그런 기술이다.

 

폴링

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

 

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

 

롱 폴링

폴링을 개선한 방법으로 클라이언트가 주기적으로 서버와 통신할 때 새 메시지가 반환되거나 타임아웃 될때까지 연결을 유지하는 방식이다.

 

클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내 모든 과정을 다시 시작한다.

 

 

⚠️ 문제

1. 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하지 않을 수 있다.

• HTTP 서버는 stateless 서버임으로 로드밸런싱을 위해 라운드로빈 알고리즘을 사용하면 메시지를 받은 서버는 해당 메시지를 수신할 클라이언트와 롱 폴링 연결을 가지고 있지 않을 수 있다.

 

2. 서버 입장에서 클라이언트가 연결을 해제했는지 아닌지 알 수 없다.

3. 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때 마다 주기적으로 서버에 다시 접속한다.

 

웹 소켓

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

 

 

 

웹 소켓 연결은 클라이언트가 시작하고 한번 맺어진 연결은 항구적이며 양방향이다.

처음에는 HTTP 연결이지만 핸드셰이크 절차를 거친 후 웹소켓 연결로 업그레이드된다.

 

웹 소켓을 이용하면 메시지를 보낼 때나 받을 때 동일한 프로토콜을 사용할 수 있다.

• 설계, 구현이 단순하고 직관적

 

🧑‍💻 주의

 

웹 소켓연결은 항구적으로 유지되어야 하기 때문에 서버 측에서 연결 관리를 효율적으로 해야 한다.

 

개략적 설계

클라이언트와 서버 사이의 주 통신 프로토콜로 웹 소켓을 사용

 

 

채팅 시스템은 3부분으로 나누어서 볼 수 있다.

• 무상태 서비스
• 상태유지 서비스
• 제 3자 서비스

 

1️⃣ 무상태 서비스

로그인, 회원가입 등 전통적인 요청-응답 서비스

서비스 탐색 서비스(Service discovery)

• 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할

 

2️⃣ 상태 유지 서비스

상태 유지가 필요한 서비스는 채팅 서비스

• 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하기 때문

 

3️⃣ 제 3자 서비스 연동

• 새 메시지를 받았다면 앱이 실행되지 않더라도 알림을 받아야 한다.

 

규모 확장성

채팅 시스템은 대규모 트래픽을 처리해야 하는 경우에도 한 대의 서버로 처리를 할 수 있지만 SPOF를 방지하기 위해서는 확장하는 것이 좋다.

• 이때도 클라이언트가 채팅 서버와 웹 소켓 연결을 끊지 않고 유지해야하는 것을 유의해야 한다.

 

 

채팅 서버	클라이언트 사이에 메시지 중계 역할
접속상태 서버	사용자의 접속 여부 관리
API 서버	로그인, 회원가입 등 처리
알림 서버	푸시 알림
키-값 저장소	채팅 이력 보관

 

 

저장소

채팅 시스템이 다루는 데이터는 2가지이다.

• 일반적인 데이터(사용자 프로파일, 설정 등) → 안정성을 보장하는 RDB에 보관
• 채팅 이력

 

💽 채팅 이력 데이터의 읽기 쓰기 연산 패턴

• 채팅 이력의 데이터는 매우 많다
• 빈번하게 사용되는 것은 최근에 주고받은 메시지

 

사용자는 최근에 주고받은 메시지 데이터만 보게되는 것이 맞지만 검색 기능을 이용하거나 특정 사용자가 언급된 메시지를 보거나 특정 메시지로 점프하거나 하여 무작위적인 데이터 접근을 하게 되는 일도 있다.

• 데이터 계층에서는 이런 기능도 지원해줘야 한다.

 

💡 키-값 저장소

• 수평적 규모확장이 쉽다.
• 데이터 접근 지연시간이 낮다 (latency)
• RDB는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리리하지 못한다.
  • 인덱스가 커지면 데이터에 대한 무작위적 접근을 처리하는 비용이 늘어난다.

 

이미 많은 채팅 시스템이 키-값 저장소를 채택

• 페이스북 메신저: HBase
• 디스코드: 카산드라

 

📖 long tail

• 데이터 분포 그래프를 그렸을 때 발생 빈도가 높은 데이터는 소수(Head)에 집중되고 나머지는 낮은 빈도로 완만하게 긴 꼬리(Tail)를 형성하는 형태

 

🧑‍💻 상세 설계

서비스 탐색

서비스 탐색 기능은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것이다.

• 아파치 주키퍼 같은 오픈소스 솔루션을 사용

 

사용 가능한 모든 채팅서버를 등록시켜두고 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라준다.

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

 

메시지 흐름

1️⃣ 1:1 채팅 메시지 흐름

1. 사용자 A가 채팅 서버로 메시지 전송
2. 채팅 서버는 ID 생성기를 사용해 해당 메시지의 ID 결정
3. 채팅 서버는 해당 메시지를 메시지 동기화 큐로 전송
4. 메시지가 키-값 저장소에 보관
5. 사용자 B가 온라인일 경우 사용자 B가 접속 중인 채팅 서버로 전송
6. 사용자 B가 오프라인일 경우 사용자 B에게 푸시 알림 전송
7. 채팅 서버는 사용자 B에게 메시지 전송

 

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

각 단말은 cur_max_message_id 라는 변수를 유지하는데 해당 단말에서 관측된 가장 최신 메시지의 ID를 추적하는 용도이다.

다음 두 조건을 만족하는 메시지는 새 메시지로 간주한다.

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

 

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

사용자 A가 그룹 채팅방에서 메시지를 보냈을 때 어떤 일이 벌어질지 보여준다.

사용자 A가 보낸 메시지가 사용자 B와 C의 메시지 동기화 큐에 복사된다.

• 새로운 메시지가 왔는지 확인하기 위해서 자기 큐만 바라보면 된다.
• 그룹이 크지 않다면 메시지를 수신자별로 복사하여 큐에 넣는 작업의 비용이 문제가 되지 않는다.

 

접속 상태 표시

사용자의 접속 상태를 표시하는 것은 채팅 서비스의 핵심적 기능이다.

• 접속상태 서버는 클라이언트와 웹 소켓으로 통신하는 실시간 서비스의 일부이다.

 

📌 사용자 로그인

클라이언트와 실시간 서비스 사이에 웹 소켓 연결이 맺어지고 나면 접속상태 서버는 사용자의 상태와 last_active_at 타임스탬프 값을 키-값 저장소에 보관한다.

• 해당 사용자는 접속중인 것으로 표시될 것이다.

 

📌 로그아웃

키-값 저장소에 보관된 사용자의 상태가 online에서 offline으로 바뀌게 된다.

 

 

⚠️ 접속 장애

인터넷 연결이 항상 안정적이지 않기 때문에 그런 상황에 대응할 수 있는 설계를 준비해야 한다.

간단한 방법은 사용자를 오프라인 상태로 표시하고 연결이 복구되면 온라인 상태로 변경하는 것이다.

• 짧은 시간 동안 인터넷 연결이 끊어졌다 복구되는 일에는 바람직하지 않다

 

해당 문제는 heartbeat 검사를 통해 이 문제를 해결한다.

온라인 상태의 클라이언트가 주기적으로 heartbeat event를 접속상태 서버로 보내도록 하고 마지막 이벤트를 받은 지 x초 이내에 또 다른 이벤트 메시지를 받으면 사용자의 접속상태를 온라인으로 유지

 

상태 정보의 전송

사용자 A와 친구 관계에 있는 사용자들은 어떻게 해당 사용자의 상태 변화를 알게 될까?

 

 

상태정보 서버는 pub-sub 모델을 사용해 각각의 친구관계마다 채널을 하나씩 둔다.

A의 접속상태가 변경되었다고 하면 A-B, A-C, A-D 채널에 그 사실을 쓰는 것이다.

• 이렇게 하면 친구관계에 있는 사용자가 상태정보 변화를 쉽게 통지받을 수 있다.

 

⚠️ 그룹이 커지면 이런 식으로 접속상태 변화를 알리게되면 비용이나 시간이 많이 들게 된다.

 

💡 방법

• 사용자가 그룹 채팅에 입장하는 순간에만 상태정보를 읽어가게 하거나 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶다면 수동으로 처리하도록 유도하는 방식

 

📚 Ref.

https://product.kyobobook.co.kr/detail/S000001033116