Introduce

---

친구를 통해 냅다 사이드 프로젝트 서버 개발 파트로 납치당했다.

프로젝트를 시작하며, 초기에 대략적으로 어떤 형태로 서비스를 운영할 서버의 구조를 잡았는지, 부족하지만 한번 선보여보도록(?) 하겠다. 당연히 최종 구조는 아니며, 최종 구조는 기회가 된다면 프로젝트 회고를 통해 얘기해보도록 할 예정이다.

너 납치된거야. -내친구가 한말임

대략적으로 정리해보는 요구사항

---

본 어플은 C2C(Customer to Customer)기반 중고 물품 대여 서비스이다. 사용자들은 중고거래 물품 올리듯이 게시물을 올려, 사용자간의 대여 일정을 잡고 주변인들 간의 물품 대여를 진행한다.

MVP 기능

• 회원 기능
  • 로그인(일반/카카오)
  • 개인정보수정
  • 지역등록
  • 거래기록 확인
• 물품대여
  • 물품 CRUD 기능
  • 리뷰
• DM
  • 물품거래 대여 진행을 위한 1:1 DM 기능
  • 대여일정 확정

위의 내용은 간단하게 정리해본 1차로 구현할 어플의 MVP 기능들이다. 이렇게 크게 3파트로 나뉘며, 1차 개발이 완료되면 서비스 시작과 함께 추가 기능 개발에 들어갈 것 같다.

프로젝트 구조

---

위와같이 서버의 구조를 잡아보았다.

API Server

대부분의 REST API는 이 API Server에 구현한다. 회원관리, 게시물 관리 등 채팅내역을 제외한 대부분의 데이터는 API Server를 통해 MySQL 에 저장하여 관리할 예정이다.

사용 스택

• Language: Java 17
• Framework: SpringBoot 3.3.3
• Database: MySQL
• Cache: Redis
• Publish: AWS EC2 Docker
• Storage: Amazon S3
• Messaging: Firebase FCM

Redis와 FCM은 제대로 사용해본 적이 없기에 개발을 진행하면서 추가 구조를 잡아갈 계획이다. FCM의 경우 추후 확장할 때, 별도의 Push Server를 구현할 생각이다.

Chat Server

Chat기능은 실시간성이 중요하고, 해당 기능에 사용자들의 트래픽이 많이 몰릴 것으로 예상이 되기 때문에, 별도의 서버를 분리하기로 결정한다. 따라서 다음과 같이 구성한다.

사용 스택

• Language: Java 17
• Framework: SpringBoot Webflux
• Database: MongoDB
• Publish: AWS EC2 Docker

Database를 MongoDB를 사용한 이유는, 채팅 내역을 다루기에 RDB보다 NoSQL 구조가 훨씬 편하기 떄문에 MongoDB를 사용했다.

또한 트래픽이 몰릴 서버이기 때문에 처리가 늦어지면 곤란하여, 채팅에 들어가는 image 파일들도, API Server 를 통해 Amazon S3에 업로드하여 링크를 받아온 후, 해당 링크를 MongoDB 에 저장하는 방식으로 운용할 예정이다.

현재는 아직 서비스를 시행하지 않는 초기 개발 단계이기 때문에, 개발서버와 운영서버를 따로 분리하지 않고, 추후 서비스를 배포할 때, 서버들을 개발서버와 운영 서버, 데이터베이스 또한 개발DB와 운영용DB로 분리하여 운용할 예정이다.