왜 NGINX나 Kong 대신 Apache APISIX를 선택할까요?

API 게이트웨이는 클라우드 네이티브 시대의 중요한 인프라 구성 요소입니다. API 게이트웨이를 평가하는 데는 두 가지 일반적인 기준이 있습니다: 얼마나 동적인지, 그리고 관찰 가능성이 얼마나 성숙했는지입니다. 많은 기업들이 과거에는 Nginx나 Kong을 API 게이트웨이로 사용했지만, 이후 Apache APISIX로 전환했습니다. 클라우드 네이티브 시대를 위해 태어난 API 게이트웨이인 Apache APISIX는 실제로 다양한 차원에서 기업들의 많은 문제점을 해결했습니다. 이제 왜 그런지 궁금할 것입니다.

NGINX와 Kong의 한계

모놀리식 서비스 시대에는 NGINX가 대부분의 시나리오를 처리할 수 있었습니다. 그러나 클라우드 네이티브 시대에는 NGINX의 아키텍처로 인해 두 가지 단점이 있습니다:

NGINX는 클러스터 관리를 지원하지 않습니다. 거의 모든 기업이 자체적인 NGINX 구성 관리 시스템을 가지고 있습니다. 비슷한 시스템이지만 통일된 솔루션은 없습니다.
NGINX는 구성의 핫 리로드를 지원하지 않습니다. 사용자가 NGINX의 구성을 수정하면 NGINX를 리로드해야 합니다. 또한 Kubernetes에서는 서비스가 자주 변경됩니다. 따라서 NGINX를 사용하여 트래픽을 처리하려면 서비스를 자주 재시작해야 하며, 이는 기업에게 받아들일 수 없는 일입니다.

Kong은 NGINX의 단점을 해결했지만 새로운 한계를 가져왔습니다:

Kong은 PostgreSQL 또는 Cassandra 데이터베이스에 의존해야 하며, 이로 인해 Kong의 전체 아키텍처가 매우 복잡해지고 기업에 고가용성 제한을 가져옵니다. 데이터베이스가 실패하면 전체 API 게이트웨이가 실패합니다.
Kong의 라우팅은 순차 탐색을 사용합니다. 게이트웨이에 천 개 이상의 경로가 있으면 성능이 급격히 떨어집니다.

APISIX는 위의 모든 한계를 해결하고 클라우드 네이티브 시대의 최고의 API 게이트웨이가 되었습니다.

Apache APISIX의 장점

잘 설계된 아키텍처

먼저, Apache APISIX는 훌륭한 아키텍처를 가지고 있습니다. 클라우드 네이티브는 현재의 기술 트렌드로, 전통적인 기업의 기술 아키텍처를 변화시킬 것입니다. 많은 애플리케이션이 마이크로서비스와 컨테이너화로 이전하고 있습니다. APISIX는 처음부터 이 기술 트렌드를 따랐습니다:

위 그림에서 왼쪽과 오른쪽은 APISIX의 데이터 플레인과 컨트롤 플레인입니다:

데이터 플레인: NGINX의 네트워크 라이브러리를 기반으로 하며( NGINX의 경로 매칭, 정적 구성, C 모듈을 사용하지 않음), Lua와 NGINX를 사용하여 요청 트래픽을 동적으로 제어합니다;
컨트롤 플레인: 관리자는 내장된 RESTful API를 통해 etcd를 조작할 수 있습니다. etcd의 Watch 메커니즘을 통해 APISIX는 밀리초 단위로 각 노드에 구성을 동기화할 수 있습니다.

데이터 업데이트의 경우, Kong은 데이터베이스 폴링 방식을 사용하며, 최신 구성을 얻는 데 5-10초가 걸릴 수 있습니다. 반면 APISIX는 etcd 구성 변경을 모니터링하여 동일한 작업을 수행하며, 이를 밀리초 단위로 제어할 수 있습니다.

APISIX와 etcd 모두 다중 인스턴스 배포를 지원하므로 단일 장애점이 없습니다.

풍부한 생태계

다음 그림은 APISIX의 생태계 맵을 보여줍니다. 이 그림에서 APISIX는 HTTP(S), HTTP2, Dubbo, IoT 프로토콜인 MQTT 등을 포함한 L7 프로토콜을 지원합니다. 또한 APISIX는 TCP/UDP와 같은 L4 프로토콜도 지원합니다.

그림의 오른쪽 부분에는 Apache SkyWalking, Prometheus, HashiCorp Vault와 같은 오픈소스 또는 SaaS 서비스가 있습니다. 그림의 하단에는 더 일반적인 운영 체제 환경, 클라우드 벤더 및 하드웨어 환경이 있습니다. 오픈소스 소프트웨어인 APISIX는 ARM64 서버에서도 실행할 수 있습니다.

