NGINX, Kong, Amazon의 API 관리 솔루션 벤치마킹: API를 실시간으로 제공할 수 있을까?

속도는 오늘날의 디지털 환경에서 핵심 요소입니다. 앱의 성능이 너무 느리면 소비자는 손쉽게 경쟁사로 옮겨갈 수 있기 때문입니다. 앱 속도는 궁극적으로 응답성이 뛰어나고 안정적이며 유연하게 적응하는 API에 의해 좌우됩니다. 또한 API 응답성을 결정하는 핵심 요인 중 하나는 API 게이트웨이로 인해 발생하는 지연 시간입니다. 하지만 모든 API 게이트웨이의 성능이 동일한 것은 아닙니다.

지난가을, 소비자 신용 업계의 주요 기업인 한 NGINX 고객이 사용자들이 기대하는 디지털 경험을 제공하기 위해 점점 더 많은 앱과 기타 구성 요소가 서로 통신해야 함에 따라 ‘실시간’ API 성능의 중요성이 커지고 있다고 말했을 때, 우리는 이 점을 절실히 깨달았습니다. 고객이 필요로 했던 최저 10밀리초(ms)의 초고속 API 지연 시간을 달성한 API 게이트웨이는 NGINX Plus뿐이었다는 사실을 알게 되어 매우 기뻤습니다. 다른 많은 고객들도 Capital One과 마찬가지로 NGINX Open Source 또는 NGINX Plus를 API 게이트웨이로 사용해 지연 시간을 단축하고 처리량을 개선한 방법을 공유해 주었습니다.

저희는 API 생태계를 더 깊이 살펴보고 어떤 요건을 갖춰야 API를 ‘실시간’이라고 할 수 있는지 알아보기로 했습니다. 여러 요인을 바탕으로 검토한 결과, 실시간 API는 API 호출을 엔드 투 엔드로 30ms 이내에 처리해야 하며 이는 99번째 백분위수까지 모든 백분위수에서 충족되어야 한다고 판단했습니다(즉, 평균적으로 100건 중 30ms를 초과하는 호출은 1건뿐이라는 의미입니다).

API 관리 솔루션 비교

자체 테스트 결과, 당사의 API 관리 솔루션을 사용하면 실시간 API 성능을 손쉽게 구현할 수 있는 것으로 일관되게 나타났습니다. 이 솔루션은 API 호출을 처리하는 API 게이트웨이인 NGINX Plus와 NGINX Controller API Management Module을 결합하여, NGINX Plus 인스턴스와 API를 정의, 게시, 관리 및 모니터링하는 전체 수명 주기에 걸쳐 모두 관리할 수 있도록 합니다.

하지만 저희의 말만 믿고 싶지는 않으실 수도 있다는 점을 잘 알고 있습니다. 그래서 저희는 독립적인 기술 연구 및 분석 기관인 GigaOm에 의뢰하여 당사의 API 관리 솔루션과 시장에서 널리 사용되는 다른 솔루션들을 객관적이고 투명하게 벤치마킹했습니다. 대상은 NGINX와 마찬가지로 온프레미스 또는 클라우드에 배포할 수 있는 두 솔루션인 Apigee와 Kong Enterprise, 그리고 완전 관리형 클라우드 서비스인 Amazon API Gateway와 Kong Cloud입니다.

이 블로그에서는 GigaOm의 테스트 결과를 요약합니다(미리 말씀드리면, NGINX Plus는 테스트한 모든 조건에서 API를 실시간으로 제공했지만 다른 솔루션은 그렇지 못했습니다). 솔루션, 테스트 방법론 및 결과에 대한 자세한 내용은 저희 팀에 문의하세요.

참고: Apigee 최종 사용자 라이선스 계약(EULA)은 Google의 명시적인 허가 없이 테스트 결과를 공개하는 것을 금지하므로, 안타깝게도 보고서와 이 블로그에는 Apigee에 관한 정보가 포함되어 있지 않습니다.

벤치마크 개요

GigaOm은 Vegeta HTTP 부하 테스트 도구를 사용하여 요청(API 호출)을 생성하고, 초당 요청 수(RPS)를 다양하게 조정하면서 API 게이트웨이로 인해 추가되는 지연 시간, 즉 API 호출에 대한 응답을 반환하는 데 걸리는 시간을 측정했습니다. GigaOm은 이를 ‘공격률’이라고 부릅니다. GigaOm은 공격률을 1,000 RPS에서 시작해 5,000, 10,000, 20,000 RPS 등으로 높여 가며 Vegeta가 오류 상태 코드를 보고할 때까지 테스트를 실행했습니다. 각 테스트는 60초 동안 진행되었으며 3회 반복되었습니다. 아래 그래프와 같이 GigaOm은 50, 90, 95, 99, 99.9, 99.99백분위수의 지연 시간을 측정했으며, 테스트 중 관측된 최장 지연 시간도 기록했습니다(그래프의 최대값).

