[MSA] MSA
Micro Service Architecture
하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐
-
장점
서비스 별로 배포가 용이함.
서비스를 확장하기 용이함 (클라우드 서비스에 적합한 아키텍쳐)
부분적인 장애를 격리하기 쉬움
-
단점
서비스가 분리되어 있어 테스트와 트랜잭션 복잡도가 증가한다.
데이터가 여러 서비스에 걸쳐 분산되어있기 때문에 중복이 있고 관리가 어렵다.
각각의 마이크로서비스는 하나의 모놀리틱 아키텍쳐와 유사하며, 독립적으로 배포가 가능하여야 한다. 각 서비스는 다른 서비스에 대한 의존성이 최소화 되도록 한다.
MSA 구성요소
1. API Gateway
MSA는 수십,수백개의 작은 서비스로 나뉘어져 운영되며, 만약 이를 클라이언트에서 서비스를 직접 호출하는 형태라면 다음과 같은 문제점이 생길 수 있습니다.
- 각 서비스마다 인증/인가 등 공통된 로직을 구현해야하는 번거로움
- 수많은 API 호출을 기록하고 관리하기 어려움
- 클라이언트에서 여러 마이크로 서비스에 대한 번거로운 호출을 해야 함
- 내부 비즈니스 로직이 드러나 보안에 취약해짐
API Gateway의 주요 기능
- 인증 및 인가
- 요청 절차의 단순화
- 라우팅 및 로드밸런싱
- 서비스 오케스트레이션
- 서비스 디스커버리
API Gateway에서 고려할 점
- API Gateway는 Scale-out 적용이 유연하게 적용하지 않을 경우 병목지점이 되어 성능 저하가 일어 날 수 있음.
- 추가적인 계층이 만들어지기 떄문에 네트워크 latency가 증가함.
2. Service Mesh
마이크로 서비스간의 통신을 담당하는 요소.
Service Mesh의 주요 기능
- Service Discovery
- 로드밸런싱
- 동적 라우팅
- Circuit Breaking
- 암호화(TLS)
- 보안
- Health check, Retry and Timeout
- Metric 수집
API Gateway와 차이점
API Gateway | Service Mesh | |
---|---|---|
네트워크 | 마이크로 서비스 그룹의 외부 경계에 위치 | 마이크로 서비스 그룹 내부에 위치 |
아키텍쳐 | 중앙 집중형 아키텍쳐 | 분산형 아키텍쳐 |
프록시 패턴 | Gateway proxy pattern | Sidecar proxy pattern |
로드밸런싱 | 단일 엔드포인트를 제공하고 요청을 내부 요소에 redirection하여 내부 요소가 처리함 | Service Registry에서 서비스 목록을 수신함 |
3. Backing Service
네트워크를 통해서 사용할 수 있는 모든 서비스, MySQL, 캐쉬 시스템 등 어플리케이션과 통신하는 리소스들을 지칭하는 포괄적인 개념
메시지 큐를 활용한 비동기 통신 패턴을 사용
하나의 트랜잭션이 여러 마이크로 서비스들과 강하게 결합되어 처리하는 방식의 경우 진행 중인 트랜잭션이 끊어지면 해당 서비스 요청을 보존할 수 없음.
Message Queue를 활용하여 서비스의 영속성을 유지할 수 있음
4. Telemetry
서비스들의 상태를 모니터링하고 서비스별로 발생하는 이슈들에 대응할 수 있도록 환경을 구성하는 역할