[Spring boot, JPA] Spring으로 타임딜 서버 구축하기 in Numble

 넘블에서 진행하는 타임딜서비스 만들기 프로젝트의 과정을 서술해보자 한다. 

우선 해당 프로젝트의 조건에 대해 명시해보자.

자세한 설명은 Numble에서 참고 바랍니다.

 

프로젝트 목표

• 동시성 처리 능력
• CI/CD 구성의 이유와 그 방법
• 프로젝트의 첫 시작부터 성능테스트까지의 경험
• 성능을 개선할 수 있는 포인트를 스스로 파악하는 프로파일링
• 와이어프레임을 직접 그려보며 화면에 대한 고민을 해보고 그에 따른 API 제작해보며 서비스단에 대한 이해도 증가 및 디자이너 소통력 증가 

 

구체적인 챌린지 내용

개발할 부분에 대해 스스로 와이어프레임을 그려보는 경험을 합니다.

예시 화면

구현 범위

• 지정된 시간에만 상품 구매가 가능하게 함
• 상품에는 재고수량이 있어 모두 판매되면 더이상 구매할 수 없어야 함
• 상품을 구매한 사람 수과 상품의 재고수량이 일치해야 함
• 장바구니 담기 및 결제하기 같은 구매하기 뒷단의 로직은 생략하고 오직 구매하기 API 를 호출했을 때 구매하기 성공 / 실패로 구분

구현 기능

• 회원 : 가입/탈퇴/조회 기능
• 상품 : 등록/수정/삭제/목록/상세 기능
• 구매 : 구매하기 기능

구현 조건

• CI / CD 필수
• 성능테스트를 통해 구매하기 API가 TPS가 얼마나 나오는지 체크할 수 있어야 함
• spring boot 버전은 크게 중요하지 않지만 2.x 이상을 사용하기를 권장
• 로그인 관리는 세션으로만 처리 (spring security 나 JWT는 사용안함)
• CI 를 활용하여 브랜치 전략에 따라 작업 브랜치 빌드 및 테스트 (정적분석 등 추가적인 코드 품질 관리 요소가 있다면 더 좋음)
• CD 를 활용하여 base 브랜치에 merge가 되면 자동으로 서버에 배포가 되는 방식
  • 특정 브랜치로 배포를 할수 있는 환경이 구성되어야 함
• 성능테스트를 위해 nGrinder를 설치
  • 만들었던 API의 TPS가 얼마나 나오는지 체크할 수 있어야 함
  • 필요하다면 성능테스트를 위해 작성한 스크립트 또한 git으로 관리
• 어플리케이션의 상태를 점검할 수 있는 APM 툴 도입 필수
  • pinpoint나 scouter를 추천
  • 성능 테스트 시 이를 활용하여 상태를 점검하고 성능 테스트 결과와 함께 리포팅
• 서버는 1대만 구성하는 것으로 정의
  • 여러대의 서버를 구성 할 수 도 있지만 현 챌린지의 규모상 1대로 제한
• ORM은 JPA와 MyBatis 중 사용하기 편한 것으로 선택해서 진행
• 각 도메인(테이블)의 요소(필드) 들은 자유

 

평가 방식