[MSA] Api Gateway 개념 & Logging Filter 적용

Msa에서 게이트웨이 역할을 하는 Api gateway에 대해서 알아보자

관련 설정은 이전 포스팅에 자세히 다뤘으니, 이번에는 개념과 필요성 그리고 전반적인 개념에 대해서 알아보자

 

MSA는 큰 서비스를 잘게 쪼개어 개발/운영 하는 아키텍쳐이다.

하나의 큰 여러 서비스를 클라이언트가 직접 호출하는 형태라면? 아래와같은 이슈가 발생한다.

 

-각각의 서비스마다 인증/인가 등 공통된 로직을 구현해야한다.

-수많은 API 호출을 기록,관리 해야한다.

-클라이언트에서 여러 마이크로 서비스에 대한 번거로운 호출을 해야한다.

-내부 비즈니스 로직이 드러나게 된다.

 

이건, 서비스 개수가 많아질수록 기하급수적으로 늘어난다.

 

그래서! 이렇게 API gateway를 하나 두는 것이 효과적이다.

 

 

API gateway는 soa의 핵심인, ESB에서 시작되었으나, SOAP/XML 기반이 아닌, REST/JSON기반으로 보다 가볍게 설계되었다.

 

 

1.인증 및 인가

마이크로 서비스 아키텍처에서 각각의 서비스에 API 호출에 대한 인증 및 인가를 하는 것은, 

같은 소스코드를 서비스 인스턴스들마다 심어주어야 한다는 것을 의미한다.

이러한 경우, 소스의 중복이 심하여, 유지관리가 어려운 것은 물론, 로깅 및 모니터링을 관리하는 것도 매우 어려워진다.

이러한 이유로 인증서 관리,인증,SSL,프로토콜 변환과 같은 기능들은 API gateway에서 오프로드 함으로, 각각의 서비스의 부담을 줄이고 서비스의 관리 및 업그레이드를 보다 쉽게 할 수 있다.

 

2.요청 절차의 단순화

여러 마이크로서비스를 대상으로하는 기능을 이용하려 할때 만약 API gateway가 없다면,

클라이언트에서 여러 서비스들에 대해 요청을 진행해야한다.

하지만 API gateway는 여러 클라이언트의 요청을 단일 클라이언트의 요청으로 대체 가능하다.

즉, 클라이언트가 굳이 여러 서비스를 호출하는 것이 아닌, api gateway만 호출하여, 서비스를 이용할 수 있다.

 

3.라우팅 및 로드밸런싱

API gateway는 클라이언트로 부터 접수된 메세지에 따라, API호출을 적절한 서비스에 라우팅 할 수 있는 기능이 있다.

또한 서비스 인스턴스들에 대한 부하 분산을 할 수도있다.

 

4.서비스 오케스트레이션

오케스크레이션은 여러개의 마이크로 서비스를 묶어 새로운 서비스를 만드는 개념입니다.

오케스트레이션 로직을 과도하게 넣으면, API gateway의 부담을 늘리고 성능저하를 일으킬 수 있어, 조심해야한다.

 

5.서비스 디스커버리

API gateway는 각 서비스를 호출하기 위해, 서비스마다 IP 주소와 포트번호를 알고있어야 한다.

유레카나, 서비스 디스커버리를 하는 다른 모듈을 사용해서, 해당 모듈에서 서비스에 대한 IP를 받아와서 라우팅한다.

대부분 유동이라, 유레카나 다른 곳에서 정보를 받아와서 사용하지만, 고정으로 박히는 경우에는 사실 그냥 API gateway에

수동으로 작성해도 된다. 그래서 API gateway에서도 서비스 디스커버리에 대한 구현도 가능하다는 것이다.

 

 

고려 해야하는 사항

- API gateway 스케일 아웃 적용이 유연하지 않으면, 병목 지점이 되어 어플리케이션의 성능 저하가 발생할 수 있다.

- 추가적인 네트워크 계층이기 때문에,추가적인 네트워크 latency가 증가한다

 

 

 

우선 SpringCloud Gateway의 동작 방식이다.

Gateway Handler Mapping으로 경로를 체크하고, Gateway WebHandler로, 요청과 관련된 곳으로 보낸다.

이때 필터를 거치게 되는데, 필터는 프록시 요청이 보내지기 전후에 나눠서 로직을 수행하게 된다.

Proxy Filter는 프록시 요청이 처리될 때 수행한다.

 

GatewayFilter는 크게 Global GatewayFilter와 GatewayFilter로 나뉘며

차이는 조건부냐 전역이냐 이다.

 

* 라우트 : 라우트는 고유ID, 목적지 URI, 조건지 목록, 필터 목록으로 정의 된다. 모든 조건자가 충족됬을때만 매칭 된다.

* 조건자 : 각 요청을 처리하기 전에 실행되는 로직, 헤더와 파라미터 값, 경로 등 다양하게 HTTP요청이 정의 된 기준에 맞는지를 확인한다.

* 필터 : 다운스트림으로 요청을 전송하기 전,후에 요청과 응답을 수정할 수 있다.

 

정리하면, 요청자가 요청을 보내면 해당 URI경로를 HandlerMapping으로 일치하는 경로를 찾고

Web Handler를 통해 필터체인으로 전송, 필터에서 전후 처리 해주고, 해당 서비스로 라우트를 시켜주는 것이다.

참고로 필터에는 일반 필터와 프록시 요청이 처리될때 수행되는 프록시 필터가 존재한다.

 

 

 

<실습>

단순 GlobaFilter, log로 찍어야 맞지만, Sl4j에 대한 의존성 주입이 귀찮아서 그냥, 일단 이렇게 테스트

단순히 GlobaFilter에 대한 구현체를 만들고, 빈으로 등록하면, 글로벌 필터로 동작을 한다.

application.yml에 등록할 필요도 없다.

다만 해당 동작이 수행하고, return chain.filter하기 때문에  preFilter라고 할수 있다.

잠시, ServerWebExchange라는 인터페이스, Mono라는게 뭔지 알고 가자

 

- ServerWebExchange :  req,res에 대한 값, applicationcontext등, 쉽게말하면 해당 시점에 상태값으로 이해하면 편하다.

ServletContext의 개념과 유사

-Mono : Flux와 유사하지만, 0~1개의 값만 처리하기 위한 객체이다. Reactive 프로그래밍에서 유래한 개념이다.

 

 

post 필터를 구현해보면 이렇다.

결론적으로, 스프링 빈으로 등록이 되면 필터처리해야되는 것들

즉 이번에는 post이기때문에, chain.filter(exchange) 이후, 제어하는 동작에 대한 반응을 하게 된다.

 

추가로, preFilter에서, 2개의 필터의순서를 정하고싶을때는 각각 Order을 지정해주면된다.

 

 

다음은 특정 라우터에서만 필터를 적용하고 싶을때 사용하는 방법이다.

해당 케이스에서는 FilterFactory, AbstarctGatewayFilterFactory를 사용하면된다. 

AbstractGatewayFilterFactory 를 상속 받고, 해당 apply메소드를 구현하면된다.

 

이런식으로 필터 팩토리를 상속받아서 apply메서드를 구현하면된다.

 

 

 

이런식으로 application.yml으로 필터를 설정할 수도있다.

이렇게 디면 글로벌 필터가 아닌 특정 경로에 대한 필터도 적용할 수 있다.

 

추가로 간단하게 application.yml으로 cors 필터 정책을 적용할 수도있다.

참고하도록 하자!