본문 바로가기
프로젝트/FitTrip

[FitTrip] 캡스톤 프로젝트 진행 2024.03 ~ 2024.06 회고

by 진꿈청 2024. 6. 23.

대략 3 ~ 4개월동안 진행했던 캡스톤 프로젝트의 마무리 단계에 들어왔다.

 

시작하기에 앞서..

3 ~ 4개월간 캡스톤 프로젝트, 정보처리기사 필기/실기, 학교 수업 등등 바쁜 시간을 보낸 것 같다.

(물론, 이것이 블로그 포스팅 작업이 뜸해진 이유이지만, 어떻게서든 할라면 할 수 있었기에 변명이 될 수도 있다.)

 

 

FitTrip 프로젝트란?

FitTrip은 많은 사용자들이 사용하는 디스코드에서 운동이라는 컨셉을 적용한 온라인 커뮤니티라고 생각하면 된다.

백엔드 서비스는 총 6가지로 구성되어 있다.

  • 커뮤니티 서비스
  • 알림 서비스
  • 채팅 서비스
  • 상태관리 서비스
  • 유저 서비스
  • 시그널링 서비스

이 밖의 MSA를 위한 연동 서비스는 2가지가 존재한다.

  • 서비스 디스커버리(Spring Cloud Eureka)
  • API GATEWAY(Spring Cloud Gateway)

나는 여기서 커뮤니티 서비스, MSA 연동 서비스(Netflix Eureka Server/Client, Spring Cloud Gateway),

도커 활용 컨테이너 관리, 로깅 시스템, CI/CD(Github Actions)를 맡았다.

 

 

전체 아키텍처

전체 아키텍처

FitTrip 프로젝트는 MSA로 설계를 하였다. 프로젝트 시작전부터 MSA를 접하고 공부를 했었는데,

이게 캡스톤 프로젝트까지 이어지게 될지는 몰랐다.

 

이 글을 읽으시는 분은 학부생이 굳이 MSA?라고 생각하실 수 있다. 실제로, MSA는 큰 대규모 서비스에 어울리는 아키텍처니까.

하지만, 다른 팀원분들은 모르겠으나 나는 인프라에 관심이 많기 때문에 단순히 MSA가 인기가 많아서 하고 싶어서 한건 아니다.

정말 지적 호기심으로 MSA를 해보고 싶었다. 또한, 당시 도커 공부를 했었기에 도커를 여러 방면으로 잘 활용하고 싶어 흥미가 더 생겼다.

 

그렇게 시작한 MSA 형식의 FitTrip 프로젝트는

나에게 네트워크, 도커 네트워크, Spring Cloud, Kafka, 여러 트러블 등 수많은 정보를 안겨주었다.

 

정리하자면, 이번 프로젝트로 MSA를 잘 안다고 하기엔 MSA는 너무 방대했지만, 그 여정을 걸으며 보다 더 얻은 것 같다.

 

Git Repository 주소

 

 

사용한 기술스택

 

거창하게 기술스택이라고 했지만, 내가 나열할 기술들을 전부 완벽하게 안다고는 말할 수 없다.

하지만, 최대한 이해해가며 프로젝트에 적용했다.

 

 

Spring Framework

  • Springboot
  • Spring Data JPA
  • Spring Netflix Eureka Server
  • Spring Netflix Eureak Client
  • Spring Cloud Gateway
  • Spring OpenFeign
  • Spring Kafka

DB

  • H2
  • MariaDB
  • Redis

Infra

  • Kafka
  • Docker
  • Docker-Compose
  • NGINX
  • Grafana
  • Loki

CI/CD

  • Git
  • Github Actions
  • GCE

Object Storage

  • Amazon S3

커뮤니티 서비스 API 명세서

 

API 명세서 깃허브 주소

 

 

회고

나름 최대한 깃허브를 잘 활용하려 노력했으며, 그라운드 룰, 나 소개서, 스프린트/스크럼 회의

협업과 관련해서도 많은 경험을 한 프로젝트가 된 것 같다.

 

 

Spring Cloud를 처음 사용해본 프로젝트이기에 여러 네트워크 에러, 설정 오류를 접했다.

또한, Kafka를 직접 서비스와 엮어서 사용해본 것은 이번이 처음이기에 새로웠고 재밌었다.

 

 

프론트 분들이 실시간으로 백엔드 서비스의 로그를 모니터링 할 수 있도록 그라파나 & 로키를 설정한 것도 잘한 것 같다.

 

 

아쉬운 점이 있다면,

Spring Cloud Config Server을 이용하지 못한 것.

테스트 코드를 작성하지 못한 것.

 

위 두 가지가 가장 아쉬운 것 같다. 물론, 테스트 코드는 리팩토링과 함께 작성해볼 것이다.

 

마무리 하며

 

당분간은 이 프로젝트 카테고리에서 FitTrip 프로젝트와 관련된 트러블 슈팅과 프로젝트 설계에 관해 포스팅할 것 같다.

본인의 트러블 슈팅이 옳지 않을 수는 있지만, 본인은 해당 방식으로 해결했다.

 

트러블 슈팅 내용과 관련해서는 기본적으로는 프로젝트 진행간 작성했던 깃 이슈를 기준으로 포스팅할 것이다.

만약, 추가해야될 내용이 있거나 추가적으로 공부한 것은 좀 더 자세히 설명하며 올릴 계획이다.