medium_need rate limiting.jpeg

small_need rate limiting.jpeg

thumbnail_need rate limiting.jpeg

need rate limiting.jpeg

#  [백신 접종 사전예약 불능 사태](https://www.ytn.co.kr/_ln/0103_202107200419566861)
> 정부에서 제공하는 백신 접종 사전예약시스템이 트래픽을 감당하지 못하여 서비스가 원활하지 못하다는 보도를 접하면서, 잠시 이 사태를 API Gateway 관점에서 생각하게 됩니다. 대체 어떤 API 게이트웨이를 사용했을까 무척 궁금해집니다.

모든 API Gateway는 기본적으로 네트워크에서 호출되는 트래픽을 감당할 수 있도록 설계되어 있고, 어떻게 고가용성 (HA, High Availability)를 보장하는가에 따라서 제품의 성능이 결정될 만큼 중요한 요소입니다. 따라서, API Gateway의 사용주체는 자신들의 서비스에 대한 가상 시나리오에 적절히 대응할 수 있는 제품을 구매하는 것이 필수입니다. 이 부분은 엔지니어의 판단이라기 보다는 사용자측, 즉 서비스 도메인 전문가의 판단이 더 중요합니다. 

Tyk API Gateway는 이러한 상황에 대처하기에 아주 편리한 접근제어체계를 제공합니다.   

1. Rate Limiting - 하나의 key 값에 대하여 x 만큼의 요청을 y 시간 내에만 가능하도록 제어하며 (예: 초당 100개의 요청), 아래의 세 가지 유형으로 설정 가능합니다.   
- Hard-synchronized: 해당 key에 대하여 모든 게이트웨이 인스턴스에 동일한 rate limit를 적용합니다.
- Distributed Rate Limiter (DRL): 해당 key에 대하여 게이트웨이 개별 인스턴스 마다 rate limit를 적용합니다.
- Global Rate Limiter: 모든 사용자에 대하여 통합적으로 rate limit를 적용합니다. 커뮤니티 에디션 (CE)는 이 유형만 가능합니다.    
2. Quotas - 정의된 시간동안 어느 만큼의 요청을 허용할 지 설정합니다. Rate limiting으로 제어하는 것 보다 더 긴 시간을 효과적으로 제어합니다 (예: 월당 10,000 개의 요청).
Tyk는 해당 사용자에 대하여 설정된 시간이 만료되면 자동으로 쿼터를 리셋 해줍니다.
3. Key의 유효기간 설정 - 해당 토큰이 만기가 되면 더 이상 요청이 작동되지 않습니다.    

# [따라하기](https://tyk.io/docs/basic-config-and-security/control-limit-traffic/rate-limiting/)




API Gateway의 유용성 - Rate limiting

# Tyk의 UDG (Universal Data Graph)와 GraphQL 정보를 한 데 모았습니다. 

저희가 열심히 개발한 GraphQL 기능들을 여러분께 소개한 지도 벌써 1년이 흘렀군요. 당시에 API 매니지먼트 플랫폼에 GraphQL을 도입하고 사용자들이 ***Tyk 내에서*** 엔드포인트를 작성할 수 있는 Universal Data Graph를 구현했었지요.

개념에서부터 직접 해보는 튜토리얼까지, 그간의 GraphQL 여정을 한 곳에 모았습니다. 간략하지만 흥미진진한 신기술을 여기서 만나보시기 바랍니다.

## [Universal Data Graph](https://tyk.io/welcome-to-the-universal-data-graph/)에 오신 것을 환영합니다.

작년 6월 초, Tyk의 CEO Martin은 우리의 API 매니지먼트 제안 속에 GraphQL 역량을 추가하기 위한 창의적인 노력에 대해 논의하기 시작했습니다. 그는  본질적으로 서로 다른 데이터 소스 스키마들을 하나의 데이터 그래프로 생성하기 위한, "함께 꿰매기"라는 아이디어와 그 방식의 강력함에 대해 소개 하였습니다.그것은 GraphQL과 Tyk를 왜 쓰야 하는 지에 대하여 답하는 훌륭한 개요였습니다.

## [GraphQL - 플랫폼으로서의 접근법](https://tyk.io/graphql-a-platform-approach/)

