✏️항해 최종 프로젝트 - Backend

🏠 Home Page / Youtube

• 주변 사람들을 손쉽게 만나고 소통하기 위한, 실시간 위치기반 소모임 플랫폼!

🚩 프로젝트 소개

실시간 위치 기반 소모임 플랫폼!

• 👫 우리동네, 같은 취미를 가진 사람을 만나고 싶으신가요?
• 🗺 사소한 일상에서부터 다양하고 색다른 경험까지 찾을 수 있는 곳!
• 🎮당신과의 만남을 기다리고 있는 이웃을 만나보세요.

🗓 프로젝트 기간

2021년 7월 23일 ~ 2021년 9월 02일

👥 개발 인원

• 이용우 (Node.js) [팀장] @ archepro84
• 이해웅 (Node.js) @ HW3542
• 임관식 (Node.js) @ gwansiklim
• 주재인 (React) @
• 황준연 (React) @
• 김유진 (React) @
• 서정화 (디자이너)
• 정지우 (디자이너)

🛠 기술스텍

Front	Back
React	Node.js
Redux	Express
Axios	MySQL
Redis
Socket.io	Socket.io
카카오맵 API	카카오맵 API

📖 라이브러리

라이브러리	설명
	쿠키 저장
	서버
	세션 관리
	입력데이터 검출
	비밀번호 암호화
	서명 암호화
	Http Log 기록
	캐시 메모리 DB 관리
	위치 정보 관리
	외부 API 요청
	MySQL
	MySQL ORM
	MySQL ORM Console
	Socket 통신
	테스트 코드
	API 문서화
	서버 부하 테스트

📚 프로젝트 아키텍처

🗃 DB ERD

📋 API Document

📂 프로젝트 회의록

🔨 Front-End Git hub

📌 코드 리뷰 및 개선사항

1) Socket GeoRedis 연산 부하 문제

발생한 문제

• 기존에는 MySQL 사용자의 위치 정보를 GeoMetry Point 타입으로 저장하였지만, 서버 부하 테스트를 진행하면서 실시간으로 주변 위치를 가공할 때 많은 부하를 발생하는 것을 확인하였습니다.

개선 방법

• Redis의 GEORADIUSBYMEMBER 함수를 사용할 경우 많은 부하를 들이지 않고 사용자 주변의 정보를 조회할 수 있다는 것을 확인했습니다.
• MySQL에서 사용하고 있던 사용자의 위치 정보를 Redis의 GeoMetry 데이터로 변경하여 사용자의 위치정보 가공속도를 향상 시킬 수 있었습니다.

2) Express API 부하 테스트

발생한 문제

• 현재 서버가 버틸 수 있는 부하량을 확인하여, 적절한 서버의 구성이 필요하다고 생각하였습니다.
• 단순히 부하 테스트를 진행할 때 일일이 사용자가 명령을 보내 테스트하는 것은 비효율적이라 생각하였습니다.

개선 방법

• Artillery 모듈을 이용해 실시간으로 Express.js의 부하 테스트를 진행할 수 있었고, Socket.Io에서 실시간으로 사용자의 위치 정보를 보내는 부하 테스트도 진행 할 수 있었습니다.

3) Socket 부하 테스트

발생한 문제

• 현재 서버가 버틸 수 있는 부하량을 확인하여, 적절한 서버의 구성이 필요하다고 생각하였습니다.
• 실시간으로 사용자의 위치를 입력 및 조회하는 기능의 한도를 확인할 수 있어야 안전한 서버 구현이 가능할 것으로 생각하였습니다.

개선 방법

• Artillery 모듈에서는 Socket.Io-v3의 Header를 지원하지 않아 사용자 인증을 받을 수 없었습니다.
• 차선책으로 자체 제작한 더미 소켓 클라이언트를 생성하여 테스트하였습니다.
• 1,000명의 소켓을 테스트했을 때 EC2: 20%, Redis: 9%의 CPU 할당량을 보였습니다.
• 1,000명의 소켓을 테스트했을 때 Redis의 메모리 할당량이 1%에서 1.6%로 상승하였습니다.

4) 테스트 코드 구성

발생한 문제

• 팀원들이 동시에 코드를 수정하게 될 경우, 변경되는 사항이 일치하지 않아 오류가 발생하였습니다.
• 코드를 수정할 때마다 모든 API의 작동 여부를 일일이 검사하는 것이 비효율적이었습니다.

개선 방법

• Swagger를 이용해 모든 API를 문서화하였고, 테스트할 수 있도록 구현하였습니다.
• Joi Schema부터 모든 API에 이르기까지 Jest를 이용해 테스트 코드를 생성하였습니다.

5) 모노리틱 아키텍처 벗어나기

발생한 문제

• EC2 단일 서버에서 Express.js, MySQL, Redis를 사용하여 많은 부하가 발생하였습니다.
• 부하 테스트를 진행하였을 때 서버가 다운되어 MySQL의 데이터 사라지거나, Redis의 Key 데이터가 초기화되는 등 데이터의 안정성을 보장할 수 없었습니다.

개선 방법

• EC2를 Express 단일 서버로 구성하였고, AWS ElastiCache로 Redis 서버의 데이터를 이관하였고, AWS RDS로 MySQL 5.7 서버의 데이터를 이관하였습니다.
• 단일 서버에서 모든 것을 처리하는 모노리틱 아키텍처에서 모든 서버를 분리하여 관리하는 마이크로 서비스 아키텍처로 변경 하기위해 노력하였습니다.
• 부하 테스트를 진행하였을 때 견딜 수 있는 부하량이 늘어났고, 서버의 안정성을 확보할 수 있었습니다.

6) 서버 모니터링 구성

발생한 문제

• 모니터링을 진행할 때 서버에 접속된 상황에서만 서버의 상태를 조회할 수 있었습니다.
• 부하 테스트를 진행하였을 때 접속 오류가 발생해 실시간으로 서버의 CPU 및 메모리 사용량 조회가 불가능하였습니다.

개선 방법

• 분리되어있는 AWS 서버의 상황을 Cloudatch를 이용하여 별도의 프로젝트를 생성하여 서버 모니터링을 진행하였습니다.
• CPU 또는 Memory 사용량을 위젯으로 설정할 수 있었고, 이외의 AWS 서버의 속성을 실시간으로 모니터링할 수 있었습니다.