Monolithic vs SOA vs MSA

스크린샷 2023-07-04 오전 10 13 34

Monolithic Architecture

1_Tiizur0VlvZlJSIgADsp4w

서비스가 커짐에 따라 빌드, 배포, 서버 가동 시간이 점점 늘어난다.
- 잦은 배포시 긴 배포 시간은 문제가 될 수 있다.
서비스 간 의존성이 존재하기 때문에 시스템 일부만 수정해도 전체 어플리케이션의 빌드, 테스트, 배포 과정을 다 거쳐야 한다.
부분적 스케일 아웃이 어렵다.
- 성능을 늘리기 위해선 스케일 업만 가능하다. (스케일 아웃: 서버의 갯수를 늘려 전체 성능 올리기, 스케일 인: 서버의 내부 성능을 높여 전체 성능 높이기)
안정성이 떨어진다.
- 부분 장애가 전체 서비스 장애로 퍼질 가능성이 매우 크다.
서비스가 커짐에 따라 히스토리, 이슈 파악이 매우 어려워진다.
코드 작은 일부분을 수정했을 때 미칠 영향력을 파악하기 쉽지 않다.
- EX) A 서비스에 사용되는 유틸 기능 코드 하나를 변경했는데, 사실 그 유틸 기능이 B, C, D 서비스에 널리 퍼져 사용되고 다른 코드 깊숙이 있었다면 파악하기 힘들다.
하나의 프레임 워크, 언어에 종속적이다.

esb_architecture

SOA(Service Oriented Architecture) : 서비스 지향 아키텍처
SOA는 기존의 어플리케이션의 기능들을 비지니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해 서비스로 구현하고, 이 서비스들을 기업의 업무에 따라 어플리케이션을 구성하는 소프트웨어 개발 아키텍처를 의미한다.
공통된 서비스를 ESB(Enterprise Service Bus)에 모아 사업 측면에서 공통의 기능 집합을 통해 서비스를 제공한다.
- ESB(Enterprise Service Bus) : 서비스를 컴포넌트화된 논리적 집합으로 묶는 미들웨어로 이벤트 및 서비스에 대한 요청과 처리를 중개하여 전체 스트럭처에 분포하게 된다.
모듈의 의존성은 줄이되 모듈 내에서 공유할 수 있는 것은 공유하자는 정책이므로 ESB를 도입하였다.

imagesoa

imagemsa

SOA vs MSA

MSA(Micro Service Architecture) : 아주 작은 서비스 아키텍처
SOA 보다 더 세분화하여 함께 작동하며, 작은 모놀리틱 아키텍처 여러 개가 최소한의 의존성을 가지며 큰 서비스를 구축하는 형태라고 볼 수도 있다.
독립적인 역할을 수행하는 작은 단위의 서비스로 분리하고, 서로 서비스가 API를 통해 통신할 수 있도록 설계하는 아키텍처이다.

각 서비스 간 API 통신, 실패 처리 등에 대한 고려가 필요하다.
여러 DB를 통해 데이터를 처리하다보니 트랜잭션 처리가 중요해진다.
서비스를 테스트할 때 비교적 어렵다.
- 여러 어플리케이션들이 얽혀 있다면 모두 실행하여 테스트하거나 다른 방법을 도입하여 테스트하여야 한다.
- 특히 통합 테스트는 운영환경과 똑같은 환경으로 가져가 테스트하는데 어려움이 있다.
각 어플리케이션의 배포 순서가 중요할 수 있다.
MSA 를 구축하고 파악하는 일은 쉬운 일이 아니다.
많은 어플리케이션을 구축하고 관리하는데 비용, 인력 비용이 큰 편이다.

Reference:

← Previous Post Next Post →