[항해] 3주차, 서버 구축 설계

 

항해 3주차에는 구축할 서비스 시나리오를 정하고, API 요구사항에 맞게 설계를 진행하였다.

선택한 시나리오와 프로젝트 설계 과정이 궁금하다면, 바로 읽어보자!

이번 주차 만큼은 J가 되.

 

목차
1. 시나리오 선정 
2. 프로젝트 Milestone 작성
3. 시나리오 요구사항 별 분석
4. API 명세서 작성
5. ERD 설계
6. 회고

 

1. 시나리오 선정 

시나리오는 e-커머스 서비스, 콘서트 예약 서비스로 총 2가지가 있었는데 이 중에서 콘서트 예약 서비스를 선택하였다.

'콘서트 예약 서비스'로 선정하게 된 이유는 대기열 시스템 구축과 좌석 임시 배정 5분 기능을 구현하면서 고민하고 배울 수 있는 포인트가 많을 것 같았다. 또한 유저 토큰을 발급해서 매 API 호출마다 사용자 인증하는데 이 부분은 어떻게 관점 분리를 시킬 수 있을지 궁금했다.

3가지 포인트를 보고 콘서트 예약 서비스를 서버를 구축하고자 마음을 먹게 되었다! 🙆‍♀️

2. 프로젝트 Milestone 작성

마일스톤이란 프로젝트 관리나 목표 달성 과정에서 특정 시점이나 중요한 단계를 나타내는 개념으로, 주요 이정표 역할을 한다.

3주 동안 진행하는 서버 구축 일정을 주차별로 나누어, 1️⃣ 분석 및 설계, 2️⃣ 단위 개발(구현), 3️⃣ 리팩토링이라는 세 가지 카테고리로 작성하였다.

 

깃허브를 이용한 프로젝트 관리

 

 

3. 시나리오 요구사항 별 분석

API 요구사항 별로 기능을 분석하고, 이를 도식화하기 위해 처음으로 mermaid 툴을 활용하여 시퀀스 다이어그램을 그려보았다!

UML로 그리면서 기능을 정의하니, 복잡한 비즈니스 로직도 한 눈에 파악하기 수월해졌다. 👁

그리고 다이어그램 내부에서는 alt를 사용하여 유저 토큰이 유효한 지와 좌석 여부를 확인하고 분기 처리를 해주었다!

 

* 시퀀스 다이어그램 : 객체 간의 상호작용을 시간 순으로 표현해주는 다이어그램으로 Actor(액터), Object(객체), Lifeline(생명선), Message(메세지), Activation(활성화)으로 구성.

 

 

4. API 명세서 작성

API 명세서에는 보통 HTTP 메서드(GET, POST, PUT, DELETE)와 EndPoint, 기능 설명, Request(Param, Query, Body 등 매개변수 및 요청 데이터), Response(응답 데이터), Authorization(인증, 권한)에 대한 내용이 포함되어 있다.

 

아래는 좌석 예약에 대한 API 문서이다. Header에는 유저 인증 토큰이 key-value 형태로 들어있고, Body에 scheduleId와 seatId를 담아서 EndPoint로 요청을 보내면 좌석 예약 후 상태 코드, 성공 여부, 메세지, 예약 정보 등을 반환한다.

 

 

5. ERD 설계

먼저 주요 엔티티를 도출하고, 각 속성을 정의하고, 관계를 설정하는 단계로 ERD를 설계하였다.

콘서트 예약 서비스 ERD는 사용자(USER), 대기열(QUEUE), 포인트 내역(POINT_HISTORY), 콘서트(CONCERT), 스케줄(SCHEDULE), 좌석(SEAT), 예약정보(RESERVATION), 결제정보(PAYMENT)로 구성되어 있고, 테이블 간의 관계 설정도 맺어주었다. 

💡 고민 포인트

예약과 결제 관계에 대해 설정하는 과정에서 고민이 생겼다.

제약 사항을 유저 한 명이 여러 좌석에 대해 예약을 한다고 정했을 때, 예약건마다 결제 건이 쌓이는 방식에 따라 관계가 달라졌다.

케이스 별로 나누어서 살펴보자 .

 

[CASE 1] 

예약 : 결제 = N : 1 일 때, 예약 건 Nrow에 대해 결제는 1row 생성된다.

CASE 1로 가져가면 예약 독립성 문제가 발생한다. 예를 들어 3개의 좌석에 대해 예약을 하고 결제 취소를 하려면 예약이 다 취소가 되어야 한다. 이 케이스가 유리한 경우는 "모두 성공해야만 성공, 그 외엔 실패"가 될 때이다.

 

[CASE 2]

예약 : 결제 = 1 : 1 일 때, 예약 건 1row에 대해 결제 건도 1row 생성되고, 결제 내역은 Nrow 생성된다.

CASE 2로 가져가면 구조 복잡도가 증가한다. 예약마다 결제건이 생성되기 때문에 이를 관리하려면 검색이나 조인, 업데이터 성능이 저하될 수 있다. 예약마다 결제를 독립적으로 관리할 때 유리하다.

 

[Solution]

티켓 테이블을 하나 더 두어서 좌석 단위로 상태를 관리하게 해주면 된다.

 

예약 : 티켓 = 1:N
예약 : 결제 = 1:1

 

위 관계로 설계하면 좌석에 대한 티켓별로 부분 취소가 가능하여 세밀하게 제어할 수 있다는 장점이 있다.

반면 티켓 테이블에 대한 관리도 늘어난다는 단점이 있다.

 

제약사항이나 비즈니스 요구사항에 부합하게 테이블 간의 관계를 설정해주어야 한다.

티켓 테이블까지 추가하기에는 관리해야 할 테이블이 많아지므로 우선은 예약, 결제의 관계를 1:1로 매핑하여 결제 상태값을 바꿔주는 것으로 방향을 설정하였다.

6. 회고

멘토링 때 쉽게 개발하려면 제약조건을 뾰족하게 정의해주어야 한다고 들었는데 설계를 진행하면서 이 부분이 크게 와닿았다.

비즈니스 별 요구에 따라 테이블 갯수, 관계, 속성이 달라지기 때문에 설계를 하고 고민할 때마다 구조를 계속 변경을 해주어야 했다.

그리고 시퀀스 다이어그램에도 최대한 조건을 반영해놓으면, 그려놓은 설계도를 보고 구현으로 바로 옮기면 돼서 개발하는 속도도 더 빨라질 것으로 예상한다! 

 

그리고 3주차에는 BP(Best Practice, 코치님마다 1개씩만 줄 수 있는)를 받았다! 🫢🩵

분석을 나만의 방식으로 이해해보고 시퀀스 다이어그램에 녹여냈는데 그 부분을 알아봐주신 것 같아서 뿌듯했다.

앞으로 남은 주차도 꾸준히 과제를 수행해야겠다.