1. Monolithic Architecture
소프트웨어의 모든 요소들이 하나의 통합된 형태의 아키텍쳐
모든 프로세스가 긴밀하게 결합하고 있고, 단일 서비스로 실행되기 때문에 소규모 프로젝트에서는 Monolithic Architecture가 훨씬 합리적일 수도 있다.
간단한 형태의 아키텍쳐이기도 하고 개발, 빌드, 배포가 용이하기 때문이다.
하지만 애플리케이션의 프로세스에 대한 수요가 급증하게 되고 일정 규모 이상으로 커지게 되면 뚜렷한 한계를 보이게 된다.
단점
- 애플리케이션의 규모가 커질수록 빌드, 배포시간이 길어짐.
- 부분적인 오류 및 장애가 애플리케이션 전체에 영향을 끼침.
- 여러 서비스의 결합도로 인해 서비스의 변경 및 수정이 어려움.
- 부분적인 Scale-Out이 어려움.
- 한 Framework와 언어에 종속적임.
이러한 한계들을 보완하여 등장한 Architecture가 Micro-Service Architecture이다.
2. Micro-Service Architecture
통합된 형태의 애플리케이션을 스스로 동작할 수 있는
작은 서비스 단위로 쪼개어 변경과 조합이 가능하도록 한 아키텍쳐
MSA는 각 애플리케이션의 서비스를 독립된 단위로 동작하고 각자의 서비스들끼리 상호 통신이 가능하게 하여, 전체 서비스를 구성한다. 서비스가 독립적으로 실행되기 때문에 특정 기능에 대한 수요가 있을때 마다 각각의 서비스를 업데이트, 배포 및 확장이 용이하다.
장점
- 서비스별로 개별 배포가 가능하여 배포시 전체 서비스에 영향도가 없음.
- 독립적인 배포 방식으로 배포 속도가 빠르며, 모놀로식에 비해 가벼움.
- 부분적인 오류 또는 장애가 전체 서비스에 영향을 끼칠 확률이 적어 장애처리 용이.
- 각 서비스 별로 적합한 언어, 프레임워크의 활용이 가능.
- 각 서비스의 부하에 따라 부분 Scale-Out이 가능.
단점
- 모놀로식에 비해 아키텍쳐 구조가 복잡하고 어렵기 때문에, 그에 따라 개발 복잡도가 올라가며, 숙련도를 요구함.
- 각 서비스가 구분되어 있어 배포 복잡도가 올라가며, 통합 테스트가 어려움.
- 분리된 서비스, DB 사용으로 트랜잭션 관리에 어려움.
- 데이터가 여러 서비스로 분리되어 관리되기 때문에 조회가 어렵고 정합성을 관리하기 어려움.
- 서비스 간 호출 시 REST API 사용으로 인한 통신비용, 지연시간이 증가함.
'Develop > CS' 카테고리의 다른 글
| 객체지향 프로그래밍(OOP) (0) | 2022.11.22 |
|---|---|
| Framework? Library? 프레임워크와 라이브러리의 차이 (2) | 2021.09.26 |