왜 Apache APISIX이 최고의 API Gateway인가?

오늘날 모바일 폰은 다양한 용도로 사용되며, AppStore에는 소셜 미디어, 유틸리티, 게임, 라이프스타일, 온라인 쇼핑 등 다양한 애플리케이션이 제공됩니다. 이러한 앱을 구축하는 것은 API와 떼려야 뗄 수 없는 관계입니다. 따라서 API를 통해 서비스를 제공하는 기업들은 서비스의 속도, 안정성, 보안을 보장하기 위해 신뢰할 수 있는 API 게이트웨이를 선택해야 합니다.

CNCF의 API 게이트웨이 랜드스케이프에는 Apache APISIX, Kong, Tyk 등 거의 20가지 유형의 API 게이트웨이가 있습니다(클라우드 벤더의 서비스는 제외). 이들 중 많은 프로젝트가 자신들이 가장 인기 있는 오픈소스 API 게이트웨이 프로젝트이자 차세대 API 게이트웨이라고 주장하지만, 과연 그럴까요?

이 글에서는 개발자들 사이의 인기, 오픈소스 라이선스, 성능, 그리고 전체 생태계 측면에서 여러 API 게이트웨이를 분석해 보겠습니다. 이 분석을 통해 Apache APISIX가 어떻게 차세대 API 게이트웨이로서 여러 측면에서 동종 제품보다 뛰어난 성능을 보이는지 확인할 수 있을 것입니다.

API Gateway landscape.png

소프트웨어 엔지니어들이 잘 알고 있습니다

소프트웨어 엔지니어들은 API와 API 게이트웨이의 사용자이자 개발자이므로, 엔지니어들 사이의 인기는 트렌드를 직접적으로 나타내는 지표입니다. 아래는 Apache APISIX, Kong, Tyk, Gloo 네 가지 API 게이트웨이의 GitHub 기여자 총 수를 비교한 그래프입니다.

GitHub Contributors.png

그래프에서 볼 수 있듯이 Kong과 Tyk는 2015년경에 시작되었고, Apache APISIX와 Gloo는 2019년에 시작되었습니다. 더 중요한 것은, 가장 최근에 시작된 Apache APISIX가 가장 가파른 곡선을 그리고 있으며, 320명 이상의 기여자를 확보하여 두 번째로 많은 Kong보다 57명 더 많은 기여자를 보유하고 있다는 점입니다. 이로써 Apache APISIX는 가장 많은 기여자를 가진 API 게이트웨이 프로젝트가 되었습니다.

Monthly Active Contributors.png

기여자 총 수 외에도, 월간 활성 기여자 수는 더 중요한 의미를 지닙니다. Tyk의 월간 활성 기여자 수는 약 5명 정도이며, 거의 10명을 넘지 않습니다. 반면 Kong과 Gloo는 10명에서 20명 사이를 오가고 있습니다. 한편, Apache APISIX는 안정적으로 20명 이상의 월간 활성 기여자를 유지하며, 최고점에서는 거의 40명에 달합니다. 이로써 Apache APISIX는 가장 활발한 API 게이트웨이 프로젝트입니다.

이 네 가지 오픈소스 API 게이트웨이 프로젝트 뒤에는 각각 상업화된 회사가 있습니다. 따라서 APISIX가 두드러지는 또 다른 지표는 월간 활성 기여자 수 대비 직원 수의 비율입니다.

API Gateway	APISIX	Kong	Tyk	Gloo
월간 활성 기여자	38	20	8	24
직원 수(Linkedln 기준)	40+	500+	200+	100+

2022년 기준으로 Kong과 Tyk는 4%의 비율을, Gloo는 24%의 비율을 보입니다. 반면 APISIX는 거의 100%에 가까운 비율을 보입니다. 이는 API7.ai가 APISIX 프로젝트를 시작한 초기부터 오픈소스 커뮤니티에 지속적으로 노력을 기울여 개발자들 사이에서 명성을 얻었기 때문입니다.

오픈소스 라이선스: 오픈소스 API 게이트웨이 선택의 가장 중요한 요소

MongoDB가 2018년에 오픈소스 라이선스를 SSPL(Server Side Public License)로 변경한 이후, 기업들은 MongoDB를 관리형 서비스로 사용할 때 자신들의 코드를 오픈소스로 공개해야 합니다. 결과적으로 기업들은 프로젝트를 선택할 때 해당 프로젝트의 오픈소스 라이선스를 심각하게 고려해야 합니다.

