12장. 채팅 시스템 설계

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

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

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

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

클라이언트는 서로 직접 통신하지 않으며 각각의 클라이언트는 위 1단계에 나열한 모든 기능을 지원하는 채팅 서비스와 통신한다.

이 채팅서비스는 아래 기능을 제공해야한다고 가정.

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

다음은 클라이언트와 채팅 서비스 사이의 관계를 요약한 그림이다.

채팅을 시작하려는 클라이언트는 네트워크 통신 프로토콜을 사용하여 서비스에 접속한다. 따라서 채팅 서비스의 경우 어떤 통신 프로토콜을 사용할 것인지는 중요하다.

HTTP 프로토콜을 사용하여 채팅서비스를 구현할 수 있지만 HTTP는 클라이언트가 연결을 만드는 프로토콜이며, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데는 쉽게 쓰일 수 없다.

서버가 연결을 만드는 것처럼 동작할 수 있도록 하기 폴링, 롱 폴딩, 웹소켓 등의 기술이 있다.

폴링

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

롱 폴링

폴링은 여러 가지로 비효율적일 수 있어서 나온 기법이 롱 폴링이다.

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

롱 폴링의 경우 다음과 같은 단점이 있다.

• 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하지 않을 수 있다. HTTP 서버들은 보통 무상태 서버인데, 로드밸런싱을 위해 라운드 로빈 알고리즘을 사용하는 경우 메시지를 받은 서버는 해당 메시지를 수신할 클라이언트와의 롱 폴딩 연결을 가지고 있지 않은 서버일 수 있는 것이다.
• 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 방법이 없다.
• 메시지를 자주 받지 않는 클라이언트도 타임아웃이 일어날 때 마다 주기적으로 서버에 다시 접속해야한다.

웹 소켓

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

웹소켓 연결은 클라이언트가 시작한다. 처음에는 HTTP 연결이지만 특정 핸드셰이크 절차를 거쳐 웹소켓 연결로 업그레이드된다. 웹소켓 연결이 되면 서버는 클라이언트에게 비동기적으로 메시지를 전송할 수 있다.

 

웹 소켓은 일반적으로 방화벽이 있는 환경에서도 잘 동작한다. 80이나 443처럼 HTTP 혹은 HTTPS 프로토콜이 사용하는 기본 포트번호를 그대로 사용하기 때문이다.

앞서 HTTP 프로토콜이 메시지를 보내려는 클라이언트에게 괜찮은 프로토콜이라고 설명했지만 웹소켓은 이에 더해 양방향 메시지 전송까지 가능하게 하므로 웹소켓 대신 HTTP를 굳이 고집할 이유는 없다.

---

개략적 설계안

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

무상태 서비스

무상태 서비스는 로드밸런서 뒤에 위치한다. 로드밸런서 뒤에 오는 서비스는 모놀리틱 서비스일 수도 있고 마이크로서비스일 수도 있다.

 

서비스탐색

클라이언트가 접속할 채팅 서버의 DNS 호스트명을 클라이언트에게 알려주는 역할을한다. 특정 서버에 부하가 몰리지 않도록 한다.

상태 유지 서비스

본 설계안에서 유일하게 상태 유지가 필요한 서비스는 채팅 서비스다. 각 클라이언트가 채팅 서버와 독립적인 네트워크를 유지해야 하기 때문이다. 클라이언트는 보통 서버가 살아 있는 한 다른 서버로 연결을 변경하지 않는다.

제3자 서비스 연동

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

---

규모 확장성

처리할 데이터의 규모가 크다면 트래픽을 서버 한 대로 처리하는데에는 한계가 있다.

다음은 여러 개의 서버들로 구성된 채팅 시스템이다.

위 사진에 유의할 것은 실시간으로 메시지를 주고받기 위해 클라이언트는 채팅 서버와 웹소켓 연결을 끊지 않고 유지해아한다.

• 채팅 서버는 클라이언트 사이에 메시지를 중계하는 역할을 담당한다.
• 접속상태 서버는 사용자의 접속여부를 관리한다.
• API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리한다.
• 알림서버는 푸시 알림을 보낸다.
• 키-값 저장소에 채팅 이력을 보관한다.

저장소

관계형 데이터베이스를 쓸 것인가 아니면 NoSQL을 채택할 것인가? 이 질문에 대한 올바른 답을 하기 위해 중요하게 따져야 할 것은, 데이터의 유형과 읽기/쓰기 연산의 패턴이다.

채팅 시스템이 다루는 데이터는 보통 두 가지다.

• 사용자 프로파일, 설정, 친구 목록 처럼 일반적인 데이터
  • 이런 데이터는 안전성을 보장하는 관계형 데이터베이스에 보관한다.
  • 다중화와 샤딩은 이런 데이터의 가용성과 규모확장성을 보증하기 위해 보편적으로 사용되는 기술이다.
