APISIX Ingress Controller가 Emissary-ingress보다 더 나은 선택인 이유는 무엇인가요?
Xin Rong
March 17, 2023
배경 정보
Kubernetes Ingress는 클러스터 내부 서비스로 외부 트래픽을 라우팅하기 위한 규칙을 정의하는 API 객체입니다. Ingress Controller는 일반적으로 Ingress 리소스의 로직을 구현하고 이러한 트래픽 규칙을 중앙에서 관리하는 데 사용됩니다.
실제로, 기업 사용자들은 일반적으로 mTLS, 재시도, 속도 제한, 인증과 같은 트래픽 관리 기능이 필요하며, 이러한 기능들은 Ingress 리소스의 의미론으로는 충족할 수 없습니다. 따라서 Ingress Controller 구현체들은 일반적으로 추가적인 CRD를 통해 기능을 확장합니다. 다음은 APISIX Ingress Controller와 Emissary-Ingress 구현체 간의 차이점을 상세히 비교한 내용입니다.
Apache APISIX Ingress Controller란?
Apache APISIX Ingress Controller는 ASF(Apache Software Foundation) 산하의 오픈소스 프로젝트입니다. 이 컨트롤 플레인은 Kubernetes에서 리소스를 구성하고 전달하며, APISIX는 실제 비즈니스 트래픽을 처리합니다. 보안을 강화하기 위해 전체 배포 과정에서 데이터 플레인과 컨트롤 플레인 아키텍처를 완전히 분리하여 데이터 플레인 공격으로 인한 Kubernetes 클러스터 권한 누출 위험을 효과적으로 방지합니다.
Emissary-Ingress란?
Emissary-Ingress는 CNCF(Cloud Native Computing Foundation)의 인큐베이팅 프로젝트입니다. Envoy 프록시의 컨트롤 플레인으로서 Kubernetes 리소스를 파싱하며, 모든 트래픽은 데이터 플레인에서 Envoy가 직접 처리합니다. 컨트롤 플레인과 데이터 플레인을 하나의 컨테이너로 패키징하여 전체적으로 접근 및 배포가 더 쉬워졌습니다.
APISIX Ingress Controller와 Emissary-Ingress의 차이점
APISIX Ingress Controller와 Emissary-Ingress는 Ingress 리소스를 지원하는 것 외에도 CRD 및 Gateway API를 통해 구성을 지원하여 Ingress 의미론의 한계를 보완할 수 있습니다.
다음 섹션에서는 기본 기능, 서비스 디스커버리, 확장성 측면에서 두 가지의 차이점과 장점을 분석합니다.
기본 기능
| 기능 | APISIX Ingress | Emissary-ingress | |
| 프로토콜 | HTTP/HTTPS | ✓ | ✓ |
| gRPC | ✓ | ✓ | |
| TCP | ✓ | ✓ | |
| UDP | ✓ | ✕ | |
| Websockets | ✓ | ✓ | |
| 로드 밸런싱 | Round Robin | ✓ | ✓ |
| Ring Hash | ✓ | ✓ | |
| Least Connections | ✓ | ✓ | |
| Maglev | ✕ | ✓ | |
| 인증 | External Auth | ✓ | ✓ |
| Basic | ✓ | ✓ | |
| JWT | ✓ | ✕ | |
| OAuth | ✓ | ✕ | |
| OpenID | ✓ | ✕ | |
| 트래픽 관리 | Circuit Breaker | ✓ | ✓ |
| Rate Limiting | ✓ | ✓ | |
| Canary | ✓ | ✓ | |
| Fault Injection | ✓ | ✕ | |
| Health Checks | ✓ | ✓ | |
일반적인 게이트웨이 기능에는 트래픽 관리, 로드 밸런싱, 인증 등이 포함됩니다. 그러나 Emissary-Ingress는 인증 지원이 상대적으로 제한적이며, Basic Auth와 External Auth 기능만 포함하고 있습니다.
서비스 디스커버리
마이크로서비스 아키텍처에서 애플리케이션은 일반적으로 특정 비즈니스 로직을 수행하기 위해 함께 작동하는 여러 마이크로서비스로 분해됩니다. 마이크로서비스 인스턴스의 수가 지속적으로 변경되기 때문에 서비스가 서로를 발견하고 위치를 파악할 수 있는 메커니즘이 필요합니다.
서비스 디스커버리는 서비스 이름을 통해 서비스 디스커버리 정보를 얻어 네트워크 상에서 마이크로서비스가 위치를 파악하고 요청을 어떤 인스턴스로 라우팅할지 결정하는 방식을 말합니다.
전통적인 마이크로서비스 프레임워크의 경우, 레지스트리 선택은 특정 비즈니스 요구 사항에 따라 결정됩니다. 그러나 기존 서비스 등록 및 디스커버리 컴포넌트를 Kubernetes 기반의 DNS 서비스 디스커버리 메커니즘으로 마이그레이션하는 데는 일정한 수정 비용이 발생할 수 있습니다.
반면, 게이트웨이가 현재 서비스 등록 및 디스커버리 컴포넌트를 지원한다면 이러한 수정이 필요 없으며, 이는 마이크로서비스 프레임워크에 대한 더 나은 지원을 제공할 수 있습니다.
다음은 두 가지의 서비스 디스커버리 컴포넌트 지원 상황입니다:
| 서비스 디스커버리 | Apache APISIX Ingress Controller | Emissary-Ingress |
|---|---|---|
| Kubernetes | ✓ | ✓ |
| DNS | ✓ | ✓ |
| Nacos | ✓ | ✕ |
| Eureka | ✓ | ✕ |
| Consul | ✓ | ✓ |
서비스 디스커버리 생태계에 대해 APISIX Ingress Controller는 더 강력한 지원을 제공하며, 사용자는 Ingress 컨트롤러를 통해 기존 마이크로서비스 프레임워크에 쉽게 통합할 수 있습니다.
확장성
Kubernetes Ingress 컨트롤러의 기능이 특정 요구 사항을 충족하지 못할 때, 사용자는 커스텀 개발을 통해 기능을 확장할 수 있습니다. 더 개인화된 요구 사항은 커스텀 플러그인 개발 또는 기존 코드 수정을 통해 충족할 수 있습니다. 강력한 확장성을 가진 Ingress 컨트롤러는 기능 개발 및 커스터마이징을 더 쉽게 만들어 특정 시나리오에 대한 더 나은 지원과 솔루션을 제공할 수 있습니다.
Emissary-Ingress
Emissary-Ingress의 확장성은 상대적으로 낮으며, 커스텀 Envoy Filter를 통한 확장을 지원하지 않습니다. 데이터 플레인과 컨트롤 플레인이 통합되어 있기 때문에 전체 시스템의 커스텀 개발이 필요합니다. 데이터 플레인 Envoy의 커스텀 개발 복잡도가 높아 개발자에게 상당한 부담을 줍니다.
또한, 사용자가 더 강력한 Emissary-Ingress가 필요하다면 Ambassador의 상용 제품인 Edge Stack으로 업그레이드해야 합니다. 일부 독점 기능은 지원을 받기 위해 비용을 지불해야 합니다.
APISIX Ingress Controller
APISIX의 데이터 플레인은 주로 플러그인을 통해 기능을 확장하며, 80개 이상의 즉시 사용 가능한 플러그인을 제공합니다. APISIX Ingress Controller는 APISIX가 제공하는 모든 플러그인을 지원하며, 대부분의 일상적인 사용 사례를 충족할 수 있습니다.
특정 비즈니스 시나리오에 기반한 커스터마이징이 필요한 경우, APISIX는 사용자가 상황에 따라 자유롭게 선택하고 조합할 수 있는 여러 확장 옵션을 제공합니다. 현재 지원되는 확장 방법은 다음과 같습니다:
- Lua 언어를 사용하여 플러그인을 개발하는 것은 상대적으로 간단하며 성능 손실이 거의 없습니다. 또한, 서버리스 플러그인을 사용하여 Lua 코드를 직접 작성할 수 있어 비즈니스 요구 사항을 빠르게 충족할 수 있습니다.
- 네이티브 Lua 언어 외에도
Plugin Runner또는WASM플러그인을 사용하여 확장할 수 있으며, Java, Python, Go와 같은 코딩 언어로 커스텀 플러그인을 개발할 수 있습니다. 이를 통해 사용자는 기존 비즈니스 로직을 활용하고 회사의 기술 스택 또는 개발 선호도에 따라 선택할 수 있으며, 새로운 언어를 배울 필요가 없습니다.
APISIX Ingress Controller는 위의 확장 방법을 완전히 지원하며 추가 개발이 필요하지 않습니다.
성능
Kubernetes ingress 트래픽 프록시 컴포넌트로서, 모든 플랫폼 인바운드 트래픽을 관리하고 다양한 트래픽 규칙을 통합적으로 관리하므로 프록시의 성능에 대한 요구가 높습니다.
이 글에서는 동일한 인스턴스(4C 8G)에서 APISIX Ingress Controller(APISIX: 3.1.0)와 Emissary-Ingress 3.4.0의 성능 테스트를 수행합니다.
QPS
QPS(Queries-per-second)는 서비스가 초당 처리할 수 있는 쿼리 수를 나타냅니다. 숫자가 높을수록 성능이 좋습니다.
- 5000 Ingress Resource QPS
지연 시간
응답 지연 시간: 서버가 응답하는 데 걸리는 시간입니다. 지연 시간이 짧을수록 성능이 좋습니다.
그래프에서 볼 수 있듯이, APISIX Ingress Controller는 다양한 리소스 규모에서 일관된 성능을 유지하며 균형 잡힌 성능을 보여줍니다.
반면, Emissary-Ingress는 대규모 리소스 규모와 다양한 라우팅 매칭을 처리할 때 QPS와 지연 시간에 상당한 영향을 받으며, 리소스 수가 증가함에 따라 성능이 감소합니다. 따라서 실제 프로덕션 환경에서 비즈니스 규모가 커짐에 따라 APISIX의 고성능이 더 두드러집니다.
결론
Emissary-Ingress는 단순성과 통합 용이성이 특징이지만, 커스텀 개발이 더 어렵습니다. 또한, 추가 기능 요구 사항은 플랫폼의 관련 컴포넌트에 의존해야 합니다.
반면, APISIX Ingress Controller는 확장성과 서비스 디스커버리 통합 측면에서 장점이 있으며, 강력한 확장성과 간단한 개발을 제공합니다. 또한, APISIX Ingress Controller는 특히 비즈니스 규모가 지속적으로 증가하는 시나리오에서 탁월한 성능을 보여주며, 상당한 이점을 가지고 있습니다.