😏 서론
현재 제가 진행 중인 토이 프로젝트는 '영화예매' 주제로 진행 중에 있습니다.
테이블 설계 이후 구현 단계에서 다른 테이블에 중복 컬럼을 왜 추가하게 됐는지 정리해보려 합니다.
(많이 History 느낌의 글입니다.)
🥹 본론
현재 프로젝트 상황
패키지
시스템 구조는 아래와 같습니다.
나중에 MSA 구조로 분리하기 위해 현재는 패키지만 분리해둔 상태입니다.
ERD
영화 서비스에선 5개의 테이블
결제 서비스와 유저 서비스에선 각각 1개의 테이블이 있는 구조입니다.
요구사항 분석
- 회원 결제목록 조회
- 로그인된 사용자의 정보를 이용해서 결제 목록을 얻어온다.
- 결제목록은 영화제목, 금액, 결제상태가 존재한다.
요구사항을 위해서는?
결제목록을 가져오는 요구사항은, 현재 설계된 모든 서비스를 거치게 됩니다.
그 이유는 현재 설계된 ERD 기준으로 영화제목은 Movie 서비스에 있고,
결제 타입과 결제 금액은 Payment 서비스에 있기 때문이죠.
만약, msa가 아닌 하나의 서비스였다면 join으로 해결할 수도 있습니다.
user join payment join ticket join movie_time join movie
join이 4번 발생하긴 하지만, 어떻게 해서든 쿼리 하나면 가져올 수 있긴 합니다.
하지만, 저희는 MSA 구조로 모듈을 나눠 진행하고 있으며, 그렇게 되면 3번의 api 통신이 이루어지게 됩니다.
여기서 고민이 생기게 되었습니다.
- 3개의 통신을 굳이 해야 할까?
- 통신을 어떻게 줄일 수 있을까?
필요한 데이터 정보
결제시스템에서 필요한 데이터 - 결제상태, 결제 금액
영화시스템에서 필요한 데이터 - 영화 제목
영화시스템에 있는 영화 제목을 가져오기 위해선
결제시스템을 조회 후 결제 ID를 통해 영화 시스템에서 조회를 해와야 합니다.
그렇다면 통신을 줄이기 위해서는
유저서비스에 결제정보를 저장하거나, 결제서비스에 영화제목을 저장하면 현재 요구사항에서는 API통신을 줄일 수 있을 것으로 보입니다.
유저서비스 안에 결제정보 ?
일단, 결제시스템에 있는 정보는 유저에 넣을 수 없습니다.
그 이유는 1대N 관계이기 때문이죠.
A유저가 '범죄도시2'와 '탑건'을 예매했을 경우 유저테이블에 결제정보가 있다면
A유저에 대한 컬럼이 2개가 되겠죠?
그건, 유저테이블의 설계가 잘못된 것으로 봐야 합니다.
결제서비스 안에 영화제목 ?
그렇다면, 결제시스템에 '영화 제목'을 넣는 건 어떨까요?
'범죄도시2' 결제내역과 '탑건' 결제내역은 이미 분리가 되어있기 때문에
결제시스템에서는 결제정보가 중복으로 생기진 않고, '영화 제목' 컬럼만 추가하여 끝낼 수 있을 것 같습니다.
어떤 걸 고려해야 할까?
데이터 관리
하지만, 동일한 데이터를 여러 서비스(테이블)에서 관리하는 건 무척 신중해야 하는 일입니다.
그 이유로는 데이터가 변경됐을 때 여러 서비스를 모두 변경해주어야 하기 때문이죠.
그렇다면 저희가 추가하려고 하는 '영화 제목'은 어떨까요?
'영화 제목'은 한 번 등록되면 변경되는 경우가 거의 없습니다.
거의 변하지 않는 데이터라 봐도 무방하죠.
만약 오타나 제목에 문제가 생겨서 간혹 변경이 생기더라도,
영화관 특성상 새벽 시간대에는 결제가 발생할 일이 없기 때문에
트래픽이 없는 시간에 Movie 테이블과 Payment 테이블의 영화 제목을 변경을 순조롭게 진행할 수 있을 것 같습니다.
그럼 '영화 제목' 특성상 데이터 변경 걱정은 한시름 놓을 수 있겠네요.
또 무슨 문제가 있을 수 있을까요?
여러 영화를 한 번에 결제할 경우에는 어떻게 할 것인가?
여러 영화를 한 번에 결제할 경우 유저 - 결제정보 에서 발생했던 문제와 동일한 문제가 발생할 수 있습니다.
결제테이블에서 동일한 결제정보가 중복으로 생기는 문제말이죠.
하지만, 저희 프로젝트에서는 여러 영화를 선택해서 한 번에 결제하는 기능을 구현하지 않을 예정입니다.
그 이유는 프로토타입 설계 시 영화를 선택하고 해당 영화를 결제하도록 진행시켰습니다.
배달의 민족처럼 장바구니에 여러 영화를 담고 결제하지 않죠.
그러므로 해당 문제는 저희 시스템에서 발생하지 않는 문제라는 결론을 내렸습니다.
물론, 나중에 어떻게 될지 모르고 확장성 있게 설계하는 게 중요하다고 보지만, 영화관의 특성 상
다양한 영화를 한 번에 결제할 필요 여부를 저희는 현재 없다고 판단하였습니다.
장단점
그럼, 결제 서비스에 '영화 제목' 을 추가하여 나온 장단점을 분석해보겠습니다.
장점
- 영화 서비스 호출을 없앨 수 있다.
- 통신이 하나가 줄어 기존보다 속도향상 및 관리가 용이해진다.
단점
- 만약 영화제목이 변경되었을 경우 영화서비스, 결제서비스 두 곳 다 변경을 해주어야 한다.
- (관리할 곳이 늘어남)
🥸 결론
저희는 '영화 제목' 특성 상 변경이 한 번 등록되면 변경이 거의 변경하지 않을 것으로 보아
결제시스템에서 중복으로 관리하는 것이 큰 부담이 없을 것으로 판단하여 추가하는 것으로 결정하였습니다.
사실 길게 썼지만
여기서 이야기 하고 싶은 부분은 payment에 '영화 제목'을 넣냐 빼냐를 얘기하고 싶었던 게 아닙니다.
'어떤 문제'를 발견하고, 여러 '해결 방법'을 고민해보면서 저희 현재 요구사항에 맞는 결정을 내리는.
즉, 무슨 이유로 해당 문제를 어떤 방식으로 해결하려고 했는지. 이런 고민이 개발자로선 중요한 부분이라 생각합니다.
모든 상황에 일치하는 정답은 없다고 생각합니다.
각자의 상황 속에서 팀원들이 생각하는 최선의 답을 찾는 과정이 의미있다 생각합니다.
'Project' 카테고리의 다른 글
| [Ticketing] 유저 PK 대신 유니크 ID 만들어 사용하게 된 계기 (유니크 ID 생성) (0) | 2022.07.12 |
|---|---|
| 'Graphql'을 선택한 이유 (0) | 2020.09.01 |
