NGINX, Kong 및 Amazon의 API 관리 솔루션 벤치마킹: 실시간으로 API를 제공하나요?

속도 – 오늘날의 디지털 환경에서는 앱 성능이 너무 느리면 소비자가 쉽게 경쟁사로 전환할 수 있으므로 속도가 중요합니다. 앱 속도는 궁극적으로 반응성, 건강함, 적응성이 뛰어난 API에 의해 결정되며, API 반응성의 중요한 요소 중 하나는 API 게이트웨이에서 발생하는 지연 시간입니다. 하지만 모든 API 게이트웨이가 동일한 수준에서 성능을 발휘하는 것은 아닙니다.

그 요점은 작년 가을에 소비자 신용 산업의 주요 업체인 NGINX 고객이 점점 더 많은 앱과 기타 구성 요소가 사용자가 기대하는 디지털 경험을 제공하기 위해 통신해야 하므로 "실시간" API 성능의 중요성이 커지고 있다고 말했을 때 우리에게 분명해졌습니다. NGINX Plus가 고객이 필요로 하는 초고속 API 대기 시간(최소 10밀리초(ms))을 달성한 유일한 API 게이트웨이라는 사실을 알게 되어 매우 기뻤습니다. 다른 많은 고객들, 와 같은 캐피탈 원또한 NGINX Open Source 또는 NGINX Plus를 API 게이트웨이로 사용하여 대기 시간을 줄이고 처리량을 개선한 방법도 공유했습니다.

우리는 API 생태계를 더 깊이 살펴보고 API를 "실시간"으로 만드는 요소가 무엇인지 알아내기로 결정했습니다. 여러 요소를 기반으로, 실시간 API는 99번째까지 모든 백분위수에서 30ms 이내에 API 호출을 처음부터 끝까지 처리해야 한다는 결론을 내렸습니다(즉, 평균적으로 100개의 호출 중 30ms보다 오래 걸리는 호출은 1개뿐입니다).

API 관리 솔루션 비교

NGINX Plus를 API 호출 처리를 위한 API 게이트웨이로 결합하고, NGINX Controller API 관리 모듈을 사용하여 NGINX Plus 인스턴스와 API를 정의, 게시, 관리, 모니터링하면서 전체 수명 주기에 걸쳐 API를 관리하는 API 관리 솔루션을 사용하면 실시간 API 성능을 쉽게 달성할 수 있다는 사실이 당사의 자체 테스트 결과에 의해 지속적으로 입증되었습니다.

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

