12장

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

• 1대1 채팅과 그룹 채팅 모두 지원

• 모바일과 웹 모두 지원

• 트래픽 규모는 DAU 기준 5천만명

• 그룹 채팅의 경우 최대 100명까지 참가

• 중요기능은 1:1 채팅, 그룹 채팅, 사용자 접속상태 표시. 텍스트 메시지만 주고받을 수 있음

• 메시지 길이 제한 100,000자

• 채팅 이력은 영원히 보관

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

• 클라이언트로부터 메시지 수신

• 메시지 수신자 결정 및 전달

• 수신자가 접속 상태가 아닌 경우에 접속할 때까지 해당 메시지 보관

어떻게 메시지를 받아올 것인가?

1. 폴링

   1. 주기적으로 클라이언트가 서버에게 새 메시지가 있냐고 물어보는 방법

   2. 답해줄 메시지가 없는 경우 서버 자원이 불필요하게 낭비됨

2. 롱 풀링

   1. 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지

   2. 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅서버에 접속되지 않을 수 있음

   3. 서버 입장에서 클라이언트가 연결을 해제했는지 아닌지 알 방법이 없음

   4. 여전히 비효율적

3. 웹 소켓

   1. 한 번 맺어진 연결은 영구적이며 양방향

개략적 설계안

세 부분으로 나눌 수 있음

1. 무상태 서비스

   1. 로그인, 회원가입, 사용자 프로필 표시 등을 처리하는 전통적인 요청/응답 서비스

2. 상태유지 서비스

   1. 채팅 서버 + 접속 상태 서버

3. 제3자 서비스 연동

   1. 푸시 알림 서비스(새 메시지를 받았다면 앱이 실행중이지 않더라도 알림을 받아야 해서)

저장소

• NOSQL vs 관계형 DB

  • 데이터의 유형과 읽기/쓰기 연산 패턴이 중요함

  • 채팅 이력

    • 채팅 이력 데이터는 양이 엄청남

    • 읽기:쓰기 비율은 대략 1:1 정도

  • →키-값 저장소가 좋음

    • 수평적 규모 확장이 쉬움

    • 데이터 접근 지연시간이 낮음

    • 관계형 DB는 롱테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있다.

    • 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 채택하고 있음

      • 페이스북 - Hbase, 디스코드 - 카산드라

데이터 모델

• 1:1 채팅

  • message_id, message_from, message_to, content, created_at

• 그룹 채팅

  • channel_id, message_id, message_to, content, create_at

3단계 상세 설계

• 서비스 탐색

  • 클라이언트에게 가장 적합한 채팅 서버 추천

    1. 로그인 시도

    2. 로드밸런서가 로그인 요청을 API 서버로 보냄

    3. API 서버가 서비스 탐색 기능(주키퍼 등)을 이용해 최적의 채팅 서버를 찾음

    4. 채팅 ㅅ서버가 클라이언트와 웹소캣 연결을 맺음

• 메시지 흐름

  • a가 채팅서버 1로 메시지 전송

  • 채팅 서버 1은 ID 생성기를 이용해 해당 메세지의 ID 결정

  • 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송

  • 메시지가 키-값 저장소에 보관됨

  • b가 접속죽인 경우 사용자 b가 접속중인 채팅 서버로 전송. 아니라면 푸시 알림 서버로 보냄

  • 채팅 서버 2는 메시지를 사용자 b에게 전송.

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

  • 각 단말은 cur_max_message_id라는 변수를 유지 (가장 최신 메시지의 ID)

  • 키 값 저장소에 보관된 메시지 중 ID가 cur_max_message_id보다 크면 새 메시지로 간주

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

  • a가 보낸 메시지가 b,c 각각의 메시지 동기화 큐에 쌓인다. (n-1 * n개의 메시지 큐)

    • 위챗이 이러한 접근법 사용중, 많은 사용자를 지원해야 하는 경우라면 똑같은 메시지를 모든 사용자의 큐에 복사하는 게 바람직하지 않을 것이다.

  • 여러 사용자(a,b)가 보낸 메시지가 c의 메시지 동기화 큐에 쌓임(수신자 관점)

• 접속 상태 표시

  • 로그인 - 사용자 A - 접속상태 서버(웹소캣 연결) → 키-값 저장소

  • 로그아웃 - 사용자 A - API 서버 → 접속상태 서버 → 키-값 저장소

  • 접속 장애 - 하트비트 이벤트 사용 - 주기적으로 하트비트 이벤트를 보내게 하고, x 초동안 안오면 로그아웃 처리

• 상태 정보의 전송

  • pub-sub model을 사용 - A-B, A-C, A-D 채널을 둬서 A가 나가면 각 채널로 이벤트가 발행됨

  • 그룹 크기가 커지면 비효율적임. 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속 상태를 갱신하고 싶으면 수동으로 읽게 함

4단계 마무리

• 사진이나 비디오 등의 미디어 지원 방법

  • 압축 방식, 클라우드 저장소, 섬네일 생성 등을 논의해볼만 함

  • 종단 간 암호화 - 발신인과 수신인 이외에는 아무도 메시지 내용을 볼 수 없음

  • 캐시 - 이미 읽은 메시지를 캐시해 둔다

  • 로딩 속도 개선 0 분산 네트워크를 통해 로딩 속도 개선

  • 채팅 서버 오류 - 채팅 서버 하나가 죽으면 클라이언트에게 새로운 서버를 배정해서 다시 접속하도록 해야 함

  • 메시지 재전송 - 메시지의 안정적 재전송을 위해 흔히 사용