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

이번 장에서는 Whatsapp, Line, Slack, Discord와 같은 채팅 시스템을 설계해 볼 것이다.

문제 이해 및 설계 범위 확정

• 채팅 방식: 1:1 채팅 및 그룹 채팅 모두 지원
• 지원 기기: 모바일 앱, 웹 모두 지원
• 트래픽 규모: DAU 기준 5천만 명 처리 가능
• 그룹 채팅 인원 제한: 최대 100명
• 메시지 길이 제한: 100,000자
• 채팅 이력 보관 기간: 평생
• 주요 기능
  • 1:1 채팅 (낮은 응답 지연 필요)
  • 그룹 채팅
  • 사용자 접속 상태 표시
  • 텍스트 메시지만 지원 (첨부파일 지원 X)
  • 하나의 계정으로 여러 단말에 동시 접속 지원
  • 푸시 알림 지원

개략적 설계안 제시

채팅 시스템에서 클라이언트는 서로 직접 통신하지 않는다. 대신 각 클라이언트는 나열한 모든 기능을 지원하는 채팅 서비스와 통신한다.

• 클라이언트들로부터 메시지 수신

• 메시지 수신자 결정 및 전달

• 수신자가 접속 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관

  클라이언트와 채팅 서비스 사이의 관계는 다음과 같이 나타낼 수 있다.

• 채팅을 시작하려는 클라이언트(sender)는 네트워크 통신 프로토콜을 사용하여 서비스에 접속한다.

• 송신 클라이언트는 수신 클라이언트에게 보낼 메시지를 채팅 서비스에 보낼 때 HTTP 프로토콜을 사용할 수 있다.

  • 채팅 서비스 접속 시 keep-alive 헤더를 사용하여 클라이언트와 서버 사이의 연결을 끊지 않고 유지할 수 있다.

• 메세지를 수신 시, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 것이 HTTP 프로토콜로는 어려울 수 있다.

  • 서버가 연결을 만드는 것 처럼 동작할 수 있도록 폴링, 롱 폴링, 웹소켓 기법이 사용된다.

폴링

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

• 잦은 폴링은 폴링 비용을 높인다.
• 답할 메시지가 없으면 결국 서버 자원의 낭비이다.

롱 폴링

일반적인 폴링은 여러 가지로 비효율적이다. 그에 따라 클라이언트가 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지하는 롱 폴링 기법이 만들어졌다.

• 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내는 동작을 반복한다.
• 문제점
  • HTTP 서버들은 보통 무상태 서버인데, 이 경우 클라이언트의 롱 폴링 연결을 갖지 않는 서버에 요청이 될 수 있다.
  • 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 방법이 없다.
  • 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 재접속하므로 비효율적이다.

웹소켓

웹소켓(WebSocket)은 서버가 클라이언트에게 비동기(async) 메시지를 보낼 때 가장 널리 사용하는 기술이다. 웹소켓은 메시지 전송이나 수신에 다음과 같이 상태를 유지하는 방식으로 사용할 것이다.

• 웹소켓을 이용하면 메시지 송수신 시 동일 프로토콜을 사용할 수 있어 설계와 구현이 단순하고 직관적이다.
• 웹소켓 연결은 항구적으로 유지되어야 하기 때문에 서버 측에서 연결 관리를 효율적으로 해야한다.

동작 과정 (3-way handshake)

1. 웹 소켓 연결은 클라이언트가 HTTP 요청으로 SYN 신호를 서버로 보내는 것으로 시작한다.
2. SYN 신호를 받은 서버는 변수 초기화 등 통신을 위한 준비를 한다. 이후 클라이언트에 대한 응답으로 ACK 신호와 함께 SYN 신호를 클라이언트에 요청한다.
3. 마지막으로 클라이언트도 정상적으로 ACK를 받으면 통신을 위한 준비를 하고, 마지막으로 서버에 한 번 더 ACK 신호를 전달한다.
4. 이후 서버와 클라이언트는 항구적인 웹 소켓 연결이 되어 비동기적으로 데이터를 주고받을 수 있다.

개략적 설계안

채팅 서비스에서는 상태를 유지할 필요가 있어 웹소켓을 쓸 것이지만, 다른 부분에서는 굳이 웹소켓을 사용할 필요가 없다. 따라서 다음과 같은 개략적 설계안을 제시할 수 있다.

무상태 서비스

