12장 - 채팅 시스템 설계 (2) - 접속 상태

[이전글]
12장 - 채팅 시스템 설계 (1) - 메세지 흐름

접속 상태 표시

사용자 로그인

• 클라이언트와 채팅 서버 간에 web-socket 연결이 맺어지면, last_active_at 이라는 타임스탬프 값을 키-값 저장소에 저장하여 접속상태를 확인한다
• 위 절차가 끝나면 해당 사용자는 접속 중인 것으로 표시된다
  

  

로그아웃

• 사용자는 API 서버로 로그아웃 요청을 보내고, API 서버는 접송상태 서버에 접속 상태 변경을 요청한다
  

  

접속 장애

• WebSocket 과 같은 지속적인 연결을 맺고 있음에도, 일시적인 접속 장애는 늘 발생할 수 있다
  • 예를들면 데이터가 터지지 않는 터널을 지날때, 접속 상태가 offline으로 변해야 하는가?
• 위와 같은 일시적인 접속 장애를 유연하게 대처하기 위해 심장박동(heartbeat) 모델을 사용한다
• 예를들면 client는 10초에 한번씩 서버에 심장박동을 전송하고, 서버는 client로부터 30초간 (약 3번의 임계치) 심장박동이 오지 않을 경우, offline 상태로 바꾸는 것이다

상태 정보의 전송

• 소규모 채팅의 경우 각 사용자 간에 MQ를 두고 본인이 속한 MQ를 구독하는 모델을 사용한다
• 그룹 채팅 참여자의 수가 커질수록 N개 만큼의 MQ의 규모가 커지므로, 효율적이지 못하다
• 따라서 대규모 채팅의 경우 채팅방에 입장하는 순간에 한번 상태 정보를 갱신하거나, 상태 정보를 본인이 원할 때 수동으로 갱신하도록 유도할 수 있다

더 나아가 고민해봐야 할 내용들

• 채팅 앱에서 사진, 오디오와 같은 미디어(Media)를 지원하는 방법
  • 이미지, 썸네일, 비디오 제공
  • 압축방식, Cloud 저장소
• 종단 간 암호화
  • 메세지의 발신인과 수신인 이외에는 메세지를 볼 수 없도록 암호화 한다
• 캐시(Cache)
  • Client에 이미 읽은 메세지를 캐시해놓으면 client<->server 사이에 주고 받는 데이터 양을 크게 줄일 수 있다
• 로딩 속도 개선
  • 사용자 데이터를 지역적으로 분산시켜 물리적 거리로 인한 지연 시간을 최소화 한다
• 오류 처리
  • 채팅 서버 오류
    • 수십만의 유저가 동시에 채팅 서버에 접속해 있는 경우, 해당 서버가 죽으면 Zookeeper가 새로운 서버로 채팅 서버를 배정할 수 있도록 한다
  • 메세지 재전송
    • retry , MQ 등을 통해 메세지 전송 안정성을 확보한다