MSA

 

Monolithic 특징

Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스입니다. 현재 많은 회사들의 소프트웨어가 레거시 또는 필요로 인해서 Monolithic 형태로 구현되어 있습니다. 소규모의 프로젝트에서는 Monolithic 형태는 간단하며, 유지보수가 편하기 때문에 선호됩니다.
그러나 일정 규모 이상을 넘어가면 Monolithic은 많은 한계점에 봉착합니다.

기존 Monolithic Architecture의 한계

• 부분 장애가 전체 서비스의 장애로 확대될 수 있음
• 전체 시스템 구조 파악이 어려움
• 서비스 변경이 어렵고, 수정 시 영향도(사이드 이펙트 등) 파악이 힘듦
• 빌드 시간 및 테스트, 배포 시간의 급증
• 서비스의 특정 부분만 스케일아웃(sacle-out) 하기 어려움

 

 

MSA 특징

MSA는 API를 통해서만 상호작용할 수 있다. 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화합니다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려집니다.

 

 

제대로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행합니다.. 즉, 어플리케이션 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임집니다. 그리고 여러 어플리케이션에서 재사용할 수 있어야 합니다.

어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관합니다.. 따라서 마이크로서비스 기반의 어플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미합니다. 

마이크로서비스는 SOA에서 사용되는 집중화된 관리 체계를 사용하지 않습니다. 마이크로서비스 구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점입니다.

 

 

 

MSA 장점

1. 배포

- 서비스별 개별 배포가 가능합니다.(배포시 전체 서비스의 중단이 없습니다.)

- 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능합니다.

 

2. 확장

- 특정 서비스에 대한 확장성(scale-out)이 유리합니다.

- 클라우드 기반 서비스 사용에 적합합니다.

 

3. 장애

- 일부 장애가 전체 서비스로 확장될 가능성이 적습니다.

- 부분적으로 발생하는 장애에 대한 격리가 수월합니다.

 

4. 그 외

- 새로운 기술을 적용하기 유연합니다.(전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능)

- 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽습니다.

---

MSA 단점

1. 설계의 어려움

- MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야합니다. 또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야합니다.

 

2. 성능

- 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재합니다.

 

3. 테스트/데이터 트랜잭션

- 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵습니다.
- 통합 테스트가 어렵습니다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않습니다.

 

4. 데이터 관리

- 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵습니다.

- 데이터를 관리하기 어렵습니다.

 

---

 

MSA는 과거 CBD(Component Based Development)방법론과 SOA(Service Oriented Architecture)의 계승자같은 느낌입니다.

 

2000년대 초반 CBD방법론 등을 국내 많은 회사들이 시도했습니다. 당시 레셔널로즈와 같은 CASE 툴을 이용하여 UML로 설계를 하는 게 일종의 트렌드였는데, 당시 가장 어려운 점 중의 하나는 컴포넌트 안에 어느 정도의 비즈니스를 넣느냐 하는 것이었습니다.

 

예를 들어 고객관리라는 컴포넌트가 맞는 건지, 고객기본정보관리, 부가정보관리, 핵심정보관리와 같은 크기가 맞는 건지 정의하기가 어렵다는 것이었습니다. 

 

또 한가지는 재사용이었는데, 컴포넌트가 재사용되어야 하는 건 맞는데 생각보다 재사용되는 컴포넌트가 없다는 것이었습니다. 예를 들어 고객관리 컴포넌트를 만들고 나니 어쩔 수 없이 비즈니스의 특징이 많이 담겨 이를 시장에 내놓아도 사용이 어렵다는 것입니다.

 

이는 SAP 프로젝트 해보신 분은 무슨 의미인지 아실 겁니다.

 

---

MSA라는 게 또 하나의 트렌드로 자리잡은 걸 보면 왜 역사에 답이 있다고 하는 지 알 것같은 느낌입니다.