[실시간 채팅 서비스#2] 설계

요구 사항

카카오톡 같은 경우 번호나 아이디를 알고 있다면 친구가 아니더라도 1:1 채팅방을 생성할 수 있으며, 요청-승인 과정도 필요하지 않다.
디스코드와 같은 경우 아이디를 알고 있더라도 설정에 따라 친구 요청-승인이 필요하다.
상대적으로 카카오톡은 개방적이고, 디스코드는 보수적인 정책을 띄고 있다고 볼 수 있다.

이런 성격은 단체 채팅방에서도 느낄 수 있다.

카카오톡은 초대자가 주도적으로 채팅방에 초대를 하면, 피대상자는 선택의 여지 없이 채팅방에 입장한다.
디스코드는 초대를 받더라도 피대상자가 승인/거절을 선택할 수 있다.

만약 카카오톡과 같은 개방적인 설계를 한다면 난이도가 쉬워지고 유저 플로우가 간단해 지겠지만, 내 성격 상 디스코드와 같이 피대상자가 주도적인 애플리케이션이 더 마음에 들었기에 위와 같이 요구 사항을 작성했다.

 

ERD

Chat는 실시간 기능의 데이터 엑세스 속도를 위해 Reactive MongoDB를 사용할 예정이며,
나머지 데이터는 보안과 ACID 를 위해 R2DBC MySQL를 사용할 예정이다.

 

기능 마인드맵

 

각각의 마이크로서비스와 기능들을 매핑했다.
초기 설계보다 기능들이 늘어나서 부담 되기는 하는데, 그 만큼 시도해 볼 거리도 늘어났기에 좋은 마음으로 개발할 수 있을 것이다.

 

엔티티 매핑

복수의 테이블에 CRUD가 일어나는 동작이 극히 적어 엔티티 매핑 설계에 필요성을 느끼지 못했다.
추후에 필요성이 느껴진다면 추가할 가능성이 있다.

 

유저 플로우 다이어그램

UserA

UserB

 

상태 다이어그램

 

이번 프로젝트는 인증/인가와 WebSocket 통신으로 인해 상태 다이어그램의 효과가 좋았다.
조금 신나서 그리다보니 과하게 15장 이상의 다이어그램이 나왔는데, 공유할 만한 것만 선별해 본다.

 

WebSocket + Pub/Sub 통신 구조

WebSocket과 PubSub을 사용한 통신 구조를 이해하기 위해 작성한 다이어그램이다.
그림에서는 생략된 부분이 많아 다른 글과 함께 이해하는 것이 좋다.

(시간이 되면 직접 작성하여 업로드할 예정)

 

Client가 WebSocket을 구독하고, 발행하는 과정과 서버가 구현해야 하는 Pub/Sub 로직, STOMP 설정 등을 이해한 뒤,

다음의 다이어그램을 살펴보자.

 

채팅방 입장(HTTP)

채팅방 입장은 HTTP 요청과 WebSocket 구독 두 가지 프로세스가 필요하다.
위 과정을 WebSocket 구독 시에 실행하는 것으로 비용을 감축할 수도 있으나, Connection이 지속된다는 특징으로 인해 보안/트랜잭션/에러 핸들링을 처리하는 것이 까다롭다.

때문에 HTTP 요청으로 Member와 ChatRoom의 중간 테이블인 Participation를 생성하고, 이를 WebSocket 구독 시에 검증하는 방향으로 설계했다.

또한 ChatRoom이 PrivateRoom인 경우 secretKey를 검증하는 로직 또한 위 API가 담당한다.

 

채팅방 입장(WebSocket)

위에서 언급했 듯, HTTP 요청 이후 WebSocket을 통한 Subscirbe 요청 시에 실행되는 로직이다.
Exception을 제외한 분기점으로, ChatRoom을 확인하여 1:1 채팅방인지, 단체 채팅방인지 확인한다.
1:1 채팅방이라면 MemberId만 검증한 뒤 바로 구독을 승인한다.
단체 채팅방이라면 HTTP 요청을 통해 Participation 객체가 생성되어 있는지를 검증한 뒤 구독을 승인한다.

 

유저 플로우 스냅샷

이번 프로젝트에선 유저의 행동에 자유도가 높은 편이라 큰 의미는 없다고 생각했기에 미뤄뒀다.
사실 안만들 생각도 하고 있었는데, 보수적인 정책을 구현하다 보니 필요성이 조금은 느껴졌기에 위와 같이 구현하였다.
전체적인 흐름 보다는 다음의 관계만 이해하면 된다.

• 친구 요청 -> 친구 승인 -> 채팅방 초대
• 채팅방 생성 -> 채팅방 삭제
• 채팅방 입장 or 채팅방 초대 승인 -> 채팅방 퇴장

위 흐름이 절차적으로 이루어진다는 것만 기억하면 개발에 미칠 실수는 없을 것이다.

유저 플로우 다이어그램에선 UserA와 UserB의 플로우를 따로 설계하기에 알기 힘들었던 부분을 동시에 눈에 담는 것과, 어떤 서비스에 요청되며 어떤 저장소에 저장되는지 까지 이해할 수 있다는 점에서 효과적이었다.

 

시스템 아키텍처