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

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

요구사항

• 1:1 채팅과 그룹 채팅 모두 지원 가능해야함.
• 모바일 앱과 웹 둘다 지원 가능해야함.
• 일별 능동 사용자 수 기준으로 5천만명 처리 가능해야 함.
• 그룹 채팅의 경우 최대 100까지 참가 가능함.
• 1:1 채팅, 그룹 채팅, 사용자 접속상태 표시 지원 가능해야 함, 텍스트 메시지만 주고받을 수 있음
• 메시지 길이 제한은 100,000자 이하여야 함.
• 종단 간 암호화는 필요없음.

설계할 채팅 앱 기능

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

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

채팅 서비스에서 제공해야 할 기능들

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

figure 12-2는 클라이언트와 채팅 서비스 사이의 관계를 요약해 보았다.

폴링

• 폴링은 클라이언트가 주기적으로 서버에게 새 메시지가 있느냐고 무렁보는 방법이다.
• 폴링 비용은 폴링을 자주하면 할수록 올라간다. 답해줄 메시지가 없는 경우에는 서버 자원이 불필요하게 낭비된다는 문제도 있다.

롱 폴링

• 롱 폴링의 경우 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지한다.
• 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내어 모든 절차를 다시 시작한다.
• 이 방법에는 아래와 같은 약점이 있다.
  • 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수도 있다. 로드밸런싱을 위해 라운드 로빈 알고리즘을 사용하는 경우, 메시지를 받은 서버는 해당 메시지를 수신할 클라이언트와의 롱 폴링 연결을 가지고 있지 않은 서버일 수 있는 것이다.
  • 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 좋은 방법이 없다.
  • 여전히 비효율적이다. 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속할 것이다.

웹소켓

• 웹소켓은 서버가 클라이언트에게 비동기 메시지를 보낼때 가장 널리 사용하는 기술이다.
• figure 12-5는 웹소켓이 어떻게 동작하는지를 보였다.

• 웹소켓 연결은 클라이언트가 시작한다.
• 한번 맺어진 연결은 항구적이며 양방향이다.
• 이 연결은 처음에는 HTTP 연결이지만 특정 핸드셰이크 절차를 거쳐 웹소켓 연결로 업그레이드된다.
• 일단 항구적인 연결이 만들어지고 나면 서버는 클라이언트에게 비동기적으로 메시지를 전송할 수 있다.
• 웹소켓은 일반적으로 방화벽이 있는 환경에서도 잘 동작한다. 80이나 443처럼 HTTP 혹은 HTTPS 프로토콜이 사용하는 기본 포트번호를 그대로 쓰기 때문이다.
• figure 12-6에 어떻게 웹소켓이 메시지 전송이나 수신에 쓰일 수 있는지 간략히 제시한다.

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

개략적 설계안

무상태 서비스

• 무상태 서비스는 로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스다.
• 무상태 서비스는 로드밸런서 뒤에 위치한다.

상태 유지 서비스

• 본 설계안에서 상태 유지가 필요한 서비스는 채팅 서비스다. 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하기 때문이다.

제3자 서비스 연동

• 채팅 앱에서는 새 메시지를 받았다면 설사 앱이 실행 주이지 않더라도 알림을 받아야 하기 때문에 가장 중요한 제3자 서비스는 푸시 알림이다.

규모 확장성

• 채팅 앱을 설계할때 따져봐야 할 사항은 서버 한 대로 얼마나 많은 접속을 동시에 허용할 수 있느냐다.
• 이번에 다루는 시스템의 경우에는 동시 접속자가 1M이라고 가정할 것인데, 접속당 10K의 서버 메모리가 필요한다고 본다면 10GB 메모리만 있으면 모든 연결을 다 처리할 수 있을 것이다.
• SPOF같은 문제점들 때문에 대량의 트래픽을 서버 한 대로 처리하는 것인 좋지 않은 생각이다.
• figure 12-8은 개략적 설계안이다.