결과: NGINX와 Kong Enterprise 비교

GigaOm은 NGINX Plus(NGINX Controller를 사용하여 배포)와 Kong Node(Kong Enterprise를 사용하여 배포)를 비교하는 두 가지 벤치마크를 수행했습니다. 첫 번째 벤치마크에서는 단일 워커 노드(NGINX Plus 또는 Kong Node 인스턴스 1개)를 사용했습니다. 두 번째 벤치마크에서는 라운드 로빈 모드의 NGINX Open Source를 통해 워커 노드 3개의 부하를 분산했습니다. (GigaOm은 NGINX Open Source를 로드 밸런서로 사용한 것이 NGINX Plus에 유리하게 작용하지 않았으며, Kong조차도 클러스터링된 Kong Node 인스턴스에 사용할 로드 밸런서로 이를 권장한다고 강조합니다.)

다음 그래프에서 볼 수 있듯이 NGINX와 Kong의 지연 시간 차이는 99백분위수까지는 미미하지만, 그 지점부터 Kong의 지연 시간이 기하급수적으로 증가하기 시작합니다. 99.99백분위수에서 Kong의 지연 시간은 두 벤치마크에서 각각 NGINX의 3배와 2배에 달합니다.

99번째 백분위수는 API를 실시간으로 정의하기 위한 적절한 최솟값이지만, GigaOm은 실제 환경에 배포할 때 99.9번째 및 99.99번째 백분위수와 같은 더 높은 백분위수에서도 짧은 지연 시간을 유지하는 것이 “매우 중요하다”고 지적합니다. 보고서는 다음과 같이 설명합니다:

지연 시간 결과는 시간 경과에 따라 여러 최빈값을 보이는 경향이 있으며, 급등 구간의 정점은 응답 시간의 일시적인 “지연”을 나타냅니다.

이러한 일시적인 지연은 중요합니다. 응답 시간 또는 지연 시간의 중앙값이 30ms 미만이더라도 1초 이상의 일시적인 지연이 발생하면 이후의 사용자 경험에 실제로 누적 효과가 생깁니다. 예를 들어 음식 대기 시간의 중앙값이 1분인 패스트푸드 드라이브스루를 이용한다면 아마도 좋은 고객 경험이라고 생각할 것입니다. 하지만 앞차의 고객이 주문에 문제가 있어 해결하는 데 10분이 걸린다면 어떨까요? 실제 대기 시간은 11분이 됩니다. 일시적인 지연이 발생한 뒤에 요청이 대기열에 들어갔기 때문에 지연된 99.99번째 백분위수의 지연이 여러분의 지연으로 이어질 수도 있습니다.

높은 백분위수에서 비정상적으로 긴 지연 시간이 미치는 부정적인 영향은 단일 클라이언트 요청이 실제로 여러 개의 다운스트림 API 호출을 생성할 수 있는 분산 애플리케이션에서 더욱 커집니다. 예를 들어 클라이언트 요청 1개가 응답이 느릴 확률이 1%인 하위 시스템에 API 호출 10개를 생성한다고 가정해 보겠습니다. 이 경우 해당 클라이언트 요청 1개가 느린 응답의 영향을 받을 확률이 거의 10%에 달한다는 것을 수학적으로 증명할 수 있습니다. 자세한 계산은 다음을 참조하세요. 내 99번째 백분위수 지연 시간은 누가 옮겼을까?

그림 1은 단일 워커 노드에서 초당 30,000건의 요청(RPS)으로 공격했을 때의 결과를 보여줍니다. 99.99백분위수에서 Kong의 지연 시간은 NGINX보다 3배 이상 길며, 실시간 API의 기준인 30ms를 초과합니다. 반면 NGINX Plus는 모든 백분위수에서 실시간 지연 시간 기준을 충족하며, 기록된 최고(최대) 지연 시간인 13ms조차 실시간 기준의 절반보다 짧습니다.

그림 1. 노드 1개에서 30,000 RPS를 처리하는 NGINX Controller와 Kong Enterprise

