Nomik94 / LounGe

---

소모임 커뮤니티 with 캘린더

같은 취미를 가진 사람을 찾고 싶으신가요?
저희는 새로운 사람을 만나는 것을 즐기고 일정을 공유하여 건강한 만남을 가지는 커뮤니티를 지향합니다.

멤버

이름	역할	깃허브
김정민	팀장	Nomik94
오길환	부팀장	5kiran
한주호	팀원	Joto-Han
김택환	팀원	taekhwankim21
유진우	팀원	goodjwyoo77

팀 노션 주소

LounGe

프로젝트 기간

2023.02.27 ~ 2023.04.03

---

📚 Tech Stack 📚

🛠 Tools 🛠

주요 기능

⭐️ 그룹 창설 및 가입으로 소규모 커뮤니티 서비스 제공

• tag 검색을 통해 원하는 성격의 그룹 조회 기능 제공
• 뉴스피드 작성을 통한 커뮤니티 활성화
• 추후 업데이트를 통해 다양한 편의성 기능 제공 예정

⭐️ 캘린더를 통한 일정 관리 기능

• fullcalendar 라이브러리를 이용하여 캘린더 기능 제공
• 그룹 일정 공유 기능 제공
• 추후 업데이트를 통해 다양한 편의성 기능 제공 예정

MVP 시연 영상

서비스 아키텍처

ERD

기술적 의사결정

📝 JavaScript VS TypeScript

JavaScript

• 장점
  • 간단하고 빠르게 개발을 할 수 있음
• 단점
  • 타입관리가 어려우므로 오류가 발생하기 쉽다
  • 디버깅에 많은 시간을 투자해야 한다

TypeScript

• 장점
  • JavaScript의 모든 기능을 사용할 수 있음
  • 강타입의 언어로 컴파일 단계에서 타입에러를 발견할 수 있다
• 단점
  • JavaScript에 비해 개발 속도가 느리다

의견 조율

• TypeScript는 JavaScript의 모든 기능을 사용할 수 있다
• TypeScript가 JavaScript보다 개발 속도가 느리긴 하지만 디버깅에 투자하는 시간을 줄일 수 있다
• 강타입 언어를 사용함으로써 코드의 안정성을 높일 수 있다

의견 결정

• 강타입 언어인 TypeScript를 사용

📝 Express.js VS Nest.js

Express.js

• 장점
  • 경량화 되어있어 개발을 빠르게 할 수 있다
  • 자유도가 높다
  • 커뮤니티 활성화가 잘 되어있어 접근성이 좋다
• 단점
  • 자유롭기 때문에 구조적인 문제가 발생할 수 있다
  • 개발자가 많은 부분에서 수동으로 처리해야 하기 때문에 코드 유지보수에 많은 비용이 든다

Nest.js

• 장점
  • TypeScript를 언어로 채택하고 있다
  • DI, IoC, Module을 통한 구조화 등의 기술을 통해 생산적인 개발이 용이하다
• 단점
  • Express.js보다 학습곡선이 높다
  • Express.js보다 상대적으로 무거운 구조를 가지고 있다

의견 조율

• Express.js는 개발을 빠르게 할 수 있다는 장점이 있다
• Nest.js는 개발 속도가 비교적 느리지만 협업 시 효율적인 개발이 가능하다
• DI, IOC 등 생산적인 개발이 용이하다
• Nest.js는 TypeScript를 언어로 채택하고 있기 때문에 TypeScript를 사용하기로 한 이상 Nest.js가 개발하기 더 편할 것이다

의견 결정

• Express.js보다 Nest.js가 우리 프로젝트에 적합하다고 판단하여 Nest.js로 결정

📝 Redis 도입 여부

Redis

• 장점
  • 조회 속도가 빨라짐
  • DB 과부화 방지(캐쉬)
  • 유효기간을 설정할 수 있음
• 단점
  • 메모리 관리를 잘 해주어야 한다
  • 인 메모리 방식이기 때문에 장애 발생 시 데이터 유실이 발생할 수 있다

의견 조율

• Redis를 통해 refreshToken을 저장하게 되면 유효기간을 설정해 줄 수 있으므로 주기적으로 삭제를 해줘야 하는 번거로움을 없앨 수 있다
• 일회성 데이터, 잦은 호출이 되는 데이터 등은 Redis를 사용하는 것이 효율적이다

의견 결정

• 데이터베이스 과부화 상황을 피하기 위해 Redis 사용

📝 ElasticSearch VS MySQL

ElasticSearch

• 장점
  • 데이터를 여러 노드에 분산하여 저장하고 있기 때문에 병렬 처리로 대용량 데이터에서 빠르게 검색할 수 있다
• 단점
  • 대용량 데이터 검색에 특화되어있기 때문에 단일 노드 성능은 MySQL 보다 좋지 않다
  • 실시간 처리가 불가능하다
  • 접근성이 좋지 않다

MySQL

• 장점
  • 데이터가 적을 경우 단일 성능이 좋기 때문에 검색 속도가 빠르다
  • 접근성이 좋다
• 단점
  • 와일드카드(%,_)를 사용하여 검색했을 경우 인덱스를 사용할 수 없다
  • 분산 검색 및 병렬 처리를 지원하지 않기 때문에 대용량 데이터 처리에는 부적합하다

의견 조율

• 대용량 데이터를 처리하는 경우 ElasticSearch 성능이 더 좋다
• ElasticSearch가 전문적인 검색 기능을 더 많이 지원한다

의견 결정

• ElasticSearch 사용

트러블슈팅

🎯 특정 API 속도 저하 이슈

• 문제 상황
  • 캘린더 조회 시 여러 그룹의 정보들을 조회해야 하기 때문에 트래픽에 따라 속도가 느려지는 문제가 생김
• 해결 방법
  • Redis를 이용하여 조건에 충족된 그룹들에 한해서 모든 일정을 캐싱 처리하여 DB와 서버의 통신 횟수를 줄여 개선

🎯 OverFetching에 의한 속도 저하 이슈

• 문제 상황
  • 데이터 조회 시 불필요한 데이터도 가져와서 조회 기능의 경우 트래픽 발생 시 속도가 느려지는 문제가 생김
• 해결 방법
  • 기존의 find에서 select를 변경하여 가져올 수 있었지만 typeORM의 find 메서드보다 조금 더 세밀하게 쿼리를 조정할 수 있다고 생각되어서 QueryBuilder를 사용하여 select 해야 할 컬럼들을 정의함으로써 필요하지 않은 컬럼의 데이터를 조회하지 않게 되어 성능 개선

🎯 사용자 피드백에서 전문일치 검색 요구

• 문제 상황
  • MySQL은 전문일치 검색 시 인덱스를 사용할 수 없기 때문에 속도가 느려지는 문제가 생김
• 해결 방법
  • ElasticSearch는 전문 검색도 가능하며 별도의 인덱싱된 문서에서 빠른 검색이 가능하기 때문에 ElasticSearch를 사용하여 성능 개선

성능 개선 그래프

• OverFetching 에 의한 속도 저하 이슈에 대해
  • 댓글 조회 약 42% 성능 개선
  • 그룹 조회 약 14% 성능 개선
  • 뉴스피드 조회 약 32% 성능 개선
• 특정 API 속도 저하 이슈에 대해
  • 캘린더 조회 약 91% 성능 개선
• 사용자 피드백에서 전문일치 검색 요구 이슈에 대해
  • 그룹 검색 약 51% 성능 개선
  • 뉴스피드 검색 약 34% 성능 개선