AWS에서 Tyk 성능 테스트 방법

8/19/202Jun Hwang

AWS - Tyk 성능 테스트 매뉴얼

다음은 AWS 환경을 프로비저닝하고 Tyk로 몇 가지 간단한 성능 테스트를 수행한 최근 수행의 절차를 소개합니다.

못보셨다면, 여기에 AWS에서 Tyk로 수행한 몇 가지 최근 벤치마크 테스트 요약을 제공하고 있습니다. 성능 테스트를 비공개로 완료하지 않고, 게시한 결과를 달성하기 위해 취한 단계를 문서화하고 싶었습니다. 이를 통해 여러분들도 Tyk 또는 다른 게이트웨이를 사용하여 자체 성능 테스트를 실행할 수 있기를 바랍니다. 또한 우리 방법에 대한 질문이나 의견에 플래그를 지정할 수도 있습니다. 의견, 생각 또는 도전을 환영합니다. 알려주세요!

테스트를 위한 다음 단계를 설명합니다:

모든 환경 호스팅을 위한 AWS 선택
업스트림 선택
높은 처리량이 가능한 부하 발생기 선택
API 게이트웨이 선택(Tyk!)
성능 및 결과 수집

설치와 단순성을 위해 모든 것이 Docker를 통해 실행됩니다.

높은 RPS 테스트를 위한 기준 만들기

가정: 이 블로그의 목적을 위해 AWS, Docker 및 이러한 플랫폼에 대한 터미널 명령에 대한 기본적인 이해를 전제로 했지만, 어쨌든 전반적인 안내를 해 드리겠습니다.

테스트를 위해 AWS를 PoC 환경으로 사용할 것입니다. 먼저 단일 AWS VPC와 서브넷을 생성해야 합니다. 각 EC2 인스턴스에 대해 사용 가능한 IP가 3개 이상 있는 서브넷을 생성해야 합니다. 이것이 이 PoC 빌드의 나머지 부분에 필요한 모든 AWS 인프라입니다.

테스트를 위해 AWS를 POC 환경으로 사용할 것입니다. 먼저 단일 AWS VPC와 서브넷을 생성해야 합니다. 각 EC2 인스턴스에 대해 사용 가능한 IP가 3개 이상 있는 서브넷을 생성해야 합니다. 이것이 이 PoC 빌드의 나머지 부분에 필요한 모든 AWS 인프라입니다.

이 작업을 수행하는 방법을 안내하는 비디오를 시청하세요.

초기 환경은 두 개의 EC2 인스턴스로 설정됩니다. 부하 생성기 인스턴스는 C5.9xLarge이고 업스트림 인스턴스는 c5.2xlarge입니다.

설정이 완료되면 다음과 같이 보입니다: AWS VPC.png

모든 EC2 인스턴스에 대해 AWS Linux 2를 사용하고 있습니다. 비용 효율적이고 이 POC에 필요한 모든 소프트웨어 구성 요소를 실행할 수 있기 때문입니다. 대부분은 Docker에서 실행됩니다.

업스트림 및 부하 생성기

우리는 오픈 소스에 대한 모든 것을 선호하므로 GO 벤치 제품군을 업스트림으로 사용할 것입니다.

이것은 동료 중 한 명이 이전 부하 테스트 연습을 위해 만든 업스트림입니다. 이 업스트림은 REST 기반 API의 일반적인 HTTP 응답을 모방하고 모의 JSON 페이로드를 반환합니다.

테스트를 위해 POST JSON 페이로드와 인증 토큰을 보낼 수 있는 로드 생성기를 사용하여 프론트엔드 사용자 또는 웹 앱을 모방하기로 했습니다.

업스트림 설치하기:

Docker를 통해 모의 업스트림을 설치할 것입니다.

1. 다음 명령을 실행하여 업스트림 EC2 인스턴스에 SSH로 연결합니다.

설정할 때 이 EC2 인스턴스에 등록한 키를 전달해야 합니다.
EC2 인스턴스가 속한 보안 그룹이 SSH 트래픽을 허용하는지 확인합니다.
메인 대시보드에서 ec2 인스턴스의 퍼블릭 IP를 얻을 수 있습니다.

