[프로젝트] MSA 기반 대용량 트래픽 프로젝트 설계 및 S.A 문서

MSA 기반 대규모 트래픽 처리 팀 프로젝트에 들어가면서, 초반 요구사항을 정리하고 ERD를 설계하는 동안 들었던 고민들과 그 결과를 정리해두려 한다.

이번 프로젝트는 요구사항이 미리 정해진 게 아닌, 팀원들과 함께 상의해서 요구사항을 정하는 프로젝트였으므로 요구사항과 도메인 구성 등등을 정하기 위한 회의를 진행했다.

 

🔹요구 사항

요구사항의 경우, 팀원들 모두가 개발 시 공통적으로 지켜야 할 요구 사항과 도메인 별 요구 사항으로 나누어 토론하고 결정했다.

공통 요구사항 일부

상품 도메인 요구사항 일부

 

🔗전체 요구사항 보러가기

요구 사항 정리 | Notion

 

🔹테이블 명세서 및 ERD

🔗테이블 명세서 보러가기

테이블 명세서 | Notion

 

ERD

마이크로 서비스 기반의 아키텍쳐이기 때문에, 모듈끼리의 연관관계는 이해를 돕기 위해 설정해둔 연관관계라고 보면 될 것 같다. 테이블마다 공통되는 감사 로그는 공통 모듈(common-module)의 BaseEntity로 분리해서 상속받아 진행했다! 

 

일반 상품과 예약구매용 상품을 설계하면서, 구조 설계를 어떻게 해야할지 고민했었는데 (상속 or 컴포지션) 이 부분은 추후 포스팅을 통해 자세히 의사결정 과정을 써보려고 한다!

 

🔹API 명세서

모든 도메인의 API들은 CRUD와 Search (검색조건 및 정렬 기능)가 구현되어 있어야 한다는 요구 사항에 맞춰 구현했다. 일단 본격적인 개발 전에는 노션을 사용해 API 명세서를 작성했고, 추후 개발이 완료된 후 Postman으로 API 명세서를 다시 작성할 예정이다.

 

🔗API 명세서 보러가기

API 명세서 | Notion

(추가) Postman 명세서 보러가기

 

 

🔹1차 아키텍처 설계도

1차 아키텍처 설계도이다. 서로 관련이 있는 비즈니스 도메인끼리 마이크로 서비스로 묶고, 초기 배포에서는 모든 서비스가 단일 EC2 인스턴스로 구성되어 있도록 구성했다.

허나 해당 구조는, 인스턴스에 장애가 발생할 경우 모든 서비스가 중단되는 문제가 생긴다는 걸 인지했다. 이는 MSA의 장점을 상실하는 구조라고 생각했다.

 

 

🔹2차 아키텍처 설계도

 

따라서 개발을 진행하면서 시스템들을 분리하기로 결정했다. 위 설계도는 그에 따른 수정된 2차 아키텍쳐 설계도다.

사실 모든 시스템이 독립적으로 운영되는 것이 좋지만,
짧은 기간에 배포를 완료(약 3일)해야 한다는 점과, 한정된 예산의 측면을 고려하여 분리할 필요가 있었다. 따라서 우선 시스템 유형 별로 인스턴스를 분리하였고, 이후 서비스끼리는 의존성이 강한 서버끼리 그룹지었다.
(e.g. 주문이 가능하려면 결제 서버가 되어야 하므로, 이 둘을 묶을 필요가 있다고 판단)

 

🔹카프카 메세지 양식

마지막으로, kafka를 사용하면서 공유해야 할 메세지 양식 또한 문서화 한 후 진행했다. 직전에 진행한 프로젝트에서는 Feign Clients DTO 문서들을 제대로 문서화 해두지 않아서, 중간중간 계속 소통해야하고 양식이 바뀌었을 때 다른 팀원 개발자가 그걸 몰라서 개발이 늦춰지는 이슈가 생겼었다.

이번엔 초반부터 문서화를 제대로 하고 진행해서 해당 이슈 발생 없이 무난하게 진행할 수 있을 거라고 기대한다.

🔗kafka 메세지 양식

 

개발을 진행하면서 생긴 트러블 슈팅이나 기술적 의사결정은 추후 포스팅을 통해 자세히 기술하도록 하겠다 😀