[Spring Cloud로 개발하는 마이크로서비스 애플리케이션]-API GATEWAY

API Gatewqy Service

• 일종의 Proxy 역할
  • 사용자가 설정한 라우팅 설정에 따라 각각 end point로 클라이언트 대신해서 요청하고 응답을 받으면 다시 클라이언트에게 전달을 해주는 일종의 proxy역할을 함
• 시스템의 내부 구조는 숨기고 외부의 요청에 대해 적절히 가공을 해서 응답을 할 수 있다는 장점
• Micro Service 내에 Micro Service들이 변경을 했을 경우?
  • 서비스들 끼리는 독립적으로 빌드, 배포 하니 상관은 없으 BUT, Micro Service의 주소에다 직접 요청을 하는 클라이언트 입장에서는 변경이 필요

위의 이유들로 인해서 Micro Service Application 개발 시 단일 진입점을 가지고 있는 형태로서 개발 되게 해야함!
이를 위해, Gateway 역할을 해주는 진입로를 넣어주고 Gateway는 Micro Service에 요청되는 모든 정보들을 일괄적으로 처리 하여줌

• 결론적으로, APP 및 WEB들은 직접적으로 Micro Service를 호출하는 것이 아닌 Gateway만 호출하면 됨!

주요 기능

• 인증 및 권한 부여
• 서비스 검색 통합
• 응답 캐싱
• 정책,회로 차단기 (클라이언트가 요청한 Micro Service에 문제가 생기면 그 회로를 차단)
• 속도 제한
• 부하 분산
  • ex) A라는 Micro Service가 3개의 인스턴스로 나뉘어 졌을 경우에도 판단 가능
• Logging,추적
  • 하나의 서비스가 다른 서비스를 호출하는 경우도 많은데 진입점 및 중간 단계를 거치고 그 다음 단계는 어디인지도 추적 가능 -> Logging하는 작업 필요! Api Gateway는 어떤 클라이언트가 어느 서비스에 요청했는지 로그 파일을 처리 가능
• IP 허용
  • 목록에 추가 허용할 수 있는 IP와 차단 IP 처리 (일종의 방화벽 처럼 사용 가능)

Spring History About Api Gateway

• restTemplate, Feign Client
  • spring cloud에서 msa간 통신을 위해 restTemplate , Feign Client를 개발하여 사용 했었음
  • 문제 : Load Balancer를 하기 위해 어떤 Service에 구축해서 작업할 것인가..
• Ribbon
  • Spring Cloud는 Load Balancer를 해주는 별도의 서비스를 위해 Netflix가 가지고 있는 기술일 Ribbon이라는 서비스를 제공
  • 클라이언트 측 내부에 Ribbon을 구축해서 사용
  • 클라이언트 안에서 이동하고자 하는 주소값을 직접 관리
  • ip:port를 명시 안해도 서비스를 이름만으로 호출 가능
  • 문제 : 비동기화 처리가 잘 되지 않음
    • maintenance 상태 (새로운 기능 추가 X)
    • Spring boot 2.4이상 버전 에서는 지원하지 않음
• Netflix Zuul
  • gateway의 역할을 해주는 서비스
  • 클라리언트가 직접 호출 하지 않을 수 있었음
  • Ribbon과 마찬 가지로 maintenance 상태 Spring boot 2.4이상 버전 에서는 지원하지 않음
• Spring Cloud Gateway
  • 비동기 처리 또한 가능 해짐
  • 동기 방식인 Tomcat 서버가 아닌 비동기 방식인 Netty 서버로 실행됨
  • 현재 널리 쓰임
    
    
• 비동기 방식?

• Reactive Programming
• blocking process로 동작하는 application을 non-blocking process로 동작하기 위해서 지원하는 programming
• 기존 Spring : Blocking 방식
  • Web 에서 서버에 요청이 왔을 때 서버는 요청에 대한 적절한 응답을 보내야 하는데 만약 작업이 오래 걸릴 경우에는 요청에 대한 응답이 모두 종료될 때 까지 Blocking 됐음.
  • 이런 이유로, Spring에서는 동시 요청 처리를 위해서 멀티 Thread를 지원 하였고 Thread마다 다른 요청을 할당 받아서 처리를 함.
  • 물론 요청을 동시에 처리하니 비동기 처럼 보일 수 있겠지만, Thread가 늘어 날수록 Thread할당에 필요한 Resource가 늘어나게 되어 비효율적!
• Spring 5 : Non-Blocking
  • Spring 5가 도입 되면서 클라이언트 요청에 별도의 Thread를 생성하지 않고 buffer를 사용해서 요청을 받고 요청을 Back단에서 처리하는 Thread를 둠.
    
• 그럼 왜 Non-blocking 방식이 사용될까??
  • IF, 수 천개의 Stream Data 가 초 당 계속 Update되는 시스템
  • 적절하게 응답을 해야하는 경우 기존의 Blocking 방식은 상당한 부하가 걸림 So, 부하를 효율적으로 처리하자라는 목적!

이상으로 포스팅을 마치겠습니다. 다음 시간엔 실제 Spring을 사용한 구현 및 필터 처리에 대해 알아보아요~ 감사합니다 :)

이 글은 인프런 이도원님의 'Spring Cloud로 개발하는 마이크로서비스 애플리케이션'을 수강하고 작성합니다.
출처: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/dashboard