클라우드 마이크로 서비스 - API Gateway Service(Netflix Zuul)1

API Gateway Service

• Netflix Ribbon과 Zuul
• Spring Cloud Gateway - 기본
• Spring Cloud Gateway - Filter
• Spring Cloud Gateway - Eureka 연동
• Spring Cloud Gateway - Load Balancer

API Gateway Service는 사용자가 설정한 라우팅 설정에  따르는 엔드 포인트이다. 즉  클라이언트 대신에 요청하고  응답을 받으면 클라이언트에게 전달 다시 응답 결과를 전달해주는 Proxy 열할을 하게 된다. 시스템의 내부 구조는 숨기고 외부 요청에 대해서 적절한 형태로 가공된 응답을 할 수 있다는 장점을 가지고 있다.

 

마이크로 서비스가 각각의 엔드포인트를 가질 때

• 새로운 마이크로 서비스가 추가된 경우
• 기존에 있던 마이크로 서비스의 주소가 변경된 경우
• 파라미터 인자값이 변경된 경우 

 

 

API Gateway를 활용한 마이크로 서비스

위 3가지 경우에는 마이크로 서비스의 경우 독립적으로 빌드되고 배포 장점을 가지기 때문에 문제가 없다. 문제는 클라이언트 사이드에 존재한다. 클라이언트 사이드에서 각각 마이크로서비스의 주소(엔드포인트)를 직접이용해서 호출했을 경우에는  클라이언트 사이드에 있는 어플리케이션도 같이 수정 배포가 이루어 져야 한다. 그래서 단일 진입점을 가지는 것이 필요하게 되었다.

 

서버단에 게이트웨이 역할을 해 줄 수 있는 일종의 진입로 역할을 해 줄 수 있는 게이트웨이를 하나 두고 서버안 에 존재하는 각각에 마이크로 서비스로 요청되는 모든 정보에 대해서 일괄적으로 처리할 수 있게 되는 것이다. 클라이언트가 어떤 식이 되었든 마이크로 서비스를 직접 호출하지 않고 클라이언트는 게이트웨이만 상대하는 것이다. 따라서 게이트웨이에서 필요로하는 정보를 변경하고 갱신하는 작업이 훨씬 더 쉬워 질 것이다. 

 

API Gateway 역할

• 인증 및 권한 부여
• 서비스 검색 통합
• 응답 캐싱
• 정책, 회로 차단기 및 Qos다시 시도
• 속도 제한
• 부하 분산
  • 마이크로 서비스가 가지고 있는 A라는 서비스 내용을 3개의 인스턴스가 나눠서 작업을 했다고 가정하자. 이때 어떤 클라이언트로 부터 A 서비스에 대한 요청이 전달이 되었을때 3개의 A 서비스 인스턴스중 어느 인스턴스로 갈지에 대한 판단도 API Gateway가 해 줄 수 있다.
• 로깅, 추적, 상관 관계
  • 마이크로 서비스는 하나의 서비스가 다른 서비스 연관적으로 연쇄적으로 호출하는 경우가 많다. 그렇기 때문에 어떤 마이크로 서비스가 누구에 의해 호출이 되었으며, 처음 진입점은 누구였고, 중간 단계는 누구였고, 그다음 단계는 어디로 이동되는지 등의 추적 관계가 상당히 중요하다.
  • 일괄적으로 로깅하는 작업도 필요한데 각각의 마이크로 서비스가 하나의 솔루션에 의해 로깅될 수도 있다. 로깅만 전문적으로 처리하는 시스템의 예시로는 ELK같은 것들이 있다.
  • API Gateway에서 직접 로그를 기록한다고 하면 어떤 클라이언트가 접속을 했는지, 어디로 이동이 됐는지, 어떤 마이크로 서비스가 사용되었는지에 대한 로그 파일도 단일화해서 처리할 수가 있다.
• 헤더, 쿼리 문자열 및 청구 변환
• IP 허용 목록에 추가

마이크로 서비스에서도 외부에 있는 모든 서비스로 부터 다 데이터를 받는 것이 아니라 일종의 방화벽 이나, 프록시 역할을 해주는 게이트 웨이를 통해서 들어온 정보만 처리하겠다는 설정을 등록할 수도 있다. 

 

Netflix Ribbon

- 스프링 클라우드에서 MSA간 통신

 

1) RestTemplate

REST 템플릿은 전통적으로 하나의 웹 어플리케이션에서 다른 어플리케이션을 이용하기 위해 자주 사용되었던 API이다.

RestTemplate restTemplate = new RestTemplate();
restTemplate.getForObject("http://localhost:8080/",User.class,200);

 

위 코드에서 처럼 RestTemplate 타입의 인스턴스를 하나 만든다. 그리고 생성한 인스턴스를 활용해 사용하고자 하는 GET 메소드나 POST 메소드 형식에 맞는 함수를 호출하고 거기에 파라미터로 접속하고자 하는 서버의 주소와 기타 파라미터를 전달한다. 이렇게 하면 필요한 외부 서비스와 연동 할수 있다.

 

