기획 및 서비스 아키텍처 설명

프로젝트명 : AirDnS 스터디 룸에 대한 대여 중계 서비스 플랫폼

등록자가 스터디 룸을 등록하고 이를 사용자가 대여할 수 있도록 중계합니다. 등록자는 정해진 규칙에 따라 스터디 룸을 웹에 등록할 수 있고 사용자가 이를 검색해 원하는 방을 예약할 수 있도록 합니다. 사용자는 예약 시스템 내에서 결제가 가능하고 후기를 남길 수 있습니다.

아키텍처 - jdk 17 spring boot 3.2.1

• swagger springdoc 2.2.9
• QueryDsl 5.0.0
• oauth2 redis, mysql

git action, DockerHub, docker, EC2, S3, SQS

토스 페이 API

vue3

MVP 주요 작업물 (서비스의 핵심이 되는 기능)

• 방 등록 및 조회 기능
  • 권한은 host와 user로 나뉘어 있고, user에서 업자로 등록할 경우 host로 승격됩니다. 방 조회는 누구나 확인 가능하고 예약에 관련된 기능은 user만 확인할 수 있습니다. host일 경우 방 등록 버튼이 활성화 되고 해당 기능을 통해 방을 등록할 수 있습니다.
• 예약 시스템
  • 방 상세정보를 통해 예약이 가능합니다. 예약 실행 시 토스 페이 API를 통해 결제를 체험해볼 수 있으며 결제 성공시 예약 정보를 마이페이지를 통해 확인하는 기능이 있습니다.

기술적 의사결정

• CI/CD 선택과정
  • 다양한 기술적 탐구를 위해 Jenkins vs. Git Action 선택과정
  • Jenkins 도입에 대한 이유가 합리적이지 않았음. (해보고 싶음, 사람들이 많이 사용)
  • Jenkins가 Git Action에 비해 장점이 뚜렷하지 않음. (초기 세팅 난이도가 높음, 주변에서 많이 사용하지 않아 도움받기 어려움, 무거움, git action에 비해 불편한 UI/UX)
  • Git Action을 통해 배포하기로 결정

• soft delete 도입
  • 등록업자가 방을 삭제하게되면, 예약 조회에서 해당 방에 대한 정보를 확인할 수가 없음.
    • soft delete 도입을 통해 이를 방어하고자 함.
    • soft delete로 발생하는 문제
      1. 삭제된 데이터에 대한 관리 삭제된 데이터는 사용하지 않는데 DB 성능에 영향을 줌 -> 아카이빙처리 해야함. (고도화 작업으로..)
      2. 작업량 증가 삭제하면 되던 작업을 연관관계에 따라 처리해줘야함 -> 아카이빙 처리 시 같이 작업하기로 함
  • 도입 방안
    • is_deleted, deleted_at 컬럼을 추가함
    1. @SQLDelete 를 통해 jparepository.delete 메소드 사용으로 soft삭제
       • delete 메소드를 사용하는 순간, "삭제"된 것으로 인식해 cascade 컬럼, 고아객체를 실제로 삭제함
       • 해당 연관관계를 사용하지 못하고 모든 작업자가 여기에 대해 신경써줘야함
       • 폐기
    2. jparepository.delete를 soft 삭제로 오버라이드
       • interface에 @query 를 달거나, 직접 쿼리를 작성해야 하는 등 작업 난이도 상승
       • 폐기
    3. entity에 delete메소드를 추가하여 soft 삭제
       • 현재 시스템상 가장 적절한 방안으로 생각되어 채택함

• 기술적 다양성을 위한 kafka, elasticSearch 고찰

  • kafka는 분산스트리밍 플랫폼으로 "대령으로 들어오는 지속적이고 실시간 데이터를 분산처리"할때 필요함

  • 현재 시스템에서 kafka는 너무 과도한 기술, 러닝 커브 완만함으로 구성원들이 적용하기 어려움

  • 메세지 큐를 사용하고 싶다면, 특정 부분에 AWS SQS 정도로 하기로 함

  • elasticSearch는 동일한 이유로 폐기 (과도함, 굳이 설명 같은 부분도 검색을 제공해야하는가?)

    ---

• 프런트 기술 선택과정

  • javascript, vue, react, Thymeleaf
  • 백앤드 api구조를 해치고싶지 않음 - javascript, Thymeleaf 배제
  • 좀더 학습난이도가 낮다고 알려져있는 vue를 채택하기로함.

• 채팅 도입 여부
  • 기술적 다양성을 위해 채팅 도입을 고민
  • 실시간 채팅 도입 시 현재 시스템의 메인 기능에 비해 채팅이 너무 비대화됨 (web socket 사용, 속도문제로 redis 사용, 채팅 로그를 남기기 위해 Message system 도입
  • 과도한 작업이라 생각돼 우선 보류