로그인하면 다음 메시지가 표시됩니다:

AWS 로그인 후 표시.png

AWS 인스턴스 상세정보

2. EC2 인스턴스에 Docker 설치

이 모든 명령을 복사하여 터미널에 붙여넣고 모두 실행할 수 있습니다.

install docker on the VM.png

모든 작업이 완료되고나면 루트로 로그인해야 하며, "docker ps"를 수행할 수 있습니다.

docker ps.png

3. 그런 다음, Docker를 통해 업스트림을 실행합니다.

run the upstream.png

이제 업스트림이 백그라운드에서 실행되고 있습니다.

docker 명령에서 실행한 플래그를 설명하자면:

"ulimit" 플래그를 사용하면 로드 생성기가 더 많은 파일 핸들을 열 수 있으므로 최대 동시 로드가 증가합니다.
"p" 플래그는 Docker에게 호스트의 포트 8000을 업스트림이 실행 중인 컨테이너의 포트 8000에 매핑하도록 지시합니다.

엔드포인트 중 하나를 cURL 하여 테스트할 수 있습니다.

이것은 Docker가 컨테이너의 포트 8000에 매핑한 EC2 호스트의 포트 8000에 도달합니다. 요청은 "/json/valid" 엔드포인트의 포트 8000에서 수신 대기하는 서버로 라우팅됩니다. 이 API는 유효한 JSON 응답 페이로드를 반환합니다. 다른 웹 서버가 도커 컨테이너에서 실행 중인 업스트림에 대한 API 호출을 할 때 본질적으로 동일한 동작입니다:

EC2 instance.png

4. 이제 부하 생성기를 실행합니다.

부하 생성기 EC2 인스턴스에서 1단계와 2단계를 반복합니다.

load generator.png

5. "UPSTREAM" 변수를 업스트림 인스턴스에서 실행되는 API 서버로 설정합니다.
이 때, EC2 인스턴스의 프라이빗 IP를 사용해야 합니다. EC2 대시보드에서 사설 IP를 얻을 수 있습니다.

setting UPSTREAM variable.png

6. 이제 테스트를 할 차례 입니다.

test with curl.png

로드 생성기 인스턴스는 다른 EC2 인스턴스에서 실행 중인 업스트림 서버에 API 요청을 성공적으로 수행하고 현재 시간을 나타내는 JSON 응답 페이로드를 수신할 수 있습니다.

이제 모의 업스트림 서버에 대해 부하 생성기를 실행할 준비가 되었습니다.

부하 테스트 – 업스트림 API에 대해 Hey를 실행합니다.

이제 AWS 환경이 설정되었으므로 모의 업스트림 API를 실행해야 합니다. 우리는 다음과 같이 진행하였습니다:
"-z" 플래그는 Hey에게 10초 동안 실행하도록 지시합니다.

"q" 플래그는 연결/작업자당 초당 1500개의 요청을 실행하도록 Hey에 지시합니다. 기본 연결 수는 50입니다.

1500 rps x 50 연결 = 75,000 rps

Docker를 통한 Hey 실행:

도커를 통한 hey 실행.png

신속한 온전성 검사 #1: 보고서 해석

우리가 이 보고서를 어떻게 해석하는지 이해하는 것이 중요합니다. 관심 있는 통계와, 그 통계에 대한 관심을 가지는 이유는 다음과 같습니다:

"상태 코드 배포 (Status code distribution)": 이 섹션은 응답 코드별로 집계된 응답에 대해 보고합니다. 우리는 여기서 성공적인 API 응답을 나타내는 [200] 응답만 볼 수 있기를 바랍니다. 그렇지 않으면 어딘가에 오류가 있습니다. 이 숫자는 "Hey"의 제한으로 인해 100만 응답에서 계산을 중지하지만 프로그램은 계속해서 로드를 생성한다는 것을 기억하세요.