당시에 Martin은 Tyk의 Universal Data Graph에 대한 그의 하이레벨 개요를 함께 공표하였는데, 우리 기술 R&D 팀 파트너, Ahmet Soormally가 우리의 GraphQL 제공 뒷단의 접근법과 전략을 잘 요약하여 정리했습니다. Ahmet은 인가/인증의 구현과 질의의 깊이를 제한함으로써 DoS 공격의 방어, 그리고 단 한 줄의 코드 작성없이 통합된 데이터 그래프로 꿰어내는 UDG 등의 이면에 자리한 우리의 사상을 설명합니다. 이 글에서는 GraphQL 공간에서 Tyk의 최신 기능성이 정확히 어떤 것을 사용자들에게 제공하는 지를 잘 설명하는 개요 입니다.
## [Airbnb, Shopify, GitHub 등 많은 회사들이 GraphQL로 어떻게 성공하고 있는가, 그리고 왜 그것이 여러분에게도 필요할까요?](https://tyk.io/using-tyks-new-graphql-functionality-whos-it-for-and-what-does-it-do/)

환상적인 성장동력을 불어 넣고, 개발을 가속화하기 위해 얼마나 많은 회사들이 GraphQL을 이용하는지 알고 싶다구요? 이 글은 테크 산업의 거대 공룡들이 어떻게 GraphQL을 활용하는 지를 요약하고 있습니다. 이것은 여러분이 볼 필요가 있는 다른 회사들이 어떻게 GraphQL의 능력을 사용 중인지 상세하게 보여주고, 여러분의 기술 스택에서 GraphQL을 사용해야 할 필요를 재확인 시켜 줄 것입니다.

## [Tyk의 새로운 GraphQL 기능성: 누구를 위한 것이고, 무엇을 하는가?](https://tyk.io/using-tyks-new-graphql-functionality-whos-it-for-and-what-does-it-do/)

우리는 엄청 많은 새 기능들을 추가했습니다. 온갖 삐까번쩍한 것들과 함께 더 해진 기능 중에는 정말 여러분들이 사용해야 할까 어렵게 고민해야하는 경우도 자주 있었지요. 이 글에서는 우리의 GraphQL 기능들 중에서 관심을 가질 만한 사용자의 유형 별로 서술하여  각 기능을 정확히 밝히기 위해 구체적으로, 그것이 무엇을 하는지 설명합니다.

### 튜토리얼, 더 또 튜토리얼!!

새로운 기능에 친숙해지는 방법은 정확하게 어떻게 사용하는지를 지켜보는 것 만한 게 없죠. 우리는 Tyk GraphQL 에서 제일 좋아하는 기능들을 어떻게 하면 간결하게 강조하는 비디오를 만들지 고민했습니다.

### REST 에서 GraphQL로 쉽게 건너가기

이 튜토리얼에서는 Tyk의 Universal Data Graph (UDG)를 활용하는 첫걸음 중 하나로서; RESTful API를 우리의 GraphQL에 대한 데이터 소스로서 사용하기 입니다. 이 예시에서 우리는 간단한 REST API를 가져다가 그것을 위한 GraphQL 스키마를 생성하고, 그 데이터 소스의 스키마를 앞에서 말한 REST API에 연결시킬 것입니다.
GraphQL 쿼리가 발송될 때, Tyk는 그 질의어를 해석하고, 데이터를 수집하여 데이터와 함께 GraphQL 응답으로 결과값을 돌려 줍니다. 여기서 Tyk가 얼마나 간단하게 GraphQL 엔드포인트를 생성하는지 보여 줍니다.

### [REST를 GraphQL로 쉽게!!](https://tyk.io/tyk-graphql-and-universal-data-graph-round-up-the-story-so-far/?utm_campaign=Newsletters%20Q2&utm_medium=email&_hsmi=133509600&_hsenc=p2ANqtz-9AO8BbJP5HXOjWunWL78IsTfvJ8iQgBbsn01a4y7Aqe5iRfFRkuPx4QT_8J_YxOy8j2Bec06nEcMkfKKg81tr3prD6Ww&utm_content=132880193&utm_source=hs_email)