• 위 설계안에서 무상태 서비스는 로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적이고 보편적인 요청/응답 서비스다.
• 이러한 서비스들은 시장에 완제품으로 많이들 나와있어 사서 사용하는 것도 가능하다.
• 이 중 “서비스 탐색(Service discovery)” 서비스는 클라이언트가 접속할 채팅 서버의 DNS 호스트명을 알려주는 역할을 하고, 이후 더 자세히 알아볼 것이다.

상태 유지 서비스

• 채팅 서비스는 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하므로 상태 유지가 필요하다.
• 클라이언트는 보통 서버가 살아있는 한 다른 서버로 연결을 변경하지 않는다.
• 앞서 언급한 “서비스 탐색” 서비스는 특정 서버에 부하가 몰리지 않도록 하는 역할도 한다.

제3자 서비스 연동

• 채팅 앱이 실행중이지 않아도 알림을 받아야 하므로 푸시 알림 서비스와의 연동은 매우 중요하다.

규모 확장성

위 설계안에서 규모 확장성을 고려해보자. 각 서비스(무상태, 유상태)의 서버들이 대규모 트래픽을 받을 수 있게, 그리고 SPOF를 방지하기 위해 여러 서버를 두는 것이 확장성 측면에서 좋을 것이다.

• 유의할 점은 실시간으로 메시지를 주고받기 위해 클라이언트는 채팅 서버와 웹소켓 연결을 유지해야 한다는 것이다.
• 채팅 서버는 클라이언트 사이에 메시지를 중계하는 역할이다.
• 접속상태 서버(presence server)는 사용자의 접속 여부를 관리한다.
• API 서버는 로그인, 프로파일 변경 등 보편적인 요청을 처리한다.
• 알림 서버는 푸시 알림을 보낸다.
• 키-값 저장소에는 채팅 이력을 보관하여 시스템에 접속한 사용자가 이전 채팅 이력을 볼 수 있게 한다.

저장소

데이터 계층에 대해서 어떠한 DB를 쓸 것인가도 중요한 문제이다. 채팅 시스템에서 보편적으로 다루는 데이터는 일반 데이터와 채팅 이력 두 가지인데 각각 다른 DB를 사용할 것이다.

1. 일반 데이터(사용자 프로파일, 설정, 친구 목록 등)
   • 위와 같은 데이터는 안정성을 보장하는 RDB에 보관
2. 채팅 이력 데이터
   • 위와 같은 데이터는 수평적 규모 확장, 낮은 지연시간, 효율적인 무작위 데이터 접근을 위해 키-값 저장소에 보관
     • 데이터 양이 엄청나므로(페이스북의 경우 600억) 수평적 규모 확장이 유리하면 좋음
     • 키-값 저장소는 데이터 접근 지연시간이 낮음
     • 주로 최근 메시지를 빈번하게 사용하지만, 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프하는 등 무작위적인 데이터 접근도 가능해야 함 → 무작위 접근 비용은 RDB보다 키-값 저장소가 더 쌈
   • 페이스북 메신저, 디스코드 등 많은 채팅 시스템에서 키-값 저장소를 채택중

데이터 모델

키-값 저장소를 데이터 계층 기술로 사용하기로 했으니, 메시지 데이터를 어떻게 보관할 것인지 자세히 살펴보자.

1:1 채팅을 위한 메시지 테이블

• 키: message_id 기본키
  • 메시지 정렬 역할도 수행 (동시에 생성되는 경우 created_at만으론 부족할 수 있음)

그룹 채팅을 위한 메시지 테이블

• 키: channel_id, message_id의 복합키
• 채널은 채팅 그룹과 같은 뜻
• 그룹 채팅에 대한 모든 질의는 채널을 대상으로 하므로 channel_id는 파티션 키로도 사용

메시지 ID

메시지 ID는 아래의 속성을 만족해야 한다.

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

위 조건을 만족시키는 message_id를 NoSQL에서 만들기 위해서는 크게 두가지 방법이 있다.
1. 전역적 64bit 시퀀스 번호 생성기 이용
2. 지역적 순서 번호 생성기(local sequence number generator) 이용
- 이 방법이 가능한 이유는 메시지 사이의 순서는 같은 채널, 또는 1:1 채팅 세션 안에서만 유지되면 충분하기 때문

상세 설계

채팅 시스템에서의 서비스 탐색(service discovery), 메시지 전달 흐름, 그리고 사용자 접속 상태를 표시하는 방법에 대해 자세히 살펴보자.