2) Feign Client

스프링 클라우드에서는 페인클라이언트라는 API를 이용해서 마이크로 서비스 인스터스 호출이 가능하다.

@FeignClient("store")
public interface StoreClient{
    @RequestMapping(method = RequestMethod.GET,value="/stores")
    List<Store>getStores();
}

 

우선 인터페이스를 하나 만들고 @FeignClient() 애노테이션을 이용해서 웹으로 호출하고 싶은 마이크로 서비스의 이름을 등록한다. 만약에 user서비스에서 페인클라이언트를 등록하고 store서비스를 호출하겠다고 하면 이전 게시물  <클라우드 마이크로 서비스 - Eureka Service Discovery>에서 application.yml을 작성한 거처럼 직접적인 서버의 주소라든가 포트 번호 없이 마이크로 서비스 이름을 사용해서 해당 서비스를 호출할 수 있게 된다. 즉 user라는 서비스에서 store 서비스에 에 있는 메서드는 자신의 메서드 처럼 사용할 수 있게된다. 

 

 

- Ribbon : Client side Load Balancer

 

스프링 클라우드에서 FeignClient를 사용해서 마이크로 서비스간의 호출을 해 왔다. 근데 Load Balancing을 하기 위한 기능 구현을 위치를 호출을 하는 곳이어야 하는지  호출이 되는 곳이어야 하는지 꾸준히 문제가 되어 왔다. 그래서 초창기 스프링 클라우드에서는 이런 Load Balance 역할을 해주는 별도의 서비스로 Ribbon을 이용했다. MSA의 편의를 위해 제공된 다른 여타의 서비스와 마찬가지로 Netflix가 가지고 있던  Load Balance 기술력이 Ribbon이라는 서비스로 완성되어서  스프링 클라우드 제단에 기부되었다.

 

• 서비스 이름으로 호출
  • 리본이라는 서비스를 이용하게 되면서 마이크로 서비스의 이름을 가지고 클라이언트가안에서 필요한 데이터를 호출 할 수 있게 되었다. 
• Health Check
  • 호출할 서비스가 정상적으로 작동 중인지 확인할 수 가 있게 되었다.

 

Ribbon이라는 서비스의 문제점은 Functional API 와 같은 비동기 방식과는 호환이 잘 되지 않는 방식이다. 이 것이 이유가 되어 최근에는 사용 점유율이 떨어지는 추세이다.

 

 

 

 

클라이언트가 직접적으로 마이크로 서비스에 있는 내용을 호출하는 방식은 좋지 않다. 그래서 앞서 언급한것 처럼 클라이언트와 각각의 마이크로 서비스 사이에는 API Gateway를 중간에 두는 것이 이상적이다. 하지만 리본 서비스 이용시 별도의 시스템을 구축하지 않고 클라이언트측 내부에 해당 서비스를 구축해 사용한다. 즉 리본은 클라이언트 사이드에서 사용할 수 있는 Load Balancer로 클라이언트 프로그램 안에서 이동하고자 하는 마이크로 서비스의 주소값을 직접 관리한다.

API Gateway와 가 하는  작업이 클라이언트 사이드로 이동 수행되는 것이라고 이해하면 쉽다. 클라이언트에는 외부에 있는 마이크로 서비스를 호출하기 위해 IP혹은 포트번호 같은 서버의 주소를 명시하지 않아도 마이크로 서비스 이름만 가지고도 해당 서비스를 호출할 수 있다는  장점이 생긴다. 하지만 최근에 스프링 클라우드 리본은 더 이상 사용하지 않고 다음 버전에도 해당 기능이 쓰일지 말지 확실하지 않은 상태이다.

 

💡Maintenance 상태

모듈을 유지 관리 상태에 두는 것으로써 스프링 클라우드 팀에서 더 이상 이러한 모듈에다가 새로운 기능을 추가하지 않는다는 뜻이다. 문제가 생길 경우 보완이 될 수도 있지만 다음 버전의 스프링 클라우드에서 빠질 수도 있다.

 

 

Netflix Zuul 구현

간단하게 API Gatewary가 어떻게 작동하고 있는지 살펴 본다.

 

구성 

• First Service
• Second Service
• Netflix Zuul : Gateway 역학을 해주는 제품이다.

 

클라이언트는 퍼스트 서비스나 세컨드 서비스를 직접 요청을 하는 것이 아니라 넷플릭스 줄에 데이터 요청을 보내면 넷플릭스 줄이 그 요청을 퍼스트 서비스  또는 세컨드 서비스로 보내주는 역할을 하게 될 것이다. API 게이트 역할과 동일한 작업을 하게 된다고 보면 된다. 리본과 마찬가지로 스프링 부트 2.4에서는 maintenance 상태이다.

 

https://spring.io/blog/2018/12/12/spring-cloud-greenwich-rc1-available-now

Spring Cloud Greenwich.RC1 available now

 

 

 

[출처 - Spring Cloud로 개발하는 마이크로 서비스 애플리케이션, 저 Dowon Lee]

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의