• 채팅 이력 데이터
  • 이 데이터를 어떻게 보관할지 결정하려면 읽기/쓰기 연산 패턴을 이해해야한다.

읽기 쓰기 연산 패턴

• 채팅 이력 데이터의 양은 엄청나다. 페이스북 메신저나 왓츠앱은 매일 600억 개의 메시지를 처리한다.
• 이 데이터 가운데 빈번하게 사용되는 것은 주로 최근에 주고받은 메시지다. 대부분의 사용자는 오래된 메시지는 들여다보지 않는다.
• 검색 기능을 이용하거나, 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프하는 등 무작위적인 데이터 접근을 하게될 수 있는데 이러한 기능도 지원해야한다.
• 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1 정도다.

본 설계안에서는 NoSQL인 키-값 저장소를 추천할 것인데, 이유는 다음과 같다.

• 키-값 저장소는 수평적 규모 확장이 쉽다.
• 키-값 저장소는 데이터 접근 지연시간이 낮다.
• 관계형 데이터베이스는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있다. 인덱스가 커지면 데이터에 대한 무작위 접근을 처리하는 비용이 늘어난다.
  • 롱테일 : 큰 데이터 집합에서 일어나는 드물고 특이한 사건을 설명할 때 사용
  • 단점 :
    1. 쿼리 최적화의 어려움: 롱 테일 데이터는 전체 데이터 중 소수의 레코드에 해당하므로 특정 쿼리에 대한 최적화가 어려울 수 있다. 관계형 데이터베이스는 쿼리 최적화를 통해 빠른 성능을 제공하는데, 이를 롱 테일에 적용하기 어려운 경우가 있을 수 있다.
    2. 인덱스의 한계: 대량의 다양한 값을 가진 롱 테일은 효율적인 인덱스 구성을 어렵게 만다. 인덱스의 크기가 늘어날 뿐만 아니라 업데이트 및 삽입 작업이 복잡해지기 때문에 성능에 영향을 줄 수 있다.
• 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 채택하고 있다.

데이터 모델

메시지 데이터를 어떻게 보관할 것인가?

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

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

1:1 채팅을 지원하기 위한 메시지 테이블의 사례다.

이 테이블은 기본키는 message_id로, 메시지 순서를 쉽게 정할 수 있도록하는 역할도 담당한다. created_at를 사용하여 메시지 순서를 정할 수 없는 이유는 서로 다른 두 메시지가 동시에 만들어질 수 있기 때문이다.

 

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

그룹 채팅을 위한 메시지 테이블의 사례다. {channel_id, message_id}의 복합키를 기본키로 사용한다. 여기서 채널은 채팅 그룹과 같은 뜻이다. channel_id는 파티션 키로도 사용할 수 있는데 그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 할 것이기 때문이다.

메시지 ID

message_id는 다음과 같은 속성을 만족해야한다.

• message_id의 값은 고유해야한다.
• ID 값은 정렬 가능해야 하며 시간 순서와 일치해야 한다.(새로운 ID는 이전 ID보다 큰 값이어야 한다.)

NoSQL은 RDBM의 auto_increment와 같은 기능을 제공하지 않기 때문에 스노플레이크 은 전역적 64-bit 순서 번호 생성기를 이용한다.

다른 방법으로는 ID의 유일성은 같은 그룹 안에서만 보증하면 충분하기에 지역적 순서 생성기를 사용한다. 이 방법이 통하는 이유는 메시지 사이의 순서는 같은 채널, 혹은 같은 1:1 채팅 세션 안에서만 유지되면 충분하기 때문이다. 전역적 ID 생성기에 비해 구현하기 쉽다.

 

3단계. 상세 설계

• 서비스 탐색
• 메시지 전달흐름
• 사용자의 접속 상태를 표시

서비스 탐색

서비스 탐색 기능의 주된 역할은 클라이언트의 위치, 서버의 용량 등을 고려하여 가장 적합한 채팅 서버를 추천하는 것이다.

서비스 탐색 기능을 구현하는데 널리 쓰이는 오픈 소스 솔루션으로는 아파치 주키퍼 같은 것이 있다.

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

아래 그림은 주키퍼로 구현한 서비스 탐색 기능이 어떻게 동작하는지를 보여준다.

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

메시지 흐름

• 1:1 채팅 메시지의 처리흐름
• 여러 단말 간 메시지 동기화 과정
• 그룹 채팅 메시지 처리 흐름도

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

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

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

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

다음 그림은 사용자 A가 전화기와 랩톱, 두 대의 단말을 이용하고 있다.