서비스 탐색

서비스 탐색의 주된 역할은 클라이언트에게 가장 적합한 채팅서버를 추천하는 것이다. 사용되는 기준으로는 클라이언트의 위치나 서버의 용량 등이 있다. 대표적인 오픈소스 솔루션으로 Apache Zookeeper가 있는데, 동작 방식은 다음과 같다.

1. 사용자 A가 시스템에 로그인 시도
2. 로드밸런서가 로그인 요청을 API 서버들 가운데 하나로 전송
3. API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능 동작, 해당 사용자를 서비스할 최적의 채팅서버 탐색
4. 사용자는 주키퍼에 의해 선택된 채팅 서버와 웹소켓 연결

메시지 흐름

1:1 채팅 메시지 처리 흐름 (from A to B)

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

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

• 사용자 A는 전화기와 랩톱 두 대의 단말을 이용한다고 가정
• A의 전화기와 랩톱 둘 다 서버 1과 웹소켓 연결이 되어있는 상황
• 각 단말은 cur_max_message_id라는 변수를 갖는데, 해당 단말의 가장 최신 메시지의 ID를 추적하는 용도로 사용
  • 해당 값은 단말마다 별도로 유지 관리
• 아래 두 조건을 만족하는 메시지는 새 메시지로 간주
  • 수신자 ID가 현재 로그인한 사용자 ID와 같다.
  • 키-값 저장소에 보관된 메시지로서, 그 ID가 cur_max_message_id보다 크다.

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

• 사용자 A가 채팅 서버에 메시지 전달
• 채팅 서버는 A의 메시지를 사용자 B, C의 메시지 동기화 큐에 전달
• 각 사용자는 새 메시지 확인 시 자신의 큐만 조회하면 되므로 메시지 동기화 플로가 단순함
• 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않음
• 수신자 관점에서 보면, 한 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야 함

LINE 라이브 채팅 아키텍처

라이브 채팅과 같은 서비스는 그룹 인원이 매우 많은 채팅방이라 봐도 무방하다. 이러한 서비스를 제공하기 위해선 앞서 언급했던 소규모 그룹에서의 메시지 흐름과는 다른 구조가 필요할 것이다.

LINE의 라이브 채팅 아키텍처 구조도

특이한 점은, 챗 서버 1에 연결된 클라이언트의 메세지(comment)가 챗 서버 2에 연결된 클라이언트에게 전송되는 것이다.

• LINE은 매우 많은 양의 코멘트를 분산시키기 위해 ‘채팅방’ 개념을 도입 >
• 시청자 수 증가에 따라 채팅방 분할, 같은 채팅방에 속한 유저들만 서로 대화 가능
• 채팅방은 여러 서버에 분산되므로, 같은 채팅방에 속한 유저라도 접속은 각기 다른 서버에 밸런싱 됨
• 즉, 서버를 기준으로 그룹 채팅을 하는 것이 아닌, ‘채팅방’ 개념을 기준으로 그룹 채팅을 하는 것과 같음

채팅 서버의 액터 시스템 구성

앞서 살펴본 전체적인 구조보다 actor에 더 초점을 맞춰 살펴보자. 참고로 Akka Actor는 액터 모델을 구현하여 병렬 처리를 효율적으로 관리하며, 메시지 기반의 비동기 통신을 가능하게 한다.

주로 ChatSupervisor, ChatRoomActor, UserActor의 3종류의 actor가 서로 연계하여 유저의 코멘트를 전달합니다. 각각의 역할은 다음과 같습니다.

• ChatSupervisor: JVM에 단 하나만 존재하는 액터로, 액터들을 생성, 감시하는 역할 (메세지 처리 로직 없음)
• ChatRoomActor: 각 채팅방마다 생성되며, 채팅방에서의 코멘트 송신과 송출 종료 등 각종 이벤트를 나타내는 메시지는 일단 여기로 전달
  • 서버 간 코멘트 동기화도 수행
  • 클라이언트에 전달할 메시지는 UserActor로 패싱
• UserActor: 유저별로 생성되는 actor이며, ChatRoomActor에서 메시지를 수신하여 자신이 담당하는 클라이언트의 WebSocket 커넥션에 페이로드 송신을 명령

Redis Cluster와 Pub/Sub의 사용

