[개발 방법론] 마이크로 서비스(MSA)와 모놀리틱 아키텍처의 차이점

개발론 공부를 합시다.

---

소프트웨어 아키텍처(SA, Software Architectire)

시스템 구성과 동작 원리, 구성 환경을 설명할 수 있는 청사진이자 설계도를 의미하는 용어입니다.

 

모놀리틱 아키텍처(MA, Monolitic Architecture)

비즈니스 로직, DB, UI 등을 하나의 프로젝트(패키지)에 담아 빌드, 배포까지 진행하는 아키텍처입니다.

 

특징

• 전통적인 웹 시스템 개발 아키텍처로, 소프트웨어의 모든 요소가 한 프로젝트(패키지)에 통합되어 있는 형태입니다.
  
• 각 비즈니스 컴포넌트와 프로세스가 강한 결합 구조를 지니고, 상호 의존성이 강하며, 단일 서비스로 실행됩니다.
• 서비스의 전체 기능을 단 하나로 일원화된 체계의 코드 베이스로 개발합니다.
• 비즈니스 로직이 서비스에 최적화된 코드를 만들어내는 데 집중할 수 있는 반면, 복합적인 예외를 만들 수 있는 위험성을 내포합니다.
  • why? : 단순한 구조로 인해 하나의 서비스에서 발생하는 예외 처리 또한 해당 서비스에서 관리해야 하기 때문, 복합적인 예외 처리의 경우 단일 서비스에서 처리하기 어렵습니다.

 

모놀리틱 아키텍처 구조 예시

java

닫기 줄바꿈

monolith-application/
|-- src/
|   |-- main/
|       |-- java/
|           |-- com.example.monolith/
|               |-- controller/
|               |-- service/
|               |-- repository/
|               |-- model/
|               |-- MonolithApplication.java
|       |-- resources/
|           |-- application.properties
|-- pom.xml

 

장점

• 단순한 아키텍처 구조를 가지며, 개발이 용이합니다.
• 적은 비용, 쉬운 난이도를 기반으로 신속한 서비스 구성이 가능합니다.
• 모든 기능과 서비스 구성이 동일 환경에서 진행되므로 복잡도가 비교적 덜합니다.
• 단일 데이터베이스와 단순한 프로세스로 고가용성 서버 환경 구성이 가능합니다.
  • 일정 수준까지 Scale-Out 에 장점을 가집니다.(동일한 구조로 확장)
• End-to-End 테스트의 용이
  • 단일 프레임워크, 애플리케이션 환경, 배포 단위로 인한 테스트가 용이합니다.
  • 실제 데이터를 기반한 상호작용이 단일 코드베이스 안에서 진행되므로 서비스 간의 간단한 API와 함수 호출로 쉬운 테스트가 가능합니다.

 

단점

• 규모에 비례해 기하급수적으로 커지는 복잡도
  • 마이크로서비스의 Scalability(확장성) 복잡도 : N + M 으로 증가합니다.
  • 모놀리식 아키텍처의 Scalability(확장성) 복잡도 : N * M 으로 증가합니다.
  • 단일 구조로 인해 프로젝트 규모가 커질 수록 컨테이너 과부하, 배포 및 스케일링의 어려움이 증가, 구동 시간의 증가합니다.
  • 코드 복잡도 증가 시 유지 보수가 어렵습니다.
  • 애플리케이션이 일정 수준을 넘어가는 순간부터 Scale-Out이 제한됩니다. 
• 높은 결합도로 인한 문제점
  • 한 컴포넌트의 오류가 어플리케이션 전체에 영향을 미칩니다.
  • 하나의 모듈 수정 → 전체 어플리케이션 수정 → 배포 지연으로 이어집니다.
  • 낮은 유연성을 가집니다.

 

마이크로서비스 아키텍처(MSA, Micro-Service Architecture)

MSA는 각 서비스를 마이크로하게 나눈 독립적으로 연결한 구조를 말합니다.

 

특징

• SOA (Service Oriented Architecture) *서비스 지향 아키텍처 스타일의 기법으로, 서비스를 기능의 독립적인 단위로 생각하고 접근하며 구조화합니다.
• 이러한 특성 덕분에 시스템 전체의 중단 없이 필요한 부분만 독립적으로 업데이트 혹은 배포가 가능합니다.
• MSA는 API를 통해서만 상호작용 할 수 있습니다.
  • 서비스의 접근점 (end-point)를 API 형태로 외부에 노출하고, 실질적인 세부사항은 모두 추상화하는 방식입니다.
  • 내부의 구현 로직, 아키텍쳐, 프로그래밍 언어, DB 등 기술 사항은 모두 서비스 API에 의해 가려지게 됩니다.
• 마이크로 서비스는 한 서비스 당 하나의 기능만 수행합니다.
  • 각 마이크로 서비스는 아키텍쳐의 일원으로 목표는 같지만 한 서비스의 단일 책임의 원칙이 적용됩니다.
• 서비스는 구현 기술과 무관합니다.
  • API를 이용하여 통신하기 때문에 서비스 구현 기술로부터 독립적입니다.
    • API 통신 대책 : REST API(Http), 메시지 큐(비동기 통신) : RabbitMQ, Kafka 등
  • 때문에 다양한 언어와 기술로 구축과 확장이 가능합니다.

 

장점

• 배포 : 서비스별 분리로 인한 개별 배포와, 특정 서비스의 요구사항을 반영한 신속한 배포가 가능합니다.
• 확장 : 특정 서비스에 대한 확장성이 유리합니다.
• 장애 : 일부 서비스 장애 발생에도 전체 서비스가 마비 될 가능성이 적으며, 부분 장애에 대한 대응이 수월합니다.
• 그 외
  • 분리된 서비스 구조로 인해, 새로운 기술(타 서비스와는 다른 언어 또는 기술로 구현)을 적용할 수 있습니다.
  • 각 서비스에 대한 구조 파악 및 분석이 쉽습니다.

 

단점

• 설계
  • MSA는 서비스가 모두 분산되어 있어야 하기 때문에 내부 시스템의 통신, 통신의 장애, 서버의 부하 등의 문제들을 고려하여 설계를 해야 하는 단점이 있습니다.
• 성능 : 서비스 간 호출을 API를 사용하기 때문에 통신 비용, Latency에 대한 이슈가 존재합니다.
• 데이터 :
  • 서비스 간 통신이 필수이기 때문에 데이터 간 트랜잭션을 유지하기 힘듭니다.
  • 데이터가 여러 서비스에 분산되어 있기에 관리가 힘듭니다.
• 테스트
  • 테스트 시 통합 테스트가 힘듭니다. (분리된 환경)
  • 그러므로 개발 환경과 실제 운영 환경을 동일하게 가져가기 어렵습니다.

 

---