야놀자 테크스쿨 파이널 프로젝트 - 채팅 도메인 설계(안 읽은 메시지 수, 채팅방 삭제, 채팅 메시지 내역)

 

파이널 프로젝트 야나바다 프로젝트를 시작하게 되면서, 프론트엔드와 백엔드 각각 각자의 파트를 나누기 시작했다. 프론트엔드는 페이지 화면을 중심으로 파트를 나눠 각자 마크업 단계를 시작했다.

 

우리 백엔드에서는 도메인 단위로 각자 파트를 나눴다.

그중 난 채팅 도메인을 맡게 되었다. 우리팀은 RDS만을 사용하기로 했고, DB로는 MySQL을 사용하기로 하였다.

 

초기 채팅 도메인 ERD 설계

 

초기 채팅 도메인의 ERD를 설계했다. 가장 필수적인 요소만을 넣어서 틀을 작성했다.

 

 

완성된 채팅 도메인 ERD 설계

 

각 화면구성을 보고 정책을 세운 뒤 확정된 채팅 도메인 ERD 설계이다. 

정책을 바꾸어 더 여러가지 기능을 넣는다면, 바꾸고 싶은 요소들이 많지만, 현재까지 정해진 사항에 맞게 최적화된 ERD 설계라고 생각한다.

 

그전까진 프로젝트를 하면서 구현에만 초점을 맞췄다면, 미니프로젝트와 파이널 프로젝트를 하면서, 서버 인프라 담당도 되면서 개발하는데에 있어 관점과 마인드 바뀌어 이걸 기록하고 싶어 이렇게 글을 작성한다.

서버 담당자가 되면서 AWS 서비스들을 이용하니, 서버비용이 부가되는 걸 보고 있자하니 로직을 짜면서도 그냥 구현하는게 아니라 경제적인 측면을 고려하게 됐다.

시간복잡도가 더 낮은 로직, DB I/O를 줄이는 방법, 서버에 부하를 줄이는 방법 등 이런 것들 고민하면서 로직을 한줄한줄 작성하게 됐다. 이러니 일반적인 쉬운 로직도 고민해봐야할 사항이 많아져서 쉽게 결정내리기 못하였다.

하지만, 더욱 성능이 뛰어나고 탄탄한 개발을 한다는 생각이 드니 보람차고 나름 자부심도 느껴졌다.  

그러면 큰 채팅도메인을 어떻게 설계하고 로직을 생각했는지 공유하겠다.

 

초기 설계

먼저 PM분들이 만들어주신 피그마의 와이터 프레임을 보고 크게 필요한 API 갯수를 생각했다. 확정까진 아니더라도 최대한으로 내가 만들어야할 API를 생각하고 채팅도메인 담당 프론트엔드 분께 이렇게 이렇게 API를 호출하시면 DTO에 데이터를 이렇게 담아서 보내줄 것이니, 렌더링시에 화면에 이렇게 뿌리시면 될것 같다고, 큰 그림으로 설명해준다. 이때 SSR 프로젝트를 하면서 프론트엔드 지식이 조금이나마 있던게 도움이 됐다. 

 

 

 

 

 

API는 크게  채팅방 생성, 채팅방 조회, 채팅방 상세조회, 채팅방 수정, 채팅방 삭제 정도로 크게 5가지로 계획됐다.

 

 

채팅방 생성 POST /v1/chats

먼저 채팅방 생성이다. 가격제안이 가능한 상품 내에서 가격제안을 누르면 채팅이 시작될 수 있어야 했다.

 

그래서 가격제안하기 버튼을 누르면 채팅방 생성 API를 호출하도록 하였다.

 

이때 주의해야한다고 생각한 점은 가격제안하기를 눌러서 채팅방이 생성됐는데, 또 다시 상품 상세의 가격제안하기를 눌러 채팅방이 이중으로 생기지 않게 해야한다고 생각했다.

그래서 상품의 id, 구매자 id, 판매자 id 3가지로 채팅방이 있는지 찾아, 있으면 그 채팅방 코드를 바로 클라이언트로 보내주고, 없다면 새로운 채팅방을 만들어서 DB에 넣고, 그 채팅방을 클라이언트에 보내주게 했다.

이때 예외처리로는 자신의 상품의 자신이 네고할 순 없으므로 구매자와 판매자 id가 같다면 예외처리해주고, 네고 불가능 제품이거나, 상품의 상태가 판매중이 아닐 경우 예외처리 해주었다.

 

 

채팅방 조회 GET /v1/chats

 

채팅방 조회시 채팅방의 요약 정보와 안읽은 메시지 수를 Pageable 을 사용하여 클라이언트한테 주었다.

