중간 발표 자료

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

프로젝트명 : 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

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로 발생하는 문제

삭제된 데이터에 대한 관리
삭제된 데이터는 사용하지 않는데 DB 성능에 영향을 줌
-> 아카이빙처리 해야함. (고도화 작업으로..)

작업량 증가
삭제하면 되던 작업을 연관관계에 따라 처리해줘야함
-> 아카이빙 처리 시 같이 작업하기로 함

◦

도입 방안

▪

 is_deleted, deleted_at 컬럼을 추가함

@SQLDelete 를 통해 jparepository.delete 메소드 사용으로 soft삭제

•

delete 메소드를 사용하는 순간, "삭제"된 것으로 인식해 cascade 컬럼, 고아객체를 실제로 삭제함

•

해당 연관관계를 사용하지 못하고 모든 작업자가 여기에 대해 신경써줘야함

•

폐기

jparepository.delete를 soft 삭제로 오버라이드

•

interface에 @query 를 달거나, 직접 쿼리를 작성해야 하는 등 작업 난이도 상승

•

폐기

entity에 delete메소드를 추가하여 soft 삭제

•

현재 시스템상 가장 적절한 방안으로 생각되어 채택함

•

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

◦

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

◦

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

◦

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

◦

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

•

프런트 기술 선택과정

◦

javascript, vue, react, Thymeleaf

◦

백앤드 api구조를 해치고싶지 않음 - javascript, Thymeleaf 배제

◦

좀더 학습난이도가 낮다고 알려져있는 vue를 채택하기로함.

•

채팅 도입 여부

◦

기술적 다양성을 위해 채팅 도입을 고민

◦

실시간 채팅 도입 시 현재 시스템의 메인 기능에 비해 채팅이 너무 비대화됨
(web socket 사용, 속도문제로 redis 사용, 채팅 로그를 남기기 위해 Message system 도입

◦

과도한 작업이라 생각돼 우선 보류

추후 개발 작업

•

테스트 코드 도입

◦

작업속도를 고려해 기술적 구현을 우선시하여 테스트 코드가 없음.

◦

테스트 코드로 코드 품질을 향상

•

AWS SQS 도입

•

HashTag 조회 도입

•

쿼리 최적화 (성능개선)

•

AWS 보안 설정

프로젝트 관련 질문에 대한 답변

•

5. DB 구조를 보니, 하나의 방은 하나의 예약자만 예약할 수 있도록 구성한 것으로 보이는데, 그럼 동시에 하나의 방을 예약하려고 하는 사용자가 여러 명일 때, 하나의 예약자에게만 방 예약이 되었다는 것을 어떻게 보장했는지 설명해주세요. 만약, 이 부분에 대한 고려가 되어 있지 않다면, 어떻게 해결할 수 있을 것인지 계획을 이야기 해주셔도 좋습니다.

◦

여러 유저가 여러 방에 등록 가능함으로, reservation 테이블이 별도로 있습니다. DB에 저장할때, 해당 방에대한 시간이 중복되지 않도록 validation하고 있습니다.

•

6. 만약, 추가 요구사항으로 "방을 대여한 사용자는 최근 60일 간 특정 방에 대해 예약으로 인해 발생한 매출액을 일 단위 꺾은선 그래프 형태로 조회할 수 있다." 라는 요구사항이 추가되었을 때, 백엔드 서버에서 어떤 로직으로 이 기능을 구현할 것인가요?

◦

해당 로직에 대해서는 “60일에 동안 발생한 매출액”을 일단위로 표현한 값을 프론트에서 받으면 됨으로,  간단한 groupby 쿼리로 해결될 것으로 보입니다. queryDSL을 통한 로직을 구현할 것입니다.

•

> (꼬리 질문 - 요청이 들어왔을 때 db 실시간 조회를 하도록 함.) 6.1) 사실 이 기능은 통계 기능인데, 실시간으로 조회해서 제공해준다고 하면 검색할 데이터 건 수가 많아 실시간으로 처리하기에는 응답 속도가 너무 느려지지 않을까요?