"지연 분포 (Latency Distribution)": 이 숫자는 API 요청이 전송된 후 응답이 반환될 때까지 걸리는 시간을 나타냅니다. 레이턴시 분배는 API 게이트웨이를 추가함으로써 얼마나 많은 지연이 발생하는지 볼 수 있게 해주기 때문에 중요합니다. 우리는 이 수치를 가능한 한 낮게 유지하기를 원합니다. 일반적으로 30-50ms 미만의 응답은 우리 앱이 실시간, 즉각적인 애플리케이션처럼 느껴질 것입니다. "실시간 인식"에 대한 추가적인 설명은 링크를 누르세요.

대기 시간 분포의 모든 숫자 중에서 P99 대기 시간 지표가 가장 중요합니다. 일반적으로 P99 대기 시간은 모든 결과의 99%가 주어진 값에 해당한다는 것을 의미합니다. 부하 테스트의 맥락에서 이는 P99 지연 시간 값이 0.5ms인 경우 API 요청의 1%를 제외한 모든 요청이 0.5ms 또는 0.0005초보다 더 빠른(낮은) 지연 시간을 경험함을 의미합니다.

P99 대기 시간에 대한 테스트는 대부분의 사용자가 여러분의 API를 사용하는 동안 경험하게 될 사항을 설명하는 지표이기 때문에 중요합니다. 우리는 최선의 응답이나 가장 느린 응답에 그다지 신경을 쓰지 않고, 우리가 구축하려는 전반적인 사용자 경험을 가장 잘 나타내는 응답에 집중하는 것이 좋습니다.

"초당 요청 수 (Requests/sec)": 이것은 우리가 받는 처리량입니다. 이는 서버와 API 게이트웨이가 처리할 수 있는 로드를 나타냅니다. 요청을 단일 사용자가 하나의 요청을 하거나, 단일 사용자가 많은 동시 요청을 하는 것으로 생각하십시오. 처리할 수 있는 요청이 많을수록 더 많은 사용자를 지원할 수 있기 때문에 이 숫자를 최대한 높게 설정합니다! 우리의 목표를 수십만 또는 수백만 명의 사용자가 동시에 하나의 API를 사용할 수 있는 Netflix와 같은 회사의 목표와 유사한 것으로 생각하십시오.

이제 테스트 과정이 실행되었으므로 "전자 상거래 프론트 엔드" 앱 "Hey"가 P99 대기 시간을 0.5ms로 유지하면서 초당 74,801개의 요청을 성공적으로 실행했음을 보여줄 수 있습니다.

(주의깊게 살펴 볼 다른 중요한 관찰 사항은; 테스트 중에 CPU 사용률이 안정적이어서 요구 사항에 적합한 인스턴스 크기를 선택했음을 나타냅니다.)

cpu utilization.png

일관성을 위해 테스트를 몇 번 더 실행하여 평균 99% 백분위수 값을 얻었습니다.

게이트웨이 사용 전의 벤치마크 요약

5분 동안 초당 75,000개 요청 처리

summary b4 gateway.png

이것으로 향후 게이트웨이 성능을 비교하기 위한 베이스라인이 완성되었습니다.

테스트에 Tyk 게이트웨이 도입:

이제 모의 API와 모의 프런트 엔드 애플리케이션이 준비되었으므로 Tyk Gateway를 테스트 조합에 추가할 수 있습니다. 또한 모든 API 트래픽을 모니터링, 관리 및 분석할 수 있는 Tyk Gateway 기능을 도입하기로 결정했습니다.

인증 (Authentication)

인가되지 않은 사용으로부터 API를 보호할 수 없으면 플랫폼이 작동하지 않습니다. 일반적인 해결책은 프론트엔드 웹 애플리케이션에 OAuth 2.0을 구현하는 것입니다. 그러나 작업을 빠르고 쉽게 유지하기 위해 지금은 PoC에서 간단한 인증 토큰을 사용합니다.

인증 토큰을 사용하면 API에서 인증이 활성화되면 Tyk에서 API 요청을 확인할 수 있습니다.

속도 제한 (Rate limiting)

속도 제한을 활성화하는 몇 가지 이유가 있습니다. 미래에는 API로 수익을 창출할 수 있으므로 수익을 창출할 계층형 비용 시스템을 구성할 수 있는 더 높은 속도 제한 액세스를 포함하는 계층형 정책 (tiered policies)을 도입해야 합니다. 또 다른 이유는 처리할 수 있는 것보다 너무 많은 연결 및 요청을 수락하여 API가 폭발하는 것을 방지하는 것입니다.