이때 정렬순서는 각 채팅방의 마지막 메세지 내림차순 즉, 최신순이다.

 

이 화면에선 어떻게 안 읽은 메시지 수를 카운트 하는지가 핵심이었다.

두가지 방법이 떠올랐다.

 

1. 채팅 메시지 엔티티에 readCount라는 필드를 두어 기본으로 2를 갖게 하고 읽을때마다 1씩 차감시켜주는 방식
2. 채팅 메시지마다 전송시간을 갖고, 채팅방 엔티티에 판매자 또는 구매자 마지막 채팅방 확인 시간을 가져, 마지막 확인 시간 이후론 온 메시지를 카운트 하는 방식.

1번 같은 경우 메시지가 매우 적은 상황에선 크게 문제없겠지만 많은 사용자가 많은 메시지를 주고 받는다는 가정했을 때 좋지 않은 설계 같다. 읽을때 마다 채팅을 읽었음을 표시하고 1씩 감소시키는 요청을 보내야하는 단점이 있다고 생각했다. 메시지 하나 마다 DB I/O를 해서 필드를 감소시켜줘야하므로 DB 에도 많은 무리를 주는 행위라고 생각한다. 또 이후에 말하겠지만 채팅을 웹소켓을 연결하여 실시간 통신을 하는데, 읽음 숫자 감소시키기 위한 HTTP 요청을 또 보내는게 웹소켓을 쓰는 의미를 퇴색시킨다고 생각했다.

 

2번 같은 경우 매번 읽었다고 숫자를 감소시키는 요청을 보내지 않아도 되고, 안 읽은 메시지 수를 카운트 하기 위해서 반복문을 타야하는 건 똑같으므로 2번이 훨씬 경제적이라 생각했다. 

단점으로는 뒤로가기 버튼 즉 채팅방에서 벗어날때 마지막 채팅방 확인시간을 수정하는데, 기기를 두개 켜두고 한쪽 방엔 채팅을 실시간으로 읽으면서 있지만, 다른 기기에서 채팅방 목록을 조회하면 아직 마지막 확인 시간이 갱신되지 않았기 때문에 읽은 메시지가 안읽은 메시지 수로 카운트 될 수 있다는 점이다.

 

각각의 트레이드오프를 파악했고, 후자가 좀더 경제적이라 생각해서 후자의 방식으로 로직을 짰다.

 

 

채팅방이 채팅메시지를 리스트로 갖고 있는데, 처음엔 OrederBy 로 전송시간 오름차순으로 갖고 있었다.

안 읽은 메시지 수를 카운트 해야하는데, 스트림은 정방향 순회 밖에 안되므로 for문을 써서 가장 최신 메시지부터 즉 리스트의 끝부터 차례대로 앞으로 순회하며 isAfter() 함수를 써서 마지막 확인 시간과 메시지 전송시간을 비교하여 안 읽은 메시지 수 카운트를 늘렸다.

하지만 그럴 필요 없이, 채팅방 상세조회시에도 가장 최근 메시지부터 줘야되고, 적은 양의 채팅메시지에선 OrederBy 의 오름차순과 내림차순 정렬의 리소스 소모가 다르지 않기 때문에 전송날짜를 기준으로 최신순, 즉 내림차순으로 바꾸고, 안 읽은 메시지 수 카운트도 스트림을 써서 정방향 순회를 하였다. 마지막 채팅 내용의 경우 리스트의 첫번째(0번째) 값을 보내주었다.

 

채팅방 상세조회 GET /v1/chats/{chatRoomCode}

 

 

채팅방 상세조회는 채팅방 코드를 PathVariable 로 받아 조회할 수 있도록 하였다.

기존엔 모든 걸 id로 조회하였지만, 프라이빗한 정보이기도 하고, 실무에서도 고유한 코드로 정보를 주고 받는 걸 알기에 생성시간과 UUID 를 커스텀하여 채팅방 코드를 만들었다.

채팅방 내에 위에 상품 정보는 프론트에게 상품 상세정보 API 호출해서 정보를 가져오게 하고, 채팅내역만 DTO에 넣어서 보내주었다. 이때 메시지의 내림차순으로 리스트를 갖고 있기에 size는 프론트와 협의 후 20으로 설정했고, 0번째부터 20개 단위로 끊어서 Pageable을 이용하여 보내주고, 프론트에선 화면에 아래에서 부터 데이터가 올라가는 형식으로 만들어 달라고 하였다.

특히 리액트에서 map을 돌릴때 key를 보고 렌더링을 하는데, 고유한 키를 갖을 수 있도록 전송시간을 밀리초 단위까지 보내주어 에러 없이 렌더링할 수 있도록 하였다. 