그림 2는 워커 노드 3개와 초당 30,000건의 요청 부하로 진행한 벤치마크에서도 매우 유사한 결과가 나타났음을 보여줍니다. 흥미롭게도 Kong은 99번째 및 99.9번째 백분위수에서 NGINX보다 우수한 성능을 보이지만, 99.99번째 백분위수에서는 다시 한번 지연 시간이 급증해 NGINX의 약 두 배에 달합니다. 첫 번째 벤치마크와 마찬가지로 NGINX는 모든 백분위수에서 30ms의 실시간 임계값 미만을 유지합니다.

그림 2. 노드 3개에서 30,000 RPS로 테스트한 NGINX Controller와 Kong Enterprise

API 게이트웨이의 성능을 평가하는 또 다른 방법은 단일 노드 및 3노드 구성 모두에서 모든 백분위수의 지연 시간이 30ms 미만이고 요청이 100% 성공하는(즉, 5xx 또는 429 [Too Many Requests] 오류가 발생하지 않는) 최대 RPS를 확인하는 것입니다. 그림 3에서 볼 수 있듯이, 이 기준으로 NGINX는 Kong보다 50% 높은 RPS를 유지합니다. 각각 30,000과 20,000입니다.

그림 3. 오류 없이 달성한 최대 처리량

결과: NGINX와 Kong Cloud 및 Amazon API Gateway 비교

세 번째 벤치마크 세트에서 GigaOm은 NGINX Plus를 Kong Cloud 및 Amazon API Gateway와 비교했습니다. GigaOm은 Kong Cloud와 Amazon API Gateway가 완전 관리형 SaaS 제품인 반면, NGINX Controller는 PaaS 제품이며 현재 SaaS로 제공되지 않기 때문에 직접 비교하는 데 상당한 어려움이 있다고 강조합니다. 특히 두 SaaS 제품 모두 사용 중인 인스턴스 유형, 컴퓨팅 성능, 메모리 또는 네트워킹 기능을 공개하지 않습니다. 따라서 GigaOm은 NGINX Plus에 적용할 만한 비교 가능한 설정을 최대한 합리적으로 추정해야 했습니다.

NGINX Plus와의 비교를 차치하더라도, 그림 4에 표시된 두 번째로 낮은 공격 속도(5,000 RPS)에서조차 SaaS 제품은 테스트된 어떤 백분위수에서도 API를 실시간으로 제공할 수 없다는 점이 분명합니다. 50번째 백분위수에서 SaaS 제품의 지연 시간은 이미 30ms 임계값의 7배를 넘으며, 99.99번째 백분위수에서는 해당 임계값을 8000% 이상 초과합니다. 이는 Kong Cloud나 Amazon API Gateway가 30ms 미만의 지연 시간으로 100% 성공률을 달성할 수 있는 조건이 전혀 없다는 것을 의미합니다.

그림 4. 노드 1개에서 5,000 RPS로 실행한 NGINX Controller, Amazon API Gateway 및 Kong Cloud

유일한 실시간 API 솔루션으로서 NGINX 검증

요약하면, GigaOm이 테스트한 솔루션 중 실시간 API 처리 기준을 충족한 것은 NGINX뿐이며, 모든 백분위수에서 30ms 미만의 지연 시간을 달성했습니다. Kong Enterprise는 99번째 백분위수에서 실시간 성능을 달성하지만, 그보다 높은 백분위수에서는 지연 시간이 크게 급증하므로 중간 수준의 실시간 API 처리량만 요구하는 프로덕션 환경에도 적합하지 않습니다. 테스트한 SaaS 솔루션 중 어느 것도 실시간 솔루션으로 분류할 수 없습니다.

GigaOm 보고서는 당사의 이전 벤치마크 결과와 고객의 의견을 모두 뒷받침합니다. NGINX Plus는 시장에서 가장 빠른 API 게이트웨이이자 모든 백분위수에서 30ms 미만의 지연 시간을 유지할 수 있는 유일한 API 솔루션입니다. 또한 NGINX Controller와 함께 사용하면 세심한 디커플링을 통해 API 관리 제어 영역(NGINX Controller)이 API 게이트웨이 데이터 영역(NGINX Plus)의 성능에 전혀 영향을 미치지 않도록 독창적으로 설계된 API 관리 솔루션을 이용할 수 있습니다.

당사의 rtapi 지연 시간 측정 도구를 사용하여 API 성능을 직접 테스트할 수 있습니다. 직접 확인해 보고 문의해 주세요. API를 실시간으로 구현할 수 있도록 당사가 어떻게 지원할 수 있는지 상담해 드리겠습니다.

---