Monolithic, MSA, SOA 정리 1편
Monolithic Architecture
개발되는 서비스의 모든 비즈니스 로직, UI, 데이터베이스 등을 한 곳에 다 때려넣고 운영하는 구조로 프로그램을 설계하는 방법이다.
하지만 소프트웨어의 규모가 커지고 복잡해지는 현 상황에서 대규모 서비스를 제작하기에는 합리적이지 않기에 서비스 개발 초기 빠른 개발을 위해 사용하더라도 해당 서비스가 어느정도 사업 모델로서 인정을 받고 기능들이 추가되면서 프로그램 복잡도가 높아진다면 MSA로 변경 작업을 거친다.
그렇기 때문에 처음부터 대규모 프로젝트를 생각했다면 사용되지 않는다.
장점
-하나의 언어와 프레임워크에 종속되어 구현하는 사람 입장에서는 하나의 언어와 프레임워크만 사용하면 된다.
-하나의 프로그램을 실행하면 모든 서비스가 동작되어 End to End 테스트를 하기 쉽다.
-초기 개발을 빠르게 가져갈 수 있다. (스타트업 입장에서 극초기에 서비스 모델이 성공할지 실패할지 모르니 빠르게 시장의 평가를 받아볼 수 있어서 사용할 것 같음)
단점
-하나를 고치면 전체 시스템에 영향을 주기 때문에 다시 빌드하고 배포하는 과정, 테스트를 하는 과정에서 상당히 비용이 많이 든다. 또한 테스트를 마쳤다고 해도 사이드 이펙트가 터지지 않는 것은 아니다.
-알맞는 언어, 프레임워크를 선택하기 어려울 수 있다.
-일단 개발을 시작하면 언어, 프레임워크를 변경할 수 없다.(수정하는데 비용과 시간 측면에서 최악이다.)
-부분 장애 때문에 시스템 전체 장애가 날 수 있는 구조이다.
-시스템의 크기가 커지면 커질수록 빌드와 배포가 오래걸린다.
-모든 개발자들 전체적인 코드를 이해하고 있어야 한다.(하나를 수정하면 다른 서비스에도 영향을 주기 때문에)
-위의 단점들로 인해 전반적인 유지보수가 힘들고 어렵다.
복잡하고 규모가 큰 소프트웨어들이 등장하면서 Monolithic Architecture대한 단점을 커버하기 힘들어 MSA, SOA 가 대두 되었는데 안좋은 측면 때문에 이러한 Monolithic Architecture의 사용을 금지하는 것은 아니다.
프로그램을 정말 대규모로 개발하는 것이서서 복잡도가 매우 큰 경우가 아니라면 Monolithic 방식을 사용하는게 더 이득일 수도 있다. 어떠한 방식으로 구현을 시작할지는 프로그램의 규모와 복잡도를 따져가며 고려해서 선택해야한다.
개인적으로 전 회사에서 임베디드 시스템을 개발할 때 모놀리틱 방식이었다. 하나를 수정하면 다른 부분에 사이드 이펙트가 발생 하는 것이 빈번했고 전체적인 동작 로직을 모르는 부분을 잘못 수정하면 갑자기 에러를 내뿜었고, 빌드시간도 상당히 오래걸렸다.
'Computer Science > MSA' 카테고리의 다른 글
081321 MSA_SpringCloud (0) | 2021.08.13 |
---|---|
081221 MSA_SpringCloud (0) | 2021.08.12 |
081121 MSA_SpringCloud (0) | 2021.08.11 |
081021 MSA_SpringCloud (0) | 2021.08.10 |
080921 MSA_SpringCloud (0) | 2021.08.10 |