Chat System

1. 요구사항

• chat 방식
  • 1:1
  • N:N (group)
• 알림
  • push notification
  • status share
• content
  • text
    • 100,000자
  • video, audio
  • image
• retrieving history
  • chat history
  • 이력은 영구보관
• 인원제한
  • 100 명
• non-functional requirements
  • low latency
  • scale-out for hugh traffic
  • availability

 

2. overall design

 

1) protocols

message 송신 protocol

• HTTP protocol
• HTTP의 keep-alive header 사용
  • client와 server 간 연결을 유지
  • TCP의 handshake 횟수 감소
• HTTP는 stateless라 server가 client에게 비동기로 message를 보내기 어려움

 

message 수신 방식

• polling
  • 주기적인 polling
    • unnecessary traffic 발생
    • latency 발생 (polling interval 즉, resolution 만큼 발생 가능)
• long polling
  • HTTP의 요청에 대해 server는 보낼 message가 생길 때 응답
  • 혹은 timeout 처리
  • 문제
    • Load balancer에 의해 다른 송/수신자가 서로 다른 서버에 연결될 수 있음
• WebSocket
  • 가장 보편적으로 많이 사용하는 방법
  • client가 연결을 맺기를 시작하고 연결은 '항구적'
  • 최초 HTTP 연결이나 이후 WebSocket 연결로 변경
    • 방화벽이 있어도 보통 잘 동작 (HTTP, HTTPS의 port인 80과 443 등을 사용)
  • 항구적 연결에 대한 관리를 server에서 해야 함

 

2) stateless services

• login, 회원가입, 사용자 profile등은 session을 유지할 필요가 없음 (request-reply 방식으로 처리 가능)

3) state oritented services

• 채팅 서비스
• 각 client가 서버와 연결 지속
• service discovery
  • 특정 채팅 서버에 load가 몰리지 않도록 balancing
  • client가 접속한 server의 DNS host name을 client에 알려줌

4) 3rd party services

• push notification
• 앱이 실행중이지 않아도 notification 필요

5) scale-up

• SPOF 대응

6) 저장소

• 안정성이 확보되어야 하는 data는 RDB에 보관
  • replication과 sharding을 통해 availability와 scale-out 확보
• chat history
  • key-value store에 저장
    • low-latency임
  • 대량의 데이터 이기에 scale-out이 용이해야 함
  • e.g.,
    • Facebook messenger는 HBase 사용
    • Discord는 Cassandra 사용

 

 

데이터 모델

 

Kafka, Message Queue 추가

 

 

• Kafka를 통해 service discovery 확보
  • Kafka의 leader follower 구조가 kafka가 관리하는 client인 zookeepr node들을 관리
    • Zookeeper node들은 chat server들이 됨
  • chat, presence server간 decouple을 위해 message queue 사용