[TIL] 2024.04.16 팀프로젝트 중간발표 회고록

1. MVP 중간발표 자료(기입)

프로젝트 정보

서비스명: 응모했슈

서비스 기획 의도: 응모를 진행하는 과정에서 여러 사이트를 하나씩 방문하는 것은 불편하다고 생각하여 이 관점에서 시작했습니다.

프로젝트 한 줄 설명: 신발 응모 정보 및 뉴스 조회 & 개인간 신발 거래 시스템

최종 MVP 스펙: 웹 스크래핑 , 유닛테스트 , rapidAPI , ci/cd , rds, MySQL , AWS EC2 , docker , nest , git action , elastic search

서비스 배포 URL:  http://3.34.188.17:3000

팀 노션 URL:그림자다빈술

2. 기술적 의사결정 & 트러블슈팅 기록

프로젝트를 진행하면서 직면한 문제를 어떤 과정으로 해결 하셨는지, 스택별로 기록 해 주세요

기술적 의사결정을 기본으로, 트러블슈팅도 있다면 기록해둡시다.

기술적 의사 결정

Puppeteer & Axios

도입 이유	웹 스크래핑 소요 시간 단축을 위해 (Puppeteer는 1분 30초 걸리던걸 Axios는 3초만에 끝냄)
문제 상황	Axios만으로는 긁어오지 못하는 CSR환경이 나타남
해결 방안	Puppeteer와 Axios를 같이 쓰면 모두가 행복해짐
의견 조율	Axios를 써서 긁어올 수 있는 SSR 환경은 Axios를쓰고 CSR 환경은 퍼펫티어를 쓰기로 조율함
의견 결정	Axios와  Puppeteer를 혼용하기로 결정

CI/CD

도입 이유	개발 및 배포 프로세스를 자동화하고 효율화하기 위해서 도입
문제 상황	개발환경과 CI/CD환경 간의 설정 및 의존성이 일치하지 않은 경우, 보안관련 CD파이프라인에서 배포단계가 실패할 수 있음(보안취약점)
해결 방안	정확한 빌드를 설정하고, 배포환경 안에서 설정해야 하는 값들을 잘 설정하기
의견 조율	첫 목표의 맞게 개발환경과 실제 배포환경을 조율해서 금액적인 부분을 조율하고, 1차 테스트이후에 성능최적화에 몰두하기로함
의견 결정	많은 tool이 있지만 쉽게 접할 수 있는 Gitaction을 활용했고, 추후에 docker를 활용해서 고도화시킬 예정

AWS Elasticsearch

도입 이유	스크래핑된 데이터를 저장하고, 검색에  특화된 DBMS로 활용 가능
문제 상황	신발 데이터가 17000개 및 스크래핑 되는 데이터가 누적됨에 따라 빠르게 검색하기 위함
해결 방안	Elasticsearch 인덱스를  활용해 접근하면 빠르게 가져올 수 있음
의견 조율	처리할 수 있는 데이터양을늘리면 비용이 비싸짐 elasticsearch 환경 오류가 계속되어 AWS Elasticsearch 활용하기로 함
의견 결정	관리 및 운영 부담이 적은 AWS Elasticsearch 활용해보기로 결정

MySQL

도입 이유	정형화된 데이터를 저장하기 위함
문제 상황	스크래핑 된 데이터를 그대로 보여주면 서버 끄면 없어지는 상황
해결 방안	스크래핑 된 데이터를 저장하고 클라이언트에게 보여주기 위해 도입
의견 조율	각 docker 로컬로 사용하고 발표에 rds로 취합
의견 결정	NoSQL보다 우리 프로젝트에 더 적합하므로 선택함

Docker

도입 이유	MySQL같은 툴을 하나씩 다운받지 않고 이미지로 가상환경에 띄워 사용하기 위함
문제 상황	안쓰면 다 하나씩 다운받고 개인 작업 공간에 영향을 끼침
해결 방안	Docker 컨테이너 및 이미지로 관리함
의견 조율	각 로컬 환경에 Docker설치
의견 결정	개발의 편의성을 위해 도입함

 

중간 발표 이후 기재

3. 중간발표 피드백 기록

월요일에 대면 피드백을 꼼꼼히 기록해두고, 개선이 필요한 사항에 적용해봅시다.

4. 중간 발표 후 회고 (예시)

1) 미구현 된 MVP 기능

AWS Elasticsearch : 연결까지는 되어있으나 인덱스로 검색이 아직 구현이 안됐음

프론트 : 마켓crud , 소셜로그인  , 캘린더 , s3적용시 프로필 이미지 업데이트

2) 추가/개선 할 기능과 그 이유

실시간 채팅 :  판매자와 구매자간의 원활한 거래를 위하여 도입

응모 사이트 실시간 혼잡도 : 유명 브랜드의 신발이 응모 시작 되었을 때 해당 사이트에 대한 다량의 트래픽 발생 시 확인을 미리 할 수 있게 혼잡도를 보여줄 예정 (타 서버에 연결 요청이 가능한지 확인하고 된다면 실행 안된다면 우리 사이트 내에서 혼잡도 체크 = 인기도 체크 // 안되면 실시간 알림으로 응모 떴다!! 할 수 있게 )

Docker 배포 : 개발환경과 운영환경의 상태를 같게 하기 위해 적용 시킬

대용량 트래픽 처리 :  인기많은 신발은 트래픽이 몰릴 수 있음 ⇒ 로드밸런서로 서버 분할 실행

부하테스트 : 우리 서버가 어디까지 버티는지 확인하고 한계점에 도달할 경우를 대비해 테스트 실행

Elastic Search 에 저장이 다 가능한지 ? 이게 안되면 ELK로 넘어가야할지?

캐싱은 적용시킬 범위가 로그인 외에는 딱히 없어보임 그래서 여유되면 하는걸로

https 보안 적용을 시키고 싶은데 프론트를 지금 분리해둬서 웹 호스팅이 필요함 ⇒ 근데 호스팅 걸거면 우리가 서버를 연다? 이게 되는건지

프론트 : cdn ,썸네일 기반 사진 저장 등 여러 방법으로 이미지 로드 빨리 될 수 있게 하기 + 미구현된 프론트 해야함

3) 추가/개선할 기능을 어떻게 구현 할 것인지

실시간 채팅 : socket.io 사용해서 1대1 채팅 구현할 예정

대용량 트래픽 : load balancer 또는 nginx  와 람다 사용해서 서버 실행

Docker 배포 : 테스트만 하면 될듯

부하테스트 : artrillery 사용 할 예정

Elastic Search ? ELK ?

4. 앞으로의 계획 및 우선순위

예시

순위	구분	앞으로의 계획 (구체적으로)	마감예정일자
1	MVP	- Elastic Search 적용 완료 시키기 ( 인덱스로 검색할 수 있게 )
2	MVP	- Docker 배포
3	개선	-프론트는 마지막에 시간 남으면 하겠습니다.
4	추가	- 대용량 트래픽 처리 및 부하 테스트
5	추가	- 실시간 채팅에 활용 할 라이브러리 학습 및 적용하기