NGINX 컨트롤러 API 관리 모듈 대비 콩: 성능 비교

API 관리(APIM) 시장은 경쟁이 치열한 분야입니다. 전체 수명 주기 API 관리 부문의 최신 Gartner Magic Quadrant에서는 22개 공급업체가 선정되었으며, 그 중 7개 업체가 Leaders Quadrant에 포함되었습니다. 기존 시장에서 경쟁하려면 경쟁자와 차별화되고 두각을 나타낼 수 있는 강력한 입지를 구축해야 합니다. 그렇다면 NGINX의 API 관리 솔루션은 어떤 점이 다릅니까?

NGINX의 목표는 가볍고 고성능 소프트웨어를 만드는 것입니다. NGINX 오픈 소스는 연결마다 프로세스나 스레드를 생성하는 웹 서버보다 이벤트 기반 아키텍처가 확장성이 뛰어나 세계에서 가장 바쁜 사이트를 위한 필수 웹 서버가 되었습니다. NGINX 오픈 소스는 업계에서 가장 널리 사용되는 API 게이트웨이이기도 하며, Apigee, Axway, IBM DataPower, Kong, Red Hat 3scale , Torry Harris와 같은 APIM 솔루션에서 API 트래픽을 처리하는 인프라 구성 요소입니다.

NGINX 컨트롤러 API 관리 모듈 은 고성능 APIM 솔루션입니다. 이 블로그에서는 고성능으로 유명한 경쟁 제품인 Kong과 성능을 비교해 보겠습니다. Kong은 NGINX 기반으로 구축되었으며 Lua를 사용하여 API 기능을 구현하는 반면, API 관리 모듈은 NGINX Plus 모듈로 구현된 기본 고성능 기능에 전적으로 의존합니다. NGINX의 API 관리 솔루션은 데이터 플레인과 제어 플레인을 분리하는 혁신적인 아키텍처를 기반으로 구축되었습니다. 모든 API 호출은 제어 평면과 상호 작용할 필요 없이 API 게이트웨이(데이터 평면) 역할을 하는 NGINX Plus를 통해 직접 처리됩니다. 이를 통해 남북 및 동서 트래픽 모두에 대한 고성능 API 트래픽 중재가 가능합니다.

결과를 잠깐 살펴보자면, NGINX 컨트롤러 API 관리 모듈은 Kong보다 2배 더 우수한 성능을 보입니다.

이 테스트를 위해 하드웨어와 실험실 공간을 제공해 준 인텔 에 특별히 감사드립니다. 전체 테스트 및 하드웨어 세부 정보는 부록 에서 확인할 수 있습니다.

단일 요청에 추가된 대기 시간

이 테스트에서는 API 관리자가 도입한 추가 대기 시간을 크기 가 0KB 와 1KB 인 파일에 대한 단일 요청에 대해 비교했습니다. 우리는 curl을 사용하여 단일 HTTP 요청( 세부 정보 )을 보냈습니다.

Kong은 API 관리 모듈과 비교해 대기 시간을 증가시킵니다. 0KB 파일의 경우 44%, 1KB 파일의 경우 24%.

초당 API 호출

표준 HTTP 확장성 측정 기준은 초당 요청 수(RPS)입니다. APIM 맥락에서 동등한 측정 항목은 초당 API 호출입니다. 우리는 wrk를 사용하여 0KB 또는 1KB 파일에 대한 요청 스트림을 3분 동안 300개의 연결을 통해 지속적으로 전송했습니다( 세부 정보 ).

API 관리 모듈은 Kong보다 성능이 우수했습니다. 1KB 응답에 대해 초당 2.6배 더 많은 API 호출을 처리했습니다.

CPU 사용량

API 관리 모듈은 Kong보다 대기 시간이 짧고 초당 더 많은 API 호출을 처리하는데, 이는 CPU를 더 효율적으로 사용하기 때문입니다. 우리는 초당 API 호출 수가 증가함에 따라 CPU 사용량을 측정했습니다. 우리는 단일 코어를 사용했기 때문에 초당 API 호출의 절대 수는 이전 테스트에서 22개 코어를 사용했을 때보다 훨씬 낮습니다( 세부 정보 ).

