Kong API Gateway + 기타 Gateway 솔루션 비교 (KrakenD, SCG, Tyk, Gloo Edge, APISIX, Ocelot)

Kong API Gateway (콩)

공식 Github
공식 홈페이지
참고 사이트

Kong은 단순한 인프라부터 복잡한 다중 클라우드 환경까지 배포된 API를 관리하기 위한 인기있는 오픈소스 API 게이트웨이입니다. (엔터프라이즈 제품도 존재합니다.)
REST, GRPC, GraphQL과 같은 다양한 프로토콜을 처리할 수 있습니다.

📌 특징

• Nginx + Cassandra + Lua Script 기반
• 밀리초 미만의 처리 대기 시간 지원 및 높은 처리량, 고성능
• 풍부한 플러그인
  • Lua script로 custom plugin제작이 가능하고 kong-pongo를 통한 unittest, integration test가 가능합니다.
  • 플러그인을 통해 로드밸런싱 로깅, 인증, 속도제한, 변환 등을 제공합니다.
• 클라우드 네이티브
  • 플랫폼에 구애받지 않으며 베어메탈에서 컨테이너에 이르기까지 모든 플랫폼에서 실행할 수 있고, 모든 클라우드에서 기본적으로 실행할 수 있습니다.
  • 공식 설치 페이지
• 쿠버네티스 네이티브
  • Kong Ingress Controller를 사용하여 모든 L4+L7 트래픽을 라우팅하고 연결하는 네이티브 Kubernetes CRD로 kong을 선언적 리소스로 관리할 수 있습니다.
  • Kong Ingress Controller Github
• 프록시, 고급 라우팅, 로드밸런싱, 서비스 모니터링 및 헬스체크, Service Discovery, Circuit-Breaker, 로깅, 속도 제한, 보안(ACL, 봇 감지, IP 허용/거부 등), 인증, 변환 (HTTP 요청 및 응답 조작), 캐싱, 클러스터링, 수평확장 등 다양한 기능을 제공하여 마이크로서비스 혹은 기존 API 트래픽을 쉽게 오케스트레이션 하기 위한 중앙 계층 역할을 합니다.
• 이러한 기능은 Restful API 혹은 선언적 구성을 통해 설정 가능합니다.

📌 아키텍처

📌 작동 방식

Kong API Gateway는 각각 Nginx로 되어있습니다.

Kong은 lua-nginx-module을 포함하는 일종의 nginx 향상된 버전인 OpenResty를 사용합니다. 따라서 Kong은 OpenResty와 함께 배포되어 lua 스크립팅 기능을 활용하여 nginx를 구성하고 확장합니다.

즉, Kong은 http/s를 통해 자체 Admin API를 통해 리버스 프록시 지시문을 수락하고, lua 스크립팅 언어를 사용하여 nginx 구성으로 변환하여 마이크로서비스 백엔드를 위한 게이트웨이 플랫폼을 구축합니다.

Admin API

• Kong을 설치하면 tcp/8001(http) 및 tcp/8444(https) 포트에서 Admin API 에 엑세스 할 수 있습니다.
• Admin API 를 이용해 Kong의 설정 정보를 동적으로 변경할 수 있습니다.
• 보안을 위해 Admin API는 내부용이며, 방화벽으로 보호되어야 합니다.

프록시

• Kong은 tcp/8000(http) 및 tcp/8443(https) 포트를 수신하여 최종 사용자의 요청을 수진하고 정의한 구성에 따라 엔드포인트로 전달합니다.
• 이러한 포트는 외부 연결을 허용해야 하는 공개 서비스 입니다.
• 추가적으로 사용되는 포트 정보는 해당 링크에서 확인할 수 있습니다.

Datastore

• Kong에는 설정 정보를 저장하는 두가지 방식을 제공합니다.
  (1) DB mode
  (2) DB Less mode.
