목표

• MSA가 나오게 된 배경인 모놀리식 아키텍쳐를 이해한다.

모놀리식 아키텍처의 구성

• 단일 repo
• WAS 1개, DB 1개 구성

• 단일 repo
• HA(High Avaliblity) 고 가용성 서버 구성
• LB를 통해 부하 분산, 두 대의 WAS, 1개의 DB

• 단일 repo
• Scale Out, 동접에 따른 확장
• LB 하나가 모든 WAS를 처리, 배포 시간이 약간 늘어남

• 단일 repo 정책을 유지한 채 업무를 분산
• 이슈 발생

1. 브랜치 합병 시 충돌
2. 배포에 따른 QA 일정 문제
3. 각 브랜치마다 달라지는 일정과 배포
   미리 완성 되어도 배포할 수 없거나 관리할 수 없음

• 업무 별 reop를 분리
• 서로 공통되지 않은 데이터를 참고할 수 없음
  share 데이터를 통해 동작 시키고, 90% 이상이 이렇게 사용
• Order에서 구현하는 코드임에도 Product의 코드를 하나라도 참고하고 된다면
  Share에 구현, Order는 안쓰게 됨
• Share 데이터를 배포에 맞춰 모든 저장소가 Sync를 맞춰야 함
• SNAPSHOT이라고 적힌 코드는 항상 빌드 툴에 의해 버전이 변경

공유 코드를 사용함으로써 하나의 DB를 유지
코드의 중복성이 다분

정리

• 단일 저장소와 공유 데이터를 사용하는 것이 모놀리식 아키텍처
• 장점

1. 하나의 repo를 공유함으로 개발과 관리가 단순
2. 확장이 아주 쉬움
   LB 연결만 늘리면 됨
3. 하나만 배포하면 됨

• 단점

1. DB 성능 하락 현상
2. 빌드가 오래 걸림
3. 기술 스택 변경 어려움
4. 결합도 높음
5. 코드의 책임의 한계 (누가 이 코드를 책임질 것인가?)

내가 보기엔 모놀리식 아키텍처는 소규모 개발에 적합한 것 같다.
단일 레포만 관리하고 브랜치 관리만 잘 한다면 확장도 쉽고..
그리고 이렇게 구성되는 것이 일반적인 MVC 패턴이다? MVC 패턴 맞나?
사실 잘 모르겠다 이 부분은 다시 공부 해야할듯

참고

HA Cluseter
모놀리틱 아키텍쳐 이해