앞의 위에서 본 예제를 좀 더 정교하게 만들어, Sedky는 여러 개의 RESTful API들을 하나의 GraphQL API로 어떻게 꿰매어 여러 개의 데이터 소스를 이용하는 지 보여 줄 것입니다. 우리는 이것을 '스키마 스티칭 (schema stitching)'라고 하는데, 이것이 Tyk의 UDG 뒷단의 핵심 컴포넌트 입니다.


### [REST를 GraphQL 꿰매기 신공!!](https://tyk.io/tyk-graphql-and-universal-data-graph-round-up-the-story-so-far/?utm_campaign=Newsletters%20Q2&utm_medium=email&_hsmi=133509600&_hsenc=p2ANqtz-9AO8BbJP5HXOjWunWL78IsTfvJ8iQgBbsn01a4y7Aqe5iRfFRkuPx4QT_8J_YxOy8j2Bec06nEcMkfKKg81tr3prD6Ww&utm_content=132880193&utm_source=hs_email)


### [기존 GraphQL 서비스로 프록시 하기](https://tyk.io/tyk-graphql-and-universal-data-graph-round-up-the-story-so-far/?utm_campaign=Newsletters%20Q2&utm_medium=email&_hsmi=133509600&_hsenc=p2ANqtz-9AO8BbJP5HXOjWunWL78IsTfvJ8iQgBbsn01a4y7Aqe5iRfFRkuPx4QT_8J_YxOy8j2Bec06nEcMkfKKg81tr3prD6Ww&utm_content=132880193&utm_source=hs_email)

이미 GraphQL을 사용 중에 있다면, Tyk를 가지고 기존의 GraphQL 엔드포인트들을 안전하게 하는 것이 바로 여러분에게 필요할 것입니다! 이 튜토리얼을 통해 우리는 간략한 몇 단계의 조작으로 기존 GraphQL 서비스로 프록시 하는 방법을 보여 줄 수 있다는 것은 희소식이 아닐 수 없습니다. Tyk 내에서 여러분이 해당 서비스를 연결하고나면, 여러분은 이 글과 다른 문서들에 언급된 GraphQL의 대단한 기능들을 바로 사용할 수 있습니다.

Tyk UDG & GraphQL 창고

# API Eventing Is The Next Big Opportunity For API Providers
## API에게 이벤트 달기



지난 10 년 여 동안 최신 웹 API는 Flickr와 같은 솔루션에서 새로운 비즈니스 모델을 생성하는 강력한 플랫폼으로 성장했습니다. 이 성장 기간 동안 대부분의 API는 HTTP를 통한 요청-응답으로 제한되었습니다. 이제 SaaS 솔루션을 연결하는 Webhook의 인기, 내부 메시징을 구동하는 Kafka와 같은 기술의 도입, IoT 장치 통합의 필요성과 함께 이벤팅으로 다시 돌아가고 있습니다.
API 이벤트는 API 소비자가 API와 상호 작용하는 방식을 완전히 바꿔놓아서 요청-응답이 할 수 없는 새로운 가능성을 만듭니다. API 이벤트 지원을 API에 추가하는 것을 여러 분이 고려하도록 영감을 줄 기회와 함께 API 이벤트 발생에 기여하는 추동 요인 (driving factors)을 살펴 보겠습니다.

##  **왜 여러분의 API가 이벤트를 지원해야 할까요?**


### 이유 1: API 이벤트는 혁신을 주도합니다. 

GitHub 플랫폼에 WebHooks가 도입됨에 따라 소프트웨어 개발이 크게 바뀌었습니다. 팀은 더 이상 빌드 프로세스를 버튼을 클릭하여 명시적으로 시작할 필요가 없습니다. 매일 또는 매시간 빌드를 생성한다는 아이디어는 과거의 일이 되었습니다. 대신 팀은 새 코드가 GitHub에 푸시 될 때마다 빌드 프로세스를 시작할 수 있습니다. Post-commit hooks는 항상 svn 및 git의 일부 였지만, GitHub는 이러한 이벤트 스트림을 전체 웹에 걸쳐 확장했습니다. 클라우드 공급 업체의 API와 결합 된 WebHooks는 팀이 자신이 선택한 어떤 환경에서든지 코드를 구축하고 배포 할 수있게 해주며, 모두 WebHooks에 의해 구동됩니다.  


