[MSA] APi gateway?

Application Programing Interface + GateWay

 

Api 인증 절차, 모니터링, 과도한 사용에 대한 제어의 기능을 해주는 Api gateway이다.

또한 msa구조에서 gateway 패턴은 가장 흔하고 유용하게 쓰는 패턴중 하나이다.

 

 

 

API gateway는 하나의 모든 클라이언트의 요청이 하나의 서버로 들어와,

해당 서버에서 요청이 정제 되거나 조작되어 각자 목적에 맞는 서비스를 찾아가도록 도와주는 방식이다.

즉, 분배,인증,로깅 등등을 통합적으로 앞단에서 관리해주는 역할을 한다.

좀더 자세히 얘기하면

 

1. 프록시의 역할과 로드밸런싱

2. 인증 서버로의 기능

3. 로깅 서버로서의 기능

 

단점으로는 아래와 같다.

 

1. 병목현상 (전체 시스템의 성능이나 용량이 하나의 구성요소로 인해 제한을 받는것) -> 적절한 스케일 아웃이 필요

2. 네트워크 Latency -> 하나의 데이터 패킷을 한지점에서 다른 지점으로 보내는데 소요되는 시간

 

 

 

Eureka 상황상, 각각의 이루카 클라이언트들은 이루카 서버에 자신들의 위치 정보를 등록, 서버는 위치를 파악하는 구조이다.

만약에 특정 고객이 A서버에서 물건을 고르고, B에서 주문하고 C에서 배송을 하면?

그러면 각각의 서버들은 다른 서버들의 정보를 모두 알아야한다.

 

 

 

A라는 서버에서 주문을 호출하면, 주문의 정보를 가지고 호출하는 것이아니라

게이트웨이를 통해서 호출한다면?? -> 해결된다.

 

이러한 경우에, 마이크로 서비스들은 서로의 포트번호를 몰라도된다.

Front에서는 요청을 gateway로만 보내면 되고, gateway포트만 알면 모든 요청을 수행 할 수 있다.

모든 요청은 gateway를 거치기 때문에 로그를 쉽게 다룰수 있다.

gateway가 요청의 진입점이므로 통합 인증 수행이 가능하다.

 

Netfilx Zuul은 MVC와 tomcat을 이용, 비동기 통신로직에 취약

-> Netty 서버를 내장한 Web Flux 기반 Gateway인 Spring Cloud Gateway를 만듦

 

Spring Cloud Gateway

-Route : 목적지의 URI와 Predicates라는 조건들의 목록 그리고 필터들을 이용하여 어떤 곳으로 Routing할 것인지 명시

-Predicate : 경로에 대한 조건 지정, Filter경로를 패턴으로 먹이듯이 맥인다

-Filter : 들어오는 요청,응답, Request,Response를 특정 필터를 타게 함으로, 우리가 원하는 방식으로 요청을 보내거나

헤더를 조작할 수있고, 해당 필터를 이용해서 로그파일을 작성할 수 있다.

 

 

1. Client는 Spring Cloud Gateway에 요청을 보냄

2. Gateway Handler Mapping에서 해당 요청에 대한 Route,Predicate가 일치하면

해당 요청은 Gateway Web handler로 보내진다.

3. handler에서 Filter Chain을 이용해서 사전 필터, 사후 필터로 나누어 동작한다.

4. 필터링 된 후 실제 마이크로 서비스에게 전달한다.

 

 

Spring Cloud Gateway 내부 구조

 

1. Gateway Handler Mapping

-gateway가 Client로 부터 어떤 요청이 왔는지, 확인하고 Mapping 하는 작업

 

2.Predicate

-Handler Mapping 시에 필요한 Uri정보, Path정보를 확인하는 주체

 

3. Filter

- Handler Mapping이 된 후, 들어온 요청에 대한 필터 작업을 수행할 수 있다.

- 2개의 필터로 크게 나뉘며, 사전과 사후 필터로 나뉜다.

 

 

 

참고, Gateway도 하나의 서비스 일 뿐이다.

 

 

다만 이런 정보로 하게되면, gateway에서 직접 서버에 대한 주소를 잡아서

라우팅 시키는 것이다. 즉, 로드밸런싱에 대한 건 불가하다

 

그러면 로드 밸런싱 효과가 있는 유레카 서버를 사용해서 진행해보자

 

 

gateway를 해당 같이 변경하면,

id, url 을 유레카 서버에서 받아오게 되고, 해당 서버에서 준값으로 사용하기 때문에

포트번호가 변경되거나 uri가 변경됨에 따라 해당 파일을 다시 작성하지 않아도된다.

 

즉, 유레카 쪽에서 클라이언트에 대한 서비스 위치를 관리하고

게이트 웨이에서는 유레카 쪽에 등록된 application -name 으로 만 Predicate값을 비교하여

넘긴다!