또한 프론트 측에서 로그인한 사람의 id를 알고있으므로 senderId를 주어 같으면 오른쪽으로 정렬 다르면 상대방이기때문에 왼쪽 정렬해달라 하였다.

실시간으로 채팅을 보내고 받는 경우는 다음 블로그 글에서 더욱 자세하게 다루겠다.

 

채팅방 수정 PUT /v1/chats

 

안 읽은 메시지 수를 카운트 하기 위해서 채팅방 마지막 확인 시간을 사용하기로 하였다. 이때 마지막 확인시간을 수정해주는 걸 이 뒤로가기 버튼을 누를때 수정하기로 설계했다. 저 버튼 외에 다른 페이지로 갈 수 있는 방법도 없었고, 리퀘스트로 채팅방 코드만을 받았다. Spring Security의 Principal로 로그인한 사람의 memberId를 가져와서 채팅방의 구매자인지 판매자인지 비교하여 구매자면 구매자 마지막확인시간을 수정하고 판매자면 판매자 마지막 판매시간을 수정해주었다.

 

 

채팅방 삭제 DELETE /v1/chats

 

 

 

채팅방 나가기를 하면 일단 판매자인 경우 구매자가 채팅방을 나갔는지 확인하고 안 나갔다면 판매자의 필드값만 true로 수정해주었다.

이유는 판매자가 채팅방 나가기로 채팅방을 삭제 했더라도 구매자가 삭제하지 않았으면 구매자는 채팅방 내용을 확인할 수 있어야하기 때문에 soft delete 해줘야기 때문이다. 

상대방도 삭제 여부를 확인하여, 상대방도 삭제했다면 hard delete를 하여 데이터베이스 공간을 확보하고, 그렇지 않다면 soft delete 한다. 따라서 HTTP Method 경우도 POST에 더 가까울 수도 있다. 실무에서도 거의 모든 메소드를 POST를 쓴다고 하지만, 지금 나는 배우는 입장이기때문에 정석에 더 가깝게 클라이언트 측에서 리소스를 어떻게할 건지 알기 쉽게 DELETE를 사용하였다.

 

채팅방 삭제여부가 TRUE가 됐다면 채팅방 목록 조회시에도 보이지 않는다. 

 

 

🤔 더 개선해볼만한 점

지금 프로젝트에선 RDS만을 사용하기로 하였다. 하지만 프로젝트가 대규모 트래필을 감당하기 위해 MSA로 전환 된다면 채팅서버를 따로 두게 될텐데, 채팅 메시지 경우 NoSQL 을 비정형 데이터로서 관리하는 게 더 확장성에 용이할 것 같다. 관리자 메시지나 상품 카드도 채팅으로 보여준다고 한다면, 지금의 설계대로라면 senderId에 값을 넣기 애매해진다.

 

 

네비바의 채팅에 보이는 안 읽은 채팅 갯수는 채팅방 목록에서 안읽은 채팅 메시지 수의 합산의 값이다.

우리는 알림으로 FCM을 사용하기로 하였고, 채팅시에도 알림으로 FCM 푸시알림을 보내기로 하였다. 따라서 FCM 서버에서 클라이언트에 응답이 오면 그때 새로운 이벤트가 일어났기에 안 읽은 메시지 수를 카운트할 수 있는 API를 호출하여 정보를 리프레쉬 해주기로 설계했다. 그러면 서버에 무분별하게 계속 요청을 보낼일도 없고, SSE 같은 서버에서 이벤트가 일어날때 보내줄 필요도 없으니 서버 부하도 덜어내 가장 이상적인 방법이라 생각했다.

하지만 프로젝트 내 FCM 알림 서비스가 사용자의 선택에 의해 ON/OFF 할 수 있게 되어 OFF로 했을시 채팅 보냈을 때 실시간으로 알려줄 수 있는 방법이 사라져 버렸다.

이때는 안 읽은 메시지 수 리프레쉬는 풀링을 사용하여 2초 간격으로 서버에 요청을 보내기로 하였다.

 

한 도메인을 구현해야겠다는 관점보다 비지니스적인 관점으로 바라보며, 사용자가 이탈하지 않게 그리고 사용자가 서비스를 이용하면서 일으킬 돌발상황들을 여러 케이스로 쪼개가며 설계를 하고 로직을 짜니 취준생 개발자가 아니라 정말 실무에서 일하는 개발자 같은 느낌이 들었다. 물론 실무에선 더욱 빡빡한 케이스와 여러 기상천외한 예외상황이 많을테지만, 이런 마음가짐과 시야로 서비스를 바라보면 잘 해결할 수 있을 거라는 자신감도 들기도 했다.

다음엔 실시간 채팅에 대해 자세히 정리할 것이다.(가장 애로사항이 많았던....ㅜㅜ)