채팅 애플리케이션 ‐ 채팅 플랫폼에 대한 시스템 디자인 설계 - dnwls16071/Backend_Summary GitHub Wiki

📚 채팅 애플리케이션을 개발하기 위해 필요한 내용을 공부

클라이언트들로부터 메시지를 수신
메시지 수신자 결정 및 전달
수신자가 접속 상태가 아닌 경우 접속할 때까지 해당 메시지를 보관

메시지 송신 클라이언트 - 채팅 서비스(메시지 저장/전달) - 메시지 수신 클라이언트

프로토콜(Protocol)

송신 클라이언트가 채팅 서비스에 메시지를 보낼 때는 HTTP 프로토콜을 사용한다.
송신 클라이언트는 HTTP 프로토콜을 이용해 수신 클라이언트에게 보낼 메시지를 정한다. 이 때, keep-alive 헤더를 사용하면 TCP HandShake 횟수를 줄이 수 있다.
HTTP는 클라이언트가 연결을 만드는 프로토콜이며, 서버에서 수신 클라이언트에 임의의 시점에 메시지를 보낼 때는 사용이 어렵기 때문에 WebSocket을 많이 사용한다.

Polling ❌

폴링 방식은 수신 클라이언트가 서버에게 주기적으로 새로운 메시지가 있는지 물어보는 방법이다. 실제 주고 받는 글이 없음에도 불구하고 클라이언트에서 주기적으로 요청을 보내기 때문에 서버 자원이 불필요하게 낭비될 수 있다.

Long Polling ❌

롱 폴링 방식은 새로운 메시지가 반환되거나 타임아웃이 될 때까지 연결을 유지한다. 클라이언트가 새로운 메시지를 받게 되면 기존 연결을 종료하고 서버에 새로운 요청을 보내 모든 절차를 다시 시작한다.
폴링 방식과 비교하면 불필요한 요청 횟수가 줄지만 여전히 메시지를 받지 않는 클라이언트도 타임아웃이 발생하면 주기적으로 서버에 다시 접속은 해야 한다.

WebSocket ✅

웹 소켓은 서버가 클라이언트에게 비동기 메시지를 보낼 때 사용되는 기술이다.
웹 소켓 연결은 클라이언트로부터 시작한다. 첫 연결은 HTTP HandShake를 이용하개 되고 이후에는 서버가 클라이언트에게 비동기적으로 메시지를 전송한다. 웹 소켓은 방화벽이 있는 환경에서도 잘 동작한다.
HTTP 프로토콜과 다른 점은 양방향 통신이 가능하다는 점이다.

클라이언트로부터의 HTTP 요청이 들어오면 HTTP 요청을 유연하게 처리할 수 있는 로드밸런서가 받아 처리를 하는 방식이다.
ALB/ELB로 적용하면 되겠지만 Nginx로도 충분히 가능하지 않을까 생각한다. 그래서 이번에 채팅 프로그램 토이 프로젝트를 개발하면서 이전에 공부했었던 Nginx 로드밸런싱 처리를 적용해보려고 한다.

채팅 서버는 클라이언트 사이(송신 클라이언트 - 수신 클라이언트)에서 메시지를 중계하는 역할을 담당한다.
접속 상태 서버는 사용자 접속 여부를 관리하게 된다.
API 서버는 로그인, 회원가입, 프로필 변경 등 채팅과 다른 성격의 서비스를 처리한다.
알림 서버에서 푸시 알림을 보낸다.
키-값 저장소에 채팅 이력을 보관한다.

저장소(Storage)

SQL, NoSQL 중 하나를 선택하기 위해 고려해야 하는 점은 데이터의 유형과 읽기/쓰기 연산의 패턴에 따라 정해진다.
채팅 시스템이 다루는 데이터는 크게 두 가지로 나뉜다.
- 일반적인 데이터(Ex. 사용자 프로필, 친구 목록, 기타 설정 값)
- 채팅 특화 데이터(Ex. 채팅 이력 데이터)
읽기/쓰기 연산 패턴
- 채팅 앱에서 빈번하게 사용되는 데이터는 최근 메시지이다. 오래된 메시지는 들여다 보지 않는 경우가 많다.
이번 채팅 애플리케이션 개발 시 NoSQL을 사용하기로 결정
- 키-값 저장소는 수평적 규모 확장이 쉽다.
- 키-값 저장소는 O(1) 시간 복잡도를 가지기에 데이터 접근 지연시간이 낮다고 생각한다.

데이터 모델링(Data Modeling)

아직 어렵다...