목표
- MSA가 나오게 된 배경인 모놀리식 아키텍쳐를 이해한다.
모놀리식 아키텍처의 구성
- 단일 repo
- HA(High Avaliblity) 고 가용성 서버 구성
- LB를 통해 부하 분산, 두 대의 WAS, 1개의 DB
- 단일 repo
- Scale Out, 동접에 따른 확장
- LB 하나가 모든 WAS를 처리, 배포 시간이 약간 늘어남
- 단일 repo 정책을 유지한 채 업무를 분산
- 이슈 발생
- 브랜치 합병 시 충돌
- 배포에 따른 QA 일정 문제
- 각 브랜치마다 달라지는 일정과 배포
미리 완성 되어도 배포할 수 없거나 관리할 수 없음
- 업무 별 reop를 분리
- 서로 공통되지 않은 데이터를 참고할 수 없음
share 데이터를 통해 동작 시키고, 90% 이상이 이렇게 사용
- Order에서 구현하는 코드임에도 Product의 코드를 하나라도 참고하고 된다면
Share에 구현, Order는 안쓰게 됨
- Share 데이터를 배포에 맞춰 모든 저장소가 Sync를 맞춰야 함
- SNAPSHOT이라고 적힌 코드는 항상 빌드 툴에 의해 버전이 변경
공유 코드를 사용함으로써 하나의 DB를 유지
코드의 중복성이 다분
정리
- 단일 저장소와 공유 데이터를 사용하는 것이 모놀리식 아키텍처
- 장점
- 하나의 repo를 공유함으로 개발과 관리가 단순
- 확장이 아주 쉬움
LB 연결만 늘리면 됨
- 하나만 배포하면 됨
- DB 성능 하락 현상
- 빌드가 오래 걸림
- 기술 스택 변경 어려움
- 결합도 높음
- 코드의 책임의 한계 (누가 이 코드를 책임질 것인가?)
내가 보기엔 모놀리식 아키텍처는 소규모 개발에 적합한 것 같다.
단일 레포만 관리하고 브랜치 관리만 잘 한다면 확장도 쉽고..
그리고 이렇게 구성되는 것이 일반적인 MVC 패턴이다? MVC 패턴 맞나?
사실 잘 모르겠다 이 부분은 다시 공부 해야할듯
참고
HA Cluseter
모놀리틱 아키텍쳐 이해