MSA 아키텍쳐

---

MSA는 마이크로 서비스 아키텍쳐의 줄임말로, 아키텍쳐 스타일 중 하나다. 

 

다시말해 마이크로 서비스로 기능 단위로 잘게 나누어 서비스 간이 연결을 뜻하고,

이는 전체 시스템이 커질수록 서비스가 많아져 연결이 복잡해지는 문제점을 낳게 된다.

 

따라서 서비스 간의 연결 구조를 파악하기 어려우며, 장애가 났을때 추적이 어렵고,

장애가 확산되면서 다른 서비스에 영향을 주는 문제가 생기곤 한다.

 

예를 들어 클라이언트→ 서비스 A → 서비스 B의 호출 구조가 있다고 하자. 만약 서비스 B가 느려지거나 응답이 없는 상태가 되어 버리면, 서비스 B를 호출 하는 서비스 A 안의 쓰레드는 서비스 B로 부터 응답을 기다리기 위해 대기 상태가 되고, 이 상태에서 클라이언트에서 호출이 계속 되면, 같은 원리로 서비스 A의 다른 쓰레드들도 응답을 받기 위해서 대기 상태가 된다. 이런 상태가 반복되면, 서비스 A에 남은 쓰레드는 없어지고 결과적으로 서비스 A도 응답을 할 수 없는 상태가 되서 장애 상태가 된다. 이런 현상을 장애 전파 현상이라고 한다.

 

이러한 문제들을패턴화하고 풀어내기 위한 방법으로 디자인 패턴으로 묶기 시작했다.

분산 시스템에 대한 로그 수집등 다양한 패턴들이 있는데, 이는 https://microservices.io/ 를 참고하면 좋다.

 

참고로, 장애 확산을 막기 위한 예로 Netflix에서 개발한 써킷 브레이커(Circuit Breaker)라는 디자인 패턴으로 해결할 수 있다.

이는 Hystix(https://github.com/Netflix/hystrix/wiki)라는 오픈 소스로 공개가 되어있다.

 

>>(예시) 써킷브레이커 

 

Netflix에서는 Hystix 외에도 서비스 디스커버리 패턴은 Eureka, 모니터링 서비스인 Turbine 등 다양한 오픈 소스를 공개했다.

 

서비스 매쉬

프록시

이러한 MSA 서비스 문제를 풀기 위해서는 인프라 측면에서도 풀기 위한 노력이 서비스 매쉬라는 아키텍쳐 컨셉이다.

 

서비스와 서비스 간의 호출이 있을때, 직접 서비스들이 호출을 하는 것이 아니라 서비스마다 프록시를 넣는다.

그렇게 하면 서비스로 들어오거나 나가는 트래픽을 네트워크 단에서 모두 통제가 가능하고, 트래픽에 대한 통제를 통해 문제를 해결할 수 있다.

 

이런 다양한 기능을 수행하기 위해서는 기존의 HA Proxy,nginx, Apache 처럼 TCP 기반의 프록시로는 한계가 있다. 예를 들어서 위에서 언급한 HTTP 헤더 기반의 라우팅이나 조금더 나가면 메세지 본문을 기반으로 하는 라우팅들이 필요하기 때문에, L7 계층의 지능형 라우팅이 필요하다.

 

그러면 서비스 매쉬는 만능인가?

그렇지도 않다.

서비스 수가 증가함에 따라 프록시 수도 증가하기 때문에, 프록시에 대한 설정을 하기 어려워진다는 것이다.

 

그래서 이런 문제를 해결하기 위해서, 각 프록시에 대한 설정 정보를 중앙 집중화된 컨트롤러가 통제하는 구조를 취할 수 있다. 

 

각 프록시들로 이루어져서 트래픽을 설정값에 따라 트래픽을 컨트롤 하는 부분을 데이타 플레인(Data Plane)이라고 하고, 데이타 플레인의 프록시 설정값들을 저장하고, 프록시들에 설정값을 전달하는 컨트롤러 역할을 하는 부분을 컨트롤 플레인(Control Plane) 이라고 한다. 

 

이러한 서비스 매쉬 구조를 구현한 오픈 소스 솔루션인 Istio가 있다.

 

---

[참고 자료]

MSA 구조

https://bcho.tistory.com/m/1293

Istio #1 - 마이크로 서비스와 서비스 매쉬

https://medium.com/microservices-in-practice/service-mesh-for-microservices-2953109a3c9a

Service Mesh for Microservices

https://bcho.tistory.com/1005

MSA 아키텍쳐 구현을 위한 API 게이트웨이의 이해 (API GATEWAY)

 

API 게이트웨이

https://medium.com/microservices-in-practice/service-mesh-vs-api-gateway-a6d814b9bf56

Service Mesh vs API Gateway

https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-

applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

API 게이트웨이 패턴과 클라이언트-마이크로 서비스 간 직접 통신

 

---