12. Chat System Design
채팅 시스템 디자인
요구사항 분석
기능적 요구사항
1:1 채팅: 두 명의 사용자가 실시간으로 메시지를 주고받을 수 있어야 합니다.
그룹 채팅: 여러 사용자가 동시에 참여할 수 있는 채팅방을 지원해야 합니다.
메시지 저장: 모든 메시지를 영구적으로 저장하고, 필요 시 검색할 수 있어야 합니다.
푸시 알림: 새로운 메시지가 도착했을 때 사용자에게 알림을 보내야 합니다.
비기능적 요구사항
확장성: 시스템은 수백만 명의 동시 접속자를 처리할 수 있도록 확장 가능해야 합니다.
지연 시간 최소화: 실시간 채팅에서 지연 시간은 최소화되어야 합니다.
가용성: 시스템은 24시간 내내 중단 없이 운영될 수 있어야 합니다.
데이터 일관성: 메시지가 중복되거나 손실되지 않도록 보장해야 합니다.
2단계: 개략적 설계안 제시 및 동의 구하기
클라이언트와 서버의 통신 방법
폴링
폴링은 클라이언트가 일정한 간격으로 서버에 새로운 메시지가 있는지 확인하는 방법입니다. 클라이언트는 주기적으로 서버에 요청을 보내고, 서버는 새로운 데이터가 있을 경우 이를 응답합니다.
장점: 구현이 간단하며, 서버의 복잡도를 낮출 수 있습니다.
단점: 주기적인 요청으로 인해 서버와 네트워크 자원이 낭비될 수 있습니다. 실시간성이 떨어질 수 있습니다.
롱 폴링
롱 폴링은 폴링의 단점을 보완하기 위해 고안된 방식으로, 클라이언트가 서버에 요청을 보낸 후, 서버가 새로운 데이터가 생길 때까지 연결을 유지합니다. 새로운 데이터가 생기면 서버는 클라이언트에 응답을 보내고, 클라이언트는 다시 서버에 요청을 보냅니다.
장점: 실시간성을 개선할 수 있으며, 폴링보다 자원 낭비가 적습니다.
단점: 서버는 많은 연결을 관리해야 하므로, 서버의 부하가 증가할 수 있습니다.
웹소켓
웹소켓은 클라이언트와 서버 간의 양방향 통신을 가능하게 하는 프로토콜입니다. 초기 연결 이후 클라이언트와 서버 간의 지속적인 연결을 유지하며, 데이터를 실시간으로 주고받을 수 있습니다.
장점: 진정한 실시간 통신이 가능하며, 클라이언트와 서버 간의 데이터 전송이 매우 효율적입니다.
단점: 초기 설정이 복잡하며, 서버 자원의 효율적인 관리가 필요합니다.
데이터 저장 방식 제안
메시지와 사용자 데이터를 관리하기 위해 데이터베이스 설계를 해야합니다. 대규모 채팅 시스템에서는 NoSQL 데이터베이스가 적합할 수 있으며, 높은 가용성과 확장성을 달성할 수 있습니다.
메시지 테이블: 각 메시지의 ID, 송신자 ID, 수신자 ID, 메시지 내용, 타임스탬프 등을 저장합니다.
채팅방 테이블: 채팅방의 ID, 참여자 목록, 생성 시간 등을 저장합니다.
사용자 테이블: 사용자 정보, 상태, 프로필 등을 저장합니다.
시스템 확장성 고려
로드 밸런싱: 로드 밸런서를 통해 각 서버에 균등한 부하를 분배할 수 있으며, 특정 서버에 장애가 발생해도 로드 밸런서가 이를 감지하고 나머지 서버로 트래픽을 자동으로 분산시킴으로써 시스템의 가용성을 유지할 수 있습니다.
데이터 분산: 분산 데이터베이스를 사용하면 데이터를 여러 노드에 나누어 저장하고, 데이터 접근 시 전체 시스템의 부하를 줄일 수 있습니다.
세션 관리: 세션 스티키니스(Session Stickiness)**나 세션 공유(Session Sharing) 기법을 사용
3단계: 상세 설계
메시지 흐름
1:1 채팅 메시지 처리 흐름
사용자 A가 채팅 서버 1로 메세지 전송
채팅서버는 ID 생성기를 사용해 해당 메시지 ID 종류 결정
채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
메시지가 키-값 저장소에 보관(target userId : messageId)
targetUserId를 확인하여 접속중이면 다음 채팅 서버로 전송, 아니면 푸시 알림 서버로 전달'
채팅 서버에서 사용자 B에게 메시지 전달
여러 단말 사이의 메시지 동기화
하나의 사용자가 두개의 단말기를 사용하는 예시입니다.
cur_max_message_id를 통해 최신 메시지를 추적합니다.
키:값 저장소에 보관된 메세지들을 확인하여 cur_max_message_id보다 큰 값들을 전송한다.
소규모 그룹 채팅에서의 메시지 흐름
사용자 B, C는 각각 메시지 동기화 큐를 가지고 있습니다.
사용자가 많지 않으면 사용자 A의 메시지를 각 큐에 넣으면 됩니다.
접속상태 표시
온라인: 웹소켓 연결이 맺어지고 나면, 접속상태 서버는 키:값 저장소에 정보를 보관합니다.
오프라인: 일정 시간동안 클라이언트의 요청이나 응답이 없으면 사용자를 오프라인 상태로 업데이트 합니다
접속 장애시: HeartBeat 검사를 통해 주기적으로 이벤트를 서버에 보내도록하여 판별합니다.
상태 정보를 전송할떄는 Pub, Sub Event를 사용합니다. A-B, A-C 형태를 사용하여, A의 상태가 변경되면 이벤트를 발행합니다. 하지만 해당 방법은 사용자가 적을때 효과적이지만, 사용자가 많으면 비용과 시간이 많이 들게 됩니다.
이를 해결하기 위해서는 manual 업데이트를 유도하거나, 중요한 이벤트(그룹 채팅 입장) 같은 순간에 상태 정보를 업데이트 하는 방식을 사용합니다.
4단계: 마무리
추가적으로 고려할 수 있는 부분들은 다양한 데이터, 암호화, 캐시, 로딩 속도 개선, 오류 처리 등이 있습니다.
다양한 데이터: 미디어를 지원하도록 하고, 그에 따른 압축 방식, 클라우드 저장소와 썸네일 생성 방법 논의
암호화: 제3자가 메시지를 볼 수 없도록 처리
캐시: 데이터베이스와 통신 횟수를 줄이기 위해 최신 메시지들만 캐싱하여 유지할 수 있습니다.
로딩 속도 개선: CDN을 사용하여 지리적으로 데이터/채널을 분산하여 빠르게 get 할 수 있도록 합니다.
오류 처리: 서버의 Failover처리와 SPOF를 해결할 수 있습니다. 메시지를 안정적으로 전송하기 위해 재시도 로직이나 메시징 큐의 로그파일을 유지할 수 있습니다.
Last updated