이 블로그에서는 GigaOm 테스트 결과를 요약합니다(스포일러: NGINX Plus는 테스트된 모든 조건에서 실시간으로 API를 제공했지만 다른 솔루션은 그렇지 않았습니다. 솔루션에 대한 자세한 내용, 테스트 방법 및 결과에 대해 자세히 알아보려면 저희 팀 구성원에게 문의하세요 .

메모: Apigee 최종 사용자 라이선스 계약(EULA)은 Google의 명시적 허가 없이 테스트 결과를 공개하는 것을 금지하므로 불행히도 보고서나 이 블로그에는 Apigee에 대한 정보가 포함되어 있지 않습니다.

벤치마크 개요

GigaOm은 Vegeta HTTP 부하 테스트 도구를 사용하여 요청(API 호출)을 생성하고 API 게이트웨이가 초당 다양한 요청 수(RPS)에서 얼마나 많은 지연 시간(API 호출에 대한 응답을 반환하는 데 걸리는 시간)을 도입하는지 측정했습니다. GigaOm은 이를 "공격 속도"라고 부릅니다. GigaOm은 Vegeta가 오류 상태 코드를 보고할 때까지 1,000 RPS에서 시작하여 5,000, 10,000, 20,000 등으로 확장하는 공격 속도로 테스트를 실행했습니다. 각 테스트는 60초씩 소요되었고 3번 반복되었습니다. 아래 그래프에서 보듯이, GigaOm은 50번째, 90번째, 95번째, 99번째, 99.9번째, 99.99번째 백분위수에서 지연 시간을 포착했으며, 테스트 실행 중 관찰된 가장 긴 지연 시간(그래프의 Max )도 기록했습니다.

결과: NGINX 대 콩 엔터프라이즈

GigaOm은 NGINX Plus(NGINX Controller를 사용하여 배포)와 Kong Node(Kong Enterprise를 사용하여 배포)를 비교하는 두 가지 벤치마크를 수행했습니다. 첫 번째 벤치마크에서는 단일 작업자 노드(NGINX Plus 또는 Kong Node의 인스턴스 하나)가 있었습니다. 두 번째로는 라운드 로빈 모드로 NGINX 오픈 소스로 부하를 분산한 세 개의 워커 노드가 있었습니다. (GigaOm은 NGINX 오픈 소스를 로드 밸런서로 사용해도 NGINX Plus에 이점이 없다고 강조하며, Kong 역시 클러스터링된 Kong 노드 인스턴스에 사용할 로드 밸런서로 NGINX Plus를 권장합니다.)

다음 그래프에서 볼 수 있듯이 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개의 클라이언트 요청이 하위 시스템에 대한 10개의 API 호출을 생성하고 느리게 응답할 확률이 1%라고 가정해 보겠습니다. 결과적으로 1개 클라이언트 요청이 느린 응답으로 인해 영향을 받을 확률은 거의 10%라는 것을 수학적으로 증명할 수 있습니다. 자세한 수학 문제는 누가 내 99번째 백분위수 지연 시간을 옮겼는가를 참조하세요.

그림 1은 단일 워커 노드를 사용한 30,000 RPS 공격률에 대한 결과를 나타냅니다. 99.99 백분위수에서 Kong의 지연 시간은 NGINX의 3배가 넘고 실시간 API에 대한 30ms 한계를 초과합니다. 이와 대조적으로 NGINX Plus는 모든 백분위수에서 실시간 지연 시간을 달성합니다. 기록된 가장 높은( Max ) 지연 시간인 13ms도 실시간 임계값의 절반도 되지 않습니다.

그림 2는 30,000 RPS 공격률에서도 3개의 작업자 노드가 있는 벤치마크에 대해 매우 유사한 결과를 보여줍니다. 흥미로운 점은 Kong이 99번째 및 99.9번째 백분위수에서는 NGINX보다 성능이 뛰어나지만, 99.99번째 백분위수에서 다시 한 번 엄청난 지연 시간 급증을 겪었으며, 이번에는 NGINX의 약 2배에 달하는 지연 시간에 도달했습니다. 첫 번째 벤치마크와 마찬가지로 NGINX는 모든 백분위수에서 30ms 실시간 임계값 아래에 유지됩니다.

API 게이트웨이의 성능을 측정하는 또 다른 방법은 100% 성공률로 처리할 수 있는 최대 RPS를 결정하는 것입니다( 5xx 또는429 단일 노드 및 3노드 구성 모두에서 모든 백분위수에서 [요청이 너무 많음 ] 오류 및 30ms 미만의 대기 시간이 발생했습니다. 그림 3은 이 측정을 통해 NGINX가 Kong보다 50% 더 높은 RPS를 유지하는 방식을 보여줍니다. 30,000 대 20,000.

결과: 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와의 비교를 제쳐두더라도 SaaS 제품은 테스트된 모든 백분위수에서 실시간으로 API를 제공할 수 없다는 것이 즉시 분명해집니다. 그림 4에 표시된 두 번째로 낮은 공격률(5,000 RPS)에서도 마찬가지입니다. 50번째 백분위수에서 SaaS 서비스의 지연 시간은 이미 30ms 임계값의 7배를 넘습니다. 99.99번째 백분위수에서는 해당 임계값을 8000% 이상 초과합니다. 명백한 의미는 Kong Cloud나 Amazon API Gateway가 30ms 미만의 지연 시간으로 100% 성공할 수 있는 조건은 없다는 것입니다.

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

요약하자면 NGINX는 GigaOm에서 테스트한 솔루션 중 실시간 API 처리 표준을 충족한 유일한 솔루션으로, 모든 백분위수에서 30ms 미만의 지연 시간을 달성했습니다. Kong Enterprise는 99번째 백분위수에서 실시간 성능을 달성하지만 대기 시간은 더 높은 백분위수에서 상당히 급증하기 때문에 중간 수준의 실시간 API 처리가 필요한 프로덕션 환경에는 적합하지 않습니다. 테스트된 SaaS 솔루션 중 어느 것도 실시간으로 분류될 수 없습니다.

GigaOm 보고서는 이전 벤치마크와 고객으로부터 들은 내용을 모두 검증한 것입니다. NGINX Plus는 시장에서 가장 빠른 API 게이트웨이이며 모든 백분위수에서 30ms 미만의 지연 시간을 유지할 수 있는 유일한 API 솔루션입니다. NGINX 컨트롤러와 페어링하면 고유하게 설계된 API 관리 솔루션에 액세스할 수 있습니다. 이 솔루션에서는 API 게이트웨이 데이터 플레인(NGINX Plus)과 API 관리 제어 플레인(NGINX 컨트롤러)의 성능에 어떠한 영향도 미치지 않습니다.

rtapi 지연 시간 측정 도구를 사용하여 자체 API 성능을 테스트할 수 있습니다. 확인해보시고 API를 실시간으로 만드는 데 어떻게 도움을 드릴 수 있는지 논의해 보시려면 저희에게 연락하세요 .