Kong은 초당 5,000개의 API 호출로 효과적으로 제한을 둡니다. 호출량이 이보다 높아지면 지연 시간이 눈에 띄게 급증하여 시스템이 완전히 로드되었음을 나타냅니다. 초당 5,000개의 호출에서 CPU 사용률은 93%로 API 관리 모듈보다 73% 더 높습니다.

JWT를 사용한 초당 API 호출

마지막 테스트에서는 각 API 게이트웨이가 API 요청을 인증하는 데 가장 선호되는 방법인 JSON 웹 토큰(JWT)을 얼마나 잘 검증하는지 측정합니다. 가장 중요한 API 엔드포인트는 인증될 가능성이 높으므로 이 테스트는 실제 구성에 더욱 근접합니다.

우리는 두 게이트웨이 모두에 HS256을 사용하여 서명된 동일한 JWT를 사용했습니다( 세부 정보 ).

API 관리 모듈은 Kong보다 초당 2배 이상 많은 JWT 인증 API 호출을 처리합니다.

NGINX 컨트롤러 작동 방식

NGINX 컨트롤러는 NGINX Plus 데이터 플레인을 관리하는 제어 플레인 솔루션입니다. NGINX Controller를 사용하면 로드 밸런서, API 게이트웨이 또는 서비스 메시 환경의 프록시로 NGINX Plus의 전체 수명 주기를 관리할 수 있습니다. NGINX 컨트롤러의 API 관리 모듈을 사용하면 API를 정의, 게시, 보안, 모니터링 및 분석할 수 있습니다.

내부적으로 NGINX 컨트롤러는 기본 NGINX Plus 데이터 플레인에 게시되는 NGINX Plus 구성을 생성합니다. 코어 구성 로더는 메모리에 구성을 저장하는 매우 효율적인 메커니즘을 갖추고 있어 API 관리 모듈이 API에 대해 높은 성능을 제공할 수 있습니다.

결론

많은 회사에서는 이미 NGINX 오픈 소스를 API 게이트웨이로 사용하고 있습니다. Capital One은 NGINX 오픈 소스를 사용하여 하루 120억 개가 넘는 API 호출을 처리할 수 있게 되었습니다. 실제로 Kong을 포함한 많은 경쟁사는 APIM 솔루션에서 NGINX 오픈 소스를 사용합니다. NGINX Plus 모듈과 함께 기본 고성능 NGINX 구성을 기반으로 하는 가벼운 설계 덕분에 API 관리 모듈은 NGINX 파생 경쟁 제품보다 더 나은 확장성을 제공합니다.

지연 시간은 최종 사용자 경험에서 가장 중요한 지표 중 하나입니다. 지연 시간이 길면 앱 반응성이 떨어져 사용자에게 실망감을 줍니다. API 관리 모듈은 Kong에 비해 사용자 요청에 대한 대기 시간을 20~30% 더 짧게 추가합니다. 또한 Kong보다 동일한 작업 부하에 대해 40% 더 적은 CPU를 사용하여 시스템 리소스를 보다 효율적으로 사용합니다.

충수

토폴로지

모든 테스트는 간단한 평면 2계층 네트워크에서 10GbE 링크로 연결된 세 대의 별도 장비를 사용하여 수행되었습니다.

사용된 하드웨어

테스트에는 다음 하드웨어가 사용되었습니다. 세 대의 기계는 모두 동일했습니다. 하이퍼스레딩은 사용되지 않았습니다. 이전 테스트에서는 하이퍼스레딩으로 인한 성능의 큰 차이를 관찰하지 못했습니다.

사용된 소프트웨어

테스트에는 다음 소프트웨어가 사용되었습니다.