• DB mode의 경우 외부 데이터베이스를 사용하여 설정 정보를 저장합니다.
• 관리 API를 통해 설정 정보를 전달하고 Kong은 이를 데이터 저장소에 저장합니다. 그리고 클러스터 내 Kong 인스턴스들은 중앙 데이터베이스를 사용할 수 있습니다.
• 지원되는 데이터 저장소는 Cassandra 및 PostgreSQL 입니다.
• Cassandra는 Kong의 분산된 다중 지역 Kong 환경을 구축하는데 선호되지만 (확장 용이), PostgreSQL 또한 문제 없이 프로덕션 환경에서 사용될 수 있습니다. PostgreSQL은 운영이 간단하며 대부분의 클라우드 공급자에서 관리형 서비스를 제공합니다.

Cache
모두 아시다시피, 성능과 관련하여 데이터베이스는 주요 병목 지점이 될 수 있습니다. 이를 방지하고 성능을 향상시키기 위해 Kong은 설정 정보를 메모리에 캐싱합니다.

어떤 DB를 사용하든 Kong의 설정을 변경하기 위해 admin API를 호출하면, 설정이 DB에 저장된 다음, DB에서 가져와 캐싱됩니다. 그 후 최종적으로 변경된 설정이 적용됩니다.

이 시점에서는 요청을 프록시하는 동안 더이상 DB 접속이 필요하지 않습니다. 설정을 변경하면 Kong은 캐시를 무효화하고 새 설정 정보를 가져와서 다시 캐시합니다.

다시 말해, 설정 변경 시 인스턴스에 바로 반영되지 않습니다. 캐시가 리프레시 되어야 설정 내용이 반영됩니다.

DB-less 모드와 선언적 구성
Kong은 설정 데이터를 위한 DB 가 필요하지만 DB-less 모드라는 또 다른 옵션이 존재합니다. 이 모드에서 설정 정보는 JSON 또는 YAML 형식의 파일로 선언되므로, Kong은 이 파일을 읽어 설정 정보를 노드의 메모리에 씁니다.

이 모드에서는 CI/CD 툴을 사용하여 Kong을 관리할 수 있습니다. 설정 정보는 정적 파일에 저장되므로 git 저장소에 보관하고 여러 Kong 노드에 배포할 수 있습니다.

그러나 이 모드에서 Admin API는 읽기 전용으로 동작합니다. Kong을 구성하는 유일한 방법은 선언적 설정 파일을 사용하기 때문입니다.
즉, RESTful API를 통해 설정을 변경할 수 없습니다.

또한 DB 기반으로 동작하는 일부 플러그인의 경우 DB-less 모드에서는 사용할 수 없습니다. (예를 들어, rate-limiting, response-ratelimiting 플러그인은 제한 값을 저장하기 위해 DB를 사용합니다.)

이 모드는 프로덕션 환경에서는 쓸모 없어 보일 수 있지만, Kong 클러스터를 생성하는 데 사용할 수 있는 하이브리드 모드의 일부이기도 합니다.

📌 클러스터링

아마도 인프라 내에서 가장 안정적인 서비스 중 하나는 API Gateway여야 하며, 이 계층에서 SPOF를 생성하고 싶지 않아 할 것입니다.
백엔드 서비스에 대한 진입점 역할을 하므로 이 계층에서는 중단이나 성능 이슈가 허용되지 않습니다.
게이트웨이에 장애가 나면 사실상 백엔드 애플리케이션의 장애나 마찬가지 입니다. 따라서 게이트웨이는 확장 가능해야 하며, 고가용성을 유지해야 합니다.

앞서 언급했듯이, Kong은 데이터 저장소를 사용하여 설정 정보를 유지하고 여러 Kong 노드가 이 중앙 데이터 저장소를 사용해 클러스터를 형성할 수 있습니다.

일반적인 Kong 클러스터는 다음과 같습니다.

Kong은 로드 밸런서가 아니므로 클러스터에서 Kong API Gateway 인스턴스 간에 트래픽을 분산하려면 Kong 클러스터 앞에 로드 밸런서가 필요합니다. 만약에 Session Affinity가 필요하다면 L4에서 IP나 Session based affinity를 설정해야 합니다.

따라서 더 많은 요청을 처리해야 하는 경우 새 노드에 Kong을 설치하고 중앙 데이터 저장소를 가리키도록 하여 더 많은 노드를 수평으로 쉽게 추가할 수 있습니다. (HA)

