# API의 공통과제 3개와 해결법 
 
 [by James Higginbotham](https://tyk.io/how-api-governance-addresses-3-common-api-problems/?utm_campaign=Newsletter%20Q4&utm_medium=email&_hsmi=156562812&_hsenc=p2ANqtz-9plyyfFbIsSZCDyCDxM6k6a6p0_e48FVoeVOUzEJ4IwdLDYVdkMc3x40-_hvCVSUY0xXzQ_nQl-5ndCsB-eArKy5CxWw&utm_content=154773899&utm_source=hs_email)

**API 거버넌스**라는 용어는 종종 딜리버리 절차를 느리게 만드는 무거운 프로세스와 함께 두려운 느낌을 가져옵니다. 그러나 반드시 그럴 필요는 없습니다. API 거버넌스는 API 프로그램의 현재 및 미래 문제를 방지하는 데 사용되는 도구입니다. 가벼운 거버넌스와 효과적인 API 관리 플랫폼을 통해 **API 불안정성, 열악한 확장성 및 보안 취약성**을 해결하는 방법을 보여주는 세 가지 시나리오를 살펴보겠습니다. 
 

## 경량 거버넌스로 API 불안정성 극복하기 

API가 릴리스 간에 안정적으로 유지되도록 하는 것이 중요합니다. 고객은 API 설계 수정으로 인해 강제로 코드를 변경하는 것을 원하지 않습니다. 설상가상으로, 그들은 자신의 코드가 실패했다는 경고를 듣고 싶어하지 않고 최신 API 릴리스에서 *연동 실패 (breaking-changes)*를 초래한 것이 여러분의 잘못이라는 것을 찾아내려 한다는 것입니다. 

이것은 한 API 제공자의 경우였습니다. 그들은 지속적으로 *연동 실패 (breaking-changes)*를 유발함으로써 고객이 이러한 일이 발생할 때마다 코드를 업데이트하도록 했습니다. 문제가 지속되면서, 그들이 더 안정적인 옵션을 찾는 동안 고객이 좌절감을 느끼며 이탈하는 것을 보아야 했습니다. 

이 문제를 해결하기 위해 경량 거버넌스 프로세스를 도입했습니다. 이 프로세스는 API 설계 변경 사항에 대한 자동화 및 수동 검토를 수행하여 새로운 릴리스마다 불안정성을 유발하는 것들을 방지하도록 간단한 단계를 정의했습니다. 

또한, 출시하기 전에, 프로덕션에 API 변경 사항을 미리 볼 수 있도록 하는 API 안정성 계약의 개념을 도입하였습니다. 이에 대한 자세한 내용은 여기, [연동 실패를 줄이기 위한 꿀팁](https://tyk.io/tyk-tips-limit-breaking-changes/)에서 확인할 수 있습니다.

이러한 단계는 일관된 API 디자인을 장려하는 스타일 가이드와 결합되어 릴리스 프로세스를 개선하고 시간이 지남에 따라 고객 이탈을 줄이는 데 도움이 되었습니다. 초기 선택의 여파가 여전히 남아있기는 하지만, 그들은 이제 회복 중에 있습니다. 
 
## 확장성 문제 해결하기 

API의 설계 과정의 일부에는 확장에 대한 계획이 포함됩니다. 모든 API가 매우 높은 초당 요청 (RPS)을 처리해야 하는 것은 아니지만, 예상되는 RPS와 최대 RPS를 아는 것은 아주 중요합니다. 

API가 거의 사용되지 않거나 피크 시간에만 사용되는 경우라면 이를 고려하여 클라우드 지출을 줄이기 위해 인프라를 프로비저닝할 수 있습니다. API가 대규모의 부하를 처리해야 하게 될 경우를 대비해 적절한 코드 최적화 및 인프라 구축을 위한 예산을 미리 알아야 합니다. 

대형 금융 기관이 이 문제에 직면했습니다. 그들은 단일 API에서 모두 오케스트레이션되는 여러 개의 마이크로서비스를 만들었습니다. 완료되고서, 각 마이크로 서비스에 요청당 2~5초가 필요하다는 것을 깨달았습니다. 더 깊이 파고들자, 그들은 각 마이크로서비스가 순차로 호출되면서 API 요청당 응답 시간이 10-25초라는 것을 알게 되었고 특히, 금융 기관의 요구에 맞추어 정확하게 확장할 수 없었습니다. 

API 게이트웨이 구성에 통합된 몇 가지 기본 SLA metrics를 구현함으로써 API 성능 저하에 대해 경고를 받을 수 있었습니다. 또한 각 프로덕션 릴리스 전에 요구 사항으로 성능 테스트를 통합했는데, 이것으로써 릴리스 전에 모든 API가 벤치마크되고 평가되는 것을 보장할 수 있게 되었습니다.
 
## 보안 취약점 해결

API 거버넌스는 일반적으로 API 스타일 가이드 및 디자인 검토 프로세스를 통해 보다 일관된 API 디자인을 만드는 것과 관련이 있습니다. 또한 적절한 보안 위험 평가를 보장하기 위해 사용되지만, 해당 디자인 검토 프로세스가 효과적으로 구현되는 경우에만 사용됩니다. 

이에 대한 한 사례로, 보안 검토를 회피하려는 소수의 변절자 팀들이 있었던 어떤 대기업을 들 수 있겠는데; 그 결과 감사 중에 식별된 많은 보안되지 않은 API를 찾아냈습니다. 고맙게도 API는 민감한 데이터를 유포하지는 않았습니다. 그러나 팀은 적절한 보안 실무지침을 준수하기 위해 상당한 변경을 해야 했습니다. 

그들은 확장된 API 거버넌스 프로세스의 일부로 향후 이를 방지하기 위한 몇 가지 조치를 구현하기로 결정했습니다. 여기에는 프로덕션 승인 전에 보안 팀 중 하나에 의한 승인이 포함되었습니다. 또한 승인되지 않은 외부 대면 배포를 감지하기 위해 자동화된 검사가 구현되었습니다. 마지막으로, API 게이트웨이를 통한 적절한 구성 및 시행을 보장하기 위해 API 설계 검토 프로세스의 일부로 RBAC(역할 기반 접근 제어)가 추가되었습니다. 
 
## 효과적인 API 거버넌스

API 거버넌스가 어려운 솔루션일 필요는 없습니다. 대신, 일관성을 만들고 API 문제를 방지하는 데 사용할 수 있는 도구로 간주되어야 합니다. 효과적인 API 거버넌스는 일관된 디자인 타임 및 런타임 API 관심사를 독려하기 위해 만들어진 많은 선택들을 반영하여야 합니다. 자동화 및 셀프 서비스 기능과 결합된 API 거버넌스 프로그램은 조직이 일관된 방식으로 올바른 API를 설계하고 제공하는 데 도움이 될 수 있습니다.

API의 공통과제: 안정성 / 확장성 / 보안, 그 해결책

large_Platform delusion.png

medium_Platform delusion.png

small_Platform delusion.png

thumbnail_Platform delusion.png

Platform delusion.png

# 플랫폼에 대한 망상   

최근에 간행된 *The Platform Delusion*이라는 책은 테크 회사들의 성공을 이끄는 요인을 검증합니다. 저자 Jonathan Knee는 Netflix의 사례를 사용하여 "플라이휠 효과"가 흔히 생각하는 것보다 덜 강력하다고 주장합니다. Knee는 Columbia Business School의 전문 실습 교수이자 Evercore의 선임 고문입니다.   
   
## 과장된 네트워크 효과  - by Jonathan A. Knee   
   
   
최근 테크 회사의 주식 가치가 폭발적으로 치솟으면서 최고의 기업을 특징짓는 자질이 무엇인지에 대한 위험한 믿음이 확고해졌습니다. 이러한 믿음은 소수의, 소위 플랫폼 회사가 전체 주식시장의 총체적 가치에서 큰 부분을 차지하게 되면서 지난 10년 동안 인기를 얻었습니다. 낡은 형태의 경쟁 우위 대신, 새로운 수퍼파워를 이러한 플랫폼 비즈니스의 결과라고 말하면서 종종 달리 설명할 수 없는 평가 지표를 정당화합니다.  
    
플랫폼의 공통점은 혁신을 장려하거나, 거래를 촉진하거나, 또는 관계를 심화함으로써 플랫폼이 가능하게 하는 연결에 대해 기본 가치 제안 (basic value proposition)을 한다는 것입니다. 그들이 상상한 무적의 능력 (invincibility)은 막을 수 없는 네트워크 효과와 미래형 인공 지능의 조합에서 파생되는 것입니다. 이 발상은, 인터넷이 이러한 네트워크의 범위를 확장했으며 생성되는 엄청난 양의 데이터가 기존 인공지능 알고리즘에 새 생명을 불어넣었다는 것입니다.   
   
**플라이휠 효과**라고도 하는 이 네트워크 효과는 모든 신규 사용자가 기존 사용자에게 네트워크 가치를 증가시킬 때 발생합니다. 디지털 환경에서는 신규 사용자가 무한히 더 많은 신규 사용자를 유치할 뿐만 아니라, 인공지능에 의해 촉진되는 지속적인 개선들이 성공적인 경쟁적 공격의 전망을 더욱 멀어지게 하므로 멈출 수없이 난공불락의 승자 독식 시장이 지배하는 세계로 끌고 간다고 주장하는 것입니다.   
   
이 내러티브의 문제점은 새로운 디지털 플랫폼이, 실제로 그것이 기업을 파괴한 아날로그 모델과 비교해보면, 경쟁적 공격에 대하여 비즈니스를 더 취약하게 만드는 수많은 방법을 무시한다는 것입니다. 고객이 쉽게 전환할 수 있기 때문에 종속성을 약화시키고 이러한 비즈니스의 자산 경량화 특성은 진입 장벽과 손익분기점에 도달하기 위한 활동 수준을 낮춥니다.  
  
예를 들어 온라인과 오프라인 소매 쇼핑몰을 비교해 봅시다. 전통적인 쇼핑몰에는 두 가지 주요 비즈니스 이점이 있습니다. 공급업체는 장기 임대에 전념했고 구매자는 차선책을 고려할만한 여지가 거의 없었습니다. 대조적으로, 인터넷에서는 구매자를 위한 대안이 단 한 번의 클릭으로 제공되며 판매자는 경쟁 플랫폼에서 자신의 상품을 제공합니다. 요점은, 귀사가 COVID-19 기간 동안에 아마존 했던 것보다 더 쇼핑몰 운영자에게 투자할 것이라는 게 아니라, 단순히 오프라인 비즈니스 모델이 놀라운 상대적 회복력을 가지고 있다는 것입니다. 세상의 여러 트렌드에도 불구하고, COVID-19 위기가 닥치기 직전까지, 어려움을 겪고 있던 온라인 소매업체는 점점 더 몰 아울렛을 열어 구조적 문제를 해결하려고 했습니다.  
   
페이스북, 아마존, 애플, 넷플릭스, 구글과 같이 이 분야를 정의하기 위해 온 회사들 사이에서도 오직 페이스북의 프랜차이즈만이 주로 네트워크 효과를 기반으로 구축되었습니다. 그럼에도, 이러한 모든 회사는 플랫폼에 대한 전통적인 믿음으로 추진하는 홍보 및 투자자 관계 가치를 높이 평가하는 것 같습니다. 하원의 조사관에 의해 드러난 내부 이메일 서신에 따르면, CEO가 취약성의 정도와 과장된 진실의 가치를 모두 이해하고 있는 것으로 나타났습니다. 다양한 경쟁 위협을 설명해야 하는 어려움에 직면한 Facebook의 기업 재무 및 사업 계획 담당 부사장은 다음과 같은 솔루션을 제안했습니다:   
> "우리는 더 간단한 '플랫폼' 스토리가 필요합니다."   
   
넷플릭스의 경우는 과대포장된 가치를 정당화하기 위해 네트워크 효과와 인공지능의 역할을 과장하는 경향에 대해 뚜렷한 사례를 제공합니다. 넷플릭스가 DVD 렌탈을 대신하는 온라인 구독을 판매할 때, 그들의 경쟁 우위는 대부분의 강력한 프랜차이즈가 역사적으로 의존해 온 동일한 두 가지 주요 출처인 규모와 고객확보에서 비롯되었습니다. 규모의 이점은 마케팅의 고정 비용을 분산하고, 그들의 보다 넓은 사용자층에 기반하여 전국 유통 인프라를 유지하는 데서 얻을 수 있었습니다. 중독성 있는 서비스와 강력한 추천 엔진으로써 고객을 확보할 수 있었습니다.   
  
2008년부터 모델이 스트리밍으로 전환되었을 때에도, 물리적 배포의 고정 비용이 이제 디지털 저장 및 배포의 고정 비용으로 대체되었지만 이점의 원천은 동일하게 유지되었습니다. 그러나 일반적인 통념은 Netflix 스트리밍 모델이 인공지능과 네트워크 효과를 통해 가능해지는 다양한 초자연적인 힘을 최초로 보여주었다는 것입니다. 도이치 뱅크의 분석가인 Bryan Kraft는 2019년 연구 보고서에서, 그 결과 Netflix에게 더 강력한 진입 장벽을 의미하고 더 높은 가치 평가를 지원하는 신비로운 "플랫폼 지위"를 부여했다고 썼습니다. 그러한 진정한 신봉자는, 예를 들어 사실이기도 한, 스트리밍 모델을 통해 Netflix가 이미 우수한 추천 엔진을 개선할 수 있을 뿐만 아니라 실제로 Netflix에 알고리즘 방식으로 조회수를 선택하는 마법의 능력을 부여할 수 있다고 생각하지만, 이 부분은 사실이 아닙니다.  
   
이 특별한 헛소문은 Netflix의 첫 번째 대히트작인 "House of Cards"가 초래된 뒷이야기에서 출발됩니다. Times 칼럼니스트 David Carr가 설명했듯이, Netflix는 빅 데이터와 인공지능이 제공하는 구조적 이점 덕분에 파일럿 없이도 시리즈의 두 시즌 (총 26개의 에피소드에 1억 달러로 알려진)에 대해 다른 모든 제공자들보다 신중하게 입찰할 수 있었습니다.   
이 이야기에서, 경쟁자들은 "House of Cards"를 확실한 히트작으로 만든 세 가지 핵심 데이터, 즉 David Fincher가 감독한 유명한 영화라는 점, Kevin Spacey가 출연한 영화라는 점, 그리고 BBC 원작의 "House of Cards" 시리즈가 있다는 점에 대해 잘 알지 못했습니다. 넷플릭스 시청자와 함께. Carr는 "이 세 가지 관심 분야를 통해 Netflix는 시리즈를 구입하는 것이 매우 좋은 선택이 될 것이라고 제안하는 벤 다이어그램 교차점을 찾을 수 있었습니다."라고 썼습니다.  

성공적인 창작 프로젝트 선정에 대한 이러한 사후 설명은 잘못된 예측 가능성을 시사합니다. 커다란 소음 뒤의 멍한 침묵 속에서 실패를 따라가듯이 그들은 불가피하게 열광을 따라갑니다. "House of Cards"의 승리 직후 Netflix는 훨씬 더 비싼 시리즈인 "Marco Polo"에 전념했습니다. 원래 구매자인 Starz는 중국에서의 엄청난 비용과 복잡한 촬영 문제로 인해 10부작 시즌의 첫 두 시즌에 1억 8000만 달러의 예산을 책정했습니다. 쇼가 취소되었을 때 알고리즘 결함에 대한 제안은 제공되지 않았습니다.  
  
오리지널 콘텐츠 지출 증가는 그 이후로 Netflix 비즈니스 모델에서 가장 중요한 변화였으며, 이는 더 나은 비즈니스가 아니라 Netflix가 라이선스 콘텐츠에 의존한 Disney, WarnerMedia, ViacomCBS, 그리고 NBCUniversal과 같은 회사와의 경쟁 심화를 반영합니다. 넷플릭스의 CEO Reed Hastings는 최초 "House of Cards"의 투자 시기 쯤에 Fast Company와의 인터뷰에서   
> “대본을 읽고 누가 캐스팅하기에 좋은지 추측하는 것은 테크 회사가 수행하는 근본적인 업무가 아닙니다. …. 우리는 차별화된 조직 역량을 구축할 수 있을 것입니다.” 그의 결론은 이보다 더 명확할 수 없습니다: "우리는 다른 사람들이 창의적인 위험을 감수하도록 손을 떼는 것이 더 낫다고 생각합니다."  
  
넷플릭스가 콘텐츠 투자에 나선 영화, Kraken은 새롭게 발견된 경쟁우위가 아니라 경쟁의 필요성을 반영하는 것입니다. 물론, 진입장벽이 올라갔는지 내려갔는지 확인하는 가장 쉬운 방법은 그 이후 얼마나 많은 진입이 발생했는지 보는 것입니다. 월스트리트 저널이 분석한 데이터에 따르면,  2019년 초와 2020년 말 사이의 짧은 기간만에 넷플릭스는 주문형 비디오 서비스에 대한 미국 구독의 거의 절반에서 4분의 1로 줄었습니다.  
   
거의 20년 동안 Netflix는 핵심 비즈니스 모델에 네트워크 효과를 통합하기 위해 반복적으로 시도했습니다. 하지만 지속적으로 실패했고 결국 포기했습니다.  
  
우편으로 DVD를 빌리던 시대까지 거슬러 올라가면, 넷플릭스는 2004년에 넷플릭스 프렌즈를 설립해 나름의 소셜 네트워킹 방식을 만들려고 했습니다. 큰 호응을 얻지는 못했지만, 2010년까지 서비스를 유지하다가 서비스를 종료했습니다. Mark Zuckerberg가 개인적으로 디자인한 것 중 하나인 Facebook에서 처럼, 많은 후속 프로그램들이 있었지만 사용자 관심 부족으로 중단되었습니다. Netflix는 2018년에 사용자 리뷰를 아예 없애기까지 했습니다. Hastings는 궁극적으로 나에게 네트워크 효과에 대한 그의 헛된 탐구를 "경쟁적 환상"이라고 묘사했습니다.  
   
Netflix는 2012년 오리지널 콘텐츠에 투자하기 시작한 이래로 총 100억 달러의 마이너스 현금 흐름을 누적한 후, 올해 현금 흐름 기준으로 겨우 손익분기점을 넘을 것으로 예상됩니다. 많은 분석가들은 규모의 확장에 따라 점점 더 많이 교체되고 있는 케이블 채널과 동일한 이윤 차이를  달성할 것이라는 믿음을 근거로 스트리밍 서비스에 대한 평가를 정당화합니다.   
  
그것에 베팅하지 마십시오. 케이블 채널 고객은 주로 유통사업체로서, 경쟁을 제한하는 용량 제약이 있는 환경하에서 장기계약을 제공합니다. 스트리밍 서비스 고객은 끊임없이 이탈하며, 그것에 대한 비용지불과 같은 진입 장벽이 거의 없습니다. 그리고 최소 6명의 돈이 많은 경쟁자들이 구독자를 유도할 수 있는 콘텐츠와 재능을 놓고 서로 경쟁하고 있기 때문에, 나는 차라리  Shonda Rhimes 같은 PD가 되거나 증명된 지적 재산의 소유자가 되는 길을 택하겠습니다.  
  
플랫폼 시대의 다양한 신화를 믿는 것의 진정한 위험은 시장에 만연한 행복감이 가라앉을 때 일어날 수 있는 일이며, 필연적으로 그러하듯이 기술 투자들 사이에 정보에 입각한 구별을 만드는 것이 재정적 생존을 위해 필수적입니다. 투자이든, 운영 또는 규제이든 상관없이, 의사 결정을 안내하기 위해 단순한 망상에 의존하기보다는 개별적인 이점의 진정한 원천과 범위를 정확히 찾아내는 것이 중요합니다.  




Netflix로부터 배우는 것

# 서킷 브레이커  (회로 차단기)  
  
## 개요  
  
Tyk에는 경로 기반 옵션으로 회로 차단기 패턴이 내장되어 있습니다. 회로 차단기는 비율 기반이므로, '샘플 크기x의 y% 만큼'이 실패하면 차단기가 트립됩니다. 게이트웨이는 사전 정의된 기간(복구 기간) 동안 해당 서비스에 대한 모든 인바운드 요청을 중지합니다. API 정의에서 *return_to_service_after* 옵션을 사용하거나 대시보드를 통해 설정하여 이 기간을 구성합니다. 회로 차단기에는 문제가 해결되었는지 확인할 수 있는 반개방 상태도 있습니다. 이는 *return_to_service_after*에 구성된 시간이 발생하기 전에 업스트림에 실제 요청을 함으로써 수행됩니다. 기본적으로 Tyk 회로 차단기는 반개방 상태를 활성화했습니다. 원하는 동작이 *return_to_service_after*에 구성된 시간이 소비된 후에만 확인하는 것이라면 *disable_half_open_state*를 true로 설정하여 이를 비활성화할 수 있습니다. 이것은 또한 수정 또는 로깅 작업을 수행하기 위해 연결할 수 있는 이벤트를 트리거합니다. 회로 차단기가 트립되면 503 "서비스를 일시적으로 사용할 수 없음 (Service temporarily unavailable)" 오류가 반환됩니다.  

회로 차단기는 호스트 전체에서 작동합니다(즉, 하나의  API에 대한 타겟이 여러 개인 경우 샘플은 모든 업스트림 요청에 있음)  

회로 차단기는 단일 호스트에서 개별적이며, 백엔드 데이터를 중앙 집중화하거나 풀링하지 않습니다. 이것은 속도를 위한 것입니다. 이는 여러 Tyk 노드가 사용되는 로드 밸런싱된 환경에서 다른 노드가 샘플링 속도 제한에 도달하게되면서 일부 트래픽이 누출될 수 있다는 것을  의미합니다.  

## 이벤트 

회로 차단기가 트립되면 *event_handlers* 섹션에서 작업을 정의할 수 있는 *BreakerTriggered* 이벤트가 발생합니다 (자세한 내용은 이벤트 데이터 및 이벤트 유형 참조):     

```json
event_handlers: {  
  events: {  
    BreakerTriggered: [  
      {  
        handler_name: "eh_web_hook_handler",  
        handler_meta: {  
          method: "POST",  
          target_path: "http://posttestserver.com/post.php?dir=tyk-breaker",  
          template_path: "templates/breaker_webhook.json",  
          header_map: {  
            "X-Tyk-Test-Header": "Tyk v1.BANANA"  
          },  
          event_timeout: 10  
        }  
      }  
    ]  
   }  
 }
```
  
템플릿에 반환된 상태 코드는 다음과 같습니다:    
  
*// BreakerTripped is sent when a breaker trips    
BreakerTripped = 0  
  
// BreakerReset is sent when a breaker resets   
BreakerReset = 1*   
  
**서비스 검색 모듈 (Service Discovery)을 사용하는 경우에는 차단기가 작동할 때마다 Tyk는 노드 목록을 새로 고치려고 시도한다는 점을 기억하십시오.**   

## API 정의로 구성하기  
    
API 정의에서 회로 차단기를 활성화하려면 버전의 *extended_paths* 목록에 새 섹션을 추가해야 합니다:    

```json
"circuit_breakers": [  
  {  
    "path": "get",  
    "method": "GET",  
    "threshold_percent": 0.5,  
    "samples": 5,  
    "return_to_service_after": 60  
  }  
]
```

- **‘path’**: 일치시킬 경로  
- **‘method’**: 일치시킬 메서드  
- **‘threshold_percent’**: 차단기가 트립되기 전에 오류가 발생할 수 있는 요청의 비율입니다. 0.0에서 1.0 사이의 값이어야 합니다.  
- **‘samples’**: 회로 차단기 창에 대해 취할 샘플 수입니다.  
- **‘return_to_service_after’**: 서비스로 복귀하기 위한 차단기의 냉각 기간(초)입니다.  
   
    
## 대시보드로 구성하기  
  
API 경로에 회로 차단기를 설정하려면 API의 엔드포인트 디자이너 섹션에 새 엔드포인트를 추가한 다음 회로 차단기 플러그인을 선택합니다.  

  ![endpoint designer.png](https://storage.googleapis.com/argo-cms-strapi-upload/endpoint_designer_543917fdba/endpoint_designer_543917fdba.png)  
 
플러그인이 활성화되면 메뉴에서 차단기를 클릭하여 다양한 구성 옵션을 설정할 수 있습니다.  

![plugin config.png](https://storage.googleapis.com/argo-cms-strapi-upload/plugin_config_c2643da522/plugin_config_c2643da522.png)

- **Trigger threshold percentage (트리거 임계값 백분율)**: 차단기가 트립되기 전에 오류가 발생할 수 있는 요청의 백분율로서, 0.0에서 1.0 사이의 값이어야 합니다.  
- **Sample size (requests) (샘플 크기 - 요청)**: 회로 차단기 창에 대해 취할 샘플 수입니다.  
- **Return to service in sec. (서비스 복귀 시간 - 초)**: 서비스 복귀를 위한 차단기의 냉각 기간(초).  



회로 차단기 (Circuit Breaker)

## Tyk v3.0     
 **Long Term Support의 중요한 기능 변화 요약**
  
타이크는 3년 동안 버전 2를 계속 사용했기 때문에 우리의 주요 Tyk Gateway 버전을 2에서 3으로 올렸습니다. 또한 Tyk Dashboard 주 버전을 1에서 3으로 변경했으며 이제부터는 주 및 부 릴리스에 대해 항상 Tyk Gateway와 정렬됩니다 (같은 버전 넘버 3.0을 가지게 됨). Tyk Pump도 이제 1.0으로 업데이트되었으므로 향후 주요 변경 사항을 더 잘 나타낼 수 있습니다.

중요한 것은 버전이 크게 변경되었다고 해서 이전 버전과의 호환성이 중단된다는 의미는 아니라는 것입니다. 더욱이 우리는 더 많은 안정성을 보장하고 모든 Tyk 제품을 더 빠른 속도로 제공할 수 있도록 내부 출시 전략을 재구성하고 있습니다. 버전 번호를 기반으로 사용자가 기대할 수 있는 안정성 기준에 대해 보다 명확하게 설명하는 것을 목표로 합니다. 또한 장기 릴리스(LTS라고도 함)를 도입하고 있습니다.

자세한 내용은 타이크의 블로그 포스트에서 볼 수 있습니다:  [링크](https://tyk.io/introducing-long-term-support-some-changes-to-our-release-process-product-versioning/)       
  

## 새로운 모양과 느낌  

Tyk 대시보드가 ​​완전히 새로워졌습니다. 약 반년 전, 우리는 창의성과 뛰어난 UX에 대한 우리의 사랑을 더 잘 표현하기 위해 시각적 브랜딩을 일부 변경했습니다. 이러한 변경 사항은 웹 사이트에서 시작되었으며 이제 이러한 시각적 변경 사항을 제품의 UI에 통합하고 있습니다. 이는 전체 Tyk 경험에서 브랜드 일관성을 유지하고 제품 사용 경험을 향상시키기 위한 것입니다.  

[업데이트된 자습서 섹션](https://tyk.io/docs/getting-started/)을 참조하십시오.  

## UDG 및 GraphQL  

이제 Tyk는 기본적으로 GraphQL을 지원합니다. 즉, Tyk는 GraphQL 미들웨어에 대해 외부 서비스나 프로세스를 사용할 필요가 없습니다. GraphQL 핵심 기능을 사용하여 기존 GraphQL API를 안전하게 노출할 수 있습니다.  

이 외에도 Tyk의 통합 GraphQL 엔진을 사용하여 UDG를 구축할 수도 있습니다. UDG(Universal Data Graph)를 사용하면 기존 서비스를 하나의 결합된 GraphQL API로 노출할 수 있습니다.  

자체 GraphQL 서버를 구축할 필요 없이 이 모든 것이 가능합니다. 기존 REST API가 있는 경우 UDG를 구성하기만 하면 Tyk에서 작업을 완료합니다.  

Universal Data Graph를 통해 Tyk는 모든 내부 및 외부 API에 대한 중앙 통합 지점이 됩니다. 이 외에도 UDG는 이미 Tyk 설치와 함께 제공되는 모든 기존 솔루션의 이점을 제공합니다. 즉, UDG는 처음부터 안전하며 그래프를 강화하기 위해 구축할 수 있는 즉시 사용 가능한 미들웨어가 많이 있습니다.  

## GraphQL 및 UDG 자세히 알아보기  
- [GraphQL](https://tyk.io/docs/graphql/)
- [Universal Data Graph](https://tyk.io/docs/universal-data-graph/)
 
## 정책 및 키 UX 변경 사항  

UX 및 UI 개선으로 업데이트할 내용이 많지만 여기서 강조하고 싶은 한 가지는 정책 및 주요 대시보드 페이지에 대한 업데이트입니다. Tyk 대시보드에서 정책과 키를 설정하는 방식에 혼란이 있었다는 것을 알고 있으므로 보안 정책 및 키를 생성, 확인 및 편집할 때 오류가 발생하기 쉽고 간단하고 직관적인 UI 워크플로를 재설계했습니다.  

키를 생성, 확인 또는 편집할 때 단계는 보다 논리적인 순서로 되어 있습니다. 정보를 쉽게 찾고 입력할 수 있도록 작성해야 하는 긴 양식을 제거하고 탭으로 대체했습니다. 또한 각 API 내의 모든 정보를 그룹화하여 혼란 없이 각 액세스 권한의 정확한 설정을 알 수 있습니다. 새 워크플로를 통해 작업을 더 빠르고 효율적으로 완료할 수 있습니다.  

[정책 생성](https://tyk.io/docs/getting-started/create-security-policy/) 및 [키 생성 방법](https://tyk.io/docs/getting-started/create-api-key/)에 대한 업데이트된 자습서 보기  

또한 우리가 한 일과 그 일을 한 이유를 설명하는 [블로그 게시물](https://tyk.io/the-transformation-of-policies-and-keys/)이 있습니다.  

## 이제, Tyk Identity Broker (TIB)가 대시보드에 내장됨  

이전에는 SSO(싱글 사인온)를 설정하기 위해 별도의 프로세스를 실행해야 했습니다. 이제 이 기능이 대시보드에 내장되어 UI가 개선되었습니다. 이제 타사 구성 요소를 설치하지 않고도 대시보드를 시작하고 UI를 통해 SSO 흐름을 만들 수 있습니다. Dashboards RBAC 및 ID 공급자와의 통합을 포함하여 소셜 로그인, OpenID Connect 및 LDAP(곧, SAML이 제공될 예정입니다!)를 통한 SSO를 포함합니다.  

[업데이트된 흐름 세부정보 보기](https://tyk.io/docs/tyk-identity-broker/)     

## 외부 비밀 관리 서비스 사용  

API 정의 내의 KV 저장소에서 비밀을 참조하고 싶으십니까? 이제 네이티브 Vault & Consul 통합을 가지고 있습니다. 심지어, tyk.conf 파일이나 환경 변수 파일에서 가져올 수도 있습니다.  

[더보기](https://tyk.io/docs/tyk-configuration-reference/kv-store/)   

## 공동 프로세스 응답 플러그인  

미들웨어가 업스트림의 응답을 수정할 수 있도록 새로운 미들웨어 후크를 추가했습니다. 응답 미들웨어를 사용하여 응답 본문 또는 응답 헤더의 일부를 변환, 검사 또는 난독화하거나 업스트림 서비스에서 수신한 정보를 기반으로 이벤트 또는 웹훅을 실행할 수 있습니다.  

현재 응답 후크는 [Python 및 gRPC 플러그인](https://tyk.io/docs/plugins/supported-languages/rich-plugins/rich-plugins-work/)에 대해 지원됩니다.  

## 향상된 게이트웨이 상태 확인 API  

이제 표준 상태 확인 API 응답에는 대시보드, redis 및 mdcb 연결의 상태에 대한 정보가 포함됩니다. 새 데이터를 기반으로 알림 또는 로드 밸런서 규칙을 구성할 수 있습니다. 예를 들어 Tyk Gateway가 대시보드에 연결할 수 없는 경우(또는 마지막으로 알려진 구성으로 올바르게 작동하더라도) 알림을 받을 수 있습니다.    

[더보기](https://tyk.io/docs/planning-for-production/ensure-high-availability/health-check/)   

## 향상된 세부 로깅  
[
자세한 로깅은 디버깅 이슈가 생길 경우에 많이 사용됩니다. 이제 세부 로깅을 전역적으로 활성화할 수 있을 뿐만 아니라(많은 트래픽으로 막대한 오버헤드를 유발할 수 있음), 단일 키 또는 특정 API에 대해서만 활성화 할 수도 있습니다.  

새로운 세부 로깅 변경 사항은 현재 온프레미스 고객에게만 제공됩니다.   

[더보기](https://tyk.io/docs/tyk-stack/tyk-pump/useful-debug-modes/)   

## 더 나은 Redis 장애 조치  

이제 Redis를 사용할 수 없는 경우 Tyk는 이 시나리오를 보다 원활하게 처리하고 단순히 Redis 연결을 종료하는 대신 속도 제한 또는 할당량과 같이 redis에 의존하는 기능을 동적으로 비활성화 한 다음, Redis가 사용가능해지면 기능을 다시 활성화 합니다. Tyk 게이트웨이는 Redis 없이도 시작할 수 있는데; Redis Sentinel 설정에서처럼, 게이트웨이가 그 자체로 Redis를 프록시하는 경우와 같은 시나리오가 가능합니다.  

## 가중치 기반 로드 밸런싱  

이제 Tyk 대시보드에서 로드 밸런싱 기능을 사용할 때 업스트림의 가중치를 제어할 수 있습니다. 예를 들어, 이제 트래픽의 20%를 한 서비스로 보내고 80%를 다른 업스트림 서비스로 보내도록 Tyk를 구성할 수 있습니다.  

이를 통해 API 및 서비스에 대한 Canary 또는 A/B 테스트를 수행할 수 있습니다. 마찬가지로 캐시에 워밍업이 필요한 경우 이러한 서비스에 낮은 비율의 트래픽을 보낼 수 있으며 로드를 처리할 수 있다고 확신하고나면 해당 서비스에 좀 더 높은 비율의 트래픽을 점진적으로 보내기 시작할 수 있습니다.   

[더보기](https://tyk.io/docs/planning-for-production/ensure-high-availability/load-balancing/#configure-load-balancing-and-weighting-via-the-dashboard)   

## 분석을 다양한 데이터 싱크로 분할하는 기능  

다중 조직 배포에서 각 조직, 팀 또는 환경에는 선호하는 분석 도구가 있을 수 있습니다. 현재 Tyk Pump에 분석을 보낼 때 조직별로 분석을 구분하지 않습니다. 즉, 모든 분석을 동일한 데이터베이스에 보내야 했습니다 -예: MongoDB. 하지만, 이제 Tyk Pump는 다른 조직에 대한 분석을 다른 장소로 보내도록 구성할 수 있습니다. 예를 들어, 조직 A는 분석을 MongoDB + DataDog에 보낼 수 있습니다. 그러나 조직 B는 분석을 DataDog에 보내고 Prometheus 메트릭스 엔드포인트를 노출할 수 있습니다.  

또한 차단 목록을 두는 것이 가능해집니다. 즉, 일부 데이터 싱크는 모든 조직에 대한 정보를 수신할 수 있지만, 차단 목록에 등록 돼 있는 경우 다른 데이터 싱크는 OrgA의 분석을 수신하지 못합니다.  

**이 변경된 기능은 새로운 Tyk Pump 1.0으로 업데이트해야 가능합니다.**    
  

[더보기](https://tyk.io/docs/tyk-pump/) 

## 404 오류 로깅 - 일치하지 않는 경로   

클라이언트가 404 응답을 받는 것이 걱정되십니까? API 정의 또는 URL 재작성이 잘못 구성되었을 수 있습니까? Tyk에 404 로그를 추적하도록 지시하면 Tyk Gateway는 특정 리소스를 찾을 수 없다는 오류 로그를 생성합니다.  

이 기능은 게이트웨이의 구성 파일에서 track_404_logs 구성을 true로 설정하여 활성화할 수 있습니다.  

## 수정  

비어 있지 않은 할당량으로 생성된 토큰과 할당량 만료가 Never로 설정된 토큰이 무제한 할당량으로 처리되는 버그를 수정했습니다. 이제 초기 할당량에 도달하면 이러한 토큰이 작동을 멈춥니다.   
 
## 업데이트된 버전  
  
- Tyk 게이트웨이 3.0  
- Tyk 대시보드 3.0  
- Tyk 펌프 1.0  

## 버전 2.9로부터 업그레이드  

특정 조치가 필요하지 않습니다.   
만약, 버전 2.8에서 업그레이드하는 경우라면, Tyk 펌프를 먼저 업그레이드 하십시오.


Tyk LTS - v.3.0

## 테스트 개요  

버전 1.9부터 Tyk는 설정된 간격으로 사용자 정의 엔드포인트를 능동적으로 폴링하여 트래픽을 관리하는 기본 서비스 및 호스트에 대한 일종의 내장형 "업타임 인식"을 지원합니다.  

Tyk의 가동 시간 인식은 기존 가동 시간 모니터링 도구를 대체하기 위한 것이 아니라 API 게이트웨이로서의 Tyk 역할의 일부로 작동 중지 상태인 비정상 노드를 우회하는 방법을 제공하여 이를 보완하도록 설계되었습니다.  

## 업타임 테스트의 동작 원리

가동 시간 테스트가 Tyk 클러스터에 추가되면 단일 노드가 스스로를 마스터로 선택하고 마스터는 Dead man's switch를 사용하여 이 상태를 유지합니다. Redis에서 키를 활성 상태로 유지함으로써 마스터는 몇 초마다 재선되거나 확인됩니다. 한 노드가 중지되거나 실패하면 다른 노드가 실패를 감지하여 자신을 마스터로 선택합니다.  

그런 후, 마스터 노드는 클러스터(샤드 그룹)에 할당된 가동 시간 테스트를 실행합니다.  

가동 시간 테스트를 실행하는 노드에는 노드 구성 가능 간격 루프에 의해 결정된 몇 초마다 테스트를 동시에 실행할 수 있도록 정의된 작업자 풀 (pool)이 있습니다. 실행 중인 가동 시간 테스트 수에 따라 이 작업자 풀은 필요에 따라 늘리거나 줄여야 합니다.  

## 최초 설정

가동 시간 테스트를 구성하려면 관련 섹션을 tyk.conf에 추가하십시오.  

*"uptime_tests": {
  "disable": false, // disable uptime tests on the node completely
  "poller_group":"",
  "config": {
    "enable_uptime_analytics": true,
    "failure_trigger_sample_size": 3,
    "time_wait": 300,
    "checker_pool_size": 50
  }
}*  

***disable***: false로 설정하면 Tyk에 가동 시간 테스트를 실행하도록 지시합니다. 가동 시간 테스트를 노드에서 실행하지 않으려면 true로 설정하면 해당 노드에서 비활성화 됩니다 (이것은 가동 시간 테스트를 별도의 Tyk 인스턴스 그룹에서 실행 중인 경우에 유용할 수 있습니다).  

***poller_group***: 이 필드는 가동 시간 테스트의 다른 그룹을 정의하는 데 사용됩니다. 동일한 poller_group이 있는 모든 게이트웨이는 해당 그룹의 마스터로 선출될 후보가 됩니다. 이는 Tyk 인스턴스들의 분할 또는 분할 그룹 (segmented or sharded group)에서 가동 시간 테스트를 실행하는 경우에 유용할 수 있습니다.  

***enable_uptime_analytics***: Tyk는 가동 시간 테스트에 의해 생성된 데이터 기록을 지원하며, 대시보드에서 이를 표로 만들 수 있습니다. 가동 시간 분석을 활성화하려면 true로 설정하십시오. 그러나 가동 시간 테스트는 지속적으로 실행되기 때문에 많은 양의 데이터를 생성할 수 있습니다. 이 데이터를 관리하지 않으려는 일부 사용자는 이 값을 false로 설정하여 비활성화할 수 있습니다.  

***failure_trigger_sample_size***: 여기에서 테스트가 실패하거나 설정된 횟수를 통과한 후 HostDown 또는 HostUp 이벤트를 트리거하도록 Tyk에 지시합니다; 이 예에서는 3. 숫자를 더 높은 값으로 설정하면 오탐을 방지할 수 있지만 검증으로 인해 리드 인시던트 시간이 늘어날 수 있습니다.  

***time_wait***: 테스트 실행 사이의 시간(초)입니다. 이 예에서는 300초로 설정됩니다.  

***checker_pool_size***: 가동 시간 테스트를 위한 작업자 풀입니다. 이 예에서 우리는 테스트를 보낼 50명의 유휴 작업자를 메모리에 유지하도록 Tyk를 구성했습니다. 말하자면, 이 구성을 사용하면, 여러분에게 최대 50개의 테스트에 대한 비동기 테스트가 거의 보장된다는 것입니다.  

## API 정의로 구성하기  

가동 시간 테스트 체크리스트는 API 구성 내에 있으므로, API 정의에서 테스트 섹션을 추가하여 구성하면 됩니다.  

*uptime_tests: {
  check_list: [
    {
      "url": "http://google.com/"
    },
    {
      "url": "http://posttestserver.com/post.php?dir=uptime-checker",
      "method": "POST",
      "headers": {
        "this": "that",
        "more": "beans"
      },
      "body": "VEhJUyBJUyBBIEJPRFkgT0JKRUNUIFRFWFQNCg0KTW9yZSBzdHVmZiBoZXJl"
    }
  ]
},*  

가동 시간 테스트는 버전이 지정되지 않습니다.  

위의 예에는 Uptime 테스트를 위한 두 가지 형식이 있습니다. GET 요청을 가정하는 "빠른" 형식과:  

*{
  "url": "http://google.com/"
}*  

또는, 전체 요청을 점검하거나 흉내 낼 수 있는 긴 형식 입니다:  

*{
  "url": "http://posttestserver.com/post.php?dir=tyk-checker-target-test&beep=boop",
  "method": "POST",
  "headers": {
    "this": "that",
    "more": "beans"
  },
  "body": "VEhJUyBJUyBBIEJPRFkgT0JKRUNUIFRFWFQNCg0KTW9yZSBzdHVmZiBoZXJl"
}*  

여기서 body는 Base64로 인코딩 됩니다.  

빠른 양식을 사용하면 시간 초과가 적용되지 않지만, 긴 양식은 500ms 시간 초과로 실패하게 된다는 것을 주목하십시오.  

## 대시보드에서 구성하기   

대시보드를 사용하여 가동 시간 테스트를 추가하는 것은 매우 간단합니다. 테스터를 활성화하려면 먼저, 게이트웨이에서 필수 구성을 충족했는지 확인하십시오.     

**1단계: 가동 시간 테스트 탭 선택**  

API 디자이너에서 가동 시간 테스트 탭을 선택합니다.
![api designer.png](https://storage.googleapis.com/argo-cms-strapi-upload/api_designer_80d2eabf19/api_designer_80d2eabf19.png)


**2단계: 추가 클릭**  
  
추가를 클릭하여 테스트를 추가합니다.
![uptime test option.png](https://storage.googleapis.com/argo-cms-strapi-upload/uptime_test_option_145e6eaaad/uptime_test_option_145e6eaaad.png)



3단계: 경로 세부정보 입력
경로 세부 정보 팝업에서 세부 정보를 완료하고 추가를 클릭하여 테스트를 추가합니다.
![path detail.png](https://storage.googleapis.com/argo-cms-strapi-upload/path_detail_cc536b7354/path_detail_cc536b7354.png)




## 이벤트

**가동 시간 및 가동 중지 시간 이벤트 (uptime and downtime events)** 

Tyk가 테스트에서 다운타임을 감지하면 HostDown이라는 시스템 이벤트를 트리거하고 해당 호스트가 서비스를 재개할 때 HostUp을 트리거합니다. 이러한 이벤트는 다른 Tyk 이벤트와 동일한 이벤트 시스템에서 트리거되므로 어떤 종류의 작업이라도 모두 수행될 수 있습니다.  

- 로거 작업  
- 알림 URL에 대한 웹 후크  
- 복잡한 API 상호 작용을 위한 사용자 정의 JS 스크립트  

API 정의에 이벤트 핸들러를 추가하는 방법은 이벤트 시스템 섹션을 참조하십시오.  

테스트는 URL별로 이루어지므로, 여러 엔드포인트가 테스트되는 단일 호스트에 대해 여러 개의 *HostDown* 이벤트를 보게 될 가능성이 있습니다.  

**로드 밸런싱 및 서비스 검색**  

**다운타임 감지 및 서비스 가용성**  

라운드 로빈 로드 밸런싱을 사용하도록 Tyk를 구성한 경우에는, API 정의의 *proxy* 섹션에서 다운타임 목록에서 해당 서버가 액티브인지 볼 수 있게, 아웃바운드 Tyk 요청(서비스에 대한)의 호스트 이름을 확인하는 옵션을 활성화함으로써, 호스트가 "down"으로 표시된 경우 Tyk는 요청하기 전에 목록의 다음 호스트로 건너뜁니다.  

*...
"proxy": {
  ...
  "check_host_against_uptime_tests": true,
  ...
}
...*

포트를 포함한 정규화된 (fully qualified) 호스트는 Tyk가 둘을 함께 연결하기 위해 가동 시간 테스트 구성과 RRLB (라운드 로빈 로드밸런서) 항목 간에 정확히 일치해야 합니다.

예: *www.myapi.com:3000*





Leading Tyk Partner in South Korea

Latest Posts

API의 공통과제: 안정성 / 확장성 / 보안, 그 해결책

Netflix로부터 배우는 것

회로 차단기 (Circuit Breaker)

Tyk LTS - v.3.0

Tyk Uptime Test 가이드

Tyk API Gateway
Licenses

Launch

Flex

Multi-Team

Global Multi-Team

Leading Tyk Partner in South Korea

Latest Posts

API의 공통과제: 안정성 / 확장성 / 보안, 그 해결책

Netflix로부터 배우는 것

회로 차단기 (Circuit Breaker)

Tyk LTS - v.3.0

Tyk Uptime Test 가이드

Tyk API Gateway Licenses

Launch

Flex

Multi-Team

Global Multi-Team

Tyk API Gateway
Licenses