• figure 12-8에서 유의할 것은 실시간으로 메시지를 주고받기 위해 클라이언트는 채팅 서버와 웹소켓 연결을 끊지 않고 유지한다는 것이다.
• 채팅 서버는 클라이언트 사이에 메시지를 중꼐하는 역할을 담당한다.
• 접속상태 서버는 사용자의 접속 여부를 관리한다.
• API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리한다.
• 알림 서버는 포시 알림을 보낸다.
• 키-값 저장소에는 채팅 이력을 보관한다.

저장소

• 관계형 데이터베이스를 쓸 것인가 NoSQL을 채택할 것인가의 질문에 대한 올바은 답을 하기 위해서는 데이터의 유형과 읽기/쓰기 연산의 패턴이다.
• 채팅 시스템이 다루는 데이터는 1) 사용자 프로파일, 설정, 친구 목록처럼 일반적인 데이터다. 이런 데이터는 안정성을 보장하는 관계형 데이터베이스에 보관한다. 다중화와 샤딩은 이런 데이터의 가용성과 규모확장성을 보증하기 위해 보편적으로 사용되는 기술이다.  2) 채팅 이력으로 이 데이터를 어떻게 보관할지 결정하려면 읽기/쓰기 연산 패턴을 이해해야 한다.
  • 채팅 이력 데이터의 양은 엄청나다.
  • 이 데이터 가운데 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지다. 대부분의 사용자는 오래된 메시지는 들여다보지 않는다.
  • 사용자는 대체로 최근에 주고받은 메시지 데이터만 보게 되지만, 검색 기능을 이용하거나, 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프하거나 하여 무작위적인 데이터 접근을 하게 되는 일도 있다. 데이터 계층은 이런 기능도 지원해야 한다.
  • 1:1 채팅 앱의 경우 읽기/쓰기 비율은 대략 1:1 정도다.
• 본 설계안의 경우에는 키-값 저장소를 추천할 것인데, 이유는 다음과 같다.
  • 키-값 저장소는 수평적 규모확장이 쉽다.
  • 키-값 저장소는 데이터 접근 지연시간이 낮다.
  • 관계형 데이터베이스는 인덱스가 커지면 데이터에 대한 무작위적 접근을 처리하는 비용이 늘어난다.
  • 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 채택하고 있다.

데이터 모델

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

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

메시지 ID

• message_id는 메시지들의 순서도 표현할 수 있어야 한다. 그러기 위해서는 아래와 같은 속성을 만족해야 한다.
  • message_id의 값을 고유해야 한다.
  • ID 값은 정렬 가능해야 하며 시간 순서와 일치해야 한다. 즉, 새로운 ID는 이전 ID보다 큰 값이어야 한다.
• 위 두 조건을 만족하는 방법은 무엇이 있을까?
  • RDBMS라면 auto_increment가 대안이 될 수 있지만 NoSQL은 보통 해당 기능을 제공하지 않는다.
  • 스노우플레이크 같은 전역적 64-bit 순서 번호 생성기를 이용하는 것이다.
  • 지역적 순서 번호 생성기를 이용하는 것이다. 여기서 지역적이라 함은, ID의 유일성은 같은 그룹 안에서만 보증하면 충분하다는 것이다.

3단계 상세 설계

서비스 탐색

• 서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것이다.
• 이때 사용되는 기준으로는 클라이언트의 위치, 서버의 용량 등이 있다.
• 서비스 탐색 기능을 구현하는 데 널리 쓰이는 오픈 소스 솔루션으로는 아파치 주키퍼등이 있다. 사용 가능한 모든 채팅 서버를 여기 등록시켜두고, 클라이언트가 접속을 기도하면 사전에 정한 기준에 따라 최적의 채팅 서버를 골라 주면 된다.
• figure 12-11은 주키퍼로 구현한 서비스 탐색 기능이 어떻게 동작하는지를 보여준다.

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

메시지 흐름

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

• figure 12-12는 1:1 채팅에서 사용자 A가 B에게 보낸 메시지가 어떤 경로로 처리되는지를 보여준다.

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

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