◦

실시간 조회라 하면 조회된 내용에 대해 캐싱을 하거나 별도 테이블을 통해 데이터를 밀어넣는 식의 구성도 가능해보입니다. 마지막 날에 대한 정보만 변경하고 동일한 내용을 굳이 다시 조회할 필요가 없기 때문입니다. 날이 끝나는 시간에 스케쥴러를 통해 데이터를 테이블에 입력하는 것도 방법이 될 것 같습니다.

•

-> (꼬리 질문 - 별도의 스케줄러를 사용함.) 6.2) 그럼 그 통계 스케줄러는 구체적으로 어떤 스펙으로 동작하는 걸까요? 예를 들어, 하루에 한 번? 15분에 한 번? 데이터를 DB에 쌓을 때 데이터 형태는 어떻게 되는지?

◦

스케쥴러는 요청 사항에 따라 다를 것 같은데요, 만약 정말 실시간으로 변경이 되어야한다면,   스케쥴러가 아니라 메세지 큐를 도입하여 매출이 발생할 때마다 해당 테이블을 갱신하는 방식이 더 나을 것 같습니다. 그러나 한시간이나 하루에 한번씩만 갱신되어도 상관없다면 (그래프로 흐름만 보고싶다) 그 요청 사항에 맞춰 스펙을 짤 것입니다. 스케쥴러 관련 데이터는 방/날짜/매출 형태의 구성을 취할 것 같습니다. 60일 이후의 데이터는 삭제하거나, 별도 테이블로 따로 분류하는 것도 좋은 방법인 것 같습니다.

•

만약, 해당 시간에 스케줄러가 동작하는 것에 대해서 실패 했다면, 해당 구간에 대해서는 아마 통계 데이터가 없을 것으로 예상이 되는데, 어떻게 하면 실패한 것에 대해서 Retry 처리를 고민해볼 수 있을까요?

◦

스케쥴러 갱신이 자주 일어난다면, 실패에 대해 크게 대응하지 않아도 될 것 같습니다. 다만 에러로 인해 스케쥴러가 전혀 동작하지 않는다면 당연히 Retry를 해도 의미가 없기 때문에 상관 없을 것 같습니다. 스케쥴러 동작이 자주 일어나지 않는다고 하더라도 이 부분을 방어하고싶다면, 쿼리에서 비어있으면 넣는 로직을 추가하면 될 것 같습니다. 이 부분이 정말 관리가 필요하고 정합성을 높이고 싶다면 좀 더 효율적으로 관리가 가능한 스프링 배치나 메세지 큐 시스템을 도입해 이 부분에 대해 처리할 수 있을 것 같습니다.

•

마지막으로 통계 스케줄러는 어떤 도구를 이용해서 구현할 예정일까요? airflow? spring scheduler? spring batch?

◦

우선 스프링 스케쥴러와 배치가 스프링에 대한 접근성이 뛰어나기 때문에 두 방식으로 진행할 것입니다. airflow는 airBnB에서 만들었기 때문에 적용을 고려해볼 수는 있겠으나, python기반임으로 다른 메세지큐보다 후순위 선택지에 놓여있습니다.

<튜터님 당일 피드백>

잘 보시면, 문서에 프로젝트 아키텍처와 요구사항 분석이 좀 더 디테일하게 들어가 있는 것을 확인하실 수 있으실 겁닏나.

어떤 기능에서 어떤 기술을 사용하겠다. 이런 내용이 sa에도 있어야

리뷰어 입장에서 해당 프로젝트에 어떤 요구 사항이 존재하고, 이런 요구 사항을 어떤 기술로 제공해주고 있구나. 등을 빠르게 판단할 수 있습니다.

요구사항 명세 부분에 대해서 좀 더 스펙을 구체적으로 적어주시고

가장 중요한건 프로젝트 아키텍처랑 사용 기술!

사실 리뷰어는 가장 먼저 그 2개만 보고 60% 이상을 판단하기 때문에

무조건 넣어주시는게 좋습니다.