Tyk를 통해 속도 제한을 활성화하고 인증 토큰에 Tyk에서 적용할 고유한 속도 제한을 부여할 수 있습니다.

분석 정보 (Analytics)

숫자로 재미있게! 우리는 Tyk가 분석을 수집하여 인프라를 모니터링하고 비즈니스 분석 팀에 정보를 제공할 수 있기를 바랍니다.

이제 우리에게 중요한 게이트웨이 기능을 결정했으므로 Tyk를 POC 환경에 설치해야 합니다. 다음은 PoC를 위한 새로운 아키텍처입니다:

analytics for PoC.png

먼저, 게이트웨이용으로 c5.9xlarge에서 세 번째 EC2 인스턴스를 가동해 봅시다!

Tyk를 실행하는 지침은 간단하며 요약하지만 여기에 공식 Tyk 문서를 찾을 수 있는 링크가 있습니다.

1. VM에 Docker 설치

install EC2 instance.png

"/home/ec2-user"에 "tyk.standalone.conf"라는 파일을 생성하고 "step1 tyk.standalone.conf"의 내용을 붙여넣습니다.

2. Tyk 게이트웨이 구성 파일 생성

여러 가지 방법으로 파일을 복사할 수 있습니다. 여기 하나가 있습니다:

curl --silent https://gist.githubusercontent.com/sedkis/8ec32c111dcc407119a6c88fc868458b/raw/df97f6267dcb62f638a9a8b0c5515910e29df2f3/step1%2520tyk.standalone.conf | cat > tyk.standalone.conf

3. "apps"라는 디렉토리를 만듭니다.

mkdir apps.png

4. "api_test.json"이라는 파일을 만들고 "step2 api_test.json"의 내용을 붙여 넣습니다.

다음 지침을 사용하거나 다른 방법으로 파일을 만듭니다:

curl --silent https://gist.githubusercontent.com/sedkis/8ec32c111dcc407119a6c88fc868458b/raw/df97f6267dcb62f638a9a8b0c5515910e29df2f3/step1%2520api_test.json | cat > apps/api_test.json

5. 도커에서 Tyk 부트스트랩 실행

먼저 Tyk Gateway가 메모리 내 저장소로서 필요로 하는 Redis를 실행합니다.

Redis 실행.png

6. 업스트림 EC2 인스턴스의 프라이빗 IP에 대한 env 변수 매핑 생성

env 변수 매핑.png

7. Tyk 실행

Tyk 컨테이너 실행.png

컨테이너를 실행하는 동안 전달한 플래그를 설명하겠습니다.

"ulimit" – 더 많은 파일 핸들을 사용할 수 있도록 합니다. 자세한 내용 ulimit 읽기

"-add-host" – 업스트림 서버가 어디에 있는지 알 수 있도록 도커 컨테이너에 호스트 이름 항목을 추가합니다. 이것은 "target" 아래의 "/apps/api_test.json" 아래의 API 정의에서 분명합니다.

"GOGC"– 더 많은 성능을 얻기 위해 GO 가비지 수집기의 기본 동작을 변경합니다. 다음은 Tyk의 Ahmet Soormally가 이에 대해 자세히 설명한 기사입니다.

"Log-opt max-size" – 로그 파일의 최대 크기를 설정합니다. 게이트웨이는 테스트에 따라 많은 오류 메시지를 인쇄할 수 있습니다.

"-v" – 호스트에서 컨테이너로 "tyk.standalone.conf" 파일과 "apps" 디렉토리를 마운트합니다. "앱"에서 생성된 모든 API 정의는 컨테이너에서 선택됩니다. tyk conf 파일은 어떻게 실행해야 하는지 Tyk에 설명합니다.

8. 마지막으로 상태 확인 엔드포인트를 눌러 Tyk 게이트웨이가 실행 중인지 확인합니다.

tyk running.png

9. Tyk 게이트웨이에서 수신 경로를 쿼리하고 업스트림 엔드포인트에서 응답을 수신하여 역방향 프록시 정의가 작동하는지 다시 확인합니다.

confirming reverse proxy.png

