Spring boot - Spring Cloud Gateway(SCG) 란?

MSA에서 코드를 구성하는 방식은 여러개가 있다.

 

그 중 피할 수 없는 건 프론트-백엔드간의 연계이다.

 

이렇게 생각해보자.

 

당신은 쇼핑몰 웹을 운영중이다.

이 쇼핑몰 앱은 여러개의 백엔드 API가 있을 것이다.

 

그 중에는 동일한 서비스(도메인)의 주소도 있을 것이고, 아예 다른 도메인도 있을 것이다.

 

예를 들어, 제품에 대한 API를 제공하는 Product 라는 서비스가 있고, 또 결제를 담당하는 payment 라는 서비스가 있을 수 있고, 결제 완료나 안내사항을 작성하는 Notification 이라는 서비스도 있을 수 있다.

 

이 모든 것을 하나의 서비스에 몰아둘 수 있지만, 그건 MSA 철학에 맞지 않는다. 아주 높은 확률로 다른 서비스로 떠 있을 것이다.

 

이때 당신의 프론트 엔드가 백엔드를 호출하는 상황을 가정해보자.

 

사용자가 처음 웹 페이지를 방문할 때는 제품 정보를 받아오기 위해 API를 호출한다.

const response = await fetch('http://localhost:8081');

 

그리고 제품을 고르고 결제를 한다면 다시 다른 서비스의 API를 호출한다.

const response = await fetch('http://localhost:8082');

 

결가 완료되었다면 그 안내를 위한 다른 서비스의 API를 호출한다.

const response = await fetch('http://localhost:8083');

여기서 편의상 localhost라고 적었지만 실제 도메인을 사용한다면 더욱 복잡해질 것이다.

 

만약 payment의 주소가 바뀐다면?

모든 코드의 호출 주소를 바꿔야 한다.

 

거기에 보안가지 생각해야 한다.

JWT 방식으로 사용자에게 토큰을 주어 사용자 식별을 한다고 가정해보자.

 

그럼 product 서비스는 jwt를 분석할 수 있는 로직이 있어야하고, 

또 payment또한 jwt를 분석할 수 있는 로직이 있어야한다.

물론 notification또한 동일하다.

 

이처럼 많은 중복 포인트와 복잡한 로직, 수정의 어려움을 겪게 되는데, 그때 사용하면 좋은 것이 Spring Cloud Gateway(이하 SCG)이다.

 

간단히 말해, 프론트(브라우저)와 백엔드 사이에 SCG를 둠으로,

프론트의 입장에서 연결될 백엔드는 오로지 SCG하나밖에 없으니 모든 코드를 이렇게 바꿀 수 있다.

const response = await fetch('http://localhost:8081'); -> const response = await fetch('http://localhost:8080');

const response = await fetch('http://localhost:8082'); -> const response = await fetch('http://localhost:8080');

const response = await fetch('http://localhost:8083'); -> const response = await fetch('http://localhost:8080');

 

거기에 jwt에 대한 검증도 마찬가지다.

기존에는 각기 모든 백엔드 서비스가 jwt에 대한 유효성 검사로 자체적인 jwt분석 로직이 있거나, 요청때마다 별도의 auth 서비스를 오고가야 했다면, 이제는 프론트 입장에서 단일 진입점은 SCG이므로, SCG에서 jwt의 유효성을 검사하고 맞는 사용자라면 별도의 헤더로 백엔드에 내려줄 수 있다.

 

예시로 test@test.com 이라는 유저가 결제 요청을 했다고 해보자.

이 API요청에는 jwt토큰또한 들어있을 것이다.

 

기존에는 payment 서비스가 jwt를 분석하고, 유효성을 판단하며, jwt안에 있는 test@test.com 이라는 유저의 Id나 Email을 뽑아내어 사용했다면, 

 

이제는 SCG가 jwt유효성을 검사하고 헤더값에 (X-User-Id: test@test.com) 이라는 헤더를 넣어 payment에 주면 된다.

 

그럼 payment 서비스는 SCG를 신뢰하여 jwt분석로직 없이 오로지 헤더의 test@test.com 이라는 값만 사용하여 비지니스 로직을 짜면 된다.

 

물론 백엔드는 SCG가 JWT검증 후 내려주는 별도의 헤더를 신뢰한다면 그것이 변조 되는 것(해킹)을 고려해야 한다.

백엔드 자체에 jwt 분석 및 검증 로직이 있다면 상관없지만, SCG를 통해 헤더로 X-User-Id 를 받기만 하면 되면, 반대로 집어넣기만 하면 통신이 된다는 의미이기 때문이다.

 

고로 백엔드가 외부에서 직접 접근 가능하다면 보안에 취약함으로, 백엔드 서비스는 SCG를 통한 접근만 가능하도록 내부망 격리, 혹은 네트워크 정책으로 막아야할 필요성은 분명 존재한다.