API Gateway설명과 Ingress와의 차이점을 비교한다.

API Gateway 분석

목적

Endpoint에 대한 정보를 가진 API 관리 서버
네트워크 외부의 트래픽을 수락하고 내부 서비스에 배포하는 것이 목적

주요 기능

Authentication, Authority, Routing, Load Balancing, Mediation, Aggregation, Logging,....

Security 역할

마이크로 서비스로 접근하는 Public IP를 Private IP로 변경하여 보안성을 높인다.
악의적인 접근이나 DDos 공격을 예방할 수 있다.
보안을 위해 API Gateway는 Static IP나 도메인을 사용하고 Keys, Tokens, IP filtering을 통해 API를 보호한다.

Protocol Adaptor 역할

새로운 프로토콜(ex. Web socket, HTTP/2)로 접속하는데 서비스에서는 지원이 안된다면
API Gateway에서 이를 호환되는 버전의 프로토콜로 변경한다.

오픈소스 솔루션

• Kong Gateway(https://konghq.com/kong/)
• Zuul(https://github.com/Netflix/zuul)
• Apache APISIX(https://apisix.apache.org/)
• tyk(https://tyk.io/)
• Ocelot(https://github.com/ThreeMammals/Ocelot)
• Goku(https://github.com/eolinker/goku-api-gateway/blob/master/README.md)
• Express Gateway(https://www.express-gateway.io/)
• Gloo(https://docs.solo.io/gloo-edge/latest/)
• WSO2(https://wso2.com/)

API Gateway와 Service Mesh 비교

서비스 메쉬(Service Mesh)

네트워크 내부에서 트래픽을 라우팅하고 관리하는 것이 목적
서비스 메쉬에서 호출은 Proxy를 통해 이루어진다.
Proxy는 서비스 내부가 아닌 Sidecar 형태로 구성되어 서비와는 별개로 실행된다.
장애 발생 파악이 용이하다.

• 주요 기능

  요청 라우팅 제어
  서킷 브레이크(계단식 장애 방지)
  부하 분산
  보안(TLS, 암호화, 인증 및 권한 부여)
  서비스 메트릭 제공

API Gateway와 Service Mesh 비교

Service Mesh, API Gateway 공통 기능

검색, 요청, 인증, 요청량 제한, 모니터링등의 기능

Service Mesh, API Gateway 동시 사용

Service Mesh와 API Gateway는 함께 작동하여 외부 트래픽을 효율적으로 수락 한 다음 해당 트래픽이 네트워크에 있으면 효과적으로 라우팅할 수 있다.
API Gateway는 인증, 에지 라우팅등의 기능을 처리하고 Service Mesh는 아키텍처에 대한 세밀한 관찰 및 제어를 할 수 있다.
Docker, K8s를 사용하는 마이크로 서비스 아키텍처를 관리하는 방식이 늘어남에 따라 Service Mesh와 API Gateway 기능이 병합될 가능성이 높다.
API Gateway의 기능이 Service Mesh로 흡수되어 점점 더 적게 사용될 것으로 예측된다.

에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.

API Gateway와 Ingress Gateway 비교

Service Mesh는 클러스터 내의 트래픽 흐름을 조정, 모니터링, 보안설정 하기 위해 만들어졌다.
API Gateway는 외부의 트래픽을 받아 내부 어플리케이션 서비스로 라우팅하기 위해 만들어 졌다.

Ingress

Ingress는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출한다.
트래픽 라우팅은 Ingress 리소스에 정의된 규칙에 의해 컨트롤된다.
외부에서 서비스로 접속이 가능한 URL, 로드밸런스 트래픽, SSL/TLS, Name 기반의 가상 호스팅을 제공하도록 구성할 수 있다.
Ingress 컨트롤러는 일반적으로 로드 밸런서를 이용해 Ingress를 수행하며 트래픽을 처리하는데 도움이 되도록 에지라우터 또는 추가 프론트엔드를 구성할 수 있다.

Istio Ingress Gateway

Istio Ingress는 클라이언트의 요청을 받아 Mesh내의 어플리케이션 서비스로 라우팅하는 API Gateway 구현체이다.

API Gateway와 Istio Ingress Gateway 특징 비교

사용 환경이 아래 기능에 부합된다면 API Gateway로 Istio Ingress Gateway를 Service Mesh와 함께 사용해도 된다.

• Traffic routing, Request routing
  프로세스 관점에서 Traffic은 얼마나 많은 Mb/s를 받았는지
  Request는 얼마나 많은 트랜잭션이 발생했는지

• API Call Aggregation
  SOA에서는 Orchestration(오케스트레이션)이라고 불렀는데, 여러개의 API를 묶어서 하나의 API로 만드는 작업을 말한다.
  예를 들어서, 계좌 이체를 한다고 했을때,
  ① A은행에서 잔액 확인
  ② A은행에서 인출
  ③ B은행으로 입금
  3개의 API 호출을 하나의 API 인 POST Transfer(인출계좌,입급계좌,금액)으로 구현할때 이를 API 게이트웨이에서 구현 하면 다음과 같은 형태로 구현할 수 있다.
  

  여기서의 이점은
  클라이언트와 서비스 간의 데이터 전송량을 줄이고
  게이트웨이는 클라이언트 요청을 받고 다양한 백엔드 시스템에 요청을 전달해 결과를 집계한 다음 클라이언트에게 보낸다.
  따라서 백엔드 시스템에 대한 어플리케이션 요청 수를 줄이고 대기 시간이 긴 네트워크에서 어플리케이션 성능을 향상시킬 수 있다.

  이러 패턴이 필요한 경우는
  클라이언트가 작업을 수행하기 위해 여러 백엔드 서비스와 통신해야 하는 경우
  클라이언트가 대기 시간이 긴 네트워크를 사용하는 경우
  사용이 부적합한 경우는
  여러 작업에서 클라이언트와 단일 서비스 간에 호출 횟수를 줄이고 싶은 경우
  클라이언트 또는 어플리케이션이 백엔드 서비스 근처에 있고 대기 시간이 중요한 요소가 아닌 경우

이러한 aggregation 기능이 좋아보이지만, 하나의 플로우에서 여러 API를 호출해야 하고, 비지니스 로직을 수행하면서 실제로 API 메세지 BODY까지 파싱해야 하기 때문에, API 게이트 웨이 입장에서는 부하가 매우 크다.
MSA 의 전신인 SOA에서 API 게이트웨이와 유사한 역할을 했던 ESB역시 이러한 aggregation을 남발해서, ESB의 성능이 떨어져서 시스템 개발이 실패하는 경우도 있었다.

내용 보완

Ingress

Ingress는 클러스터 외부에서 내부 서비스로 접근하는 HTTP, HTTPS 요청을 어떻게 처리할지 정의해둔 규칙들의 모음
K8s는 기본적으로 L4레이어로 TCP단에서 Pod를 로드밸런싱한다.
K8s 서비스 하나가 하나의 URL로 대표되는 경우가 많다(/member, /product)
그래서 MSA 서비스 간 라우팅을 하기 위해서는 API게이트웨이를 넣는 경우가 많은데,
URL기반의 라우팅 정도라면 API게이트웨이처럼 무거운 아키텍쳐 컴포넌트가 아닌 L7 로드밸런서 정도로도 라우팅이 가능하며, 이때 필요한게 바로 쿠버네티스 Ingress다.
만약 Ingress가 없다면 외부에서 들어오는 트래픽을 처리할 수 있는 것은 NodePort, ExternalIP가 있다.
서비스를 외부로 노출시켜야 한다면 Ingress를 사용하는 것이 바람직하다.

Ingress-controller

Ingress는 추상화 단계(yaml)
Ingress Controller에서 규칙을 적용(nginx, kong)
Ingress(yaml)에서 규칙을 정의해서 Ingress-controller(nginx)에 배포하는 개념

Ingress-controller 서비스

클라우드 환경에서는 load balancer 타입을 사용하는 것이 일반적이다.
온 프리미스 환경에서는 NodePort 서비스로 사용한다.

Ingress 주요 기능

외부로부터 들어오는 요청에 대한 로드밸런싱, TLS/SSL 인증서 처리, 도메인 기반 가상 호스팅, 라우팅

Ingress with TLS

HTTPS 통신을 지원
1)X509를 이용해서 SSL 인증서(인증키) 생성
2)생성된 인증키를 이용해 secret 생성
3)생성된 secret에 대한 정보를 Ingress에 yaml 파일에 tls 항목으로 추가
4)Ingress 규칙을 설정해 Controller에 배포하고 서비스 PORT를 조회해 보면 80, 443이 조회됨
5)사용자는 HTTPS://svc/user 형태로 접속 가능

API Gateway, Service Mesh

API Gateway는 외부에서 들어오는 트래픽에 대한 제어를 담당한다. (North-South)
Service Mesh는 서비스간 통신을 위한 것이다.(East-West)
API Gateway와 Service Mesh는 프록시 같은 기술을 기본적으로 공유하고 있어 기능이 중복된다.
또 트래픽 제어, 라우팅, 메트릭 수집, 보안/정책 적용등도 기능이 중복된다.
Istio 같은 Service Mesh는 Ingress Gateway를 가지고 있어 더 혼란스럽다.
하지만 본래 만들어진 목적이 다르다.
Service Mesh만으로도 Ingress Gateway를 갖고 있기에 Service Mesh 하나만 써도 된다.
API Gateway에는 Ingress에 없는 좀더 고급 기능들이 있기에 필요하면 API Gateway를 같이 써도 된다.
트래픽 제어, A/B 테스트등
유명한 사람이 말하기를 점점 더 API Gateway, Ingress, Service Mesh의 경계가 없어지고 있다고 한다.

참고
https://geekflare.com/api-gateway/
https://daddyprogrammer.org/post/13700/service-mesh/
https://banzaicloud.com/blog/backyards-api-gateway/
https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/
https://bcho.tistory.com/1005
https://docs.microsoft.com/ko-kr/azure/architecture/patterns/gateway-aggregation