채팅에서는 서버 간 코멘트 동기화와 코멘트 및 각종 수치의 캐싱을 위해 Redis Cluster를 사용한다.

• 같은 채팅방이라도 여러 서버에 분산될 수 있음
• 채팅방이 여러 서버에 걸쳐 있는 경우, 서버 간에 어떻게 코멘트를 동기화하는가가 중요
• 같은 채팅방 내의 코멘트가 Redis의 Pub/Sub에 의해 동기화

참고: https://engineering.linecorp.com/ko/blog/the-architecture-behind-chatting-on-line-live

접속상태 표시

개략적 설계안에서는 접속상태 서버(presense server)를 통해 사용자의 상태를 관리한다. 접속상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부라는 점에 유의하자. 이제 사용자의 상태가 바뀌는 시나리오를 살펴볼 것이다.

사용자 로그인

1. 클라이언트와 실시간 서비스 사이에 웹 소켓 연결
2. 연결 후 접속상태 서버는 A의 상태와 last_active_at 타임스탬프 값을 키-값 저장소에 보관
3. 이후 해당 사용자는 접속 중인 것으로 표시됨

로그아웃

1. 사용자의 로그아웃 요청을 API 서버에 전송
2. API 서버는 접속 상태 서버에 사용자 상태를 변경하는 요청을 보내고, 키-값 저장소에 보관된 상태를 변경
3. 이후 사용자는 접속 중이 아닌 것으로 표시

접속 장애

인터넷을 통한 연결은 항상 안정적일 순 없다. 실제로 접속중이지만 일시적인 인터넷 장애로 인해 매번 온/오프라인 전환이 되는 것은 UX 측면에서 좋지 못하다.
이와 같은 문제를 박동(heartbeat) 검사로 해결할 수 있다.
1. 온라인 상태의 클라이언트는 주기적으로 박동 이벤트를 접속상태 서버로 전송
2. 마지막 이벤트를 받은 지 x초 이내에 또다른 박동 이벤트를 받으면 온라인 상태 유지 (위 그림에서는 x=30초)
3. 그렇지 않으면 오프라인으로 상태 전환

상태 정보의 전송

마지막으로 사용자들은 친구들의 상태 변화를 어떻게 알게되는지 알아볼 것이다.

1. 상태정보 서버는 발행-구독 모델(pub-sub model) 사용, 클라이언트와 서버 사이의 통신은 실시간 웹소켓 사용

2. 사용자 A의 상태 변경

3. 변경된 상태에 대한 메시지를 각 사용자별 구독 채널(A-B, A-C, A-D)에 전송

4. 각 사용자 B,C,D는 자신의 구독 채널에서 상태변화 메시지를 통지받음

   위와 같은 방식을 그룹 크기가 작을때 효과적이다. 그룹의 크기가 커지면 접속상태 변화를 알리는 데에 비용이 많이 들게 되므로, 사용자가 그룹 채팅에 입장하는 순간에만 상태정보를 읽어가게 하거나, 접속 상태 갱신을 수동으로 하는 방식이 있다.

마무리

주요 컴포넌트

• 실시간 메시징을 지원하는 채팅서버
• 접속상태 서버
• 푸시 알람 서버
• 채팅 이력보관용 키-값 저장소
• 나머지 기능을 담당하는 API 서버

추가 논의 주제

• 사진이나 미디어 지원: 미디어 파일을 지원하려면 압축, 클라우드 저장소, 썸네일 생성 등을 고려할 수 있다.
• 종단간 암호화: Whatsapp은 메시지 전송에 있어 종단 간 암호화를 지원한다. 메시지 발신인과 수신자 이외에는 아무도 메시지를 볼 수 없다.
• 캐시: 이미 읽은 메시지 캐시 시, 서버와 주고받는 데이터 양을 줄일 수 있다.
• 로딩 속도 개선: 슬랙은 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축해 앱 로딩 속도를 개선했다.
• 오류 처리
  • 채팅 서버 오류: 채팅 서버 하나에 수십만 사용자가 접속해 있는 상황을 생각해보자. 그런 서버 하나가 죽으면 서비스 탐색 기능(주키퍼)가 동작하여 클라이언트에게 새로운 서버를 배정하고 다시 접속할 수 있도록 해야 한다.
  • 메시지 재전송: 재시도(retry)나 큐(queue)는 메시지의 안정적 전송을 보장하기 위해 흔히 사용된다.