[MSA] Spring Cloud를 사용해보자(1)-MSA개념

스프링클라우드를 이용하기에 앞서 MSA 개념부터 짚고 넘어가고자 한다.

 

✔ MSA 개념

MSA란 무엇일까..? 요새 어떤 요구사항을 봐도 MSA라는 단어를 심심찮게 볼 수 있다.

그만큼 많은 기업들이 MSA(Microservices Architecture) 아키텍쳐에 관심을 가지고 도입하는 추세이다.

과연 기존과 어떤 점이 차별화 돼 있길래 이 MSA 아키텍쳐를 사용하는걸까?

 

먼저, 과거를 보자.

기존 대부분의 기업용 애플리케이션은 하나의 거대한 서비스 형태로 개발되어 왔다.

이 형태는 모놀리식 아키텍쳐(Monolithic Architecture, MA)라는 개념을 기반하며,

UI 부터 DB접근까지가 하나의 애플리케이션으로 패키징되고 서버에 배포되어 왔다.

 

이에 대응하기 위해 MSA개념이 떠오르기 시작했다.

경량화되고 독립적인 여러 개의 서비스를 조합하여 애플리케이션을 구현하는 방식으로,

서비스마다 자체 데이터베이스 엑세스를 가지고 동작하는 방식이다.

 

참조 https://foot-develop.tistory.com/17

 

 

 

단순히 그림만 보곤 뭐가 좋고 나쁜지 잘 모르겠으니,

명확하게  MA vs MSA의 장단점을 비교해 보자.

 

	MA	MSA
장점	- 서비스의 환경이 동일하여 복잡하지 않아 개발에 용이하다. - end-to-end 테스트가 용이하다.	- 애플리케이션이 커지더라도, 서비스별로 관리 하기 때문에 빠른 빌드, 배포가 가능하다. - 서비스별로 책임을 분담하였기 때문에, 수정사항 발생 시 해당 서비스만 수정하여 빌드/배포하면 된다. - 서비스별로, 원하는 기술스택을 이용해서 개발이 가능하다.
단점	- 애플리케이션의 커질수록 빌드부터 배포까지의 시간은 더욱 늘어난다. - 작은 수정사항이라도 전체를 빌드/테스트/배포 하여야 한다. - 강한 의존성으로 인해, 부분의 오류가 전체로 영향을 끼칠 수 있다.	- 애플리케이션이 확장될수록, 서비스가 확장돼 복잡도가 늘어난다. - 서비스가 분리돼있기 때문에, 테스트시 많은 비용이 든다. - 데이터가 여러 서비스를 거치기 때문에, 데이터의 정합성을 보장하기 어렵다.

 

24시간 서비스를 하며 트래픽이 많이 발생하는 B2C 서비스일 수록, 빠르게 서비스를 제공하고 트래픽을 분산하여야 하기 때문에, MSA 아키텍쳐는 거의 필수사항이 되어 가고 있다. 

 

 

자, 그럼 MSA의 구조에 대해 본격적으로 한번 파악해보자.

참조 https://foot-develop.tistory.com/17

 

✔ API Gateway

• MSA는 서비스가 각기 다른 IP와 Port를 가지며 분산배포되어 있다. 클라이언트가  각각의 서비스의 정보를 관리하고 호출하는 것은 엄청 큰 부담이 따른다. 여기서 API Gateway라는 녀석이 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 한다. 즉, 클라이언트의 요청을 API Gateway가 자신의 IP와 Port로 모든 요청을 받고 각각의 서비스들로 포워딩을 해주는 것이다. 이외에 Filter를 통해 인증, 인가 처리로 가능하며, 로드밸런싱 등 다양한 역할을 담당하게 된다.

 

✔ Service

• 각각의 서비스는 DB를 구성하고 빌드/배포되어 독립적으로 분산돼 있다. 따라서 서비스마다 기술스택이 다를 수 있고 각각의 IP와 Port를 가지고 작동하는 minimal한 Monolithic Architecture로 볼 수 있으며 서로 다른 서비스 컴퍼넌트에 대해 의존성은 없지만, 다른 서비스의 API를 호출해 데이터를 가져와야 한다.

 

 

참고

https://foot-develop.tistory.com/17