학교에서 짧게 진행할 프로젝트에서 MSA를 적용해야한다. 근데 난 아직 MSA가 뭔지 잘 모르기에... 이참에 정리하고 넘어가자!
✅ Monolithic Architecture?
- 모든 업무 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스
- 애플리케이션에서 사용하는 데이터가 한 곳에 모여 참조되어 서비스되는 형태
- 대규모 단일 코드 베이스를 빌드/배포
장점
일단 상대적으로 운영하기가 용이하다. (코드 관리, 장애 관리, 로그 관리, 모니터링 등등) 내부 메소드 호출로 성능 문제 없고 트랜잭션 관리가 용이하다.
단점
스케일 아웃 시 전체 시스템을 확장해야하기에 비효율적이며, 빌드/배포 시간 오래 걸린다. 작은 수정에도 전체 시스템 빌드/배포해야 하고, 하나의 버그에 전체 시스템 실패할 수도 있다. 기능들 간의 결합도가 높아 기능 변경 시 영향도 파악 어렵다.
-> 코드가 운영환경에 민첩하게 배포되기가 어렵다
종류
Single Monolith System
가장 일반적인 형태의 Monolithic
Modular Monolith System
각 기능별로 모듈화 되어 있는 형태로 각각의 모듈의 결합도를 제어, 관리할 수 있어 MSA의 좋은 대안이 될 수 있다.
하지만 아직 배포와 확장에 대한 이슈는 여전히 존재하고 데이터에 대한 이슈(결합도)도 존재한다. 이 시스템의 장점을 취하기 위해서는 모듈 간의 결합도를 자주 관리해야 한다.
Distributed Monolith System
분산된 Monolith System이다. 단순히 쪼갰다고 해서 MSA는 아니고, 쪼개진 서비스 간에 매우 강결합이 된 형태로 항상 같이 배포되는 형식이다.
따라서 아직은 영향도, 결합도 등 Monolith의 단점 모두 가지고 있다. 그리고 네트워크를 통한 협력에 의한 성능 저하, 관리가 어려움 등 분산 시스템의 단점도 존재한다.
✅ Microservice Architecture
애플리케이션을 자율적인 다수의 서비스로 분리하여 개발하는 방식이다.
각자 별도의 프로세스에서 실행되며, HTTP API 같은 가벼운 매커니즘으로 통신하는 작은 애플리케이션으로 구성되어 있다.
작은 서비스들은 각자의 비즈니스 기능을 담당하고, 완전히 자동화된 절차에 따라 독립적으로 배포된다.
각 서비스는 서로 다른 프로그래밍 언어나 서로 다른 데이터 저장 기술을 사용할 수 있다.
장점
빠른 Delivery
각 서비스는 독립적으로 개발되고 느슨하게 결합된다. 서비스가 작기 때문에 코드 수정에 대한 영향 범위가 상대적으로 작다. (빠른 빌드, 빠른 테스트 등)
각 서비스들은 네트워크를 통한 Interface로 느슨히 결합된다.
탄력적이고 선택적인 확장
작은 서비스 단위로 확장이 가능하고, 각 서비스는 코드 베이스가 작아 확장 비용이 상대적으로 저렴하다.
Polyglot Architecture 지원
모놀리틱 아키텍처는 조직의 표준 기술을 만들고 모든 조직에 강제였다면 MSA에서는 Polyglot 아키텍처를 제공해 특정 task에 가장 적절한 기술을 적용할 수 있다.
단점
- 운영 관리가 어렵다.
- 성능이 내부 호출보다 느리다.
- 모니터링 대상이 증가한다.
- 다양한 장애 상황이 발생한다.
- 단위 테스트 컴포넌트 테스트 난이도가 증가한다.
- DB 트랜잭션 처리가 어렵다.
- 서비스 간 다른 Polyglot data store를 사용한다.
특징
분산된 데이터 관리
- MSA는 해당 서비스의 데이터를 각자 관리한다.
- 서비스는 서로 다른 데이터 저장 기술 사용이 가능하다(Polyglot Persistence)
- 각 서비스는 API를 통해서만 다른 서비스의 데이터에 접근이 가능하다.
- 트랙잭션 처리가 어렵고 결과적 일관성을 적용해야 한다.
인프라 자동화
다수의 서비스와 인스턴스가 존재하는 환경에서는 자동화가 필수이다.
- 자동화된 테스팅
- 자동화된 CI/CD
장애 방지 설계
특정 서비스의 장애는 항상 일어나고 다른 서비스로 전파가 되기 때문에 이상 동작을 최대한 신속하게 알 수 있어야하고, 가능하면 자동으로 복구할 수 있도록 해야한다.
✅ SOA VS MSA
그럼 SOA(Service Oriented Architecture)와 MSA는 뭐가 다른가
| SOA | MSA | |
|---|---|---|
| 공유 지향점 | 재사용을 통한 비용 절감 (서비스 공유 최대화) | 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응(서비스 공유 최소화) |
| 기술 방식 | 공통의 서비스를 ESB에 모아 사업 측면에서 공통 서비스 형식으로 제공 | 각 독립된 서비스가 노출된 REST API를 사용 |
참고
마이크로서비스 아키텍처의 핵심개념과 핵심 기술 및 아키텍처 패턴, MSA(MicroService Architecture)
스프링 클라우드 마이크로서비스
