Spring Cloud Gateway

배경

클라이언트가 서비스A를 이용하기 위해 요청을 보낼 때 어떻게 처리해야할까? 서비스A의 IP 또는 URL로 HTTP 통신을 하면 된다. 다만, 서비스A가 동일한 서비스를 제공하는 서로 다른 IP를 가진 클러스터로 있다면 어떡할까? 매 요청마다 서비스A의 클러스터 중 어떤 서비스IP를 이용할지 결정하는 알고리즘이 필요할 것이다. 이 방식은 클라이언트와 서버의 의존도를 높이게 되고 각 서버를 마이크로 단위로 보기 힘들게 한다.

 

이러한 둘 간의 의존도를 낮춰줄 서버가 gateway서버다. 클라이언트는 서비스A의 물리적인 IP에 의존하지 않고 단지 논리적인 서비스A를 게이트웨이에 요청한다. 그럼 실제 어떤 IP로 서비스A를 요청할지 결정하는 건 gateway서버가 되는 것이다!

 

 

초간단 설정

의존성 추가

 

application.yml 설정

자바코드를 추가하지 않고 yml에 게이트웨이 정보를 추가하는 것만으로 서버를 구축할 수 있다. routes의 하위에 여러 라우팅 정보를 추가할 수 있다.

id : 라우팅 정보 id

uri : 실제 라우팅될 url

predicates : 라우팅 조건(handler mapping 정도로 보면 될 것 같다)

위예제는 요청url이 /hello인 경우 8080번 포트의 /hello로 요청을 라우팅하는 설정이다.

놀랍게도 다른 설정 또는 코드 없이 이 작업만으로 간단한 게이트웨이서버 구축이 끝난다...

 

predicates에 Method와 같은 다른 파라미터를 추가하는 것도 가능하다.

 

 

필터 추가하기

필터를 직접 작성할 수도 있지만 이미 만들어진 필터를 yml파일에서 추가할수도 있다.

filters에 AddResponseHeader로 key와 value를 지정했다. 간단하게 테스트를 해보면

헤더가 잘 추가된 걸 확인할 수 있다.

 

 

모든 라우터에 공통된 필터 적용하기

application.yml에 default-filters를 추가하면 모든 라우터에 적용되는 필터를 추가할 수 있다.

모든 라우터에 URL을 조작하는 필터를 넣었고 조작한 대로 URL이 rewrtie되어 잘 전달된 걸 확인할 수 있다.

 

 

Custom Filter 만들기

predicate은 대부분의 조건이 이미 만들어져 있고, 정말 디테일한 조건으로 매핑하지 않는 한 굳이 커스텀할 필요는 없어보인다(적어도 아직까지는). 하지만 filter같은 경우는 커스터마이징이 매우 크게 열려 있다. 일단 당장 프로젝트에 적용할 jwt인증 프로세스를 위한 AuthenticationFilter를 커스터마이징해 적용해보자.

 

커스터마이징한 필터는 AbstractGatewayFilterFactory를 상속했고 @Value를 사용하기 위해 빈으로 등록했다. 이제 추상메서드 apply를 구현한 뒤 원하는 요청에 필터를 추가해주기만 하면 된다. apply()내용을 보면 요청을 분석해 인증정보를 확인한 뒤 false를 return하면 response.setComplete()를 통해 요청을 마치는 걸 확인할 수 있다. 정상적으로 인증을 성공했다면 chain을 통해 다음 필터를 거치게 한다. 이제 이 필터를 요청에 추가해보자.

요청이 memberservice/**로 오는 요청이라면 커스터마이징한 AuthenticationFilter를 적용하지 않았다.

이와 달리 요청이 portfolioservice/**로 오는 요청이라면 AuthenticationFilter를 적용하도록 했다.

 

간단하게 테스트해보자.

 

인증필터를 거치지 않는 memberservice는 정상적으로 요청이 처리된 걸 확인할 수 있고 인증필터를 거쳐 인증이 되지 않은 상태인 요청인 portfolioservice는 401에러를 응답하는 걸 확인할 수 있다.

 

 

마치며

spring cloud를 사용하는 게 익숙지 않고 비동기 방식으로 깔끔하게 프로그래밍 하는 게 약간 어렵다. 좋은 코드를 많이 보며 배워야 할 것 같다. 우선 사용법부터 익히도록 하자. 최대한 빠르게!!