9. API Gateway - Zuul

API Gateway

• 클라이언트와 백엔드 서버 사이의 출입문 (front door)
• 라우팅 (라우팅, 필터링, API 변환, 클라이언트 어댑터 API, 서비스 프록시)
• 횡단 관심사 (cross-service concerns)
  • 보안, 인증 (authentication), 인가 (authorization)
  • 일정량 이상의 요청 제한 (rate limiting)
  • 계층 (metering)

 

Netflix Zuul

• 마이크로 프록시
• 50개 이상의 AWS ELB의 앞단에 위치해 3개의 AWS 리전에 걸처 하루 백억 이상의 요청을 처리 (2015년 기준)
• Zuul 이중화 (L4 또는 ELB)

 

API Gateway - Zuul

1. Zuul의 모든 API 요청은 HystrixCommand로 구성되어 전달된다.
   • 각 API 경로 (서버군) 별로 Circuit Breaker 생성
   • 하나의 서버군이 장애를 일으켜도 다른 서버군의 서비스에는 영향이 없다
   • CircuitBreaker / ThreadPool의 다양한 속성을 통해 서비스 별 속성에 맞는 설정 가능
2. API를 전달할 서버의 목록을 갖고 Ribbon을 통해 Load-Balancing을 수행한다.
   • 주어진 서버 목록들은 RR으로 호출
   • Coding을 통해 Load Balancing 방식 Customize 가능
3. Eureka Client를 사용하여 주어진 URL의 호출을 전달할 '서버 리스트'를 찾는다
   • Zuul에는 Eureka Client가 내장
   • 각 URL에 Mapping된 서비스 명을 찾아서 Eureka Server를 통해 목록을 조회함
   • 조회된 서버 목록을 'Ribbon' 클라이언트에게 전달함
4. Eureka + Ribbon에 의해서 결정된 Server 주소로 HTTP 요청
   • Apache Http Client가 기본 사용
   • OKHttp Client 사용 가능
5. 선택된 첫 서버로의 호출이 실패할 경우 Ribbon에 의해서 자동으로 Retry 수행
   • Retry 수행 조건
     • Http Client에서 Exception 발생 (IO Exception)
     • 설정된 HTTP 응답코드 반환 (ex 503)

• Zuul의 모든 호출은...
  • HystrixCommand로 실행되므로 Circuit Breaker를 통해 장애 시 Fail Fast 및 Fallback 수행 가능
  • Ribbon + Eureka 조합을 통해 현재 서비스가 가능한 서버의 목록을 자동으로 수신
  • Ribbon의 Retry 기능을 통해 동일한 종류의 서버들로의 자동 재시도가 가능

 

Spring Cloud Zuul

• Spring Cloud Zuul은 기존 netflix-zuul을 감싸서 만든 것.
• 기본 isolation이 semaphore임. (Netflix Zuul은 threadpool)
• semaphore는 network timeout을 격리시켜주지 못한다 => spring-cloud-zuul의 isolation을 thread로 변경해야 함.
• semaphore 방식을 쓸 것인지, threadpool 방식으로 쓸 것인지 유의해야 함.

 

[참고 및 출처]

www.youtube.com/watch?v=6g1wH97BiuQ&list=PL9mhQYIlKEhdtYdxxZ6hZeb0va2Gm17A5&index=8