Monolithic vs MSA

Monolithic Architecture

• 전통적인 아키텍처로 하나의 단위로 개발되는 일체식 어플리케이션
  • 소프트웨어의 모든 구성요소가 한 프로젝트에 통합 되어있는 형태
• 보통 하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍쳐를 가질 때, Monolithic 하다고 부릅니다.
• 하나의 논리적인 단일체로 내부 요소간의 의존성이 강합니다.

장점

• 단순한 아키텍쳐 구조이기에 소규모 프로젝트에 적합
• 전체가 합쳐져 있기 때문에 개발, 빌드, 배포, 테스트가 용이
• 단순히 하나의 어플리케이션을 복사만 하면 되기 때문에 쉽게 고가용성 서버 환경 구축 가능

단점

• 하나에 모든 것이 들어있기 때문에 규모가 커질수록 어플리케이션 구동시간이 늘어나고 빌드, 배포 시간도 길어짐
• 하나를 수정하더라도 전체를 다시 빌드하고 배포해야함
• 많은 양의 코드가 몰려 유지보수가 힘듦
• 하나가 오류나면 전체가 영향을 받음
• 각 기능별로 적합한 기술이나 언어, 프레임워크가 다를 수 있는데 서로 합쳐져있다보니 선택하기가 어려움
• 특정 기능만 사용량이 몰릴 경우, 스케일 아웃을 기능별로 할 수 없고 전체 어플리케이션을 동시에 확장해야함
• 데이터베이스가 통합되어 하나로 운영되기 때문에 어플리케이션을 스케일 아웃 하더라도 탄력적으로 대응하기 어려움

Micro Service Architecture

• 여러 서비스 인스턴스가 모여 하나의 비즈니스 어플리케이션을 구성하는 아키텍쳐
• 비즈니스 기능 별로 서비스가 개발되어 독립적으로 배포되는 형태
• 각 서비스가 독립적으로 실행되며 HTTP API와 같은 가벼운 수단을 사용하여 서비스 간 통신

장점

• 어플리케이션 하나의 단위가 작아져 빌드, 배포가 빠름
• 하나를 수정하더라도 수정한 서비스만 빠르게 빌드해서 배포 가능
• 기능별로 개발되어있기때문에 유지보수가 쉬움
• 하나에 오류가 발생하더라도 해당 서비스만 격리 시킨 후 복구시킬 수 있기 때문에 빠르게 정상화 가능
• 해당 기능에 맞는 기술, 언어 등을 선택하여 사용할 수 있음 → 폴리글랏(Polyglot)하다.
• 트래픽이 몰리더라도 몰리는 서비스만 스케일 아웃하여 대처할 수 있음
• 데이터베이스가 서비스별로 존재하기 때문에 탄력적으로 대처 가능

단점

• 서비스들이 분산되어있기 때문에 모니터링이 어려움
• 서비스 간 호출 시 API 사용으로 인한 통신 비용, 지연시간이 증가
• 트랜잭션 관리,데이터 정합성 관리 , 장애 추적 및 테스트가 어려움
• 전체 서비스가 커질수록 복잡도가 기하급수적으로 증가

 

기타 잡담

MSA가 좋고 Monolithic은 안좋다! 라는게 아닌 각기 상황에 맞춰 적절한 아키텍쳐를 선택하는 것이 중요한 것 같습니다.

다만, 요새 개발 환경을 보면 클라우드 인프라들이 잘되어있기 때문에 이를 사용한 MSA를 채택하는 것이 대세로 보여집니다.

기업들도 자체 서버를 가지고있는 것이 아닌 클라우드 서비스를 이용하여 자사의 서비스를 제공하는 경우가 많아지고 있으니 MSA로 개발해보는 경험을 가져가야할 것 같습니다...