대규모 시스템 설계 기초 책 정리하기 : 12-1 채팅 시스템 설계

읽을때 마다 새로운 지식을 알게되는 책이지만, 다음 챕터로 넘어 갈수록 너무 어려워져서 손이가지 않는 책으로 최대한 많이 이해하고 완독을 목표로 정리를 하기위해서 글을 작성하게 되었다.

처음에는 2부 부터 읽다가 왜 1을 읽지 않느냐는 질문을 받고 1부를 읽게되었고 1부 부터 읽는게 필수라고 할정도로 난이도 차이가 있다.

잘근잘근 씹어먹듯, 많은 지식을 남길 수 있도록 열심히 정리해보자!
가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24

채팅시스템이란

채팅 시스템은 사용자 간에 텍스트·음성·영상 등의 메시지를 실시간으로 주고받을 수 있게 해주는 소프트웨어/서비스를 말합니다. 우리가 흔히 사용하는 카카오톡, 슬랙(Slack), 디스코드, 왓츠앱 등이 대표적인 예시입니다.

어떤 기능이 필요한가

페이스북 메신저와 유사한 채팅앱 설계 기준
세부 항목은 다음과 같다.

응답지연이 낮은 1:1 채팅 기능이 기본적으로 필요합니다. 추가로 최대 100명까지 참여하는 그룹 채팅 기능과 사용자의 접속 상태 표시 기능을 추가합니다. 다양한 단말지원 하나의 계정으로 여러 단말에 동시 접속 가능하게 구현하고 단말마다 푸시 알람을 줘야합니다.

개략적 설계

채팅앱은 Client 별로 직접 통신하지 않고, 채팅 서비스를 구현하여 해당 통신을 구현해야한다.

서비스의 기능 구현

 Client 로 부터 메세지 수신

수신자 결정과 전달 작업을 수행합니다/
다만, 수신자가 offline 일 경우 접속할때까지 해당 메세지를 보관합니다.

해당 로직을 구현하기 위해 다음과 같은 방법을 사용할 수 있습니다.

“클라이언트와 채팅서비스를 HTTP 프로토콜로 연결한다.”

• keep-alive 해더를 사용하면, client 와 서비스 사이를 끊기지 않고 유지할 수 있습니다.
• TCP 접속과정의 hand-shake 횟수를 줄일 수 있습니다.
• 다만 HTTP 는 메세지 전송용도는 괜찮은데, 서버에서 클라이언트로 전송하기 어렵습니다.

구현 기법

서버에서 클라이언트로 전송하기 어려운 부분을 해결하기 위해, 다음과 같은 기법을 사용하고 구현 할 수 있습니다.

 1) 폴링 기법

해당 기법은 클라이언트가 주기적으로 서버에 메세지 여부를 요청하는 방법입니다.
폴링(요청)을 많이할수록 비용이 증가하고(줄인다면 실시간성이 떨어집니다), 메세지가 없는 요청은 무의미한 서버 자원도 낭비될 수 있습니다.

2) 롱 폴링 기법

해당 기법은 클라이언트와 서버의 연결을 지속적으로 유지하는 방법인데, 새 메시지가 반환되거나, 타임아웃이 될때까지 연결을 유지하는 방법입니다.

하지만 해당 방법에서는 서버입장에서는 연결중단을 모를 가능성이 있고, 서버가 여러개로 구성되어있다면, 요청 클라이언트와 수신 클라이언트가 다른서버에 접근할 수 도 있습니다.

결국 메세지를 많이 받지 않는 클라이언트도 타임 아웃이 일어날때 마다 주기적으로 서버에 접속해 있어야 되므로 비효율적인 사용이라고 볼수 있다.

 3) 웹소켓

서버가 클라이언트에게 비동기 메세지를 보낼때 널리 사용하는 기술로 항구적이고 양방향이라고 할 수 있다. 앞에 나온 두가지 방법의 비효율성을 잡는다고 볼 수 있다. 구현도 직관적으로 해당기법을 안쓸 이유가 없다.

설계안

계략적으로 해당 서비스는 총 3가지의 서비스(무상태 서비스, 상태 유지 서비스, 제 3자 서비스)로 구성된다.
각각 정리해보면 다음과 같다.

1) 무상태 서비스

• 로그인, 회원가입, 사용자 정보 등을 처리하는 응답/요청서비스
  2) 상태 유지 서비스
• 채팅 서비스를 지원하며, 여기서는 웹소켓을 이용한다.
  3) 제 3자 서비스
• 푸시 알림을 제공하기 위해 적용

해당 서비스를 기반으로 모식도를 그려보면 다음과 같다.

모식 도 기반으로 조금더 자세히 설명하면

• 채팅서버 : 상태 유지 서비스로 클라이언트 사이에 메세지를 중계하는 역활
• 접속 상태 서버 : 사용자의 접속 여부를 관리
• API 서버 : 무상태 서비스로 로그인, 회원가입 프로파일 변경등 나머지 전부의 일을 한다.
• 알림서버 : 사용자에게 푸시 알람을 보낸다.
• 키값 저장소 : 채팅 이력을 보관한다.

여기서 한 가지 챙겨 가야하는 부분이 있는데 규모를 어느정도로 구성할까 하는 부분이다. 모든 서비스를 하나의 서버에서 구현 할 수 있다. 하지만, 서버 한대로 얼마나 많은 접속을 동시에 허용할 수 있는지와 관련되어서도 확인이 필요하다.
또한 SPOF (single-point-of-failure) 도 또한 문제가 될 수 있다.

저장소

어떤 데이터 베이스를 써야할까 고민을 또 하게된다.
데이터의 유형과 읽기/쓰기 연산의 패턴의 파악이 가장 중요하다.

채팅시스템을 중점적으로 분석해보면
1. 사용자 프로파일, 설정, 친구목록 처럼 일반적인 데이터
-> 안정성을 보장하는 관계형 데이터 베이스에 보관
2. 채팅 이력 정보
-> 데이터 양이 많고, 최근 데이터만 많이 호출한다.
-> 검색이나, 언급메세지, 특정메세지로 점프하거나 무작위적 접근을 하게된다.
이런 기준에서, 여기서는 키/값 저장소를 추천한다. (자세한 부분은 2부에 정리) 비슷한 서비스로는 다음과 같다. 페이스북 메신저 (HBase) / 디스코드 (cassandra)

너무 길어져서 2탄으로 계속…