이러한 단순성과 유연성 덕분에 Kong은 자동화에 적합한 플랫폼이기도 합니다. 예를 들어, Kong 클러스터 리소스 사용률을 추적하고(prometheus 플러그인을 통해 메트릭을 수집하여) 자동으로 확장 또는 축소하도록 결정할 수 있습니다.

하이브리드 모드 클러스터링

일반적으로 Kong API Gateway 클러스터의 각 노드들은 중앙 데이터 저장소에 의존하지만, Kong 클러스터를 구축하기 위한 하이브리드 모드라는 또 다른 방법이 존재합니다.

이 모드에서 Kong 노드는 Control Plane Node(CP)와 Data Plane Node(DP)라는 두가지 역할로 분리됩니다.

Admin API를 제공하는 컨트롤 플레인 노드는 중앙 데이터 저장소와 상호 작용하는 유일한 구성요소입니다.
반면, 들어오는 요청을 처리하는 데이터 플레인 노드는 컨트롤 플레인 노드에서 설정 정보를 가져옵니다.

이 모드는 DB mode와 DB-less mode 모두 사용하기 때문에 하이브리드 모드라고 불립니다.

데이터 저장소 부하 감소, 보안 향상 및 관리 용이성과 같은 이점이 존재합니다.

📌 단점

• 관리용 대시보드가 Enterprise 버전에만 제공됩니다.
  • CE 버전에서도 오픈소스 프로젝트인 Konga 와 Kong Dashborad 를 사용하면 보완 됨
• 설정 변경등은 모두 RESTful API 요청으로 수행해야 합니다.
• 플러그인 개발이 어렵습니다.
  • Lua 언어를 따로 학습해야 합니다.

KrakenD (크라켄)

공식 홈페이지
공식 문서

KrakenD는 확장 가능하고 선언적인 고성능 오픈소스 API 게이트웨어 입니다. Go 언어로 개발되어 Go의 Concurrency, Speed의 장점을 활용해 핵심 기능의 성능이 매우 좋다고 합니다. (70k req/sec on c4.2xlarge)
벤치마크 결과

Go에 기반을 둔 대부분의 애플리케이션처럼, 단일 독립(Self-contained) 바이너리로 제공됩니다. 대안으로 소스에서 컴파일링을 할 수 있습니다. 또 Go 라이브러리를 바탕으로 자신의 애플리케이션을 만들 수도 있습니다.
다양한 설치 가이드

KrakenD는 endpoint를 생성하는 선언적 방법을 제공하므로 프로그래밍이 필요하지 않습니다. API Gateway 동작을 GUI를 통해 시각적으로 편집할 수 있는 KrakenDesigner를 제공합니다.

또한 다양한 플러그인과 임베디드 스크립트를 사용하여 기능을 확장할 수 있습니다.

공식문서가 매우 정리가 잘 되어있으니, 위 공식 문서 링크 확인 해보시면 되겠습니다.

stateless

또 다른 특징은, Kong과 다르게 stateless 특성을 가지는데, 데이터 또는 애플리케이션의 상태를 DB같은 영구 저장소에 저장하지 않습니다. 대신 모든 설정 데이터와 애플리케이션 상태가 설정 파일 내에 존재합니다.

설정 파일은 krakend.json 파일에서 구성할 수 있습니다. (다른 이름을 사용할 수 있고, .toml, .yaml, .yml 등 다른 확장자를 사용할 수 있습니다)

이러한 무상태 특성으로, SPOF 없이 클러스터 확장을 단순화하고, 각 노드는 coordination 없이 독립적으로 작동하기 때문에 다중 영역 또는 하이브리드 구성에서도 선형 확장성을 얻을 수 있습니다.

또한 각 독립 노드에는 고유한 설정 파일이 있으므로, 인스턴스 간의 데이터 조정 또는 동기화가 필요하지 않습니다. 이러한 설계는 API 게이트웨이에 장애가 발생해도 가용성과 탄력성을 유지하도록 합니다.