APISIX는 많은 프로토콜과 운영 체제를 지원할 뿐만 아니라 다국어 프로그래밍 플러그인도 지원합니다. 처음 출시되었을 때 APISIX는 Lua 언어로만 플러그인을 작성할 수 있었습니다. 이 경우 개발자는 Lua와 NGINX 관련 기술 스택을 숙지해야 했습니다. 그러나 Lua와 NGINX는 상대적으로 소수의 개발자에게만 익숙한 기술입니다. 따라서 우리는 APISIX에서 다국어 플러그인 개발을 가능하게 했으며, Java, Golang, Node.js, Python과 같은 언어를 공식적으로 지원합니다.

활발한 커뮤니티

아래 그림은 기여자 성장 곡선입니다. 가로축은 시간을 나타내고, 세로축은 총 기여자 수를 나타냅니다. Apache APISIX와 Kong 두 프로젝트가 상대적으로 더 활발한 것을 볼 수 있습니다. Apache APISIX는 첫날부터 훌륭한 성장률을 유지했으며 Kong의 약 두 배의 속도로 빠르게 성장하고 있습니다. 2022년 7월 기준으로 APISIX의 기여자 수는 Kong을 초과했으며, 이는 APISIX의 인기를 보여줍니다. 물론 프로젝트의 활동성을 평가하는 데는 월간 활성 이슈, 총 PR 수 등 다른 방법도 있습니다. 좋은 소식은 APISIX가 이러한 측면에서도 타의 추종을 불허한다는 것입니다.

통합 프록시 인프라

아래 그림에서 APISIX의 목표를 이해하셨을 것입니다: 프록시 인프라를 통합하는 것입니다.

APISIX의 핵심은 고성능 프록시 서비스이므로 어떤 환경 속성에도 묶이지 않습니다. 따라서 Ingress 및 Service Mesh와 같은 제품으로 진화할 때 APISIX의 내부 구조를 변경할 필요가 없습니다. 다음은 APISIX가 이러한 시나리오를 어떻게 지원하는지 단계별로 소개합니다.

로드 밸런싱 및 API 게이트웨이

첫 번째는 전통적인 LB 및 API 게이트웨이 시나리오입니다. APISIX는 NGINX + LuaJIT를 기반으로 구현되었기 때문에 고성능 및 보안 기능을 가지고 있으며, SSL 인증서의 동적 로딩, SSL 핸드셰이크 최적화 등을 지원합니다. 로드 밸런싱 측면에서도 APISIX는 더 나은 성능을 보입니다. NGINX에서 APISIX로 전환하면 성능이 저하되지 않고 통합 관리와 같은 기능으로 인한 관리 효율성이 향상됩니다.

마이크로서비스 게이트웨이

APISIX는 여러 언어로 확장 플러그인을 작성할 수 있게 하여, 이스트-웨스트 마이크로서비스 API 게이트웨이가 직면한 주요 문제인 이질적인 환경에서 통합적으로 관리하는 방법을 해결할 수 있습니다. APISIX는 Nacos, etcd, Eureka와 같은 서비스 디스커버리와 표준 DNS 방법도 지원하므로 Zuul, Spring Cloud Gateway, Dubbo와 같은 마이크로서비스 API 게이트웨이를 완전히 대체할 수 있습니다.

Kubernetes Ingress

현재 K8s의 공식 Kubernetes Ingress Controller 프로젝트는 주로 NGINX 구성 파일을 기반으로 개발되었기 때문에 라우팅 기능과 로딩 방식에서 약간 부족하며 몇 가지 명백한 한계가 있습니다. 예를 들어, API를 추가하거나 수정할 때마다 새로운 NGINX 구성을 업데이트하기 위해 서비스를 재시작해야 합니다. 서비스를 재시작하는 것은 온라인 트래픽에 큰 영향을 미칩니다.

APISIX Ingress Controller는 위에서 언급한 모든 한계를 완벽하게 해결합니다: 완전한 핫 리로드를 지원합니다. 동시에 APISIX의 모든 장점을 상속받으며, 네이티브 Kubernetes CRD도 지원하므로 사용자가 쉽게 마이그레이션할 수 있습니다.

서비스 메시

다음 5~10년 동안 클라우드 네이티브 모델을 기반으로 한 서비스 메시 아키텍처가 등장할 것입니다. APISIX도 미리 트랙을 잠그기 시작했습니다. 풍부한 연구와 기술 분석을 거쳐 APISIX는 xDS 프로토콜을 지원하게 되었습니다. APISIX Mesh가 탄생했으며, APISIX는 서비스 메시 분야에서도 자리를 잡았습니다.

요약

Apache APISIX가 오픈소스된 지 3년이 되었습니다. 활발한 커뮤니티와 사례 연구는 APISIX가 클라우드 네이티브 시대의 완벽한 API 게이트웨이임을 증명했습니다. 이 글을 읽으면서 APISIX에 대해 더 포괄적으로 이해하셨을 것입니다.

질문이 있으시면 GitHub issue에 메시지를 남겨주세요; 커뮤니티 기여자들이 빠르게 응답할 것입니다. 물론 APISIX Slack 채널과 메일링 리스트에도 참여할 수 있습니다; 자세한 내용은 Join Us를 참조하세요.