Polling
- 계속해서 Backend에게 요청을 해서 응답을 받음
Long Polling
- 새로운 메시지가 있는지 계속 서버에게 물어보기
- 메시지가 있거나 / 타임아웃 할 때 까지 리퀘스트 잡고 있기
WebSocket
- WebSocket은 Open Connection을 유지해줘야 되기 때문에 따로 Chat Server를 만들어서 관리
- 일반적인 리퀘스트 (로그인 / 프로필 사진 바꾸기)는 API Server에서 HTTP로 관리
메시지 큐 (Message Queue)란?
- Kafka, RabbitMQ
- 서비스들 간에 데이터를 주고 받는 방법중에 하나
- RestAPI / RPC를 사용 하면 Synchronous 하게 데이터를 주고 받음
-
Publisher는 이벤트를 메시지 큐에 넣는 사람
-
Subscriber은 이 이벤트가 일어나면 나한테 알려줘 라고 메시지 큐한테 Subscriber를 하고 있는 서비스들
-
왜 쓰냐?
- Decoupling
-
RestAPI나 RPC를 이용하면 Synchronous 하게 이용할 수 있는데 그러면 그 모든 Dependency에 관련된 코드를 Service A에 넣어야 함
-> Service A는 복잡해지고 테스트하기 어려워지면 커플링이 많다고 말함
-
이 상황에서 Message Queue를 넣게 되면 dependency가 훨씬 적어짐
-
Service A는 Service B, C, D가 있다는 사실을 모름
-
ex)
Service B -> DB에 이 메시지 저장
Service C -> push notification 보내고
Service D -> 유저한테 메시지를 forward
-> 같은 일을 하는데 Service A가 B, C, D에 대한 dependency가 없어짐
-
1:1 채팅) 유저 A가 유저 B한테 메시지 보내기
1:1 채팅) 유저 A가 유저 C한테 메시지 보내기
데이터베이스는 어떤걸 써야 할까?
- 트래픽 특성
- 엄청난 양의 트래픽 그룹 채팅 - 하루에 600억 메시지
- 오래된 채팅 잘 안봄
- Read / Write ratio 1:1
- 다른 데이터들과 join할 필요가 거의 없음
- Relational Database 같은 경우 데이터가 많아지고 index가 많아지면 느려짐
- Key-Value store
- 스케일 하기가 편함
- Read Latency가 낮음
- Facebook 같은 경우 HBase; 디스코드는 Cassandra를 사용함
- Key를 만들 때 Range Scan 하기 쉽게 디자인 해야함
- 최근에 보낸 메시지 일수록 Key 값이 높게
- Chat같은 경우 우리가 시간 순서대로 chat을 읽어야 하는 경우가 많음
- Key range scan을 했을 때 채팅된 순서대로 메시지가 나올 수 있도록 key를 디자인하는 방식으로 해야함
- 쉽게 하는 방법은 메시지 id가 계속 올라가는 방식
그룹 챗 기능 추가
- 그룹 챗 몇명까지 지원 할거냐가 중요한 쟁점 디자인이 달라질 수 있음
- 그룹 챗 최대 200명까지 지원한다고 가정을 한다면
- 어느정도 Fan out은 괜찮음
Hello World