또 이러한 상태 비저장 아키텍처는 Immutable Infrastructure와 GitOps 사용을 권장합니다.
변경 불가능한 인프라는 구성 파일을 모든 노드에서 최신 상태로 유지하고 버전 관리 및 동기화 문제에 대한 걱정 없이 API Gateway 배포 및 업데이트를 간소화합니다.

📌 Zero-trust security

제로 트러스트 보안 정책이 적용되었기 때문에, 쿼리 문자열, 쿠키 및 헤더를 전달할 때 허용되는 항목을 정의할 수 있습니다.

📌 단점

• 로그 기본 셋팅이 빈약함
• 모니터링을 위한 3rd-party 별도 구성 필요

Spring Cloud Gateway

사용중인 기술 스택이 JVM 기반이거나 Spring Boot를 사용하고 있는 경우 우선적으로 생각해 볼 수 있는, Spring 생태계 기반의 API Gateway입니다.

Tyk (타이크)

go 기반의 API Gateway 로 구글 출신의 개발자들이 만든 것으로 유명한 서비스입니다. 설치도 간단하고 GUI 관리도구도 제공되어 사용이 편리한 점이 있습니다.

📌 구성 요소

구성요소로 API Gateway, Dashboard, Pump + Redis, MongoDB Dependency Module로 구성되어 있습니다.

파란 라인의 경우 관리자가 Tyk 대시보드로 접근하여 API Gateway에 수집된 Metrics를 확인하는 과정입니다.

주황 라인의 경우 API 소비자가 L4, DNS 등의 로드밸런서를 통해 이중화 또는 다중화 된 API Gateway에 접근하여 마이크로서비스를 호출하는 과정입니다.

마지막 빨간 라인의 경우 Dashboard, API Gateway에서 저장할 Log나 Metrics 정보를 Redis로 전송하면, Pump 모듈은 해당 정보를 MongoDB 또는 3rd Party Module로 전송하는 역할을 수행합니다.

📌 단점

• 상대적으로 속도가 느리다.
• 무료 라이센스는 비상업적 용도로만 1개의 Tyk 노드를 관리하는데 유효하다. (확장성에 문제가 있을 것으로 보임)
• 공식 문서가 조잡하다.
• 국내 사용풀이 적어 레퍼런스를 얻기 쉽지 않다 (이는 즉슨 트러블 슈팅이 어렵다?)
• 특별한 장점을 찾기가 ..

Gloo Edge (글루 엣지)

공식 문서

Gloo Edge는 Golang 기반의 쿠버네티스 네이티브 인그레스 컨트롤러이자 클라우드 네이티브 API 게이트웨이 입니다. CRD를 지원하여 손쉽게 설치할 수 있습니다. 서비스 메시 인그레스로 동작하여 Istio를 포함한 모든 서비스 메쉬를 보완할 수 있습니다.

📌 Envoy Proxy

Gloo Edge는 Envoy Proxy 위에 구축되었으며, 요청이 Envoy Proxy를 통해 흐르기 때문에 강력한 기능 수준의 라우팅, 다양한 트래픽 관리 및 처리, Observability를 수행할 수 있습니다. (Istio랑 비슷한 것 같음.)

또한 Envoy Filter를 배포하여 요청이 엔드포인트에 전달되기 전에 다양한 전처리 작업을 수행할 수 있습니다.

Apache APISIX

공식 문서
공식 Github

Apache APISIX는 Nginx 라이브러리 및 etcd를 기반으로하는 동적, 실시간, 고성능 API 게이트웨이입니다.

APISIX는 로드 밸런싱, 동적 업스트림, Canary Release, 써킷 브레이커, 인증, Observability 등과 같은 풍부한 트래픽 관리 기능을 제공합니다.
K8s 인그레스 컨트롤러로도 사용할 수 있습니다.

📌 특징

다양한 플랫폼 지원

• 클라우드 네이티브 : 공급업체에 종속 없이 베어메탈에서 쿠버네티스까지 실행할 수 있습니다.
• ARM64 지원

다중 프로토콜

• 동적 TCP/UDP 프록시 제공
• Dubbo, MQTT, gRPC, Websocket 등 다양한 프록시 제공
• 동적으로 SSL 인증서 로드