표면적으로는 Apache APISIX, Kong, Gloo 모두 상업 친화적인 Apache License Version 2.0을 사용하고 있으며, Tyk는 Mozilla Public License Version 2.0을 사용합니다. 그러나 더 깊이 파고들면 Kong, Gloo, Tyk 모두 상업화된 오픈소스 벤더가 지원하고 있습니다. 이들은 MongoDB와 마찬가지로 언제든지 라이선스를 변경할 수 있으며, 공공 클라우드나 다른 기업들이 자유롭게 사용하는 것을 제한하고, 새로운 버전에 접근하기 위해 비용을 지불하도록 강요할 수 있습니다.

라이선스 변경의 가능성은 아무도 모릅니다. 그러나 이러한 위험은 다모클레스의 칼처럼 사용자들 위에 떠 있는 것입니다.

이러한 상황에서 Apache Software Foundation(ASF)의 오픈소스 프로젝트나 CNCF의 오픈소스 프로젝트를 선택하는 것이 최선의 선택입니다. 왜냐하면 이들은 프로젝트의 라이선스를 변경할 수 없기 때문입니다. Apache APISIX는 그러한 프로젝트입니다. ASF의 최상위 프로젝트로서, 어떤 상업 회사도 Apache APISIX 프로젝트를 절대적으로 통제할 수 없으며, 모든 코드는 ASF에 속하며 라이선스는 변경되지 않습니다. 기업 사용자들은 변호사와 규제 부서로부터 문의 이메일을 받을 걱정 없이 자유롭게 사용할 수 있습니다.

Apache APISIX, Kong, Gloo의 성능

커뮤니티에서 자주 묻는 질문 중 하나는 Envoy 기반의 Gloo와 NGINX 기반의 APISIX 중 어느 것이 더 나은 성능을 보이는가입니다. 성능이 가장 중요한 지표는 아니지만, 가장 직접적인 지표임은 분명합니다. 아래 표는 Apache APISIX와 Gloo의 벤치마크 점수를 보여줍니다. Apache APISIX의 QPS는 Gloo의 4.6배이며, 지연 시간은 Gloo의 7%에 불과합니다.

API Gateway	Apache APISIX	Gloo Edge
QPS	59122	12903
지연 시간	50.000% 470.00us 75.000% 648.00us 90.000% 0.89ms 99.000% 1.60ms	50.000% 6.80ms 75.000% 9.25ms 90.000% 11.32ms 99.000% 17.06ms

NGINX 또는 Envoy의 선택이 성능 차이의 주요 요인은 아니지만, APISIX가 소스 코드에서 수행한 최적화가 주요 요인입니다. NGINX 기반인 KONG과 비교해도 APISIX는 큰 성능 우위를 보입니다. 아래 그래프는 GigaOm의 보고서에서 추출한 Kong Enterprise Edition과 AP7 Enterprise Edition의 테스트 결과입니다(전체 데이터는 문의 가능).

Kong의 지연 시간은 API7(Apache APISIX 저자들이 만든 Enterprise Edition)의 수십 배에서 수백 배에 달합니다.

왜 APISIX가 이렇게 큰 성능 우위를 보일까요? 코드 앞에는 비밀이 없습니다.

말보다 코드를 보여주세요

이제 기술적인 관점에서 Apache APISIX, Kong, Gloo를 분석해 보겠습니다. Apache APISIX의 장점은 대부분 소스 코드의 최적화와 혁신에 기반합니다. 이러한 기술적 장점은 단순한 PoC(Proof of Concept)에서는 반드시 드러나지 않지만, 더 복잡한 프로덕션 환경에서 나타납니다.

APISIX 프로젝트가 등장하기 전에도 많은 상용 API 게이트웨이 또는 오픈소스 API 게이트웨이 제품들이 있었습니다. 이러한 제품들은 API 데이터, 라우팅 정보, 인증서, 설정 데이터를 관계형 데이터베이스에 저장했습니다. 관계형 데이터베이스에 이러한 데이터를 저장하는 장점은 매우 명확합니다. 사용자는 SQL 문을 사용하여 유연한 쿼리를 수행할 수 있으며, 백업 및 후속 유지보수도 편리합니다.

그러나 게이트웨이는 클라이언트의 모든 트래픽을 처리하는 미들웨어입니다. 가용성에 대한 요구가 매우 높습니다. API 게이트웨이가 관계형 데이터베이스에 의존한다면, 관계형 데이터베이스가 실패(예: 다운타임 또는 데이터 손실)할 경우 API 게이트웨이도 영향을 받고, 전체 시스템의 가용성도 저하됩니다.

이러한 손상을 줄이기 위해 APISIX는 다운타임과 데이터 손실 가능성을 피하기 위해 아키텍처를 구성했습니다. APISIX는 관계형 데이터베이스 대신 etcd를 사용하여 설정 데이터를 저장합니다. 이렇게 하는 장점은 다음과 같습니다:

클라우드 네이티브 아키텍처와 더 잘 맞습니다.
API 게이트웨이에 필요한 데이터 유형을 더 잘 표현합니다.
더 높은 가용성을 제공합니다.
변경 사항을 밀리초 단위로 알릴 수 있습니다.

etcd를 사용하여 설정 데이터를 저장한 후, 사용자는 etcd 업데이트를 모니터링하여 데이터 변경을 감지할 수 있습니다. APISIX는 밀리초 단위로 최신 설정을 얻을 수 있어 실시간 효과를 달성합니다. 그러나 데이터베이스에서 폴링하는 경우 최신 설정 정보를 얻는 데 5-10초가 걸릴 수 있습니다. 따라서 etcd를 저장 방식으로 사용하는 것은 APISIX를 더 클라우드 네이티브하게 만들 뿐만 아니라 가용성도 높입니다.

고성능 라우트 매칭 알고리즘

요청을 처리하기 위해 API 게이트웨이는 각 요청의 호스트 정보, URI, HTTP 메서드 등과 대상 표현식을 매칭해야 합니다. 따라서 효율적인 매칭 알고리즘이 중요합니다. 해시 기반 알고리즘은 성능이 좋지만, 퍼지 매칭을 할 수 없습니다. 정규 표현식은 퍼지 매칭을 할 수 있지만 성능이 좋지 않습니다. Apache APISIX의 해결책은 퍼지 매칭을 지원하는 효율적인 검색 데이터 구조인 트리를 사용하는 것입니다. 더 정확히 말하면, Apache APISIX는 radix tree(압축된 접두사 트리)를 사용합니다. 이 데이터 구조는 하나의 자식만 있는 중간 노드를 압축합니다. 알려진 모든 API 게이트웨이 제품 중에서 Apache APISIX는 라우트 매칭에 radix tree를 적용한 첫 번째 제품이며, 하나의 접두사가 여러 라우트와 매칭되는 시나리오를 지원합니다. 구현 세부 사항은 lua-resty-radixtree를 참조하세요.

요청을 매칭할 때, radix tree를 사용한 알고리즘은 점진적으로 매칭하며, O(K) 복잡도를 가집니다(K는 라우트의 URI 길이이며, API 수와 독립적입니다). 이 알고리즘은 공공 클라우드나 CDN과 같이 많은 라우트가 있는 시나리오에 매우 적합합니다. 또한 빠르게 증가하는 많은 라우트를 처리하는 데도 문제가 없습니다.

고성능 IP 매칭 알고리즘

IP 주소에는 두 가지 표기법이 있습니다: 표준 IP 표기법과 CIDR 표기법, 32비트 IPv4를 예로 들면:

표준 IP 표기법: 192.168.1.1
CIDR 표기법: 192.168.1.1/8

Apache APISIX의 IP 매칭과 라우트 매칭은 다른 알고리즘을 사용합니다. 192.168.1.1의 IP를 예로 들면, 각 IP 세그먼트의 범위는 0에서 255까지이므로 IP 주소는 네 개의 16비트 정수로 구성되어 있으며, IP의 길이는 고정되어 있습니다. 따라서 더 효율적인 알고리즘을 사용하여 매칭을 완료할 수 있습니다.

500개의 IPv4 레코드가 포함된 IP 라이브러리가 있다고 가정하면, APISIX는 500개의 IPv4 레코드를 해시 테이블에 캐시하고, 해시 테이블을 사용하여 IP 매칭을 수행합니다. 시간 복잡도는 O(1)입니다. 다른 API 게이트웨이는 리스트 반복을 통해 IP 매칭을 완료하며, 게이트웨이로 전송된 각 요청은 최대 500번 반복될 수 있습니다. 따라서 APISIX의 고정밀 IP 매칭 알고리즘은 WAF와 같이 대량의 IP 허용 목록 및 차단 목록 매칭이 필요한 시나리오의 효율성을 크게 향상시킵니다.

라우트 세분화

API 게이트웨이는 요청의 다양한 정보(호스트 정보, URI, URI 쿼리 매개변수, URI 경로 매개변수, HTTP 메서드, 요청 헤더 등)와 사전 정의된 규칙을 매칭합니다. 이러한 정보는 대부분의 API 게이트웨이에서 지원됩니다. 그러나 Apache APISIX는 이러한 정보 외에도 더 많은 데이터를 지원하여 더 복잡한 사례를 해결합니다.

첫째, Apache APISIX는 NGINX 내장 변수를 지원합니다. 즉, uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_name 등 수십 개의 NGINX 내장 변수를 매칭 매개변수로 사용할 수 있습니다.

NGINX 내장 변수 목록은 NGINX Variables를 참조하세요.

둘째, Apache APISIX는 조건식