1. Monolithic

Monolithic(돌덩이 하나의, 단단히 짜여 하나로 되어있는)

• 내부 요소간의 의존성이 강함
• 각 비즈니스 컴포넌트들이 하나의 강한 결합 구조를 지니고 통일성 있음

- 장점

• 개발 초기에 단순한 아키텍쳐 구조와 개발에 용이
• 어떤 서비스든지 개발되어있는 환경이 같아서 복잡하지 않음
• 쉽게 고가용성 서버 환경을 만들 수 있음
  

- 단점

• 프로젝트의 규모가 커짐에 따라 애플리케이션 구동시간이 늘어나고, 빌드, 배포 시간이 길어짐
• 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포해야함
• 많은 양의 코드가 몰려있어 개발자가 모두를 이해할 수 없고, 유지보수가 힘듦
• 일부분의 오류가 전체에 영향을 미침
• 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기 까다로움

2. MSA

MSA(Micro Service Architecture)

- 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처

• 기능(목적)별로 컴포넌트를 나누고 조합할 수 있도록 구축
• 산업적인 합의는 없으며, 공식적인 정의 또한 없으나 아래의 특징들로 이루어진 개념이라고 여기면 됨

- 특징

• 애플리케이션을 여러개의 작은 서비스로 분해할 수 있음
• 모듈성을 개선시키고 애플리케이션의 이해, 개발, 빌드, 테스트, 배포를 쉽게 해줌
• 규모가 작은 팀들이 팀별 서비스를 독립적으로 개발 및 배포할 수 있게 해줌
• 지속적인 리팩터링을 통해 각각의 서비스 아키텍처를 하나로 병합할 수 있게 해줌

- 장점

• 배포 관점 : 서비스별 개별 배포 가능(배포 시 전체 서비스의 중단이 없음), 요구사항을 신속하게 반영하여 빠르게 배포 가능
• 확장 관점 : 특정 서비스에 대한 확장성이 용이
• 장애 관점 : 장애가 전체 서비스로 확장될 가능성이 적음, 부분적 장애에 대한 격리 수월

- 단점

• 전체 서비스가 커짐에 따라 복잡도가 기하급수적으로 늘어날 수 있음
• 성능 : 서비스 간 호출 시 API를 사용하기 때문에, 통신 비용이나 지연시간이 그만큼 늘어나게 됨
• 테스트 / 트랜잭션 : 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원 필요
• 데이터 관리 : 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어려움

- MSA가 필요한 경우

• 애플리케이션의 배포에 한 시간 이상 소요될 경우
• 단순한 기능 하나를 수정해도 전체 기능에 대한 QA가 필요할 경우
• 단순한 버그 수정이 더 중대한 버그를 생산하는 일이 많아졌을 경우
• 현재의 애플리케이션을 기능별로 나눈다고 가정했을 때 수십개의 마이크로 서비스가 가능할 경우

참고자료
https://shaul1991.medium.com/%EC%B4%88%EB%B3%B4%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%9D%BC%EC%A7%80-%EB%8C%80%EC%84%B8-msa-%EB%84%88-%EB%AD%90%EB%8B%88-efba5cfafdeb
https://m.blog.naver.com/dktmrorl/221863498991
https://m.blog.naver.com/dktmrorl/221860647521