• figure 12-13은 여러 단말 사이에 메시지 동기화는 어떻게 하는지를 보여준다.

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

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

• figure 12-14, 12-15는 그룹 채팅에서의 메시지 흐름을 보여준다.

• figure 12-14는 사용자 A가 그룹 채팅 방에서 메시지를 보냈을 때 어떤 일이 벌어지는지 보여준다.
• 해당 그룹에 3명의 사용자가 있다고 하자(사용자 A,B,C), 우선 사용자 A가 보낸 메시지가 사용자 B와 C의 메시지 동기화 큐에 복사된다.
• 이 설계안은 소규모 그룹 채팅에 적합한데, 이유는 다음과 같다.
  • 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되니까 메시지 동기화 플로우가 단순하다.
  • 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않는다.
• 지금 설명한 메시지 흐름을 수신자 관점에서 살펴보면, 한 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야 한다.
• 따라서 각 사용자의 수신함, 즉 메시지 동기화 큐는 figure 12-15와 같이 여러 사용자로부터 오는 메시지를 받을 수 있어야 한다.

접속상태 표시

• 채팅 애플리케이션을 사용하다 보면 사용자의 프로파일 이미지나 대화명 옆에 녹색 점이 붙어 있는 것을 보게 되는데, 이것이 바로 사용자가 접속중임을 나타낸다.
• 개략적 설계안에서는 접속상태 서버를 통해 사용자의 상태를 관리한다고 했었다.
• 접속상태 서버는 클아이언트와 웹소켓으로 통신하는 실시한 서비스의 일부라는 점에 유의하자.

사용자 로그인

• 클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버는 A의 상태와 last_active_at 타임스탬프 값을 키-값 저장소에 보관한다.
• 이 절차가 끝나고 나면 해당 사용자는 접속 중인 것으로 표시될 것이다.

로그아웃

• figure 12-17과 같은 절차로 사용자는 로그아웃을 한다.

• 이때 키-값 저장소에 보관된 사용자 상태가 online에서 offline으로 바뀐다.

접속 장애

• 인터넷을 통한 연결이 항상 안정적이라면 좋겠지만 그렇지 못하다는 것이 문제다.
• 이런 장애에 대응하는 간단한 방법은 사용자를 오프라인 상태로 표시하고 연결이 복구되면 온라인 상태로 변경하는 것이다.
• 하지만 이 방법에는 문제점이 있다. 짧은 시간 동안 인터넷 연결이 끊어졌다 복구되는 일은 흔하다. 이럴때마다 사용자의 접속 상태를 변경하면 그것은 지나친 일일 것이고, 사용자 경험 측면에서도 바람직하지 않을 것이다.
• 본 설계안에서는 박동 검사를 통해 이 무제를 해결할 것이다. 즉, 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 하고, 마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지하는 것이다.
• figure 12-18은 박동 이벤트가 어떻게 동작하는지 보여준다.

상태 정보의 전송

• figure 12-19는 친구 관계에 있는 사용자들이 어떻게 다른 사용자의 상태 변화는 알게 되는지 보여준다.

• 상태정보 서버는 발행 구독 모델을 사용하는데, 각각의 친구관계마다 채널을 하나씩 두는 것이다.
• 가령 사용자 A의 접속상태가 변경되었다고 하자 그 사실을 세 개 채널, 즉 A-B, A-C, A-D에 쓰는 것이다. 그리고 A-B는 사용자 B가 구독하고, A-C는 사용자 C가, A-D는 사용자 D가 구독하도록 한다.
• 이렇게 하면 친구 관계에 있는 사용자가 상태정보 변화를 쉽게 통지 받을 수 있게 된다.
• 클라이언트와 서버 사이의 통신에는 실시간 웹소켓을 사용한다.
• 위의 방안은 그룹 크기가 작을 때 효과적이다.
• 그룹 크기가 커지면 이런 식으로 접속상태 변화를 알려서는 비용이나 시간이 많이 들게되므로 좋지 않다.
• 이런 성능 문제를 해소하는 한 가지 방법은 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도하는 것이다.