실전프로젝트 4주차 회고

2022년 4월 22일 부터 실전 프로젝트를 시작했지만, 바쁘다는 핑계로 조금 늦게적는 4주차 회고

 

5/14 ~ 20

 

MVP 기능을 다 끝내고 5/14 중간발표를 통해 받은 피드백을 기반으로 우리 프로젝트의 부족한 부분을 추가, 보완 하기로 했다. 

 

중간발표 때의 피드백은 다음과 같다.

FE )

1. 기능을 좀 걷어내고, 프론트에서 보여줄 수 있는 새로운 기술을 도입 고려 필요

2. 리엑트 리덕스 악시오스를 사용한 이유

3. 파이어 베이스는 어느 기능을 위해 사용했는지?

BE )

1. 채팅 대화 내용 데이터를 어떻게 처리할 것인지 논의 필요

2. 소켓 사용시 어떻게 무중단 배포를 할 것인가에 대한 고민 필요

 

내가 맡은 부분은 채팅이기에 채팅 대화 내용 데이터를 어떻게 처리할 것인지에 대해 고민해봤다.

 

현재 채팅내역은 모두 Redis에 저장되어 있다. Redis는 Remote Dictionary Server의 약자로서, "key-value" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템이다. 

"key-value" 데이터 베이스이므로 NoSQL이며, In-memory 기반의 데이터 처리 및 저장을 제공하여 속도가 빠르지만 서버가 꺼지면 모든 데이터가 사라진다는 단점이 있다. 이러한 단점을 해결하고자 채팅 내역을 파일로 저장, S3에 업로드 하기로 했다.

 

채팅 메시지는 Redis에 CHAT_MESSAGE 라는 key 안에 roomId, List<ChatMessage> 의 Hash 형태로 저장이 되어있다. 클라이언트가 Message를 보낼 때 Redis에 save를 하고 구독한 클라이언트에게 저장된 메시지를 publish 한다. 기존에는 이 로직이 전부 였지만, 서버가 다운되면 사라지는 채팅 내역을 저장하기 위해 List<ChatMessage>의 크기가 일정 크기 이상일 때 txt 파일로 저장하여 S3에 올리고 S3에 올라간 파일을 RDS로 저장하기로 했다.

 

txt 파일로 저장할 때 RDS에 roomId로 검색하여 마지막 데이터가 있으면 prevId를 마지막 데이터의 id로 설정하고 없다면 0으로 설정하여 db에 저장한다. 이런식으로 저장한 이유는 클라이언트가 이전채팅 내역을 보려고 스크롤을 올릴 때 txt파일을 순차적으로 return 해주기 위함이다.

 

roomId 가 2aeafa58-7cf2-4ffe-a57a-40fff6676b48 인 채팅방에서 스크롤 업을 하면

/chat/message/file/2aeafa58-7cf2-4ffe-a57a-40fff6676b48 를 서버에 요청하고 서버에서는 file_id가 5인 txt 파일을 읽어 채팅 내역과 prevId를 같이 return 해준다.

그후 또다시 스크롤 업을 하면 서버에서 받은 prevId를 넣어 백에 요청한다.

/chat/message/file/2aeafa58-7cf2-4ffe-a57a-40fff6676b48?prevId=3

이렇게 요청이 오면 서버에서는 file_id 가 3인 txt 파일을 읽고 prevId와 같이 return 하는 식으로 파일 저장 문제를 해결하였다. 

 

날짜를 기준으로 Redis에 expire 를 설정하여 txt 파일로 만들 수 도 있었지만, 클라이언트에 동일한 양의 List<ChatMessage>를 넘겨주기 위해 이러한 방식을 선택했다. 물론 더 좋은 방법이 있을 수 있겠지만, 시간이 충분치 않은 상황에서 급하게 마무리 지었다.

 

중간발표 직전에 사용자에게 보여줄 주차를 선택하는 과정에서 db를 쪼개야 하는 상황이 있었다. 기존 db는 주차-팀 Table로 묶여있어 특정 주차를 사용자에게 보여주는 로직을 짜려면 번거롭게 모든 주차를 찾고 display 값을 바꿔줘야 했다.

이러한 불편함을 해결하기 위해 주차 - 팀 Table을 주, 팀 Table로 쪼갰다. 주 Table에서는 display 값을 할당하여 1개의 주만 사용자에게 보여줄 수 있도록 설정이 해 놓았다. 기존 코드들의 대다수를 다시 손 봐야하는 작업이었지만, 초기 설계를 잘못했기 때문에 어쩔수 없이 하나하나 뜯어 고쳤다.

초기 erd를 잘못짜게 되면 얼마나 고생하는지 깨달을 수 있었다. 각 Table들이 맡은 역할이 크면 클 수록 의존도가 높아지게 되고 그렇게 된다면, 추후 유지 보수 할 때 몇배는 고생해야 한다는 것을 몸으로 느낄 수 있었다.