### **이유 2: API 이벤트는 협업을 가능하게 합니다.**

HipChat 및 Slack과 같은 메시징 플랫폼은 팀원들이 협업하는 방식을 변화 시켰습니다. 이러한 팀 메시징 플랫폼은 bots와  command-line 자동화를 통합 할 기회를 열었습니다. 그 결과 기존의 IRC 및 그룹 채팅을 뛰어 넘는 새로운 커뮤니케이션 방법이 탄생했습니다. 이를 위해, 이러한 플랫폼은 요청-응답 API와 실시간 이벤트 스트리밍의 조합을 제공하여 외부 앱, 봇 및 API를 플랫폼에 원활하게 통합 될 수 있도록 합니다.  


### **이유 3: API 이벤트는 코드 없는 통합을 주도합니다.** 

SaaS (Software-as-a-Service) 제품은 점점 더 통합을위한 API를 제공하고 있습니다. [Zapier](https://zapier.com/)(link) 나 [IFTTT](https://ifttt.com/)와 같은 iPaaS (Integration Platform as a Service) 도구는 복-붙 없이 많은 공통 작업을 자동화하기 위해 서로 연결 할 수 있게 지원합니다. 많은 iPaaS 제품은 사용자를 대신하여 코드마저도 호스팅 해주기 때문에 서버와 인프라를 관리 할 필요가 없습니다.  

이러한 종류의 통합은 항상 코드 작성을 요구하지는 않지만, API에서 제공하는 트리거 유형에 따라 제한됩니다. API가 요청 / 응답 지원만 제공하는 경우에는, 클라이언트는 중요한 데이터에 변경 사항이 있는지 확인하기 위해 폴링을 해야합니다. API 이벤트를 통해, 이러한 도구들은, 데이터가 변경 될 때 트리거 (해당 이벤트)를 수신하고 요구되는 자동화 흐름을 실행할 수 있습니다.  


### **이유 4: API 이벤트는 유연한 아키텍처를 생성합니다.**

점점 더 많은 팀이 전체 솔루션의 일부를 이해하는 데 필요한 인지 부하를 줄여 복잡한 솔루션 주변에 경계를 설정하는 방법으로서 마이크로 서비스 아키텍처를 탐색하고 있습니다. 이 모든 것은 신속하게 기능을 제공 할 수 있는 소규모의 독립적인 팀을 만들어서 제공 속도를 높이는 것을 목표로 수행됩니다. 느슨하게 결합된 마이크로 서비스 아키텍처의 결과로 서비스는 비즈니스 워크플로우를 구동하는 데이터 변경 및 주요 비즈니스 이벤트를 다른 마이크로 서비스에 알리는 이벤트를 내 보냅니다.  

또한 서버리스 세계 안에서 function-as-a-service (FaaS)가 부상하고 있습니다. 전체 애플리케이션을 배포하는 대신 더 작은 기능이 배포 된 다음 메시지 기반 이벤트 또는 요청 / 응답 스타일 호출을 제공하는 API 게이트웨이를 통해 트리거 됩니다.  

Kafka, RabbitMQ 또는 Amazon SNS / SQS와 같은 메시징 브로커는 종종 마이크로 서비스 이벤트를 유도하고 함수 기반 서비스 (function based service)를 트리거하는 데 사용됩니다. 이는 내부 메시징에 대한 유효한 솔루션이지만 외부화를 위해 설계되지 않았습니다. 이벤트를 외부화하는 경우 소비자가 WebHook, event streaming,  또는 어쩌면 일부 상황에서는 덜 효율적인 long-polling의 조합을 사용하여 이벤트를 소비하는 방법을 고려해야 합니다.  


### **이유 5: 이벤트는 사물인터넷과 엣지 컴퓨팅을 위한 접착제 입니다.**

집이나 사무실 주변에 스마트 기기가 있을 것입니다. 이러한 장치는 웹 또는 모바일 장치의 중요한 데이터 및 이벤트를 시각화하기 위해 종종 클라우드 서비스와 통신합니다. 공급 업체가 제공하는 클라우드 기반 API를 통해 IoT 서비스와 통합하면 타사 자동화 솔루션이 이러한 장치의 유용성을 확장 할 수 있으므로 이벤트 스트리밍의 이점을 얻을 수 있습니다.  

일부 장치 통합 시나리오의 경우 클라우드 리소스에 대한 네트워크 연결이 보장되지 않거나 생성 된 데이터의 양이 클라우드로 전송되기 전에 평가 및 집계가 필요할 수 있습니다. 이를 '에지 컴퓨팅'이라고 하며, 특히 고대역폭을 항상 사용할 수 있지는 않은 제조 및 에너지 산업에서 수년 동안 일반적이었습니다.  

이제 엣지 컴퓨팅이 차세대 IoT 장치의 일부로 등장 할 것이라는 신호가 있습니다. 에지 장치가 서로 통합되고 로컬 네트워크의 스마트 컨트롤러 장치와 통합하려면 이벤트 스트리밍이 필요합니다. IoT 용 API를 구축하는 경우 이벤트 스트리밍은 에지 커뮤니케이션 및 컴퓨테이션에 필수적 입니다. 
 

## **여러분의  API 가 이벤트 구독(Event Subscriptions)을 제공해야 할까요?**

API 이벤트는 일상적인 문제를 해결하기 위해 API를 사용할 때 API에 필요한 대화의 종류를 확장합니다. 우리는 팀이 API 이벤트를 추가하여 API 대화를 강화할 수 있는 방법을 고려하도록 권장합니다. 이벤트 지원이 없으면 API는 단순히 사용자가 요청 하기만을 기다리게 됩니다. 이벤트 지원이 추가됨으로써, 비로소 API는 다른 API 및 애플리케이션과 양방향 대화를 할 수 있습니다. 이를 통해 더 나은 사용자 경험을 제공하고 API 채택을 크게 확대하게 되어 소비자의 이탈을 줄입니다.  

 API에 이벤트 달기   

# Tyk 3.2 - 차세대 엔터프라이즈 FLAPIM (Full Life cycle API Management)

##**복잡한 엔터프라이즈 APIM 보안, 간편하게 처리하기**

어떤 API first 제품 비즈니스에서든지 보안은 제일 중요한 고려사항 중 하나이거나, 제일 중요한 바로 그것 입니다. 이것은 Tyk와 같은 현대의 API  기술 스택이 API 관리 플랫폼들의 심장부에 자리하고 있다는 것이 주된 이유이며, 그것이 플랫폼의 필수적인 부품이 되기 때문입니다. 플랫폼들은 강력한 보안 역량을, 내부의 API를 만드는 쪽과 외부의 API 사용자 양쪽 모두에게, 간편하고 비용효과적인 형식으로 제공합니다.

당연히, 엔터프라이즈 수준의 보안은 언제나 Tyk의 핵심 역량이었습니다만, 우리는 지금 3.2 버전 릴리스에 탑재된 더 높은 수준의 보안 역량에 대해 말하고 있는 것입니다.  완전히 판을 뒤바꿔 놓을 새로운 기능들을 여러분들이 잘 알고, 그것들이 어떻게 여러분들의 사업에  이익을 가져다 줄 지 한시 빨리 알려 드리고 싶습니다. 이것과 함께 우리는 차세대 [GraphQL 엔진](https://tyk.io/docs/graphql/)을 탑재하여 여러분들의 [Universal Data Graph (UDG)](https://tyk.io/docs/universal-data-graph/udg-concepts/)에 보안과 사용성에 터보 파워를 더하였습니다!

Tyk 3.2는 [DCR (Dynamic Client Registration)](https://tyk.io/docs/tyk-stack/tyk-developer-portal/dynamic-client-registration/)과 [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) 기능들을 구현하여 Tyk의 대시보드와 개발자 포털의 호환성을 초특급으로 향상시켰기 때문에, 어떤 종류의 인증 (authorisation) 이든지 상관없이, 스트럭처나 프로세스를 구성하는 등의 모든 업무가 믿기지 않을 만큼 간단하게 형상관리을 관리하고 상태를 유지할 수 있도록 하나의 통합된 방법으로 제공됩니다. 

전체 기술을 알고 싶다면, [릴리스 노트](https://tyk.io/docs/release-notes/version-3.2/)로 바로 다이빙 하시면 되지만, 우리의 흥미진진한 새로운 기능들을 여유롭게 둘러볼 시간이 된다면 우리가 여러분의 디스커버리로 데리고 갈 수 있게 맡겨 주세요~^^

##**Dynamic Client Registration으로 자신의 IDP (Identity Provider)를 사용하기**

IDP들은 현대 APIM 스택에서 빠져서는 안될 부분이며 점점 더 많은 엔터프라이즈들이 그들의 전 자산에 걸쳐  IDP를 필수적으로 채택하고 있습니다. 이것은 3자 개발자들과 파트너들을 위한 온보딩 절차를 간소화 할 뿐 아니라, 조직의 전체적인 애플리케이션 포트폴리오에 걸쳐 하나의 통합된 보안체계를 만들 수 있게 하였습니다. 

여러분의 조직이 Keycloak를 사용하든, Gluu 또는 Okta를 외부 IDP로 사용하든 상관없이; Tyk 3.2가 제공하는 [Dynamic Client Registration](https://tyk.io/docs/tyk-stack/tyk-developer-portal/dynamic-client-registration/) 기능을 가지고, 여러분은 단지 몇 단계의 절차 만으로 그것들을 Tyk의 개발자 포털에 통합시킬 수 있습니다. 아랫단의 인증 매커니즘에 시달리거나 고민할 필요가 전혀 없습니다.

DCR은 IETF가 인증 서버를 가지고 클라이언트의 동적 등록을 하기 위한 표준을 정하기 위해 공표한 프로토콜의 일종 입니다. Tyk 개발자 포털을 통하여 앱을 생성할 때, Tyk 3.2는 해당 클라이언트를 여러분의 인증 서버에 동적으로 등록할 것입니다. 그렇게함으로써 인증 서버가 해당 서버에 대하여 클라이언트 ID와 클라이언트 시크릿을 발급하는 것입니다.


##**Open Policy Agent로 직접 커스터마이징**

API 거버넌스는 현대 엔터프라이즈의 전생명주기 API 관리 (FLAPIM, Full Life cycle APIM) 스택에 빠져서는 안되는 부분입니다. 거버넌스의 핵심 기능은 접근제어 입니다. 이것을 통하여, 스택 내에서 '맞는 행위'는 더 쉽게, '잘못 행위' 는 더 어렵게 이행되도록 보장해 주는 것입니다. 전형적인 엔터프라이즈들은 DevOps에서 API 엔지니어링과 API 관리자들, 그리고 시스템 통합자들에 이르기 까지 복수의 팀들을 가지고 있고, 이 모든 참여자들이 하나의 스택 내에서 서로 다른 관심사를 처리합니다. 다른 API들에 대한 보안 강화와 접근 제한을, 사용자들의 역할에 기반하여, 우리는 [Open Policy Agent (OPA)](https://tyk.io/docs/tyk-dashboard/open-policy-agent/)를 가지고 Tyk의 대시보드를 형상관리 하는 기능을 도입하고 있습니다. 

OPA를 가지고 사용자 정의 퍼미션을 안전하게, 효과적으로 생성할 수 있습니다. OPA의   policy 엔진은 대시보드의 정면에 위치하며, 여러분이 하이레벨 언어 ([Rego](https://blog.openpolicyagent.org/opas-full-stack-policy-language-caeaadb1e077))로 정책을 코드와 간단한 API들로 명시할 수 있게 함으로써 여러분의 소프트웨어에 대한 정책 의사결정의 짐을 덜어 줍니다.


##**GraphQL과 UDG의 기능 향상**

[Universal Data Graph (UDG)](https://tyk.io/docs/universal-data-graph/)의 GraphQL 기능서을 업데이트 하기 위해 우리는 부단한 노력을 해 오고 있습니다.  UDG는 어떤 업스트림 서비스라도, 그것이 보안된 것이든 오픈된 것이든 상관없이, 단순한 GUI를 통해 함께 꿰맬 수 있게 합니다. 이것은 여러분들의 모든 REST 자산을 하나의 데이터 그래프로 여러분이 전환 시킬 수 있다는 것을 의미합니다. 이 강력한 새 해법은 심지어 단순한 GUI 조작으로 완성됩니다. 

이제 여러분은 깊은 단계로 중첩된 GraphQL과 REST API들을 어떤 가능한 방법으로든 함께 꿰맬 수 있습니다.  웹소켓과 서브스크립션을 가능하게 해 주는 쿼리들은 Tyk의 다음 릴리스에서 제공될 것입니다.

업스트림 헤더를 동적으로 설정하는 것도 가능한데, 클라이언트 요청으로부터 UDG업스트림에 주입하면 됩니다. 이 기능은 다른 것들 사이에서 보호된 업스트림에 접근하는데 사용할 수 있습니다.

끝으로, 우리는 사용하기 쉬운 URL 빌더도 추가하였습니다. 이것은 여러분이 UDG 내에서 REST API들을 꿰맬 때, 오브젝트 필드들을 REST API URL들로 주입하는 것을 한결 쉽게 만들어 줍니다. 각 필드 레벨에 대한 쿼리의 깊이를 제한하는 것도 할 수 있습니다.

여러분이 UDG로 GraphQL 업스트림 서비스를 사용하고 있다면, 이제는 UDG를 통하여 업스트림 에러 오브젝트들을 전달하는 것이 가능하게 됨으로써 그것들을 클라이언트에 노출시킬 수 있습니다.


##**당장 개이득!!**

Tyk 3.2 버전의 강력한 파워를 장착할 준비가 되셨나요?
여기, 우리의 웹사이트로 가셔서 [프리 트라이얼 버전을 다운로드](https://tyk.io/get-started/) 받으세요.


**[## 관련 웨비나 등록 (6/17)](https://www.brighttalk.com/webcast/18833/490122?utm_source=Tyk&utm_medium=brighttalk&utm_campaign=490122)**



Tyk 3.2가 공개 되었습니다!

large_Banner_benchmark.png

medium_Banner_benchmark.png

small_Banner_benchmark.png

thumbnail_Banner_benchmark.png

Banner_benchmark.png

# 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에서 성능 테스트를 안내하는 [단계별 가이드](https://tyk.io/a-manual-for-simple-performance-testing-with-tyk-on-aws/)를 제공합니다.

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

맨 앞단에서의 벤치마크 결과 - 5분 동안 초당 75,000 요청 처리 (75,000 RPS)
![Picture1.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture1_007d9e5594/Picture1_007d9e5594.png)


투명 프록시로서의 벤치마크 결과 - 5분 동안 초당 75,000 요청 처리 (75,000 RPS)
![Picture2.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture2_24809a2221/Picture2_24809a2221.png)


Full-load APIM (트래픽 조정, API 인가/인증, 대시보드 분석정보 포함)
5분 동안 초당 75,000 요청 처리 (75,000 RPS)
![Picture3.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture3_d9e73a07c8/Picture3_d9e73a07c8.png)


게이트웨이 없이 투명 프록시로서 여러 가지 기능들을 활성화하고 테스트 한 뒤 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에서 어떻게 구동되는지, 세계 곳곳으로 연결된 엔터프라이즈의 인프라가 어떻게 확장되고 관리될 수 있는지 보여 드리고 싶습니다. 또한, 타이크가 어떻게 벤더에 종속적으로 되는 것을 방지하는지 보여 드리고, 이종 클라우드에서 여러 개의 클러스터를 수용하는 기능을 각각의 플랫폼에서 타이크 게이트웨이 서비스를 통하여 보여 드릴 것입니다. 

여러분이 이런 벤치마킹에 관심이 있다면, [저희에게 메모](http://argopacific.io)를 남겨 주십시오.

![Picture2.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture2_24809a2221/Picture2_24809a2221.png)
![Picture3.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture3_d9e73a07c8/Picture3_d9e73a07c8.png)
![Picture1.png](https://storage.googleapis.com/argo-cms-strapi-upload/Picture1_007d9e5594/Picture1_007d9e5594.png)


Leading Tyk Partner in South Korea

Tyk Pricing

Tyk Launch

Tyk Flex

Tyk Multi-Team

Tyk Global Multi-Team

Latest Posts

API Gateway의 유용성 - Rate limiting

Tyk UDG & GraphQL 창고

API에 이벤트 달기

Tyk 3.2가 공개 되었습니다!

왜 Tyk (타이크) 인가