사이드 프로젝트로 디스코드를 만들기로 계획했다.
디스코드의 많은 기능 중 먼저 실시간 채팅 기능을 구현하고자 한다.
먼저 채팅 어플리케이션의 트래픽 특성을 간단히 보자.
채팅 어플리케이션의 트래픽 특성
- 엄청난 양의 트래픽 그룹 채팅
- 오래된 채팅 잘 안봄
- 1:1 채팅 앱의 경우 Read / Write 비율 1:1
채팅이 일어나는 방식과 기존 HTTP의 문제
이제 1대1로 채팅을 한다고 생각해보자.
A, B가 채팅을 쓰고 server로 보낸다. 그리고 A, B 둘 다 서버에 채팅방의 메시지 데이터를 요청하면 볼 수 있다.
그런데 여기서 문제가 하나 있다. 실시간 채팅을 한다고 가정했을 때, A가 채팅을 보냈다는 사실을 B가 어떻게 알 수 있을까?
방법을 생각해보자면, A가 server로 채팅을 보내고, 그것을 B가 바로 알려면 server가 B에게 채팅이 왔다는 사실을 알려주면 된다. 하지만, 우리가 API 통신을 할 때 주로 활용하는 HTTP는 stateless이며, client의 request가 존재할 때 server의 response가 존재하는 형식이다.
즉, 우리가 채팅을 쓰고 server에게 보내는 것과 server에게 채팅 내역을 요구하는 것에는 문제가 없지만, server가 새로운 채팅이 생긴 것을 인지하고 유저에게 그 사실을 알리는 것은 어렵다는 것이다. (유저는 server의 정보가 있지만, server는 유저가 먼저 요청하지 않는 한 유저의 정보를 알 방법이 없다.)
해결방법
그러면 이제 해결방법에 대해서 생각해보자. 대표적으로 3가지 방법을 제시할 수 있다.
1. Polling
먼저 Polling이다.
서버가 나를 모르기 때문에 채팅이 왔다고 알려줄 수 없다면? 내가 채팅이 왔냐고 주기적으로 계속 물어보면 되는 것이다.
간단하지만, 문제가 있다.
먼저, 한 명의 유저가 물어보는 트래픽은 감당한다고 쳐도, 그걸 수천만 명, 수억 명이 동시에 요청한다고 생각했을 때는 server가 받는 부하가 너무 심하다.
그리고, 주기적으로 채팅 내역을 요청한다고 해도, 약간의 딜레이가 생기는 것은 피할 수 없을 것이다. 보낸 직후에 요청을 하지 않을 수 있기 때문이다.
또한, 답해줄 메시지가 없는 경우에는 서버 자원이 불필요하게 낭비된다는 문제도 있다.
단점
- request 수
- 메시지 latency
- resource 낭비
2. Long Polling
Polling의 변형 버전이라고 생각하면 된다.
Polling과 마찬가지로 request를 보낸다. 하지만 여기서 차이는 time out이 존재한다는 점이다.
server는 client에게서 request가 들어왔을 때 채팅이 존재하면 바로 response를 해준다. 그러나 채팅이 존재하지 않는다면 time out을 건다. 그리고 time out이 될 때까지 response할 채팅이 존재하지 않는다면 그때는 client에게 time out이라고 response한다. Long Polling은 이 과정을 반복하는 것이다.
Polling과 비교했을 때 response 수는 좀 더 줄어들겠지만, 여전히 request 수는 많을 것이고 server가 받는 부하도 클 것이다. 또한, request와 response 사이에 정보의 딜레이가 생기는 것도 여전할 것이다.
메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수도 있다. HTTP 서버들은 보통 stateless 서버다. 로드밸런싱을 위해 round robin 알고리즘을 사용하는 경우, 메시지를 받은 서버는 해당 메시지를 수신할 클라이언트와의 롱 폴링 연결을 가지고 있지 않은 서버일 수 있는 것이다.
또한 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 좋은 방법이 없다.
단점
- request 수
- 메시지 latency
- 서버 확장 시 통신에 문제가 생길 가능성이 있음
3. Websocket
Websocket이 채팅 어플리케이션을 만들 때 사용할 통신 protocol이다.
WebSocket은 서버가 클라이언트에게 비동기 메시지를 보낼 때 가장 널리 사용하는 기술이다.
HTTP 통신은 request, response 형태로 통신이 종료된다. 하지만 Websocket은 client와 server의 커넥션을 맺은 상태로 유지한다. 그리고 커넥션이 유지되어 있는 동안에는 양방향 소통이 가능해진다.
WebSocket에 대한 보다 자세한 얘기는 해당 글에 서술했다. (WebSocket)
Websocket을 이용한 채팅 어플리케이션 server
기본적인 구조는 다음과 같다고 보면 된다.
server가 2개로 분리되어 있는 이유는 websocket 통신의 경우 커넥션을 유지해야하기 때문에 따로 관리하는 것이 좋기 때문이다. 생각해보면 오픈 커넥션을 지속적으로 유지하려면 server 자원을 많이 쓸 거라고 예상해볼 수 있다.
- websocket은 open connection을 유지해줘야 되기 때문에 chat server를 만들어서 관리
- 일반적인 request는(로그인 / 프로필 사진 변경 등) API server에서 HTTP로 관리
그리고 위와 같이 server가 분리되기 시작하면 server 간의 통신을 위해 Message Queue, RPC, Rest API 등을 사용하는데 이 또한 내용이 길기 때문에 자세한 설명은 다른 게시글에서 하도록 하겠다. (Message Broker)
일단 해당 프로젝트에서는 Message Queue를 사용해 micro service 간의 통신을 할 수 있도록 설계할 것이다.
Message Queue를 활용하는 것의 장점은 task를 asynchronous하게 처리할 수 있다는 것이다. 그리고 이는 micro service들 간의 decoupling을 할 수 있게 해준다.
그림과 같이 각각의 service들은 서로에게 의존적이지 않고, Message Queue만 알고 있으면 된다. Message Queue는 각각의 event에 대해서 listen하고 있는 service들에게 전달해주는 역할을 맡게 된다.
채팅 시스템 구조
어플리케이션에서 채팅 시스템의 대략적인 구조는 다음과 같게 된다.
- A가 B에게 채팅을 보내면
- Message Queue의 user B의 queue에 들어가게 된다.
- 그러면 해당 queue를 subscribe하고 있던 service들에게 notification이 가게 되고
- 따라서 message db에 메시지를 생성하고, 동시에 B가 접속한 chat server에 해당 내역이 전달된다.
Message DB는 모든 event를 listen하고 있는 상태이다.
그리고 만약 A가 C에게 채팅을 보내면, C는 로그아웃 상태이기 때문에 user C의 queue를 subscribe하고 있는 push notification service가 C에게 알림을 보내게 된다.
위와 같은 설계는 그룹챗을 할 때 한 방에 수 천명, 수 만명까지 들어갈 수 있는 경우에는 적합하지 않다.
chat server에 입력이 들어오고, db를 통해 관계를 확인한 뒤 데이터를 전송하게 되는 system인데, 이 때 fan out이 발생하기 때문에 데이터를 전송해야 하는 유저가 지나치게 많아지게 되면 이 설계는 적합하지 않게 된다.
접속상태 표시
사용자의 접속 상태를 표시하는 것은 상당수 채팅 애플리케이션의 핵심적 기능이다.
사용자 로그인
클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버는 A의 상태(online, offline)와 last_active_at 타임스탬프 값을 key-value 저장소에 보관한다.
로그아웃
key-value 저장소에 보관된 사용자 상태가 online에서 offline으로 바뀌게 된다.
접속 장애
사용자의 인터넷 연결이 끊어지면 클라이언트와 서버 사이에 맺어진 웹소켓 같은 연결도 끊어진다. 이런 장애에 대응하는 간단한 방법은 사용자를 오프라인 상태로 표시하고 연결이 복구되면 온라인 상태로 변경하는 것이다. 하지만 이 방법에는 심각한 문제가 있다. 짧은 시간 동안 인터넷 연결이 끊어졌다 복구되는 일은 흔하다. 이런 일이 벌어질 때마다 사용자의 접속 상태를 변경한다면 그것은 지나친 일일 것이고, 사용자 경험 측면에서도 바람직하지 않을 것이다.
이는 heartbeat 검사를 통해 해결할 수 있다. 즉, 온라인 상태의 클라이언트로 하여금 주기적으로 heartbeat event를 접속상태 서버로 보내도록 하고, 마지막 이벤트를 받은 지 x초 이내에 또 다른 heartbeat event를 받으면 해당 사용자의 접속상태를 계속 온라인으로 유지하는 것이다. 그렇지 않을 경우에만 오프라인으로 바꾸는 것이다.
상태 정보의 전송
그렇다면 사용자 A와 친구 관계에 있는 사용자들은 어떻게 해당 사용자의 상태 변화를 알게 될까?
다음 그림은 그 원리에 관한 그림이다.
상태정보 서버는 발행-구독 모델을 사용하는데, 즉 각각의 친구관계마다 채널을 하나씩 두는 것이다. 가령 사용자 A의 접속상태가 변경되었다고 하자. 그 사실을 세 개 채널, 즉 A-B, A-C, A-D에 쓰는 것이다. 그리고 A-B는 사용자 B가 구독하고, A-C는 사용자 C가, 그리고 A-D는 사용자 D가 구독하도록 하는 것이다. 이렇게 하면 친구 관계에 있는 사용자가 상태정보 변화를 쉽게 통지 받을 수 있게 된다. 클라이언트와 서버 사이의 통신에는 실시간 웹소켓을 사용한다.
이 방안은 그룹 크기가 작을 때는 효과적이다. 그룹 크기가 더 커지면 이런 식으로 접속상태 변화를 알려서는 비용이나 시간이 많이 들게 되므로 좋지 않다.
이런 성능 문제를 해소하는 한 가지 방법은 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로 하도록 유도하는 것이다.
DB 선정
앞의 내용이 채팅 어플리케이션의 전체적인 구조 설계에 대한 내용이었다면, 다음은 데이터들을 담는 데 어떤 db를 선정해야 하는 지에 대한 얘기다.
RDB vs NoSQL
사실 이 얘기 또한 자세히 다룰 필요가 있기 때문에 후에 다음 게시글에서 서술하도록 했다. (NoSQL)
일단 RDB는 많은 사람들이 잘 알고 있듯이 table 간의 관계가 핵심인 db이다. data간의 관계가 복잡할 때 쓰기 적절한 db이고, 당연히 data의 양이 많아지고 index가 증가할수록 성능은 낮아지게 된다.
RDB의 강점은 정규화를 통해 data를 관리하는 것인데, 사실 채팅 메시지의 경우는 다른 table과 Join할 일이 거의 없다. 누가, 어느 채팅방에, 언제, 어떤 데이터를 보냈는지만 안다면 크게 추가할 데이터가 없기 때문이다.
이런 이유로 채팅 메시지 data는 NoSQL에 저장하는 것이 더 낫다. NoSQL의 경우 data들이 "key : value" 형태로 저장되어 있기 때문에 빠르게 찾고 읽어올 수 있다는 장점이 있다. 또한 data간의 관계를 고려하지 않기 때문에 scale out이 편하다는 부분도 중요하다.
한 가지 추가적으로 고려해야 될 점은 채팅 data 특성 상 최근 data들을 우선적으로 읽어오기 때문에 이를 빠르게 읽어올 수 있도록 세팅해야 한다는 점이다.
NoSQL DB
- key
- scale 하기가 편함
- read latency가 낮음
- key를 만들 때 range scan하기 쉽게 디자인 해야함
- 최근에 보낸 메시지일수록 key 값이 높게
- created_at을 사용하여 메시지 순서를 정할 수는 없는데, 서로 다른 두 메시지가 동시에 만들어질 수도 있기 때문. 문제는 NoSQL은 auto_increment 기능을 보통 제공하지 않음 (자세한 방법은 후에 다른 게시글을 통해 서술)
참고: 카카오톡 시스템 디자인
참고 서적: 가상 면접 사례로 배우는 대규모 시스템 설계 기초
