[GDSC 프로젝트 트랙] 4. 채팅 구현 방식 결정 & API 작성

로그인 API 구현 이후로는 채팅 API를 구현하게 되었다.

우선 실시간 채팅 API를 구현하기 위해 Firestore 에서 제공하는 document 변경 감지 기능을 사용하는 것을 고민해보았다.

https://firebase.google.com/docs/firestore/query-data/listen?hl=ko

Cloud Firestore로 실시간 업데이트 가져오기  |  Firebase

 

채팅방에 해당하는 문서를 만들고, 그 문서 안에서 채팅 내역 데이터가 바뀔때마다 장고에게 알려주면, 장고가 클라이언트에게 알려주는 식으로 구현하면 좋겠다고 생각했었다.

그러나 이 기능만으로는 구현이 안된다는 것을 금방 알아챘다.

실시간으로 장고가 클라이언트에게 알려주기 위해서는 클라이언트와 장고가 계속 연결되어있어야 했기 때문이다.

 

그래서 장고와 클라이언트가 계속 연결되어있을 수 있도록 (즉, 실시간성을 구현할 수 있도록) 하는 방법을 찾아보니 웹소켓을 사용하는 방법을 발견했다.

 

장고에서는 이를 Django-Channels 라는 라이브러리를 통해 구현할 수 있었다.

https://channels.readthedocs.io/en/latest/

Django Channels — Channels 4.0.0 documentation

 

공식문서를 보면서 차근차근 따라가다보니 어느덧 혼자서 실시간으로 메세지를 주고받는데 성공했다.

채팅방 하나에 멤버가 한명만 있을 때, 멤버가 메세지를 보내는 요청을 보낼 때마다 실시간으로 메세지 도착에 대한 응답이 왔다.

 

그런데 그 다음부터가 문제였다.

채팅방 하나에 여러 멤버를 두고, 여러 멤버 사이에도 실시간성을 구현하려고 하니 Djagno Channels 말로는 '레이어' 를 쌓는 방식을 사용해야 한다고 한다.

 

여기까지는 아무래도 괜찮아서 구현을 하려고 했더니, Django-Channels 가 이 레이어 정보를 저장할 일종의 DB를 필요로 하였고, 그 DB는 Redis 를 사용한다는 것을 알게 되었다.

 

그런데 여기에서 문제가 발생했다.

Redis를 도커를 통해 실행해야 했는데, 도커의 메모리 사용량이 최소 2GB 라는 것을 공식문서에서 확인하였다.

하지만 내가 사용하는 서버는 프리티어 서버라 메모리가 1기가 밖에 없어서 도커를 돌릴 수 없는 서버였다.

그래서 이 방식은 서버 성능 부족으로 구현이 불가능하다고 판단했다.

---

 

그래서 다음으로 생각한 방식은 기존 HTTP 를 이용한 Polling 방식의 채팅이었다.

Polling 방식은 클라이언트가 주기적으로 서버에 채팅 메세지에 변화가 있는지 체크하는 요청을 보내고, 서버는 그 요청에 대해 매번 채팅 메세지 변화 여부를 응답하는 방식이다.

 

클라이언트가 서버에 짧은 주기로 요청을 보낼수록 실시간성은 높아지지만, 그 만큼 서버에는 부하가 가는 것이 이 방식의 단점이었지만, 현재 사용가능한 서버 성능에서는 이 방식이 최선이라고 생각해서 이 방식을 이용한 API를 구현하기로 했다.

 

 

그렇게 설계한 API는 위와 같다.

채팅방을 생성하는 API, 클라이언트가 서버에 주기적으로 요청을 보내면서 채팅방의 메세지를 가져올 API

채팅방을 삭제하는 API, 채팅방에 메세지를 보내는 API 를 작성하였다.

채팅방의 설정 (알림 설정 등) 을 변경하는 API 는 일단 명세만 해두고 구현은 하지 않았다.

 

---

그리고 채팅을 테스트하다보니 매번 로그인 하는 것이 번거로워서 로그인 여부를 체크하면서 현재 로그인한 유저의 정보를 가져오는 authentication.py 의 내용을 로그인 여부와 관련없이 임의 유저 정보를 매번 반환하도록 임시로 수정하고 테스트 했다.

 

또한, firestore 데이터베이스와 소통하는 일종의 manager 역할을 하는 클래스의 기능을 테스트 하기 위해 python manage.py shell 을 이용하는 것이 번거로워서 (드디어) 테스트 케이스를 작성하기 시작했다.

 

 

이런 느낌으로 작성하기 시작했다.

이제 서버를 실행시킬 때는 python manage.py test 의 결과로 에러가 없을 때만 실행하면 된다.

 

---

다음 글에서는 프로젝트가 수정되었을 때 자동으로 배포하는 CI/CD 구축 과정과 (진짜) 장고 서버 배포에 대한 내용을 정리하고자 한다.