마이크로 서비스 아키텍처와 모놀리식 아키텍처
마이크로 서비스 아키텍처는 기존의 통합 관점의 단일 시스템(Monolithic Architecture)을 서비스 단위로 나누고 분리하는 개념 입니다. 아래는 기존의 모놀리틱 아키텍처의 구조와 마이크로 서비스 아키텍처의 구조입니다.

[그림] 모놀리식 아키텍처와 마이크로 서비스 아키텍처
위 그림에서 보여지는 것과 같이 기존의 모놀리식(Monolithic, 이하 모놀리식) 아키텍처는 하나의 어플리케이션 내에 모든 로직이 들어가 있는 구조 입니다. 모놀리식 구조의 이점은 하나의 어플리케이션 내에 모든 기능이 모여있어 소규모 서비스의 개발에 적합하며, 아래와 같은 몇 가지 장점이 존재합니다.
[모놀리식 아키텍처의 장점]
- 개발과 배포, 관리의 편이성
- End-to-End 테스트 용이성
- 전체 구조 파악 용이
그러나 대형 서비스 개발에는 여러 문제점이 발생합니다.
[모놀리식 아키텍처의 단점]
- 빌드와 배포 시간의 증가
소규모 시스템에서 문제되지 않던 빌드와 배포, 테스트까지 커진 규모와 함께 많은 시간이 소요됩니다. 최근에 강조되는 CI/CD(지속적인 통합/배포)에 문제점이 노출됩니다.
- 개발 언어의 종속적
전체 어플리케이션이 개발된 언어 외에 특정 기술에 특화된 언어를 이용한 컴포넌트를 추가하는것이 매우 어렵습니다.
- 선택적 확장의 불가능
원하는 컴포넌트만 확장할 수 없고, 프로젝트 전체를 통째로 확장해야 합니다. 이로인하여 전체 프로젝트가 확장됨에 따라 다시 아래와 같은 문제도 발생됩니다.
- 단일 컴포넌트의 전체 시스템 성능 영향
각 컴포넌트들이 어플리케이션 내에서 로컬 콜(Call-By-Reference) 기반으로 긴밀하게 연결되어 있기 때문에, 특정 컴포넌트나 모듈에서의 문제가 전체 시스템의 문제나 장애로 이어질 수 있습니다. 커진 규모에 따라 개인이 전체 시스템의 구조와 특성을 이해하는 것은 어려워 집니다.
마이크로 서비스 아키텍처의 등장
각 기능들이 긴밀하게 연결되어있는 모놀리식 아키텍처와는 달리 마이크로 서비스 아키텍처는 관련 있는 관계의 컴포넌트끼리는 묶는데, 이를 서비스라 부르며 잘게 나뉘어 묶여진 서비스들은 독립된 서버로 구성되고 타 컴포넌트와의 의존성 없이 독립적으로 개발하고 배포될 수 있습니다. 마이크로 서비스 아키텍처는 아래 같은 장점이 있습니다.
[마이크로서비스 아키텍처의 장점]
- 빌드와 배포 시간의 단축
모놀리틱 아키텍처와 달리 나뉘어진 각 서비스 별로 빌드와 배포가 가능하기 때문에 전체 시스템의 크기와 상관없이 짧은 CI/CD가 가능하게 됩니다.
- 폴리글랏(Polyglot) 구조의 구성
상황에 맞게 특정 기술을 유연하게 적용할 수 있습니다. 서비스 별로 특정 기술에 용이한 기술로 서비스를 구성할 수 있습니다. 예를 들어 시간당 TPS(Transaction Per Second)가 높고 읽기 작업이 많은 서비스에는 Node.js 와 Redis 를 통해 구현하고, 안정성과 트랜잭션이 중요한 서비스에는 Spring과 RDB를 적용하여 구성할 수 있습니다.
- 탄력적이고 선택적인 확장성
필요에 따라 작은 단위로 나뉘어진 서비스를 선택적으로 확장할 수 있습니다. 특정 서비스의 사용률이 증가하면 그 서비스의 독립적인 확장(Scale Out)이 가능합니다.
- 타 서비스에 영향을 주지 않는 서비스
각 서비스 별로 물리적인 서버를 나누어 놓기 때문에 하나의 서비스의 장애가 타 서비스에 영향을 주지 않습니다.
마이크로 서비스의 단점
하지만 마이크로 서비스 아키텍처의 분리된 서비스로 인해 생기는 이점 외에 단점도 존재합니다.
[마이크로서비스 아키텍처의 단점]
1. 성능 이슈
모놀리틱 아키텍처에서는 컴포넌트 간 상호작용이 필요할때 로컬 콜에 의해 직접 메소드를 호출하지만 마이크로 서비스 아키텍처에서는 주로 RestAPI 와 같은 HTTP 를 사용하게 됩니다. 이는 네트워크로 연결된 각 서버들의 통신으로 각 서비스들의 호출이 일어난다는 것을 말하며 이는 네트워크 성능에 의해 서비스 상태가 좌우됨을 의미하게 됩니다.
2. 관리 포인트의 증가
하나의 어플리케이션만 관리하면 되는 모놀리틱 아키텍처와 달리 마이크로 서비스 아키텍처에서는 나뉘어진 서비스의 수와 각 서비스의 인스턴스 수 만큼 관리해야하는 대상이 늘어나게 됩니다. 운영에 있어 꼭 필요한 로깅, 모니터링, 배포 등의 관리가 점점 어려워 지고 부담스러워질 수 밖에 없습니다.
3. 장애 대응의 어려움과 전파
이렇게 나뉘어진 서비스들의 관리도 복잡해진 연결구조로 인하여 장애 발생 시 서로 다른 서비스를 호출하는 구조의 특성으로 장애 경로 추적과 디버깅이 어려워 지고, 장애가 발생한 서비스로 인해 타 서비스를 호출하는 로직이 수행되지 않아 결과적으로 다른 서비스도 동작하지 않는 장애 전파 현상이 발생합니다. (** 장애 전파 현상의 경우 써킷 브레이커(Circuit Breaker)라는 디자인 패턴으로 해결이 가능.)
'최신기술 > MSA' 카테고리의 다른 글
서비스 매시 아키텍처(Service Mesh Architecture) (0) | 2021.01.26 |
---|