[MA & MSA & SOA] 개념, 장단점, 차이점
아키텍처를 구상할 때, MSA 아키텍처에 대해 많이 이야기 하는데, 이에 대해 조금 더 개념적인 정리를 하면서, 연관된 개념들 역시 같이 정리해보았다.
MA
MA(Monolithic Architecture)란?
- 모놀로식 아키텍처.
- 전통 아키텍처를 지칭하는 것으로, MSA(MicroService Architecture, 마이크로서비스 아키텍처)와 반대되는 말.
- 하나의 서비스 또는 어플리케이션션이 하나의 거대한 아키텍처를 가질 때, 모놀로식 아키텍처라고 한다.
특징
- 모놀로식 아키텍처를 갖는 소프트웨어는 내부 요소 간의 의존성이 강하다.
- 각 비즈니스 컴포넌트들이 강한 결합 구조를 가지고 있으며, 통일성이 있다.
→ 비즈니스 로직이 서비스에 최적화된 코드를 만들어 내는데 좀 더 집중할 수 있으나, 복합적인 예외를 만들 수 있는 위험성 역시 내포하고 있다.
- 자동화된 테스트가 필수. (CI/CD)
장점 및 단점
장점
- 모놀로식 아키텍처의 가장 큰 장점은 심플함이다. 개발 초기 단순한 아키텍처 구조와 개발에 용이.
- 어떤 서비스든지 개발되어 있는 환경이 같아 복잡하지 않다.
단점
- 프로젝트 규모가 커짐에 따라, 어플리케이션션 구동 시간이 늘어나고, 배포 시간도 길어진다.
- 조그마한 수정 사항이 있어도, 전체를 다시 빌드하고 배포해야한다.
- 많은 양의 코드가 몰려 있어, 개발자가 모두 이해하기 어렵고 유지 보수 역시 어렵다.
- 여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 때문에 수정에 대한 영향도 파악이 힘들며, 일부분의 오류가 전체에 영향을 끼치기도 한다.
- 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기 까다롭다.
- 사용되지 않는 다른 모든 서비스가 Scale-out되어야 하기 때문에 부분 Scale-out이 어렵다.
⇒ 이러한 한계점을 극복하고자 기존의 특정한 물리적인 서버에 서비스를 올리던 on-promise 서버 기반의 Monolithic Architecture에서 이제는 클라우드 환경을 이용하여 서버를 구성하는 MicroService Architecture로 많은 서비스들이 전환되고 있다.
MSA
MSA(MicroService Architecture)란?
- 작고 독립적인 서비스들의 집합으로 구성된 어플리케이션션 구조.
- 확장성과 유지 관리가 용이해진다.
특징
- 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다.
→ 하나의 목표를 향해 일하지만, 자기가 개발하는 서비스만 책임진다.
- 여러 어플리케이션션에서 재사용할 수 있어야한다.
- ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않고, REST 등 가벼운 통신 아키텍처 또는 Kafka 등을 이용한 Message Stream을 주로 사용한다.
- API를 통해서만 상호 작용 할 수 있다.
- 서비스의 End Point를 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다.
→ 내부 구현 로직, 아키텍처와 프로그래밍 언어, 데이터 베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 가려진다.
장점 및 단점
장점
- 서비스별로 독립적 배포가 가능하다.
- 서비스별 부하에 따라 개별적으로 scale-out이 가능하다.
- 팀 단위로 기술 스택을 다르게 가져갈 수 있다.
- 각각의 서비스는 모듈화 되어있으며, 모듈끼리는 RPC 또는 Message-Driven API 등을 이용하여 통신한다.
→ 각각 개별의 서비스 개발을 빠르게 하며, 유지보수도 쉽게 할 수 있다.
단점
- 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템 통신에 대해 고민해야 한다.
- 서비스를 나눠서 데이터 중복이 발생할 수 있고 정합성을 보장하기 어렵다.
- 모놀로식에서는 단일 transaction을 유지하면 됐지만, MSA에서는 비즈니스 DB를 가지고 있는 서비스도 각기 다르고 서비스 연결을 위해 통신이 포함되기 때문에 트랜잭션 유지가 어렵다.
- 통합 테스트가 어렵다.
모놀로식과 마이크로서비스의 서버 확장 비교
공통점
- 사용자 트래픽이 몰려 서비스를 안정적으로 유지하기 위해서는, 어플리케이션션을 실행하는 서버를 추가함으로써, 수평적으로 확장한다. (Scale-out)
- 클라이언트에서 요청이 들어오면 로드밸런서(LB)를 두어서, Scale-out 방식으로 서버를 추가하여 확장.
차이점
- 모놀로식의 경우, 모든 서비스(모듈)가 하나의 어플리케이션션으로 배포되기 때문에 특정 서비스에만 트래픽이 발생해도 서버를 추가할 때는 모든 기능이 담겨진 어플리케이션션의 사본을 생성해 이를 운영하는 서버를 추가해서 Scale-out을 해야하며, Scale-up을 위해서도 각 호스트 서버의 자원(CPU, RAM)을 늘려 확장해야 한다.
→ 이로 인해 코드의 무결성을 체크하기 위해 많은 테스트를 거쳐야 하며 기술적 부채가 늘어나게 된다.
- 마이크로서비스의 경우, 각 기능마다 서버와 DB가 존재하기 때문에, 특정 서비스에 트래픽이 몰리면 해당 서비스에 대한 Scale-out, Scale-up만 진행하면 되며, 다른 서비스에 대한 무결성을 지킬 수 있다.
→ 기술 부채의 감소, 개발자 생산성 및 속도 향상, 테스트 효율성 증가, 확장성 증가
⇒ MSA를 보다 보니, SOA의 부분 집합으로 다루어진다고 하는데, 그렇다면 SOA는 무엇일까?
SOA
SOA(Service Oriented Architecture)란?
- 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크 상에 연동하여 시스템 전체를 구축해 가는 방법론
- 문제 영역을 서비스로 나누고, SOAP 기반 통신을 사용하며, 사용자는 ESB(Enterprise Service Bus)를 통해 메세지를 전송.
→ 그러나 ESB에 장애가 발생하면 서비스 작동이 잘 안 될 수 있으며, 서로 통신도 불가함.
마이크로서비스와 SOA 차이
- 중앙 집중적인 EBS 대신 Restful 기반으로 통신하는 마이크로서비스는 무거운 미들웨어 통신 채널이 필요 없고, 경량화된 메시징을 통해 각 서비스 중심으로 처리.
- SOA는 가능한 공유가 중요하다는 원칙을 믿기 때문에 서비스 간 리소스 공유를 촉진 시켜, 서비스간 결합을 증가시킨다. 또한 일반적으로 서비스끼리 DB를 공유하지만 마이크로 서비스는 서비스마다 각각의 DB를 가진다.
⇒ 그렇다면 MSA가 좋아보이는데, 어떻게 구성해야하는 건가?
MSA 아키텍처 개요
개요
크게 Inner Architecture와 Outer Architecture로 나눌 수 있다.
Inner Architecture
- 내부 서비스와 관련된 아키텍처. 즉, 어떻게 내부 서비스를 잘 쪼갤지에 대한 설계.
- 고려할 부분
- 마이크로 서비스를 어떻게 정의할 것인가?
- 비즈니스 특성에 따라 서비스를 어느 정도로 분리할지 등을 고려할 필요가 있다.
- 그 외에도 서비스 간 종속성, 배포 용이성, 장애 대응, 운영 효율성 등 다양한 관점에서 고려해야 한다.
- DB Access 구조를 어떻게 설계할 것인가?
- 마이크로서비스는 각 서비스별 DB를 가질 수 있는데, 일부 트랜잭션의 경우, 여러 서비스를 걸쳐 있기 때문에 정합성을 보장할 수 있는 방안에 대해 고려할 필요가 있다.
- 서비스 내 API를 어떻게 설계할 것인가?
- 등등.. 비즈니스마다 특성이 다르기 때문에 정해져 있는 정답이 없고, 그래서 어렵다.
Outer Architecture
- 총 6개의 영역으로 분류
- External Gateway
- Service Mesh
- Container Management
- Backing Services
- Telemetry
- CI/CD Automation
- External Gateway
- 전체 서비스 외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기 위한 요소.
- 사용자 인증과 권한 정책 관리를 수행하며, API Gateway가 핵심적인 역할을 담당한다.
- Service Mesh
- 마이크로서비스 구성 요소 간 네트워크를 제어하는 역할
- 서비스 간 통신을 위해서는 Service Discovery, Service Routing, 트래픽 관리 및 보안 등을 담당하는 요소가 있어야 하는데, Service Mesh는 모두 수행.
- Container Management
- 컨테이너 기반 어플리케이션 운영(Kubernetes)
- 컨테이너 기반의 운영은 유연성과 자율성을 가지며, 개발자가 손쉽게 접근 및 운영할 수 있기 때문에 MSA에 적합
- Backing Services
- 어플리케이션이 실행되는 가운데 네트워크를 통해서 사용할 수 있는 모든 서비스
- 데이터베이스, 캐시 시스템, SMTP 서비스 등 어플리케이션과 통신하는 attached resource들 지징하는 포괄적 개념
- 데이터 변경이나 보상 트랜잭션과 관련된 처리는 송신자와 수신자가 직접 통신하지 않고 Message Queue를 활용한 비동기 처리하는 것이 가 효율적이기 때문에 MSA는 이를 지향.
- Telemetry
- 마이크로서비스가 분산 환경에서 운영되는 경우가 많기 때문에, 서비스들을 모니터링 하고 서비스별 발생 이슈에 대응할 수 있는 환경을 구성하는 역할.
- 실시간으로 먼 거리에서 원격으로 측정할 수 있는 기능.
- 서비스 상태 모니터링.
- CI/CD Automation
- 어플리케이션 개발 단계를 자동화하여, 어플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법
- 자동화하는 것은 배포가 잦은 MSA에 필수적인 요소.
=>
나도 이분 글(링크)처럼 스스로 msa 아키텍처에 대해서 작성해 보아야겠다.
* 참고 글 *