• NGINX 컨트롤러 API 관리 모듈 버전 2.
• Kong 오픈 소스 버전 1.0.0. Kong Enterprise는 테스트하지 않았지만, 추가 기능 중 어떤 것도 우리 테스트와 관련이 없습니다(예를 들어, Kong Open Source와 Kong Enterprise는 동일한 JWT 플러그인을 사용합니다).
• curl 버전 7.61.0.
• Docker 버전 18.09.1. 관리를 보다 쉽게 하기 위해 Docker 컨테이너 내에서 Kong과 API 관리 모듈을 모두 실행했습니다. Docker는 성능을 약 30% 정도 저하시키는 것으로 나타났지만, 상대적인 성능을 비교하고 있기 때문에 Docker를 사용하는 이점이 성능 저하보다 더 크다는 것을 알 수 있었습니다.
• systat 패키지 버전 12.0.1의 mpstat .
• wrk 버전 4.1.0은 이 지침 에 따라 설치되었습니다.

NGINX 구성

다음 NGINX 구성은 테스트에 사용되었습니다.

업스트림 my_upstream { keepalive 60; 서버 API 서버 :80; keepalive_requests 3000000; keepalive_timeout 300; } 서버 { listen 8000; access_log off; keepalive_requests 3000000; keepalive_timeout 300; tcp_nodelay on; 위치 /test { set $apimgmt_environment 4; set $apimgmt_definition 3; set $upstream my_upstream; set $upstream_protocol http; rewrite ^ /_devel_4 last; } 위치 = /_devel_4 { 내부; set $apimgmt_definition_name my_api; set $apimgmt_environment_name devel; proxy_intercept_errors on; proxy_http_version 1.1; proxy_set_header 연결 ""; proxy_pass $upstream_protocol://$upstream/0kb; # 0KB 파일 #proxy_pass $upstream_protocol://$upstream/1kb.bin; # 1KB 파일 } }

성능을 극대화하기 위해 다음과 같은 설정을 했습니다. 다음 섹션에서 자세히 설명하겠지만, Kong 구성에서도 비슷한 설정을 했습니다.

• TCP 연결 설정으로 인한 오버헤드를 최소화하기 위해 keepalive_requests 와 keepalive_timeout을 큰 숫자로 설정했습니다.
• tcp_nodelay가 활성화되어 Nagle 알고리즘이 비활성화되어 성능이 약간 향상되었습니다.
• access_log가 비활성화되었습니다. 이 기능을 활성화하면 성능이 약 10% 저하됩니다.
• 우리는 두 개의 proxy_pass 지시어를 사용하여 적절한 파일 크기를 요청했습니다.

Kong 구성

이전 섹션에서 설명한 NGINX 구성의 설정과 일치하도록 다음 구성 지침을 kong.conf.default 에 추가했습니다.

nginx_http_tcp_nodelay=onnginx_http_keepalive_requests=3000000
nginx_http_keepalive_timeout=300
프록시_액세스_로그=끄기

다음의 Kong API 호출을 실행하여 API 서버로의 경로를 생성했습니다. 첫 번째 명령은 test 라는 서비스를 만들고 두 번째 명령은 서버를 가리키는 /test 경로를 만듭니다.

$ curl -X POST http://localhost:8001/services/ \ --data '이름=테스트' \ --data 'url=http:// API 서버 :80/0kb' $ curl -X POST http://localhost:8001/services/test/routes \ --data '경로[]=/테스트'

다음 명령은 각각 서비스 및 경로 구성을 표시합니다. JSON 출력을 더 쉽게 읽을 수 있도록 출력을 jq 도구로 파이프합니다.

$ curl localhost:8001/services/ | jq '.' { "다음": null, "데이터": [ { "호스트": "172.20.40.32", "생성_시간": 1556770191, "연결_시간 초과": 60000, "id": "f4629d56-550b-4b37-aa59-66d931aa6f37", "프로토콜": "http", "이름": "테스트", "읽기_시간 초과": 60000, "포트": 80, "경로": "/0kb", "updated_at": 1556770191, "재시도": 5, "쓰기_시간 초과": 60000 } ] } $ curl 로컬호스트:8001/서비스/테스트/경로 | jq '.' { "다음": null, "데이터": [ { "생성_시간": 1556770191, "메소드": null, "id": "a7b417af-ccd4-48f7-b787-ae19490194dc", "서비스": { "id": "f4629d56-550b-4b37-aa59-66d931aa6f37" }, "이름": null, "호스트": null, "updated_at": 1556770191, "preserve_host": 거짓, "regex_priority": 0, "경로": [ "/test" ], "소스": null, "대상": null, "snis": null, "프로토콜": [ "http", "https" ], "스트립_경로": true } ] }

테스트 방법론

단일 요청에 추가된 대기 시간

우리는 단일 요청 지연 시간 테스트에 curl을 사용했습니다. 기준선을 설정하기 위해 먼저 API 게이트웨이 없이 API 서버에 요청을 했습니다. 그런 다음 API 서버 앞에 있는 각 API 게이트웨이에 동일한 요청을 보내서 이로 인해 발생하는 지연 시간을 측정했습니다.

$ curl -w "@curl-latency.txt" -o /dev/null -s http:// 대상 서버

curl-latency.txt 의 내용:

    time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
----------\n
time_total: %{time_total}\n

단일 요청에 추가된 대기 시간 의 차트는 time_total을 밀리초 단위로 보여줍니다. 샘플 출력은 다음과 같습니다.

$ curl -w "@curl-latency.txt" -o /dev/null -s http://192.0.2.1/api-endpoint 시간_이름조회:  0.000035 시간 연결:  0.000364 시간_앱 연결:  0.000000 시간 사전 전송:  0.000401 시간_리디렉션:  0.000000 time_starttransfer:  0.001701 ---------- 총 시간:  0.001727

초당 API 호출

우리는 종종 사용하는 확장 가능한 벤치마킹 도구인 wrk를 사용하여 초당 API 호출을 테스트했습니다. 우리는 다양한 매개변수 조합을 시도했고, 이 조합은 API 관리 모듈과 Kong 모두의 성능을 극대화했습니다.

$ wrk -t 22 -c 300 -d 180 http:// 대상 서버

이 명령은 22개의 작업 스레드(코어당 1개)와 스레드 전체에 걸쳐 총 300개의 연결을 생성합니다. -d 매개변수는 테스트 기간을 지정하는데, 우리의 경우에는 180초(3분)입니다. 샘플 출력:

$ wrk -t 22 -c 300 -d 180 http://192.0.2.1/api-endpoint 3분 테스트 실행 @ http://192.0.2.1/api-endpoint 22개 스레드 및 300개 연결 스레드 통계 평균 표준 편차 최대 +/- 표준 편차 대기 시간 13.96ms 7.84ms 279.85ms 77.37% 요청/초 0.96k 298.23 1.88k 68.55% 3.00m에서 3769861개 요청, 36.25GB 읽기 초당 요청:  20934.34 전송/초:    206.16MB

CPU 사용량

우리는 초당 API 호출 수를 알아보기 위해 wrk 명령을 실행하는 동안 mpstat (이 목적을 위한 표준 Linux 도구)로 CPU 사용량을 테스트했습니다. 샘플 출력(가독성을 위해 두 줄로 나눠서 표시):

$ mpstat Linux 4.18.0-13-generic (nbdw38) 2019-04-29 _x86_64_ (88 CPU) 오후 3시 34분 50초 CPU %usr %nice %sys %iowait %irq %soft %steal ...
오후 03:34:50 전체 0.04 0.00 0.02 0.00 0.00 0.03 0.00 ... ... %guest %gnice %idle ...   0.00 0.00 99.91

JWT를 사용한 초당 API 호출

우리는 초당 API 호출에 대한 wrk 명령으로 JWT 성능을 테스트했습니다. 여기에는 Authorization에 JWT를 삽입하기 위한 -H 매개변수가 추가되었습니다 . 베어러 HTTP 헤더. 이 블로그 게시물 의 지침에 따라 JWT와 JSON 웹 키(JWK)를 생성하고 JWT를 test.jwt 라는 파일에 저장했습니다.

$ wrk -t 22 -c 300 -d 180 -H "권한 부여: 베어러 `cat test.jwt`" \ http:// target-server