이것은 업스트림의 "/json/valid" 엔드포인트에 대한 "/apitest" 수신 경로를 통해 프록시 트래픽을 역전 (reverse proxy)시킵니다.

신속한 온전성 검사 #2: 상태 점검

우리가 한 일은 헤드리스 모드에서 실행되도록 Tyk를 설정하고 파일에서 API 프록시 구성을 가져오는 것이었습니다. 우리가 정의한 단일 API 프록시 정의는 속도 제한 없이 인증되지 않은 상태로 실행됩니다. 이 단계에서 Tyk는 이 업스트림에 대한 간단한 역방향 프록시이며 엔드포인트 "/apitest"에서 수신 대기합니다.

이제 재미가 시작됩니다: Tyk에 대해 부하 생성기를 실행해 보겠습니다.

이제 로드 생성 VM으로 돌아가 모든 구성 요소가 설정되고 실행되는 테스트를 시작할 수 있습니다.

1. Tyk가 실행 중인 EC2 인스턴스의 프라이빗 IP에 매핑되는 env 변수를 생성합니다. 이것은 EC2에서 찾을 수 있습니다.

private IP 매핑.png

2. 다음 명령을 사용하여 Tyk에 대해 부하 생성기를 실행합니다:
(5분 후 Hey가 터미널에 부하 테스트 보고서를 뱉습니다.)

run load gen.png

신속한 온전성 검사 #3: 우리는 어떤 숫자에 관심이 있습니까?

우리가 관심을 갖고 있는 두 가지 주요 수치는 초당 요청 수(RPS)와 99%의 대기 시간 분포였습니다. RPS 결과에서 알 수 있듯이 Tyk는 70,000 RPS 이상의 리버스 프록시를 수행하면서 밀리초 미만의 대기 시간만 추가할 수 있었습니다. 명확하게 말하면 Tyk는 99번째 백분위수 대기 시간에 0.6ms만 추가하여 총 1ms 동안 초당 무려 71,556개의 요청을 역방향 프록시했습니다.

꾸준한 활용으로 65% CPU만 사용하면서 이 RPS를 달성했습니다:

벤치마크 요약 결과 – 단순한 프록시

5분 동안 초당 75,000개 요청 처리

투명 프록시 결과.png

우리의 첫 번째 테스트는 Tyk를 단순한 역 프록시로 보여 환상적인 수치를 만들어 냈지만 앞에서 언급했듯이 게이트웨이에서 더 많은 기능을 원합니다. 다음은 기능을 켠 상태에서 테스트한 내용입니다.

<u>이번에는 모든 기능이 켜진 상태에서 진행합니다 (Full loaded test)!</u>

** 1. Tyk 게이트웨이 인스턴스에 SSH 연결** ** 2. "apps/auth_api.json" 아래에 새 파일을 생성하고 "step2 auth_api.json"의 내용을 복사합니다.**

다음 지침을 사용하거나 다른 방법으로 파일을 만듭니다.

curl --silent https://gist.githubusercontent.com/sedkis/8ec32c111dcc407119a6c88fc868458b/raw/df97f62

바로 앞의 API 정의와 비교하여 "keyless" 플래그를 제거하고 인증 비트를 추가한 것을 알 수 있습니다. 마지막으로, "disable_rate_limit"를 false로 설정합니다. 이 새로운 API 역방향 프록시 정의에 대한 Tyk 게이트웨이의 엔드포인트는 "/auth_api_test"입니다.

3. "tyk.standalone.conf"를 수정하여 "enable_analytics"를 true로 설정합니다.

이렇게함으로써 Tyk에서 분석을 수집할 수 있습니다. Tyk는 분석을 Redis에 임시로 저장합니다. DataDog, Logz.io, ElasticSearch, Grafana, Prometheus 등과 같은 영구 데이터 저장소로 이동하려면 Tyk Pump를 사용합니다.

"nano" 또는 "vi"를 사용하여 파일을 수정하거나, 이게 더 쉽다면, 간단히 삭제하고 이 파일을 복사할 수 있습니다.

4. 변경 사항을 적용하려면 게이트웨이 컨테이너를 다시 시작하십시오.

도커 재시작.png