1. Monlith

2. MSA

1. Monlith(모놀리틱)

1-1) Monolith

Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태임.

아직까지는 많은 소프트웨어가 Monolithic 형태로 구현되어 있으며 소규모 프로젝트에는

Monolithic Architecture가 훨씬 합리적임. 간단한 Architecture이고, 유지보수가 용이함.

일정 규모 이상의 서비스 혹은 수백명의 개발자가 투입되는 프로젝트에서 한계가 있음.

1-2) Monolith의 한계

→ 서비스와 프로젝트가 커질수록 영향도와 전체 시스템 구조의 파악에 어려움이 있음.

→ 빌드와 테스트와 배포시간(Click)이 기하급수적으로 늘어나게 됨.

→ 서비스를 부분적으로 Scale-out(Click)하기가 힘듦.

→ 부분 장애가 전체 서비스의 장애로 이어지는 경우가 발생함.

2. MSA

2-1) MSA

MSA는 비즈니스 민첩성과 관련이 큼. 서비스나 프로젝트가 크고, 복잡하며, 장기적으로

운영 될수록 MSA의 장점이 더욱 드러남.

2-2) MSA vs Monolith

→ 각각의 서비스는 크기가 작을 뿐 서비스는 하나의 모놀리틱 아키텍쳐와 유사한 구조를 가짐.

→ 각각의 서비스는 독립적으로 배포가 가능해야 함.

→ 각각의 서비스는 다른 서비스에 대한 의존성이 최소화 되어야 함.

→ 각 서비스는 개별 프로세스로 구동되며, REST와 같은 가벼운 방식으로 통신되어야 함.

2-3) MSA의 장점

MSA는 서비스가 커지면서 생겼던 Monolithic Architecture의 문제점을 보완해줄 수 있음.

2-3)-1. 배포(Deployment) 관점

서비스 별 개별 배포 가능(배포 시 전체 서비스의 중단이 없음)

요구사항을 신속하게 반영하여 빠르게 배포할 수 있음.

2-3)-2. 확장(Scaling) 관점(Click)

특정 서비스에 대한 확장성이 용이함.

클라우드 사용에 적합한 아키텍처

2-3)-3. 장애(Failure) 관점

장애가 전체 서비스로 확장될 가능성이 적음

부분적 장애에 대한 격리가 수월함.

2-4) MSA의 단점

Monolithic Architecture은 단순한 아키텍처인데 MSA는 보다 복잡한 아키텍처로 전체 서비스가

커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있음.

2-4)-1. 성능

서비스 간 호출 API를 사용하기 때문에 통신, 비용, Latency가 그만큼 늘어나게 됨.

2-4)-2. 테스트 / 트랜잭션

서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고,

많은 자원을 필요로 함.

2-4)-3. 데이터 관리

데이터가 여러 서비스에 걸쳐 분산되기 때문에 한 번에 조회하기 어렵고,

데이터의 정합성 또한 관리하기 어려움.