스프링 클라우드 MSA

모놀로식 개발 vs MSA 개발

 

모놀로식 개발은 프로젝트에서 흔히 사용하는 모든 기능들이 하나의 서버로 동작하는 방식이다. 이 방식은 간편하지만, 오류 발생 시 모든 기능이 사용 불가능하다는 단점과 하나의 프레임워크로만 개발되어야 한다는 단점이 존재한다. 때문에, MSA 구조의 개발에 대한 관심이 생겼다.

 

 

MSA의 장점

1. 하나의 기능에서 오류가 발생해도 나머지 기능 사용 가능
2. 언어, 프레임워크를 기능별로 다르게 사용 가능(스프링과 express 등)
3. 서비스별 스케일링 가능

물론 장점만 존재하지는 않고, 초기에 구축하기 어려우며 분산 관리가 힘들다는 단점도 존재하긴 하지만, 그럼에도 불구하고 장점이 명확하기에 MSA를 공부하게 되었다.

 

 

 

사진 출처 : 스프링 클라우드 MSA 유튜브 강의 (강의자 : 개발자 유미)

스프링 클라우드 MSA의 구성 환경에 대한 그림이다. 

 

각각의 스프링 부트 서버는 해당하는 요청을 받아서 로직을 수행한다.

 

Spring Cloud Gateway(SCG)는 요청에 해당하는 서버로 요청을 보내게 된다. 예를 들어서 /user로 요청이 왔다면, 해당하는 컨트롤러의 서버에 요청을 보내주는 역할을 한다.

 

Eureka Server는 각각의 스프링부트 서버와 Gateway의 상태를 모니터링할 수 있는 서버이다. 여기에는 등록되어 있는 모든 서버의 정보가 뜨며, 각각의 서버에서 등록을 시켜주면 Eureka Client가 생긴다. 추가적으로 Spring Cloud Gateway에 요청을 분배하는 로드밸런싱 역할도 한다. 스프링 MSA는 scale out이 자동으로 이루어지는데, 부하가 커졌을 때 새로운 ip 주소를 SCG에 알려주는 역할을 Eureka Server가 수행한다.

 

application.yml나 공통으로 사용되는 것들을 제공해주는 Spring Config Server가 뒷단에 존재해, 특정 서버의 Config Client에 데이터를 전달한다.

 

변수들은 Spring Config Server에 들어있지 않고 여기는 서빙만 해주는데, 뒤에 있는 Config Repository라는 곳에 데이터가 있다. 보통 깃허브 리포지토리, redis와 같은 저장소를 사용한다. 여기서 특정 변수값을 수정하면 모든 서버에서 수정된 변수를 사용할 수 있다.