Why Tyk?

Tyk API Gateway의 AWS 성능 테스트 (benchmark)

최근에 우리는 새로운 사용자로부터 초당 일천 만 개의 API 요청을 처리할 수 있는 게이트웨이를 찾는 중이라고 들었습니다. 그것도 저가로 말이죠. 그 분들은 모든 것을 AWS를 이용하여 cloud-first 온라인 쇼핑몰을 운영 중이라고 하였습니다. “이 분들은 Tyk의 성능이 AWS 상에서 어느 정도이기를 기대할까?” 하는 궁극적인 질문을 하게 되는 대목입니다.

이 질문에 대한 정답은, 사실대로 말하자면, 아무도 듣고 싶지 않은, ‘경우에 따라 다르다’ 입니다. 그것은 여러분의 설정에 달려 있고, 환경에 따라 다르며, 어떤 타입의 CPU/Memory/Storage 자원을 제공하는 지에 따라, 어떤 기능을 사용하고 싶은 지에 따라, payload가 어느 정도인 지에 따라, 사용하는 애플리케이션의 속성에 따라, … 이 리스트는 한없이 길어집니다. Tyk는 처음부터 클라우드 네이티브 아키텍처로서 설계되었기 때문에, 수직확장 (scale-up)과 수평확장 (scale-out)에 아무런 제약이 없습니다.

하지만, 고객들이 기대하는 성능 수준에 대해 계속되는 질문은, 우리가 지난 번에 성능 벤치마킹 결과를 게시한지 거의 1년이 되었다는 사실을 알아차리게 하였습니다. 그 당시에 동료, Ahmet Soormally는 부가기능 없는 2코어 서버와 4GB의 램으로 구성된 환경에서 Tyk의 성능이 극도로 낮은 수준의 지체 (latency)와 함께 6400 RPS를 이른다는 것을 보여준 바 있습니다.

그 벤치마킹의 의도는 Tyk를 경쟁제품과 비교하려는 것이 아니었습니다. 그것은 절대로, 테스트 환경을 블랙박스 안에 감추거나, 이상한 환경적 설정을 적용하여 성능에 대한 거짓 주장을 하려던 것이 아니었습니다. 그것은 “그래, 그렇지만…” 하고 나서는 Tyk를 싫어하는 어떤 사람들의 주장에 기름을 부을 목적도 아니었습니다.

그 당시에는, 오히려, 우리가 벤치마킹으로 무엇을 하고 있는지에 대하여 몇 가지 사항에 주의를 기울인 다음, Tyk가 아주 유연한 게이트웨이라는 사실을 알리기 위한 목적이었습니다. 타이크가 어떤 성능 필요와 어떤 규모의 예산에도 맞춤 재단 될 수 있다는 것을 알리자는 의도였죠. 여러분의 유스케이스에 따라, 타이크를 사용하여 요구사항에 맞게 API를 매니지먼트 할 방법은 아주 많습니다.

작년의 Ahmet의 벤치마킹 개요는 크기 조정, 구성, 종속성, 그리고 설치 및 몇 가지의 기법에 대하여 다루었습니다. 따라서, 단순히 “예, 우리 제품은 빠르고, 저가입니다” 라고 말하기 보다는 실제로 그가 어떻게 자신의 테스트를 수행하였고 그 당시 자신의 사고 과정을 보여주고 싶었던 것입니다.

1년의 빠르게 지났고 우리는 비슷한 방법의 테스트를 원했습니다. 타이크로부터 기대할 수 있는 성능 유형에 대한 같은 질문에 답하고 싶었지만, 이번에는 AWS를 기본 인프라로 사용하는 데 중점을 두었습니다.우리의 접근방식에 투명성을 제공함으로써 오픈 소스의 정신에 충실하기 위하여 AWS에서 성능 테스트를 안내하는 단계별 가이드를 제공합니다.

아래의 요약표를 보시고 자세한 사항은 위의 링크를 참조하세요.

맨 앞단에서의 벤치마크 결과 - 5분 동안 초당 75,000 요청 처리 (75,000 RPS)

투명 프록시로서의 벤치마크 결과 - 5분 동안 초당 75,000 요청 처리 (75,000 RPS)

Full-load APIM (트래픽 조정, API 인가/인증, 대시보드 분석정보 포함) 5분 동안 초당 75,000 요청 처리 (75,000 RPS)

게이트웨이 없이 투명 프록시로서 여러 가지 기능들을 활성화하고 테스트 한 뒤 Tyk 게이트웨이를 추가할 때, 초당 69,000 개 이상의 요청을 리버스 프록시하는 동안 0.77ms만 늘어나는 것으로 나타났습니다. 다음은 모든 API 요청에 대해 달성된 기록입니다. 인증 토큰에 대한 유효성 검증 수행 인증 토큰 별 요청에 대한 리소스 접근권한 검증 수행 속도 제한 추가 수행 (해당 키가 초당 100,000 요청 이상 쿼리 하지 못하게 설정) 추가 분석 및 향후 추적을 위하여 모든 요청/응답 트립에 대하여 분석정보 수집

앞으로 더, 우리는 타이크의 성능에 대한 벤치마킹 테스트를 진행할 것입니다. 그 테스트들에서 우리는 타이크를 어디까지 확장할 수 있는지를 보기 위해 더 높은 초당 요청수 (RPS)를 추구할 것입니다.우리는 주요 병목점이 타이크 노드 (게이트웨이 nodes)와 Redis 클러스터의 CPU 사용량이라고 믿고 있습니다. 우리가 그 문제를 해결하기 위해 하드웨어를 추가할 수 있는 한, 타이크는 플랫폼이 요구하는 가능한 만큼의 충분한 처리를 해 낼 수 있습니다.

앞에서 언급한 것처럼, 예산은 천차만별이고 large EC2 인스턴스는 누구에게나 허용된 자원이 아닐 것입니다. 그래서 우리는 항상 하드웨어를 추가하는 것이 해결책 일 수 없다는 것을 잘 압니다. 하지만, Ahmet이 작년에 보여주었고, 우리가 여기에서 확인한 것처럼, Tyk는 스스로, 다양한 예산 범위 내에서 유연하면서 고성능의 게이트웨이라는 것을 증명하고 있습니다. 한 예로, 다른 인스턴스 사이즈로 테스트 한 결과, 우리는 smaller EC2 인스턴스가 오히려 ‘비용의 측면 (RPS / latency per dollar)’에서 더 높은 RPS와 latency를 보여준다는 것을 알았습니다. 이처럼 가성비를 올리면서 효율을 증대시킬 수 있습니다.

향후에는 Tyk Pro 버전으로 다른 설정으로 어떤 결과를 보이는지 블로그에 포스팅 할 예정입니다. 우리는 K8s와 같은 다른 배포환경도 테스트 요소로 추가할 것입니다. 컨테이너와 마이크로서비스가 점점 확산되면서, 우리는 타이크가 K8s에서 어떻게 구동되는지, 세계 곳곳으로 연결된 엔터프라이즈의 인프라가 어떻게 확장되고 관리될 수 있는지 보여 드리고 싶습니다. 또한, 타이크가 어떻게 벤더에 종속적으로 되는 것을 방지하는지 보여 드리고, 이종 클라우드에서 여러 개의 클러스터를 수용하는 기능을 각각의 플랫폼에서 타이크 게이트웨이 서비스를 통하여 보여 드릴 것입니다.

여러분이 이런 벤치마킹에 관심이 있다면, 저희에게 메모를 남겨 주십시오.