Full Dynamic (완전 동적)

• hot update & hot plugin
  • 재기동 없이 구성 및 플러그인 업데이트 가능
• Proxt Rewrite
  • 요청이 업스트림으로 보내지기 전에 host, uri, schema, method, headers 를 덮어쓸 수 있습니다.
• Response Rewrite
  • 사용자 정의 응답 상태 코드, 본문 및 헤더를 설정할 수 있습니다.
• 해시 기반 로드밸런싱
• 헬스 체크
  • 업스트림 노드에 대한 헬스체크가 가능하고, 시스템의 안정성을 유지하기 위해 자동적으로 문제가 있는 노드에 대해서는 로드밸런싱 하지 않습니다.
• 써킷 브레이커
• 프록시 미러링
  • 클라이언트 요청을 미러링 하는 기능을 제공합니다.
• 트래픽 분할
  • 다양한 업스트림 간의 트래픽 비율을 증분적으로 지정할 수 있습니다.

세분화된 라우팅

• 전체 경로 일치 및 접두사 일치 지원
• 모든 Nginx 내장 변수를 라우팅 조건으로 지원하므로 cookie, args 등을 카나리아 릴리스, A/B 테스트 등을 구현하기 위한 라우팅 조건으로 사용할 수 있습니다.
• 라우팅 판단 조건으로 다양한 연산자를 지원합니다. (ex. {"arg_age", ">", 24})
• IPv6, TTL, 우선순위, 배치 HTTP 요청, Graph QL 속성으로 라우팅 등 다양한 기능을 지원합니다.

보안

• 풍부한 인증&인가를 지원합니다.
  • key-auth, JWT, basic-auth, wolf-rbac, casbin, keyclaok, casdoor 등
• IP, Referer 화이트리스트/블랙리스트
• 서비스에 대한 요청 횟수, 동시 요청 수 제한
• API 에 대한 CORS 활성화
• 요청 유효성 검사
• Double Submit Cookie 방식을 기반으로 하여 CSFR 공격으로부터 API 보호

OPS 친화적

• Zipkin Tracing
• Consul, Nacos, Eureka, Zookeeper 지원
• Prometheus, Elasticsearch, Datadog
• HashiCorp Vault
• Helmchart 등..

높은 확장성

• 커스텀 플러그인 작성 가능
• 사용자 지정 로드밸런싱, 라우팅 작성 가능

서버리스 통합 가능

• Lua functions : APISIX의 각 단계에서 함수를 호출합니다.
• AWS Lambda : 특정 URI에 대한 모든 요청을 AWS API 게이트웨이 엔드포인트로 프록시하는 동적 업스트림으로서 AWS Lambda 함수와 통합합니다. API 키 및 AWS IAM 액세스 암호를 통한 인증을 지원합니다.
• Azure Functions : 특정 URI에 대한 모든 요청을 Microsoft Azure 클라우드로 프록시하기 위한 동적 업스트림으로서 Azure Serverless Function과 원활하게 통합됩니다.
• Apache OpenWhisk : 특정 URI에 대한 모든 요청을 자체 OpenWhisk 클러스터로 프록시하기 위한 동적 업스트림으로서 Apache OpenWhisk와 원활하게 통합됩니다.

Ocelot

Ocelot은 마이크로서비스를 위해 만들어진 .NET Core 기반의 오픈소스 API 게이트웨이 입니다. 분산 아키텍처에서 들어오는 HTTP 요청을 다양한 마이크로 서비스 또는 백엔드 서비스로 관리하고 라우팅하는 방법을 제공하도록 설계되었습니다. 클라이언트가 시스템의 다른 부분에 액세스할 수 있는 단일 진입점 역할을 하여 로드 밸런싱, 인증, 권한 부여, 캐싱, 요청/응답 변환 등과 같은 이점을 제공합니다.

Docker, Kubernetes, Service Fabric 등과 같은 마이크로 서비스/컨테이너를 배포하는 동일한 애플리케이션 배포 환경에 배포할 수 있습니다. 또한 .NET Core Linux 또는 Windows에 배포할 수 있는 크로스 플랫폼입니다.