사용자 A가 전화기에서 채팅 앱에 로그인한 결과로 채팅 서버 1과 해당 단말 사이 웹소켓 연결이 만들어져 있고, 랩톱에서 로그인한 결과로 역시 별도 웹소켓이 채팅 서버 1에 연결되어 있는 상황이다.

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

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

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

cur_max_message_id는 단말마다 별도로 유지 관리하면 되는 값이라 키-값 저장소에서 새 메시지를 가져오는 동기화 작업도 쉽게 구현할 수 있다.

 

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

1:1 채팅에 비해 그룹 채팅에서의 메시지 흐름은 조금 더 복잡하다.

해당 그룹에 사용자 A, B, C 3명의 사용자가 있다고 가정한다.

사용자 A가 보낸 메시지와 사용자 B와 C의 메시지 동기화 큐에 복사된다.이 큐를 사용자 각각에 할당된 메시지 수신함 같은 것이라고 봐도 무방하다. 이 방법은 소규모 그룹 채팅에 적합한 이유는 다음과 같다.

• 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되어 메시지 동기화 플로가 단순하다.
• 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않는다.

하지만 많은 사용자를 지원해야하는 경우 똑같은 메시지를 모든 사용자의 큐에 복사하는 것은 바람직하지 않을 것이다.

위 설계를 수신자 관점에서 바라보면, 한 수신자는 여러 사용자로부터 오는 메시지를 수신할 수 있어야 한다.

따라서 각 사용자의 수신함, 즉 메시지 큐는 다음과 같이 여러 사용자로부터 오는 메시지를 받을 수 있어야 한다.

접속상태 표시

접속상태 서버는 클라이언트와 웹소켓으로 통신하는 실시간 서비스의 일부이다. 사용자의 상태가 바뀌는 몇가지 시나리오를 살펴본다.

사용자 로그인

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

로그아웃

사용자 로그아웃은 다음과 같은 절차를 거친다.

키-값 보관소에 보관된 사용자 상태가 online에서 offline으로 바뀌게 된다는 점에서 유의해야한다.

이 절차가 끝나면 UI상에서 사용자의 상태는 접속 중이 아닌 것으로 표시될 것이다.

 

접속 장애

인터넷을 통한 연결은 항상 안정적일 수 없다. 이러한 현상을 대응할 수 있는 설계를 준비해야 한다. 사용자의 인터넷 연결이 끊어지면 클라이언트와 서버 사이에 맺어진 웹소켓 같은 지속성 연결도 끊어진다. 이런 장애에 대응하는 간단한 방법은 사용자를 오프라인 상태로 표시하고 연결이 복구되면 온라인 상태로 변경하는 것이다. 짧은 시간 동안 인터넷 연결이 끊어졌다 복구 되는 일은 아주 흔하다.

본 설계안에서는 박동(heartbeat) 검사를 통해 문제를 해결한다. 즉, 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 하고, 마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지하는 것이다. 그렇지 않을 경우에만 오프라인으로 바꾸는 것이다.

위 사진은 클라이언트는 heartbeat event를 5초에 한번씩 서버로 보낸다. 이벤트를 3번 보낸 후, 클라이언트가 30초 동안 heatbeat event를 보내지 않았기 때문에 서버는 사용자를 오프라인 상태로 변경한다.

상태 정보의 전송

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

상태 정보 서버는 각각의 친구관계마다 채널을 하나씩 두는 발행-구독 모델(publish-subscribe model)을 사용한다. 가령 사용자 A의 접속 상태가 변경되었다고 하면 A-B, A-C, A-D 세 개의 채널에 쓴다.

채널 A-B : B가 구독

채널 A-C : C가 구독

채널 A-D : D가 구독

이렇게 하면 친구 관계에 있는 사용자가 상태정보 변화를 쉽게 받을 수 있게 된다. 클라이언트와 서버 사이의 통신에는 실시간 웹소켓을 사용한다.

이 방안은 그룹의 크기가 작을 때 효과적이다. 그룹의 크기가 커지면 이런 식의 접속 상태 변화 알림은 비용과 시간이 많이 든다. 가령 100,000 명의 사용자가 있다면 상태 변화 1건당 100,000개의 이벤트 메시지가 발생할 것이다. 이를 해결하기 위해서는 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 접속 상태를 갱신하고 싶으면 수동으로 하도록 유도하는 것이다.

 

4단계. 마무리

클라이언트와 서버 사이의 실시간 통신을 가능하도록 하기 위해 웹소켓을 사용하며, 실시간 메시징을 지원하는 채팅 서버, 접속 상태 서버, 푸시 알림 서버, 채팅 이력을 보관할 키-값 저장소, 그리고 이를 제외한 나머지 기능을 구현하는 데 쓰일 API서버 등이 주요 컴포넌트였다.

추가로 고려해볼 수 있는 사항

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