[Dining-together] 회식모아(Dining-together) 회고록

Jifrozen·2021년 12월 17일
4

Dining-together

목록 보기
25/25

회식모아(Dining-together) - msa적용한 spring boot 프로젝트

회사, 학교, 모임 등의 단체에서 진행하는 행사 및 회식에 있어, 예산과 인원에 대비한 효율적인 단체 회식 장소 선정을 위해 단체 사용자의 회식 공고와 외식업체의 견적 및 서비스 입찰로 이루어지는 msa 기반 경매방식의 앱 개발 프로젝트

  • 오픈인프라개발 경진대회 동상
  • 한이음 입선

service mesh

member service

ㅁ 로그인, 로그아웃
JWT 토큰을 발급하여 사용자의 로그인과 로그아웃을 수행합니다.

ㅁ 엔티티 CRUD
가게, 고객, 메뉴 등의 엔티티에 대한 CRUD를 수행합니다.
이미지는 Object Storage에 저장하여 URL을 통해 다운받을수 있도록 합니다.

ㅁ 메일인증
Mailgun을 통해 사용자 인증, 비밀번호 초기화 메일 전송을 수행합니다.

auction service


ㅁ 엔티티 CRUD
경매, 입찰, 낙찰, 리뷰 등의 엔티티에 대한 CRUD를 수행
이미지는 object storage에 저장하여 URL를 통해 다운

ㅁ 권한체크
업체, 소비자 권한체크를 위해 Interceptor, annotation을 이용

ㅁ Scheduling을 통해 실시간 경매 상태 처리
Scheduling을 이용해 경매 마감 시간, 낙찰 예약시간을 바탕으로 경매 상태를 처리한다.

search service


ㅁ 가게와 경매에 대한 키워드 검색.
가게와 경매 등록시 kafka를 통해 정보를 읽어와(consume) elasticsearch에 저장한다.
사용자가 keyword로 검색시 nori로 토큰화 시켜 검색을 실시하고, 정보를 반환한다.
ㅁ Embed kibana 전송
1.사용자로그를 logstash로 전달하고 filter을 통해 로그데이터를 정제한다.
2. 정제한 데이터를 바탕으로 kibana 대시보드를 구성한다.
3. 구성한 dashboard를 embed kibana로 내보낸다.

chat service

ㅁ WebSocket && STOMP
채팅방을 생성한다 – pub/sub 구현을 위한 Topic이 하나 생성된다
채팅방을 입장한다 – Topic을 구독한다
채팅방에서 메시지를 보내고 받는다 – 해당 Topic으로 메시지를 발송하거나(pub) 메시지를 받는다(sub)

ㅁ Redis 발행/구독 모델 구현
ReidsPublisher – 메시지를 작성하면 해당 메시지를 Redis Topic에 발행
RedisSubscriber – Redis에 메시지 발행이 될 때까지 대기 -> 메시지 읽어 처리하는 리스너

config

Config Client는 Spring Cloud Bus 를 통해 서로 연결.
RabbitMQ를 통해 모든 클라이언트로 이벤트를 브로드캐스트 (broadcast) 한다.

  1. Private git repository에 git push를 통해 설정값 갱신

  2. 설정값을 갱신하기 위해서 클라이언트
    의 actuator/busrefresh 엔드 포인트를 호출

  3. RabbitMQ로 연결된 모든 클라이언트에서 설정값이 갱신

로그 분석

  1. Api 호출시 각 Microservice에서 조회, 리뷰, 입찰, 검색에 대한 로그를 발생시킨다.

  2. 발생시킨 로그는 Logback으로 cumtom filter를 거쳐 필요한 로그만 Logstash로 전송한다.

  3. Logstash에 전송된 로그를 정의된 함수를 통해 정제하고, 해당되는 인덱스에 전송한다.

  4. 전송받은 로그를 바탕으로 Kibana 대시보드를 구성한다.

  5. 구성한 dashboard를 Embed Kibana로 내보내어 사용자에게 보여준다.

devops


5가지 절차를 자동화 시켜 CI/CD(지속적 통합/지속적 제공) 구성

  1. Git repository에 code를 commit, push
  2. Jenkins pipeline를 통해 빌드 및 테스트 진행
  3. docker 이미지 만들어 docker Hub 에 push
  4. Shell script를 실행해 도커 배포
  5. 슬랙에 알림

느낀점

지금까지 해 온 프로젝트 중 나에게 가장 뜻깊은 프로젝트였다.
나는 진로에 대한 고민이 많았다. 너무 고민이 많아 1년 휴학도 했다. 개발이 나의 길이 아닌가? 파이썬? 자바? 어떤언어를 공부해야하나? 백엔드 프런트엔드 어떤 직무를 가야하지? 등등 엄청 고민이 많을 시기에 들어간 프로젝트이다.

백엔드 개발자

프로젝트 경험이 많다는 이유로 백엔드 개발자 역할을 맡게 되었고(?) 같은 백엔드 개발자분께서 스프링 부트를 사용하고 싶다는 하셔서 스프링 부트를 사용하게 되었다. 처음하는 프레임워크에다 msa 까지 적용하다 보니 여간 힘든게 아니었다. 또, 처음에 얼마나 열정이 많은지
단순한 CRUD기능부터 검색 채팅 실시간 경매 무중단 배포 로그분석까지 모든 기능을 프로젝트에 담도록 계획을 짰다.( 정말 아무것도 몰라서 할 수 있었던 계획ㅋㅋ) 어쨌든 6개월 개발기간 동안 모두 구현하긴 했다...

나는 로그인, service mesh 구성, 경매 서비스, 채팅, config 서버, devops를 맏아 진행하였다.
msa를 처음 공부할때와 배포를 진행할땐 정말 스트레스........살짝 눈물 흘림
msa에 관련된 정보가 많이 없기 때문에 공식문서를 굉장히 많이 볼 수 밖에 없었고, 이제는 습관이 되었는지 정보를 찾을때 공식문서를 먼저 본다.
ELK같은 경우는 내가 맡지 않고 동료 백엔드 개발자분이 맡아주셨는데 나중에 리팩토링을 진행하면서 혼자 공부해 써보고싶다!

PM

또, 처음으로 PM 팀장 역할을 맡아 프로젝트를 이끌어나갔다.
PM을 처음하기 때문에 팀원들에게 피해를 주면 안되겠다 싶어 굉장히 많은 자료조사를 진행했다. 애자일로 노션을 통해 스프린트를 관리했고 화상 회의는 매주 진행하였다.

pr을 통해 코드리뷰를 지향해 프로젝트를 진행하였다.

또한, 코드 컨벤션과 브랜치 커밋 규칙을 만들어 팀 규칙에 일관성을 만들었다.

최선을 다해 PM역할을 수행했고 팀원들도 좋게 봐주셨는지 PM 백엔드 개발자로 한번 더 프로젝트를 같이 진행하자는 제안도 받았다.

마무리

인생에서 가장 큰 고민이였던 '내가 과연 개발자를 할 수 있을까?'가 이 프로젝트를 계기로 해결되었다.
나는 백엔드 개발자가 하고싶다!
한이음에서 우연하게 만난 팀원분들이였지만 모두 최선을 다해 프로젝트에 임해주셔서 감사했다. 인생 팀플중 가장 완벽한 팀원분들이였다.

0개의 댓글