프론트엔드 4명이 만드는 채팅 웹사이트(+ AWS) 1부

코드잇 부트캠프의 마지막 프로젝트를 남겨두고, 마지막 파트 팀배정을 기다리며 미니 프로젝트에 회원관리 및 게시물관리 등의 간단한 백엔드 기능을 구현할 예정이였다. 그리고 팀배정이 완 먽료되었는데 과반수가 위워크에 자주 보이던 멤버였으며 다른 팀에 가도 그 팀을 리딩할 능력이 있는 구성원들이 모여있는 듯 했다. 조심스럽게 마지막 프로젝트를 백엔드 인원없이 진행해보는 게 어떻냐는 의견을 냈고 다들 긍정적으로 생각했다.(타 팀들은 백엔드 2명이 팀에 합류함)
백엔드 인원없이 진행하는 것은 확정이 됬고, 1주일동안 관련 기술에 대해서 학습해본 이후 개인적인 역할에 대한 이야기를 하기로 했다.

 

2명은 회원가입 및 로그인, 1명(나)은 채팅, 1명은 WebRTC기반의 음성/화상 채팅을 구현해보기로 했다.

 

1주일 간 AWS의 여러 기능 및 아키텍쳐에 대해 고민해봤다.

 

초기 아키텍쳐

 

모놀리릭 vs 마이크로서비스

어떤 DB를 선택할 것인가

 

이 두가지를 가장 고민했던거 같다.

 

 

 

MSA방식의 서버구조

모놀리릭은 하나의 서버에 모든 서비스들이 통합되어 있는 형태

MSA는 서비스(도메인) 별로 분리되어 있는 서버가 분리되어 있는 형태로 이상적인 MSA구조는 DB까지 분리되어 있는 구조로 서버간 데이터 전달방식 등 여러가지 고려해야할 것들이 많다.

 

우리가 만들려는 서비스는 실시간 소켓통신 기능이 필수적이다. 그래서 소켓통신을 처리하는 서버와 http메서드를 사용하는 서버를 구분하고 그 중에서도 회원가입, 로그인 등 유저정보를 관리하는 서버와 채팅방 등 채팅관련 데이터를 관리하는 서버를 나눌수 있을 것이라고 판단했다.

프로젝트의 목적이 여러가지를 시도해보자는 이유도 있었기 때문에 MSA구조로 프로젝트를 진행하기로 했다.

 

DB선택

팀원 모두가 sql 지식도 없고 사용한 db라곤 실습때 배운 mongoDB밖에 없는 상황에서 어떤 DB를 어떻게 사용할지에 대한 고민을 많이 했다.

첫 결정은 유저정보와 채팅 메시지를 제외한 채팅정보(서버, 채팅방 등)를 하나의 mysql db에 저장하고,

이전 채팅 메시지 정보는 nosql기반인 aws의 dynamodb를 사용하기로 했다.

(추가)이후 채팅서버에서 유저서버를 통해 유저정보를 가져오는 방법을 사용하기로 결정(처음에는 이상해 보였음)하고

유저서버와 유저DB 채팅서버와 채팅DB로 DB까지 분리하기로 결정했다.

 

그리고 이번 프로젝트에서는 prisma ORM을 사용하기로 했다. 백엔드, DB, AWS가 모두 처음인 상황에서 절대적인 시간이 부족할거 같다는 판단이였다. 그래서 sql을 직접 사용하는 것 대신에 prisma를 선택하기로 했다.