📝 프로젝트 정보

프로젝트 주제 : shoe-auction

최근 패선엽계에서 한정판 스니커즈 리셀(resell · 재판매)이 화두로 떠오르고 있는 점을 고려하여 판매자와 구매자 사이에서 중개자 역할을 통해 가품 판매 방지와 사기 방지를 지원하는 중개 거래 플랫폼

공통 사항

커밋 컨벤션 통일

✅ 기본적으로 커밋 메시지는 제목 / 본문 / 관련이슈로 구분한다.
✅ feat : 새로운 기능 추가
✅ fix : 버그 수정
✅ docs : 문서 수정
✅ style : 코드 포맷팅, 세미콜론 누락, 코브 변경이 없는 경우
✅ refactor : 코드 리펙토링
✅ test : 테스트코드, 리펙토링 테스트 코드 추가
✅ chore : 기타 변경사항
✅ 제목은 50자를 넘기지 않고, 맞침표를 붙이지 않는다.
✅ 영어로 작성할시 과거시제를 사용하지 않고 명령어로 작성하며, 첫 글자는 대문자를 사용한다.
✅ 선택사항 이므로 모든 커밋에 본문내용을 작성할 필요는 없다.
✅ 본문은 "어떻게" 보다 "무엇을" 과 "왜"를 설명한다.
✅ 한줄에 최대 72자를 넘기지 않고 제목과 구분되기 위해 한칸 띄워 작성한다.
✅ 선택사항 이므로 모든 커밋에 꼬리말을 작성할 필요는 없다.
✅ 이슈번호를 적는다. 여러개 적어도 상관 없다.

프로젝트 컨벤션

• PR을 통한 merge : 리뷰어가 모두 approve 해야 merge 가능하도록 제한

• Google checkStyle 적용

---

Git-Flow 브랜치 전략

✅ master : 베포 단계에 출시될 수 있는 브랜치
✅ develop : 개발이 끝난 버전을 개발하는 브랜치
✅ feature : 기능을 개발하는 브랜치
✅ release : 베포 버전을 준비하는 브랜치
✅ hotfix : 베포 버전에서 발생한 버그를 수정 하는 브랜치
✅ issue/* : issue를 나누어서 개발에 적용하는 브랜치

Reference : 우아한 형제들 기술블로그 : Git-flow

---

Shoe-auction 서버 구조

1. Redis Server

성능 테스트 결과 Cache의 적용 여부에 따라 엄청난 성능 차이를 보이는 것을 확인할 수 있었습니다. 따라서 Redis 서버를 각 기능별로 분리시켜 효율적인 메모리 관리를 통해 캐시 저장소의 가용성을 잘 유지해야 합니다. 이번 프로젝트에서는 총 3개의 기능별로 레디스 서버를 분리시켰습니다.

✅ FCM 토큰 저장소 : [Compact] 1vCPU, 2GB Mem, 50GB Disk

✅ Login Session 저장소 : [Compact] 1vCPU, 2GB Mem, 50GB Disk

✅ 캐시 데이터 저장소 : [Compact] 1vCPU, 2GB Mem, 50GB Disk

2. WAS

로그인 테스트에서 3000명의 가상 사용자 접속 시 불완전한 성능지표를 보였습니다. 따라서 기존에 WAS 1대만 이용하던 방식에서 웹서버 nginx와 WAS1대를 추가로 띄어서 로드밸런싱을 통한 부하 분산이 가능하도록 서버 구성을 변경하였습니다.

✅ WAS 1 : [Compact] 1vCPU, 2GB Mem, 50GB Disk

✅ WAS 2 : [Compact] 1vCPU, 2GB Mem, 50GB Disk

✅ nginx : [Compact] 1vCPU, 2GB Mem, 50GB Disk

3. MySQL

성능 테스트 이전에 DB에서 발생하는 병목현상을 개선하고자 사전에 Master/Slave 구조의 Replication을 구성했었습니다. 일단 Slave서버는 1개만 구성하였고, Master 서버와 Slave 서버 모두 동일한 스펙의 서버를 사용했습니다.

✅ MySQL Master : [Compact] 1vCPU, 2GB Mem, 50GB Disk

✅ MySQL Slave : [Compact] 1vCPU, 2GB Mem, 50GB Disk

4. Jenkins

처음 Jenkins 서버를 띄었을 때는 NCP에서 1년간 무료로 사용할 수 있는 micro 서버를 사용했었습니다. git push 또는 pull request가 발생 할 때마다 자동 테스트와 빌드가 진행되도록 설정했었는데, 테스트가 진행될 때마다 20분에서 최대 1시간까지 걸리고 심할 경우 Timeout으로 인해 빌드가 실패하는 문제가 생겼습니다. 따라서 Jenkins 서버의 스펙은 다른 서버들보다 조금 더 높은 사양을 선택했습니다.

✅ Jenkins : [Standard] 2vCPU , 4GB Mem, 50GB Disk

5. AWS S3 & Lambda

프로젝트에 사용되는 이미지를 저장하기 위해 AWS S3와, 이미지 리사이징을 위해 AWS Lambda를 선택했습니다. 해당 프로젝트에서 이미지를 업로드할 수 있는 사용자는 관리자 뿐이기 때문에 사용량이 그리 높지 않을 것이라고 판단했습니다. 추후 커뮤니티성 게시판을 추가 구현한다면 해당 서버 스펙도 Sacle -UP을 진행할 예정입니다.

✅ AWS S3 & Lambda : AWS 프리 티어 (이미지 저장 기본 50GB, Lambda 월별 무료요청 100만)

6. ngrinder

최대한 정확한 테스트 결과 지표를 얻기 위해 Controller와 Agent, 그리고 테스트 Target이 되는 Server를 모두 각각 띄어서 성능 테스트를 진행하였습니다.

Controller의 명령을 받아 Agent에서 실제 부하를 발생시키기 때문에 Agent의 서버 스펙을 가장 높게 구성하였습니다.

✅ Controller server : [Standard] 2vCPU, 4GB Mem, 50GB Disk

✅ Agent server : [Standard] 4vCPU, 8GB Mem, 50GB Disk