## Response Header (응답 헤더)의 변환  

Tyk를 사용하면 response가 client로 다시 프록시될 때 header 정보를 수정할 수 있습니다. 이는 제거해야 하는 민감한 를 잠재적으로 노출하는 업스트림 API가 있는 경우에 매우 유용할 수 있습니다.  

Response Transform Middleware(응답 변환 미들웨어)는 API Definition 또는 endpoint designer의 response 섹션에 설정이 적용된다는 점을 제외하고는 Request Transform Middleware(요청 변환 미들웨어)와 동일한 방식으로 작동합니다. 자세한 내용은 [Request Header Injection 문서](https://www.argopacific.io/blog/post/transform-traffic-request-headers)를 참조하세요.   

### 설정 방법 - API Definition
Tyk를 사용하면 *extended_paths.transform_response_headers* 필드에 다음을 추가하여 API 정의를 설정할 수 있습니다:  
![Response Header API Definition.png](https://storage.googleapis.com/argo-cms-strapi-upload/Response_Header_API_Definition_5098848bdc/Response_Header_API_Definition_5098848bdc.png) 

### 설정 방법 - Dashboard UI
Coming Soon 

### Response Middleware에 필요한 사항
Response Middleware(응답 미들웨어)를 등록해야 하므로 API Defintion를 편집할 때 마지막 단계가 필요합니다. 즉, 아래와 같이 프로세서에 Response Middleware를 추가하는 것입니다:  
![response middleware.png](https://storage.googleapis.com/argo-cms-strapi-upload/response_middleware_692c6de241/response_middleware_692c6de241.png)
 

Tyk Feature - Response Header 제어

## 방법1 - API 정의를 사용하여 요청 헤더 변환 

Tyk를 사용하면 헤더 정보가 프록시를 떠나기 전에, 업스트림 API로 전달되거나 응답이 클라이언트로 다시 프록시될 때 헤더 정보를 수정할 수 있습니다. 이는 단일 인증 키가 있는 업스트림 API가 있을 때, 이를 수정하거나 새로운 사용자를 지원하기 위해 투박한 인증 방법을 추가하지 않고 해당 API에 대한 다중 사용자 액세스를 추가하려는 경우에 매우 유용할 수 있습니다. 

 
**[시나리오 예시]** 

액세스를 허용하기 위해 x-widgets-secret 헤더를 사용하는 WidgetsAPI라는 API가 있습니다. 이것은 팀에서 사용하는 내부 API이지만 고객에게 공개하고 액세스 비용을 청구하려고 합니다. 

이 때, 여러분은;
1. API를 수정하고 전체 사용자, 키 및 액세스 관리 시스템을 추가하거나 
2. Tyk를 사용하여 이 헤더를 삽입하도록 만들 수 있습니다. 

**API 정의 객체 (API definition object) 업데이트:** Tyk를 사용하여 *extended_paths.transform_headers* 필드에 다음을 추가하여 API 정의를 설정할 수 있습니다. 

![extended_paths.transform_headers.png](https://storage.googleapis.com/argo-cms-strapi-upload/extended_paths_transform_headers_7f90c83950/extended_paths_transform_headers_7f90c83950.png) 

이제, 이 API 및 버전으로 설정된 액세스 정의 규칙으로 생성한 Tyk 키에 기존 API에 새로운 코드나 기능을 추가할 필요 없이 할당량(quotas), 조절(throttling)및 액세스 검사를 적용할 수 있습니다. 

 
## 방법2 - 대시보드를 사용하여 요청 헤더 변환 

대시보드의 GUI를 사용하여 요청에 새 헤더를 삽입하려면 API 정의의 엔드포인트 디자이너 섹션에서 편집해야 합니다. 

**1단계: 엔드포인트 추가하고 헤더 수정 플러그인 선택합니다** 
또한, 매칭시킬 메소드와 요청 패턴을 설정해야만 합니다. 이러한 패턴은 중괄호, { }로 묶인 문자열 형식의 와일드카드를 포함할 수 있습니다. 이러한 와일드카드는 사람이 읽을 수 있도록 하고 변수명으로 변환하지 않습니다. 내부에서 와일드카드는 (.*)의 "모든 항목 일치" 정규식으로 변환됩니다. 
![API Designer_modifiying headers.png](https://storage.googleapis.com/argo-cms-strapi-upload/API_Designer_modifiying_headers_f384719440/API_Designer_modifiying_headers_f384719440.png)

**2단계: “Request" 탭 선택** - 이렇게 하면 인바운드 요청에만 적용됩니다. 
![Modify headers.png](https://storage.googleapis.com/argo-cms-strapi-upload/Modify_headers_701a565199/Modify_headers_701a565199.png)

**3단계: 헤더 수정 설정** 
제공된 필드를 사용하여 삭제 및 삽입할 헤더 설정을 선택합니다. 추가하는 모든 헤더는 카멜방식의 대문자로 표시됩니다. 즉. UI 또는 API 정의에 x-request-id를 추가하면 응답에서 호출자는 X-Request-Id를 받게 됩니다. 
>중요: Add 버튼을 클릭하여 목록에 추가되었는지 확인하십시오. 

![setup header modify.png](https://storage.googleapis.com/argo-cms-strapi-upload/setup_header_modify_7ea34a8d81/setup_header_modify_7ea34a8d81.png) 

**4단계: API 저장** - API가 저장되면 요청 경로 및 메서드가 패턴과 일치하면 엔드포인트에 도달하는 요청이 관련 수정됩니다. 


## 방법3 - 전역적으로 요청 헤더 수정 
 
**전역적으로 헤더 주입 및 제거하기** 
어떤 경우에는 모든 아웃바운드 요청에 보안 헤더를 추가하고 싶을 수 있습니다(예: 트래픽이 게이트웨이에서 오는지 확인). 그렇게 하려면 API 정의의 버전 블록에 다음을 추가하십시오. 
![injecting and removing header globally.png](https://storage.googleapis.com/argo-cms-strapi-upload/injecting_and_removing_header_globally_bd0d3e1d4a/injecting_and_removing_header_globally_bd0d3e1d4a.png)
 

## 방법4 - 대시보드를 통해 전역 인젝션 추가하기 
 
**Global Version Setting** 메뉴를 선택하여 API 엔드포인트 디자이너를 통해 대시보드에서 이를 달성할 수도 있습니다.
![adding global injection.png](https://storage.googleapis.com/argo-cms-strapi-upload/adding_global_injection_f6851e03d5/adding_global_injection_f6851e03d5.png)


## 방법5 - 헤더에 사용자 지정 동적 데이터 삽입 

사용자 세션 객체 내에서 전달되는 정보를 헤더 공간에도 주입할 수 있습니다. 각 토큰 또는 키에는 ‘meta_data’ 필드가 포함된 연결된 세션 개체가 있습니다. 이는 동적 미들웨어 및 기타 구성 요소가 인바운드 요청의 ID 정보를 노출하지 않고 지능적으로 작동할 수 있도록 하는 key/value 맵입니다. 


헤더 변환에서 이 데이터를 사용하려면 특수 $tyk_meta 네임스페이스에 액세스하기만 하면 됩니다. 다음은 작업 예입니다. 


세션 개체에 다음 메타데이터를 포함했다고 가정해 보겠습니다: 

![injecting custom dynamic data into header.png](https://storage.googleapis.com/argo-cms-strapi-upload/injecting_custom_dynamic_data_into_header_996765c884/injecting_custom_dynamic_data_into_header_996765c884.png)
 
헤더 변환에서 이것을 사용하려면 API 정의 경로는 다음과 같습니다. 
![transform headers.png](https://storage.googleapis.com/argo-cms-strapi-upload/transform_headers_c7093ddf02/transform_headers_c7093ddf02.png)
 
 
## 방법6 - 대시보드의 메타 데이터 

변수 이름(*$tyk_meta*)은 대시보드 필드에서도 사용할 수 있으며 동일한 방식으로 작동합니다. 
 
## 방법7 - 헤더에 컨텍스트 변수 인젝팅 

버전 2.2부터 Tyk에서는 *$tyk_context. namespace*를 사용하여 컨텍스트 변수를 헤더에 주입할 수 있습니다. 네임스페이스. 자세한 내용은 [컨텍스트 변수](https://tyk.io/docs/context-variables/)를 참조하십시오. 

**Global Header 섹션 예시** 
![example global header section.png](https://storage.googleapis.com/argo-cms-strapi-upload/example_global_header_section_e6a896bd36/example_global_header_section_e6a896bd36.png)

Tyk Feature - Request Headers 제어

medium_클러스터 내부구조.png

small_클러스터 내부구조.png

thumbnail_클러스터 내부구조.png

클러스터 내부구조.png

![클러스터 내부구조.png](https://storage.googleapis.com/argo-cms-strapi-upload/_b5514ea6af/_b5514ea6af.png)   

다이어그램에 표시된 것처럼 마스터 노드는 컨트롤 플래인으로서, 클러스터 관리를 담당합니다. 클러스터의 모든 활동을 조정하고 노드와 통신하여 Kubernetes 및 애플리케이션이 계속 실행되도록 합니다.   
노드는 Kubernetes 클러스터에서 작업자 머신 역할을 합니다. 주목해야 할 한 가지 중요한 점은 이 노드가 물리적 컴퓨터 또는 가상 머신이 될 수 있다는 것입니다.    

**노드로 역할하기 위해서는 다음과 같은 요구 사항이 있습니다:**  
- 각 노드에는 실행 중인 Kubelet이 반드시 있어야하고,   
- Docker와 같은 컨테이너 도구와   
- 실행 중인 kube-proxy 프로세스    
- 그리고, Supervisord 처럼 구성 요소를 다시 시작할 수 있는 프로세스가 있어야 합니다.   

>프로덕션의 설정에서는 Kubernetes를 사용하는 경우 최소한 노드 클러스터가 3개 이상인 것이 좋다는 것을 유의하세요.  

실습을 위해 로컬 머신에 설치하여 테스트하려면 minikube가 간편한 방법이지만, Windows 프로페셔날에서만 가능합니다.      
홈 버전의 윈도우 사용자는 [인터렉티브 튜토리얼](https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/)을 사용하세요.  
미니큐브는 로컬 박스에 가상 머신을 생성하고 하나의 단일 노드가 포함된 간단한 클러스터를 배포하는 경량의 Kubernetes 구현체입니다.  

![Pods의 구성요소.png](https://storage.googleapis.com/argo-cms-strapi-upload/Pods_f29bde9836/Pods_f29bde9836.png)

어떤 시나리오에서는 포드에서 여러 도커 컨테이너를 실행할 수 있지만, 포드는 단일 배포 단위로서 밀접하게 연결되고 리소스를 공유하는 Kubernetes의 단일 애플리케이션 인스턴스를 나타냅니다.   
포드는 일시적이고 일회적인 개체로 설계되었습니다. 그러므로 프로덕션 애플리케이션에서 단독으로 Pod를 생성하지 마십시오. 그런 생성은 기본 컨테이너가 실제로 작동하는지 테스트해야 할 때만 수행하는 것이 바람직합니다.   

>프로들은 Pod를 직접 사용하지 말고. 대신에 배포할 때 처럼 컨트롤러를 사용하라고 조언합니다.  

게다가, 포드는 자가 치유되지 않습니다.   
어떤 이유로 Pod가 죽으면 리스케줄 되지 않습니다. 또, 리소스가 부족하여 노드에서 포드가 종료되면 다른 건강한 노드에서 다시 시작되지 않습니다.   
컨트롤러라고 하는 Pod를 관리하고 안정성을 추가하는 더 높은 수준의 구성이 있습니다.   

**수명 주기를 통해 Pod는 다음과 같은 상태를 갖습니다:**  
- Pending  
- Running   
- Succeeded  
- Failed  
- Unknown  
- 그외, CrashLoopBackOff     

파드의 *status* 필드는 *phase* 필드를 포함하는 *PodStatus* 오브젝트로 정의됩니다.  
>파드의 phase (단계)는 파드가 라이프사이클 중 어느 단계에 해당하는지 표현하는 간단한 고수준의 요약으로서, Phase는 컨테이너나 파드의 관측 정보에 대한 포괄적인 롤업이나, 포괄적인 상태 머신을 표현하도록 의도되지는 않았습니다.  파드 phase 값에서 숫자와 의미는 엄격하게 지켜집니다. 공식문서 내용 이외에는, 파드와 파드에 주어진 phase 값에 대해서 어떤 사항도 가정되어서는 안됩니다.  

파드는 정의된 라이프사이클을 따릅니다:  Pending 단계 (Phase)에서 시작해서, 기본 컨테이너 중 적어도 하나 이상이 OK로 시작하면 Running 단계를 통과하고, 그런 다음 파드의 컨테이너가 실패로 종료되었는지 여부에 따라 Succeeded 또는 Failed 단계로 이동합니다.  

phase에 적용되는 값은 아래와 같습니다:   

**Pending**은 Kubernetes 시스템에서 Pod를 수락했지만 컨테이너가 아직 생성되지 않았음을 의미합니다. 즉, 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았습니다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함됩니다.

**Running**은 노드에서 포드가 예약되고 모든 컨테이너가 생성되고 적어도 하나의 컨테이너가 실행 중 상태인 실행 중입니다. 즉, 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었으며, 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있음을 의미합니다.

**Succeeded**는 Pod의 모든 컨테이너가 종료 상태가 0으로 종료되었음을 의미하고, 이는 성공적인 실행을 나타내며 다시 시작되지 않습니다. 

**Failed**는 실패 상태, 즉 파드의 모든 컨테이너가 종료되었고 적어도 하나 이상의 컨테이너가 실패하여 0이 아닌 종료 상태를 반환했습니다. 다시말해, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었음을 의미합니다.

**Unknown**은 알 수 없음, 즉 어떤 이유에 의해서 파드의 상태를 얻을 수 없는 경우입니다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생합니다.

그외에, **CrashLoopBackOff**이 있는데, 이는 어떤 이유로 컨테이너 시작에 실패하면 Kubernetes가 계속해서 Pod를 다시 시작하려고 시도하는 경우입니다.







K8s 기본 빌딩 블럭

large_K8s 클러스터 아키텍처.png

medium_K8s 클러스터 아키텍처.png

small_K8s 클러스터 아키텍처.png

thumbnail_K8s 클러스터 아키텍처.png

K8s 클러스터 아키텍처.png

## Kubernetes Cluster Architecture

>구름은 언제나 하늘에 떠 있었지만, 이제 클라우드 없는 세상을 상상하기 어렵게 됐습니다. 바람은 구름을 움직이고, 쿠버네티스 (Kubernetes, K8s)는 클라우드를 움직입니다.  
>   
>**Tyk APIM은 K8s 플랫폼과 유연하게 연동됩니다.**  
 
**K8s 없이는 클라우드를 조율할 수 없으니 기본 중의 기본; K8s 클러스터의 아키텍처와 각 컴포넌트들의 핵심 기능을 알아봅니다.**
     
   
   

  

![K8s 클러스터 아키텍처.png](https://storage.googleapis.com/argo-cms-strapi-upload/K8s_87ec1a5ae7/K8s_87ec1a5ae7.png)

**마스터 노드는 Kubernetes 클러스터의 전반적인 관리를 담당하며; 
통신, 스케줄링 및 컨트롤러를 처리하는 세 가지 컴포넌트: Kube API 서버, 스케줄러, 그리고 컨트롤러 관리자로 구성됩니다.**

**Kube API 서버**를 사용하면, 이름에서 알 수 있듯이, Kubernetes API와 상호 작용할 수 있습니다. 이 Kube API 서버는 Kubernetes 제어 평면의 프런트엔드입니다. 

**스케줄러**는 생성된 Pods를 감시하며 아직 Node 설계가 되지않은 Pod를 생성하고 특정 Node에서 실행되도록 Pod를 설계합니다. 

**컨트롤러 관리자**는 컨트롤러를 실행합니다. 이들은 클러스터에서 작업을 실행하는 백그라운드 스레드입니다. 컨트롤러에는 실제로 다양한 역할이 있지만 모두 단일 바이너리로 컴파일됩니다. 이들 역할에는 worker의 상태를 담당하는 **노드 컨트롤러**, 복제된 컨트롤러에 대해 올바른 수의 Pods를 유지 관리하는 책임을 지는 **리플리케이션 컨트롤러**, 서비스와 포드를 함께 연결하는 **엔드포인트 컨트롤러**가 포함됩니다. 
그리고 액세스 관리를 처리하는 **서비스 계정 및 토큰 컨트롤러**. 
마지막으로, 저장된 간단한 분산 키 값인 CD가 있습니다. 
Kubernetes는 etcd를 데이터베이스로 사용하고 모든 클러스터 데이터를 여기에 저장합니다. 저장될 수 있는 정보 중 일부는 작업 일정 정보, Pod 세부 정보, 단계 정보 (stage info) 등입니다. - Pod Lifecycle
여기까지가 마스터 노드입니다. 

여러분은 Kubernetes용 커맨드라인 인터페이스인 Kubectl 애플리케이션을 사용하여 마스터 노드와 상호 작용하게 됩니다. 
Kubectl에는 Kubeconfig라는 설정 파일이 있습니다. 이 파일에는 서버 정보와 API 서버에 접근하기 위한 인증 정보가 있습니다. 하지만, 작업자 노드 없이는 아무것도 할 수 없습니다. 이러한 작업자 노드는 여러분의 애플리케이션이 작동하는 노드입니다. 작업자 노드는 마스터 노드와 다시 통신합니다. 작업자 노드와의 통신은 Kubelet 프로세스에 의해 처리됩니다. 작업자 노드는 Pod가 노드에 맞게 설계되었는지 확인하기 위해 API 서버와 통신하는 에이전트입니다. 

작업자 노드는 컨테이너 엔진을 통해 Pod 컨테이너를 실행합니다. Pod 볼륨 및 시크릿을 탑재하고 실행합니다. 그리고 마지막으로 노드에 탑재된 포드의 상태를 인지하고 Master에게 다시 응답합니다. Kubelet이 작업자 노드에서 올바르게 작동하지 않으면 문제가 발생한다고 여기는 것이 안전합니다. 
Kubernetes는 컨테이너 오케스트레이터이므로 작업자 노드에서 실행 중인 컨테이너 기본 플랫폼이 있어야 합니다. 그래서 이 지점에서 Docker가 도입되어서 Kubelet과 함께 작동하여 노드에서 컨테이너를 실행합니다. 

다음으로 이야기할 프로세스는 Kube-proxy입니다. 이 프로세스는 단일 작업자 노드에서 서비스에 대한 네트워크 프록시이면서 로드 밸런서입니다. TCP 및 UDP 패킷에 대한 네트워크 라우팅을 처리하고 연결 전달 (connection forwarding)을 수행합니다.  
Docker Daemon이 있으면 컨테이너를 실행할 수 있습니다. 애플리케이션의 컨테이너들은 Pod에서 단단하게 결합됩니다. 공식문서에 정의된 것처럼, Pod는 Kubernetes에서 배포 (deployment)로 예약할 수 있는 가장 작은 단위입니다. 이 컨테이너 그룹은 무엇보다도 스토리지, Linux 네임 스페이스, IP 주소를 공유합니다. 그들은 같은 위치에 함께 있으며 항상 같이 스케줄된 리소스를 공유합니다. 포드가 배포되고 실행되면 Kubelet 프로세스는 포드와 통신하여 상태 및 상태를 확인하고 Kube-proxy는 통신을 원할 수 있는 다른 리소스도부터 포드로 모든 패킷을 라우팅합니다. 작업자 노드는 로드 밸런서를 통해 인터넷에 노출될 수 있습니다. 그리고 노드로 들어오는 트래픽도 Kube-proxy 의해 처리되며, 이는 최종 사용자가 Kubernetes 애플리케이션과 대화를 종료하는 방식입니다. 





K8s 클러스터 아키텍처



> Tyk 게이트웨이가가 요청을 같은 API 정의와 리스닝 경로를 사용하는 여러 개의 다른 백엔드 엔드포인트로 포워딩하는 것이 가능한가요?  


## Batch 프로세싱 예제   

**비즈니스 시나리오에서 하나의 요청이 어떤 집계된 형태의 데이터를 보여 주어야 하는 경우가 종종 있습니다. 이런 경우에는 여러 개의 다른 백엔드 엔드포인트를 호출하여 요청의 결과를 집계하여 리턴하는데, Tyk에서는 가상 엔드포인트 (virtual endpoint) 기능과 batch processing을 사용하여 원하는 결과를 얻을 수 있습니다.**    

아래의 예제는 batch 프로세싱 API를 사용하여 구현하는 방법을 보여 줍니다: 

function batchTest(request, session, config) {  
  
  // 응답 오브젝트 설정   
  var response = {  
    Body: "",  
    Headers: {  
      "test": "virtual-header-1",  
      "test-2": "virtual-header-2",  
      "content-type": "application/json"  
    },  
    Code: 200  
  }  
    
  // Batch 요청  
  var batch = {  
    "requests": [  
      {  
        "method": "GET",  
        "headers": {  
          "x-tyk-test": "1",  
          "x-tyk-version": "1.2",  
          "authorization": "1dbc83b9c431649d7698faa9797e2900f"  
        },  
        "body": "",  
        "relative_url": "http://httpbin.org/get"  
      },  
      {  
        "method": "GET",  
        "headers": {},  
        "body": "",  
        "relative_url": "http://httpbin.org/user-agent"  
      }  
    ],  
    "suppress_parallel_execution": false  
  }  
    
  log("[Virtual Test] Making Upstream Batch Request")  
  var newBody = TykBatchRequest(JSON.stringify(batch))  
    
  // 요청은 응답으로서 바디에 JSON을 가지고 올 것을 알고 있으니, 파싱합니다 
  var asJS = JSON.parse(newBody)  
  for (var i in asJS) {  
    asJS[i].body = JSON.parse(asJS[i].body)  
  }  
    
  // 이제 Tyk가 응답객체에 스트링 객체를 임베드하여 보낼 차례입니다.   
  response.Body = JSON.stringify(asJS)  
    
  return TykJsResponse(response, session.meta_data)  
    
}  
log("Batch Test initialised")  
                


Tyk Feature - Request Forwarding 하기

오픈 뱅킹의 개념은 수  년 동안 존재해 왔지만 업계는 대부분, 특별한 이유가 있어서가 아니라, 규정 준수를 위해 이를 지지했습니다. 그러나 팬데믹이 초래되면서 전 세계적으로 오픈 뱅킹 접근 방식과 수용이 결정적이고 신속하게 채택되었습니다. 예를 들어, Covid의 파괴적인 여파로 많은 어려움에 처한 차용인, 특히 소규모 기업과 개인은 오픈 뱅킹 생태계가 더 쉬운 신용 출처임을 알게 되었습니다. 은행 및 기타 다양한 기관이 데이터를 제3자 제공업체와 실시간으로 공유할 수 있는 권한을 부여함으로써 차용인은 보다 유리한 조건으로 더 많은 신용 공급을 이용할 수 있습니다. 그리고 이것은 오늘날 우리 세계의 핵심 변혁 수단이 된 오픈 뱅킹의 채택을 가속화하는 많은 요인 중 하나일 뿐입니다.  
  
이러한 오픈뱅킹에 대한 수요 증가와 함께 최근에는 오픈뱅킹의 범위도 확대되고 있습니다. 오픈 뱅킹 초기에는 정보 공유가 제한적이었고 그 외에는 거의 없었습니다. 오늘날 참가자들은 규정 준수와 자신감을 얻음에 따라 신용, 지불 및 회계 솔루션을 포함한 광범위한 제품 포트폴리오를 제공하고 있으며 저축 및 투자 상품도 도입을 계획하고 있습니다.  

두 가지 요인이 이러한 성장을 뒷받침하고 있습니다. 첫 번째는 많은 국가의 규제 추진이고 두 번째는 개방형 API의 확산입니다. 2020년 첫 2분기 동안 전 분기 대비, Open Banking API 플랫폼은 전 세계적으로 49% 성장했습니다. 최신 EFMA Infosys Finacle Innovation in Retail Banking 연구에서 금융 기관은 Open Banking API가 2021년 은행 비즈니스에 중간 정도 이상에서 매우 높은 정도까지의 영향을 미칠 것이라고 말했습니다. API는 Open Banking 생태계의 거대한 조력자로서 참여자와 참여자 간의, 그리고 제3자/비은행 채널들에 대한 다양한 오퍼링을 위한 효율적인 데이터 교환을 촉진합니다.

> “API는 은행 업무의 미래를 바꿀 태세입니다. 그것들은 앞으로 은행 산업과 가장 밀접한 오픈 뱅킹 주도 비즈니스 모델의 혁신을 가능하게 할 엄청난 잠재력을 가지고 있습니다.”  
  
**오픈뱅킹의 영향력 확대**

오픈 뱅킹은 은행 및 금융기관의 본질을 바꾸고 있습니다. 가장 높은 수준에서는 ‘파이프라인’ 범용 뱅킹 모델을 해체하고 그 자리에 '플랫폼' 모델을 활성화하고 있습니다. 결과적으로, 전통적으로 상품을 기획하고 자체 채널을 통해 자체 고객에게 유통하던 은행은 이제 다른 공급자로부터 조달하거나 제3자 채널을 통해 자체 상품 및 서비스를 유통하는 다양한 금융 및 비금융 상품을 제공하고 있습니다. 그들은 다양한 방식으로 외부 생태계와 협력하여 이를 수행하고 있습니다:

파트너와 공동 제품 만들기: 예로는 씨티은행 (와 VISA)와 공동 브랜드 신용 카드를 도입한 Paytm, Apple과 협력하여 Apple 카드를 출시한 골드만 삭스에 의한  Marcus(와 Mastercard)가 있습니다.
고객의 주요 여정에 비은행 상품 포함: DBS는 중고차, 부동산, 여행 및 유틸리티에 대한 성공적인 시장을 통해 고객이 은행 상품을 찾기 시작하기 훨씬 전에 고객 여정에 진입할 수 있는 좋은 예입니다.  
(심지어) 경쟁 제품을 제공하기 위해 제3자와 협력: IndusInd Bank 및 ICICI Bank와 각각 고가치 정기 예금 및 디지털 대출에 대해 협력하고 있는 Paytm의 예를 다시 한 번 생각해 보십시오.  

**은행은 플랫폼 비즈니스를 다음과 같은 혁신적인 모델로 구성해 나가고 있습니다.**

**BaaS(Banking-as-a-Service)**: BaaS는 최근 개발된 것으로 모델이 아직 채택 초기 단계에 있습니다. 아마도 가장 유명한 지수는 은행 계좌 생성, 결제 및 추적, 활동 세부 정보 액세스를 위한 API 세트를 제공하는 Goldman Sachs일 것입니다. 개발자는 은행의 인프라를 활용하여 금융 경험을 자체 프런트 엔드 애플리케이션에 구축할 수 있습니다.    
    
**마켓플레이스**: 마켓플레이스 모델은 한 곳에서 동급 최고의 금융 및 비금융 상품을 판매하는 마켓플레이스를 제공함으로써 많은 은행에서 인기를 얻고 있습니다. 어떤 면에서 마켓플레이스 모델은 BaaS 모델과 반대입니다. 여기에서 은행은 백화점과 마찬가지로 고객의 비은행적 요구도 충족시키기 위해 다른 제공업체의 최상의 옵션을 집합적으로 제공하기 때문입니다. 앞서 언급한 DBS Bank 외에도 영국의 Starling Bank는 자산 관리, 연금 계좌 및 회계 소프트웨어와 같은 다양한 서비스를 제공하는 성공적인 마켓플레이스를 운영하고 있습니다.    
 
**유틸리티**: 매우 흥미로운 비즈니스 모델은, 대형 은행이 규모와 효율성을 활용하여 백엔드 인프라 서비스를 다른 은행/제공업체에 제공한 다음 프론트엔드 활동에만 집중하는 유틸리티 모델입니다. 지불 유틸리티는 이제 매우 일반적이며 은행에서도 이러한 조치를 취하고 있습니다. 예를 들어 ABN Amro Bank는 다른 소규모 대출 기관 및 핀테크 회사에 수금, 커뮤니케이션 및 대출 관리와 같은 모기지 서비스를 제공하는 Stater NV를 설립했습니다.   

**API – 디지털 생태계 활성화 및 오픈 뱅킹 패러다임 육성**

위의 비즈니스 모델은 표면적으로는 다르지만 모두 내부의 API에 의해 구동됩니다. API는 개방형 뱅킹 기업 전반에 걸쳐 여러 수준에서 작동합니다: 전문화된 내부 API 또는 마이크로서비스를 통해 은행은 문제를 해결하고 고객을 위한 새로운 가치를 창출할 수 있습니다; API는 고객 확보 및 상품 확장에 도움이 됩니다. API 주도 아키텍처를 통해 은행은 세계 최고의 기업과 동등한 수준으로 혁신할 수 있습니다.  
따라서 건전한 API 전략의 중요성은 결코 과소평가될 수 없습니다. API를 개발하는 동안 은행은 다음 사항에 유의해야 합니다:    
  
 **API는 사용자 중심성, 재사용성 및 전체 종단에 걸친 프로세스 적용과 같은 우수한 설계 원칙과 가치를 기반으로 해야 합니다.**     
 **전략은 강력한 운영 모델과 핵심 비즈니스 가치를 지원하는 수익 창출 모델을 생성해야 합니다.**    
 **비즈니스가 미래에 새로운 기능을 제공하기 위해 API 우선 접근 방식을 도입하려면, 오늘 당장 최대한의 재사용성을 위해 API를 설계해야 합니다.**    
 **내부 및 외부 API를 실행하기 위한 건전한 거버넌스 메커니즘과 마찬가지로 명확한 소유권이 있는 최신 API 관리 플랫폼이 필수적입니다.**    
 **마지막으로 중요한 것은, 은행의 리더십은 조직 전체에 API 문화를 육성하기 위해 노력을 기울여야 합니다. 시간이 지남에 따라 은행에는 조직 전반에 걸쳐 활동하면서 API를 개발하는 여러 애자일 팀이 있어야 하기 때문에 적절한 인재와 교육 리소스를 확보하는 것이 중요합니다.**    

**API 및 오픈 뱅킹의 다음 단계**

강행 규제로 출발한 느린 시작 이후, Open Banking은 자체적으로 등장하기 시작했습니다. 이는 중요한 기회입니다. 오픈 뱅킹이 주류가 될 것이며 오픈 파이낸스와 같은 새로운 가능성을 열어줄 것입니다. 이는 결국 시장 경쟁과 혁신을 촉진하여 금융 기관과 다양한 고객 부문 모두에게 윈-윈 하는 제안이 될 것입니다.  


API를 이용한 Open Banking 비즈니스 모델

## 멀티 테넌시 (Multi-tenancy)  

멀티 테넌시는 하나의 타이크 전개로써 여러 테넌트들을 수용하는 기능   
데이터는 하나의 DB에 저장, 사용하지만 각 테넌트들은 자신이 소속된 Organisation의 데이터에만 접근가능하도록 멀티 테넌시를 지원   
테넌트 (tenant)와 조직 (organisation)은 같은 의미로 사용    

**조직 (Organisations)**  
하나의 organisation은 타이크 내에서 단일의 테넌트를 의미  
Organisations는 타이크 오브젝트의 계층구조 내에서 root 오브젝트로 간주  
     타이크 데이터베이스에서 가지고 있는 오브젝트들은 하나의 organisaiton에 대한 레퍼런스이고, 그것의 *org_id* 필드가 해당 organisation과 연관된 데이터를 가리키는 (indicate) 것.  
     한 오브젝트는 오직 하나의 조직 (organisation)에만 소속된다.  
 일반적으로 대시보드 사용자는 자신과 연결된 조직의 데이터에만 접근가능.
 특정 대시보드 사용자에게 여러 개의 조직에 접근허용하는 설정 방법:   
      a. 사용자를 복수의 조직들에서 동일한 이메일 주소를 사용하여 사용자 계정을 생성   
      b. 여러 조직에 접근허용 되더라도 한 번에 한 조직에만 접속가능   
      c. 사용자가 접근 인가된 후에 어떤 조직을 접근할 지를 반드시 선택해야만 함  
      d. 사용자가 자신에게 허용된 다른 조직으로 접근할 때는 다시 인가를 받아야만 됨
  
 다중 조직 접근을 생성하는 것은 사용자들의 계정을 각 조직에 대하여 별도로 만듦으로써 가능  
 다중 조직 사용자를 활성화 하려면:  
     a. 대시보드 라이선스가 최소한 2 개 이상의 게이트웨이를 가질 수 있어야 되고 (Tyk에 질의해야 함)
     b. 대시보드의 conf 파일의 enable_multi_org_users 플래그의 값을 true로 설정하여야 함

**Super Users**  

수퍼 유저들은 대시보드 내의 모든 조직들과 모든 데이터에 대해 접근 권한을 가짐
 전체 데이터 셋에 대한 리포팅에 유용하게 사용
 수퍼 유저들의 사용자 데이터베이스 내의  *org_id*는 빈값이며, 그들이 아무 조직과도 연결되지 않음
 수퍼 유저는 일반 UI나 API를 통하여 생성될 수 없고, 오직 특별한 대시보드 어드민 API를 통해서만 생성될 수 있음
 수퍼 유저는 데이터를 쓰기를 허용하지 않고 읽기만 권장:  수퍼 유저가 생성하는 데이터에 대해 *org_id* 값이 생성되지 않으므로 유효성 검증에 실패할 수 있음  
 
![data ownership.png](https://storage.googleapis.com/argo-cms-strapi-upload/data_ownership_f17ad64a79/data_ownership_f17ad64a79.png)


1. 사용자 Wile E.Coyote는 조직 1001 (Acme Corporation)에만 접근허용되고, API 2001, 2002만 보거나 관리할 수 있고, 2000 My API는 볼 수도 없음.
2. 사용자 Martin은 조직 1000에 접근 가능하므로 My API만 보거나 관리
3. 수퍼 유저는 org_id가 없으므로 어느 조직에도 속하지 않고, 모든 API를 볼 수도 관리할 수도 있음

**Listen Path Collisions (청취 경로 충돌)**

단일의 Tyk 설치로 다중 테넌트를 운용하는 경우에는 API 정의들이 같은 릿슨 패스를 사용하여 생성되는 일이 생길 수 있는데; 이것을 청취경로충돌 이라고 한다.

게이트웨이가 청취경로충돌을 감지하면:  
1. 애플리케이션 로그에 에러를 기록 (API 정의의 상세정보를 포함)
2. 충돌을 일으킨 모든 API들의 청취경로를 변경 (API Definition ID를 청취경로에 추가함으로써 각 청취경로를 유니크하게 만드는 방식)

![Listening path collison.png](https://storage.googleapis.com/argo-cms-strapi-upload/Listening_path_collison_99962e398e/Listening_path_collison_99962e398e.png)

위의 예시처럼, API A와 API B가 ‘/my-api’ 라는 같은 청취경로를 사용한다면;   
1. 게이트웨이가 이 API들을 로드할 때 청취경로충돌을 감지  
2. API ID를 사용하여 새로운 청취경로를 생성  

     **청취경로충돌을 피하기 위한 방법**  

     1. MDCB를 사용하면, 게이트웨이는 단일 Org에 종속되므로, 전체 테넌트들에 걸쳐 충돌이 발생할 수 없는 구조
     2. API를 Sharding 하여  API Definitions를 다른 게이트웨이에 분리하면 각 게이트웨이가 자신에게 할당된 API 정의를 로드하기 때문에 충돌을 방지할 수 있으나, API Sharding을 하기 위해  tag 를 맞게 입력해야 하기 때문에 이 때 휴먼 에러가 생길 수 있음   
     3. 커스텀 도메인을 사용하여 중복된 청취경로를 서로 구별할 수 있음 (각 도메인 명을 청취경로의 prefix로 사용하는 방식)   
     4. 대시보드 설정에서 *enable_duplicate_slugs* 의 설정값을 false 로 하여 대시보드가 같은 조직 내에서 청취경로충돌을 방지 (다중 테넌트에서는 역할 못하므로 MDCB가 필요)   


Tyk 멀티테넌시 (Multi-tenancy)

# 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*





Tyk Uptime Test 가이드

large_benchmark summary - full loaded.png

medium_benchmark summary - full loaded.png

small_benchmark summary - full loaded.png

thumbnail_benchmark summary - full loaded.png

benchmark summary - full loaded.png

AWS에서 Tyk 성능 테스트 방법

## Tyk API 게이트웨이를 위한 인프라 크기 설정 

[관련 영상보기](https://www.youtube.com/watch?v=DIt9hfrM4bs)

인프라 규모를 결정하는 것은 과학이기도 하고 최적화 문제이기도 합니다. 비용을 절감하면서, 동시에 성장을 가능하게 하는 규모인지 확인하는 것은 모든 조직이 풀어야 할 과제입니다.

다행히도, 시스템 메트릭을 주의 깊게 분석하여 기본 요구 사항이 무엇인지 결정할 수 있다는 것입니다. 여기에는 예상하거나 수신하는 초당 요청 수, 대기 시간에 대한 소비자의 관용 범위 (tolerance), 내결함성을 얼마나 깊이 검토해야 하는지와 같은 요인이 포함될 수 있습니다. 이 접근 방식은 이러한 방정식의 과학적 측면을 다룹니다.

인프라 크기 조정 방정식의 낙관적인 측면은 사용자가 미래에 인프라에 얼마나 많은 요구를 가할 것인지를 묻습니다. 그 요구가 너무 크면 창 밖으로 돈을 던지게 될 것이고, 너무 작게 설정하면 시스템에 부담을 주어 대기 시간과 불행한 사용자를 초래함으로써 사용자로부터 외면 받게 될 것입니다. 고맙게도 클라우드 플랫폼을 사용하면 인프라를 쉽게 확장 및 축소할 수 있는 옵션을 통해 신중하게 낙관할 수 있습니다.

그렇다면 이러한 인프라 크기 조정 고려 사항에서 Tyk 게이트웨이는 어디쯤 있을까요? 계속 읽으시면 알게 됩니다 !

*참고: 성장의 각 단계에서 인프라 비용을 확인하여 초과 지출과, 또는 활용도가 낮은지 확인해야 합니다. 운영을 위해 가장 크고 최고의 서버가 정말로 필요합니까? 결국, 여러분의 에고는 과도한 클라우드 요금을 마술처럼 낮춰주지는 못합니다! 비용을 확인하여 지불할 금액을 파악하고 이를 월 지출에 반영하십시오. 예상하지 못한 거대한 청구서에 놀라실 이유가 없습니다!*


**기본 요구사항 결정**

여러분이 속한 시나리오에 따라 베이스라인을 다르게 개발할 수 있습니다: 기존의 트래픽이 있는 이미 보유하고 있는 앱인가요, 아니면 히스토리가 없는 새로운 앱입니까?

트래픽 데이터가 있는 경우 가장 좋은 방법은 평균 지연 시간 (average latency)과 평균 초당 요청 수(RPS)를 중심으로 하는 몇 가지 지표를 조사하는 것입니다. 평균 대기 시간이 확실하지 않지만 평균 RPS를 알고 있는 경우 여기에서 다루는 간단한 부하 테스트 연습이 현재 설정의 평균 대기 시간을 결정하는 데 도움이 될 것입니다.

참조할 트래픽이 없다면 경험과 지식을 바탕으로 충분한 추측을 하십시오. 애플리케이션의 흐름과 출시 또는 트래픽이 피크를 치게 될 것으로 예상하는 이벤트 시점에서의 예상되는 사용자 기반에 대해 조사하면 도움이 될 것입니다. 이것은 최선의 추측을 기반으로 해야 하지만 너무 높거나 너무 낮지 않도록 주의해야만 합니다. 자신이 편안하게 느끼는 현실적인 범위를 찾으십시오.

새로운 앱에 사용자가 없고 API 호출 집약적이지 않은 데도, 밀리초 미만의 지연 시간으로 10,000 RPS를 처리할 수 있는 인프라를 프로비저닝하는 것은 과도합니다. 너무 작게 가고 싶지는 않지만 트래픽이 없다면 문제가 되지 않을 것입니다.

이 단계에서는 이러한 요청이 어디에서 오는지 확인할 수도 있습니다. 글로벌 사용자 기반이 있는 경우라면 사용 사례에 따라 다른 지역에서 인프라를 가동할 수 있습니다. 또한 트래픽을 분할하는 방법을 살펴볼 수도 있습니다. 분산된 지역에서 여러 개의 소규모 서버를 실행할 것인가요, 아니면 몇 개의 중앙 허브를 선택하고 더 큰 서버를 실행할 것인가요?

다양한 시나리오로 실행 해보고 각각의 부하를 테스트하여 가장 좋은 출발점을 결정하는 것이 유용합니다. 그런 다음 비용을 확인하십시오! 일부 인프라를 축소하고 몇 달러를 절약할 수 있습니까? 고객에게 영향을 미치지 않는 절감액을 찾으십시오.

**인프라 베이스라인 체크리스트**

* 현행 고객 또는 예상되는 초기 사용자 기반으로 계수정보 (metrics) 수집합니다.
* 여러 개의 작은 서버 또는 더 적은 수의 서버로 로드를 분할할지 여부를 결정합니다.
* 결과가 사용자의 기대에 부합하는지 확인하기 위한 부하 테스트
* 비용을 확인하고 절감액을 찾으십시오.

**미래의 요구사항 예측**

신규 애플리케이션이든 기존 애플리케이션이든 관계없이 어느 정도는 추정을 하게 됩니다. 일부 시나리오에서는 이 작업을 더 쉽게 수행할 수 있습니다. 예를 들어, 비즈니스에서 현재 사용자 기반을 두 배로 늘리려는 계획이 있는 경우, 이를 위한 시뮬레이션을 수행하고 시스템이 여전히 잘 작동하는지 확인할 수 있습니다. 백오피스 애플리케이션을 사용하면 새로운 사용자가 예상되기 때문에 이것이 가능할 수 있습니다.

그러나 외부 시스템을 사용 중이고 향후 요구 사항이 확실하지 않은 경우에는 어떻게 합니까? 또는 사용자 증가 및 채택에 대해 정의되지 않은 숫자가 있는 새 시스템이 있는 경우 어떻게 하시겠습니까? 이러한 시나리오에서는 시장에 대한 좋은 아이디어를 얻기 위해 유사한 회사의 성장을 살펴볼 가치가 있습니다.

현명한 낙관주의가 여기에 도움이 될 것입니다. 확장 방법에 대한 계획을 세울 때입니다. 시스템 및 고객 요구 사항에 따라 사용자 기반을 두 배, 세 배, 네 배(등)로 늘리는 데 필요한 인프라를 고려하십시오. 예상 성장, 이를 지원하는 데 필요한 인프라, 해당 인프라 비용을 개략적으로 설명하는 공식 계획을 작성하십시오. 이 플랜을 사용하여 여러 클라우드 제공업체에서 쇼핑하여 기능 및 비용을 기준으로 사용 사례에 가장 적합한 서비스를 확인할 수 있습니다.

이제 인프라 요구 사항에 대한 몇 가지 수치와 아이디어를 얻었으므로 계획의 각 단계에 따라 몇 가지 부하 테스트를 실행합니다. 이렇게 하면 인프라 계획이 예상 트래픽을 처리할 수 있는지 확인하는 데 도움이 됩니다.

**미래 요구사항 체크리스트**

* 향후 부하 및 트래픽을 예측하기 위해 잠재적 성장에 대한 정보를 수집합니다.
* 베이스라인 사례로부터 향후 필요한 한도까지 확장할 계획을 도출합니다.
* 예상 성장의 각 단계를 통해 사용자의 기대에 맞는지 확인하기 위해 부하 테스트를 만듭니다.
* 비용을 확인하고 얼마나 절감됐는지 확인하십시오!


**자동 확장을 위한 인프라 설정**

인프라를 클라우드로 이전할 때 얻을 수 있는 엄청난 이점은 인프라를 자동으로 확장 (auto scaling) 할 수 있다는 것입니다. 대부분의 퍼블릭 클라우드 공급자는 초당 요청, CPU 사용률, 시간 일정 또는 이 세 가지 모두의 조합과 같은 특정 조건에 따라 자동으로 확장할 수 있으므로 크기 조정에 대한 추측을 피할 수 있습니다.

Auto-scaling 그룹은 대부분의 클라우드 공급자에서 사용할 수 있습니다. 지정된 구성상의  제한 또는 매개변수를 기반으로 다양한 리소스에 유연성을 제공합니다. 새 인스턴스가 작동하기 전에 구동되는 데 지연이 있기 때문에 모든 문제를 해결하기 위해 자동 크기 조정에 완전히 의존하지 않고, 발생하는 구동 지연에 따라 인스턴스 크기를 조정하는 것이 중요합니다. 예를 들어, AWS에서는 기본적으로 지난 5분 이내의 지표를 기준으로 확장을 계산합니다. 이는 부하의 급증이 소비자의 급증가된 요청의 영향을 줄이기 위해 충분히 적시에 새 리소스로 실행 되지 않을 수 있음을 의미합니다. 대부분의 클라우드 서비스는, 물론 그 자체적인 문제가 있기는 하지만, 보다 즉시적인 반응적 확장을 허용하는 더 짧은 측정 기간(AWS는 1분)을 유료로 제공합니다.

Auto-scaling 그룹의 제한을 설정할 위치를 논의할 때 최소 인프라 요구 사항에 대한 시작점으로 베이스라인을 사용하는 것이 유용합니다. 그런 다음, 예상되는 미래 요구 사항보다 약간 높게 상한선을 설정하십시오.

수평적으로 확장하면 작동 준비가 된 새 인스턴스를 가져오는 데 시간이 지연된다는 문제가 있습니다. 확장은 즉각적이지 않기 때문에 수요를 충족하기 위해 확장에만 의존할 수는 없습니다. 작업을 실행할 수 있는 가장 작은 서버를 선택한 다음 필요에 따라 확장하지 마십시오. 더 나은 방법은, 대부분의 시간 동안 요구 사항을 처리하는 서버 구성을 찾고, 물론 비용을 고려하면서, 최대 피크 때의 활동을 처리할 수 있도록 확장을 설정하는 것입니다. 하루의 운영기간 동안 두 개의 인스턴스에서 최대 10개의 인스턴스로 여러 번 확장하는 경우라면, 위의 첫 번째 지점으로 돌아가 이 새롭게 가진 데이터를 기준으로 베이스라인을  재평가해야 할 때 일 것입니다.

운영 비용을 먹어치우는 또 다른 요소는, 특히 더 크고 비용이 많이 드는 인프라가 필요한 대규모 작업에서 확장 이벤트 중에, 자동 확장 이벤트 시에 아키텍처가 경험하게 되는 안정화 (stabilization) 및 휴지 기간 (cooldown period)입니다. 설정이 서버를 가동하기 시작하면 설정된 일정 기간 동안 활성 상태를 유지합니다. 이것은 때때로 안정화 기간으로 알려져 있는 것입니다. 예를 들어, 구글 클라우드(GCP)는, 이 글의 작성 시점에는, 기본적으로 10분으로 설정됩니다. 따라서, 서버가 가동되어 필요하지 않은 경우에도 GCP에서 10분 동안 실행되어 월별 요금이 추가됩니다. 안정화 기간 이후 서버가 쿨다운되는 휴지 기간은 몇 분 동안 지속될 수 있습니다. 이것 또한 월별 비용에 추가될 수 있습니다. 이러한 이벤트가 여러 확장 그룹에서 발생하면, 하루에 여러 번 발생하면, 월말에는 엄청난 비용에 놀랄 수 있습니다.

자동 크기 조정은 올바르게 사용하면 인상적인 기능이지만 위에서 언급한 함정에 주의하십시오. 계획을 정기적으로 감사하십시오. 더 높은 트래픽과 부하가 발생하면 베이스라인을 높이고 수요를 충족하도록 아키텍처를 확장하십시오.

**오토 스케일링 체크리스트**

* 최소 및 최대 Auto Scaling 요구 사항을 ‘현실적으로’ 살펴보십시오.
* 클라우드 공급자에 맞게 오토 스케일링 조정을 구성하십시오.
* 오토 스케일링 조정이 작동하는지 테스트 하십시오.
* 비즈니스 요구 사항에 따라 주기적으로 Auto Scaling 계획 조정
* 안정화 및 쿨다운 기간의 숨겨진 비용을 조심하십시오.
* 실제 비용을 확인하고 절감액을 점검 하십시오!


**사용량을 모니터링을 통한 비용 절감**

인프라 비용을 절약하고 계획이 제대로 작동하는지 확인하는 가장 좋은 방법은 여러분의 클라우드 공급자가 제공하는 보고서를 확인하는 것입니다. CPU 사용량을 보면 여러분의 추측이 트래픽을 과대평가했는지 여부를 비롯한 추세를 쉽게 확인할 수 있습니다.

사용 통계를 정기적으로 검사하는 것이 좋습니다. 새로운 인프라로 자주 수행한 다음, 시간의 진행에 걸쳐서, 또는 애플리케이션 사용자 또는 사용량이 특정 비율만큼 증가할 때 검사의 간격을 두십시오. 이것은 모두 여러분의 작업 설정 방법과 조직의 요구 사항에 따라 다릅니다. 핵심 사항은 사용량 모니터링이 인프라에 지출하는 비용이 잘 활용되고 있는지 확인하는 효과적인 방법이라는 것입니다.

발생하는 다양한 스케일링 이벤트를 알 수 있도록 알림을 설정할 수도 있습니다. 대부분의 클라우드 공급자는 이러한 알림을 설정할 수 있으며, 이것은 Auto-Scaling 인프라의 상태를 모니터링하는 데 큰 도움이 될 수 있습니다.

훌륭한 모니터링 및 보고의 또 다른 이점은 시스템을 확장하거나 업데이트하고 인프라 계획을 다시 거쳐야 할 때 베이스라인과 향후 요구 사항을 설정하는 데 도움이 되는 훌륭한 계측정보를 얻을 수 있다는 것입니다.

**모니터링 체크리스트**

* 필요하다면, 해당 월의 사용 보고서를 감사하도록 미리 알림을 설정합니다.
* 인프라 확장 이벤트에 대한 알림 설정
* 자문해 보십시오: 과거 사용량을 기준으로 베이스라인 시스템을 상향 조정하거나 하향 조정해야 합니까?
* 모니터링 보고서에 표시되는 추세와 일치하도록 Auto scaling 조정 구성을 변경합니다.
* 실제 비용을 확인하고 절감액을 점검 하십시오!

**Tyk API 게이트웨이에 적용하세요!!**

이제 인프라의 크기 조정을 살펴보았으니, 이 지식을 Tyk API 게이트웨이 인프라에 적용할 차례 입니다. 아래는 AWS 내의 다양한 서버 오퍼링, 상대적 비용 및 여러분이 달성할 수 있는 성능을 개략적으로 보여주는 표 입니다.
![AWS EC2 Specs.png](https://storage.googleapis.com/argo-cms-strapi-upload/AWS_EC_2_Specs_7aa8951dbd/AWS_EC_2_Specs_7aa8951dbd.png)



이제 여러분은 위에서 언급한 전술의 일부 또는 전부를 사용하여 시스템의 다른 구성 요소와 함께 Tyk의 인프라 크기를 정확하게 조정할 수 있습니다.

결론적으로 말하면, 인프라 크기 조정 요구 사항에 대해 현명하고 현실적이 되는 것은 적은 예산을 유지하거나 운영 비용을 줄이는 인상적인 방법입니다. 인프라는 필수입니다. 하지만, 필요하지 않은 것은 어떤 이점도 제공하지 않으면서 조직에 비용을 청구하는 거대한 아키텍처입니다. 적절한 규모의 인프라만 있으면 비즈니스를 성공시키고 성장시킬 수 있습니다.


Tyk Auto Scaling 방법

## 가성비라는 이름의 모호성
화폐경제 내에서 경제주체인 우리는 날 마다 구매의사결정을 합니다. 가정에서의 개인 소비재 구매로부터 직장에서의 대리인으로서 하는 기업의 소부장과 서비스 등 생산재 구매에 이르기 까지 예외가 없습니다. 이 때, 우리는 '가성비'로 대표되는 유무형의 제품 간 비교절차를 거치게 됩니다. 가격 대비 성능 또는, 비용 대비 효과라는 이 '명검 (the rule of thumb)'은 현대인의 인지체계에 부지불식 간에 확실히 자리잡고 있어서 깔끔한 의사결정을 돕는 것으로 생각하지만, 그것의 헛점은 의외로 쉽게 간과되는 듯 보입니다.  
  
IT 업계에서 어떤 제품이나 솔루션을 구매할 때는 해당 제품이 구매 주체인 기업의 니즈에 부합하는 지를 사전에 검증하게 되는데, 그러한 절차를 '개념 증명'이라고 부릅니다.   

이 글에서는 IT 산업 구매의사결정에서 '가성비'에 대한 모호성을 제거하고 조금이라도 나은 선택을 위하여 어떤 의사소통이 필요한 지를 생각해 보려 합니다.  


전자상거래 사이트나 대형 마트의 제품 가격표는 단위당 가격을 표시하고 있습니다.  마트의 육류 가격표는  소비자가 어느 제품의 가격이 낮은 지를 비교하기 쉽게 도와주는 중요한 정보입니다. 육류의 경우에 100g 당 가격이 중요한 정보인 것은 맞지만 현명한 소비자는 원산지도 비교하지 않을까요? 올리브 오일은 100ml 당 가격으로 표시됩니다. 이 경우라면 우리는 제품이 엑스트라 버진인지, 콜드 프레스드 인지를 비교합니다. 이처럼, 숫자로 표시되는 가격 정보는 중요한 정량적 (quantitative) 데이터로서, 다른 연관 데이터는 제품의 성격을 규정하는 정성적 (qualitative) 정보로서 의사결정의 핵심 포인트가 됩니다.  
그런데, 와인은 어떤가요? 액체임에 틀림 없지만, 어디에도 100ml 당 가격을 표시하지 않습니다. 대신에, 그 와인의 주재료인 포도의 종류 및 원산지, 바디, 맛, 숙성 방법 등등 아주 세세한 정성적 정보를 표시하고 있습니다.  

##  IT 제품과 서비스의 구매절차  
SaaS (Software as a Service)가 등장한 이래, 클라우드는 지난 10 여년 에 걸쳐 소프트웨어의 생태계과 유통 구조를 완전히 바꿔 놓았습니다. 제품과 솔루션은, 이제 더 이상 인쇄된 매뉴얼과 함께 패키지 된 상태로 제공되지 않습니다. 대신에, 해당 제품이나 솔루션을 제작사의 웹사이트로부터 다운로드 받고 라이선스 키를 메일로 전달 받는 형식이 대부분입니다. 공산품과 마찬가지로 가격 정보는 벤더를 통하여 쉽게 알 수 있지만, 그 제품의 정성적 (qualitative)인 정보를 얻기는 꽤나 까다롭습니다. 해외 제품인 경우 언어 접근성 등의 여러 원인이 있겠으나, 가장 큰 이유는 제품이나 솔루션이 제공하는 너무도 다양한 기능 때문입니다. 게다가, 그런 제품과 솔루션이 이제는 '정물'이 아니기 때문입니다.  

SaaS의 등장 이전에는 표시된 가격으로 해당 제품의 패키지를 구매하고 나면 해당 제품은 버그 수정을 제외하고는 거의 납품상태 그대로 생명주기를 끝냈던 반면에, 이제는 구독 (subscription) 방식으로 최초 구매 후 매 1년을 기준으로 새로운 상태의 제품을 구매하게 되는 것입니다. 그 뿐 아니라, 좀 더 들여다 보면, 실제로 해당 제품이나 솔루션은 구매된 그 날부터 더 이상 같은 제품이 아닙니다. 소프트웨어 제작사는 끊임없이 기능을 추가하고 개선하면서 중단없이 제품을 바꾸고 있으며, 이는 소프트웨어가 무형의 자산이라는 특성 때문에 태생적으로 유형의 제품과는 다른 영역에 속하는 때문입니다.  

아마존 웹서비스가 정물이 아니라는 데에 다른 의견이 없을 것입니다. 마찬가지로, Tyk (타이크) APIM도 실제로 생물로서 진화하는 것이며, 단지 릴리즈 될 때의 버전 넘버로 대표되는 일련의 스냅샷을 가지는 것 일 뿐, 고객들은 Tyk를 언제든지 인터넷을 통하여 새로운 버전으로 업데이드 할 수 있습니다. 구매할 시점의 아반테가 언제든지, 구매한 라이선스가 만기 도래하기 전에, 제네시스로 바뀔 수 있다는 것을 유념하십시오.  

## 인식의 전환 
변화는 '선형 (linear)' 이라는 말로 대표 됩니다. 어떤 변화가 기존의 틀을 벗어 날 때 우리는 그것을 '이동 (shift)'라고 추상화 합니다. 이동을 넘어 전체 판이 뒤바뀔 때 '패러다임 변화 (paradigm shift)'라고 합니다. Jeff Bezos의 AWS는 인식의 대전환을 요구해 왔고, 더 이상 우리는 클라우드 서비스를 고정된 대상으로 생각하지 않습니다.  이제는 아마존 뿐 아니라, 아무리 작은 스타트 업의 작은 제품, 솔루션, 서비스들이 모두 'API'라고 하는 작은 생명체의 집합이라고 생각해야 할 때 입니다.  

> [아르고 퍼시픽 (Argo Pacific)](https://argopacific.io) 은 Tky의 설립 초기부터 같은 숨을 쉬면서 변화를 수용하며 고객과 함께 리듬을 조율하고 있습니다.   

## 변화된 패러다임에서의 POC  
AWS에서 엄청난 규모의 새로운 서비스를 시도 때도 없이 론칭하는 것이 이제는 그리 놀랍지 않은 일이 되었습니다. Tyk Technologies 사도 APIM을 개선하고 확장시키는 일에 관해서는 뒤지지 않습니다.  

### 여러분들은 어떻게 와인을 고르시나요?  

어떤 맛과 향의 와인을 찾고 계시는지, 구매자인 여러분들을 빼고 나면 누가 알 수 있을까요?  
시장에 API Gateway를 제공하는 개발사는 몇 되지 않습니다. 하지만, 미세한 구성 (configuration)을 통해 서비스 될 수 있는 API 게이트웨이의 조합은 어쩌면 와인의 종류 만큼 다양해 질 수 있습니다. 때문에, API 게이트웨이를 선정하는 작업은 정교해야 합니다.  

제가 굳이 와인을 예로 든 이유는; 첫째, 와인에 대한 자신의 취향을 자신 보다 잘 아는 사람은 없다고 생각하기 때문입니다. 심지어, 최애하던 와인이 엊그제 곁들인 음식과 살짝 안맞던 그런 경험까지 더해지는 경우라면, 숫제, 우리는 소믈리에가 필요한 지경에 이릅니다. 둘째, 바로 이 첫 번째 이유 때문에, 솔루션 제공자와의 지속적인 소통이 너무도 중요한 때문입니다.  

앞에서 언급한 것처럼, Tyk는 지속적으로 무한변신 중 입니다. 단언컨대, 분기 마다 새로운 제품이 릴리즈 되며 새로운 기능과 향상된 퍼포먼스를 탑재하고 있습니다. 이런 변화는 하루가 다르게 바뀌는 기술표준의 진화를 수용하기 위한 Tyk사의 노력의 반영입니다.  진화되고 정제된 기능들을 고객사의 요구사항에 반영시키기 위해서는 제품 도입의 초기단계에서부터 유기적인 커뮤니케이션이 필수입니다.  
여러분들의 취향을 상담하여 주십시오. APIM에 대하여 훨씬 더 정교한 접근법을 제시하여 드리겠습니다.  

### 유감, The  
아시는 분은 이미 아실테지만; 시스템의 고도화나 개편을 위한 프로젝트에서 현재 상황 (As-Is)과 니즈를 모르고는 제대로 된 해결책을 제시하는 것이 어렵습니다. 하지만, 그간의 경험을 비추어 볼 때 중재자로서의 역할은 녹녹치 않았는데, 주된 이유는 As-Is를 알려 주지 않기 때문입니다. 정보 보안의 관점에서 저간의 사정을 짐작은 하지만, 태부족인 정보와 정보공유에 대한 소극적인 접근은 컨설팅에 아주 큰 걸림돌이 되었습니다. 때로는, 이러한 정보의 비대칭성이 조직 내부의 일부 이해당사자의 정보 독점을 초래하여 조직 내에서 대리인 비용을 발생시킴으로써 효율적인 시스템 개편을 방해하는 요소로 작동됩니다. 

새로운 프로젝트의 착수 시에 귀사의 통점 (Pain Points)과 To-Be 요구사항을, 그리고 도입을 검토하기 위한 개념 증명 (POC)의 요구사항을 공유할 수 있어야 문제점을 해결할 수 있습니다. 






개념 증명 (Proof of Concept, POC) 유감

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 Expiry** - 키의 유효기간 설정은 해당 토큰이 만기가 되면 더 이상 요청이 작동되지 않습니다.    

# [따라하기](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)


왜 Tyk (타이크) 인가

API를 설계할 때 개발자들은 누가, 어떤 API를, 언제, 어떤 목적으로 사용하고 있는지를 보여 주게 될 컴포넌트들의 보안 설계에 대하여 반드시 좋은 의사결정을 하여야만 합니다. 이 글에서 API의 보안을 위해 까다로운 역할을 담당하는 컴포넌트들의 내부에 대한 인사이트를 얻기 바랍니다.

보안은 퍼블릭 클라우드에 배포되는 모든 애플리케이션에 대한 비즈니스 요구사항이기 때문에, API 아키텍트들은 클라이언트 애플리케이션에서 다른 사람들이 퍼블릭 API를 사용하게 하려면 반드시 보안이 최고 우선순위가 되게 해야 합니다. 현재, 대부분의 퍼블릭 API는 JSON 또는 XML로 된 REST 기반의 것들입니다. REST, JSON, XML은 유연성과 개방적 태생으로 말미암아 서비스 엔드포인트와 데이터를 위협으로부터 보호하기 위한 핵심적인 보안 설계 고려사항이 되었습니다.

API를 설계할 때 개발자들은 authentication, authorization, monitoring/tracking과 같은 어떤 사용자가 어떤 APIs를 언제, 왜 사용하는지 등을 보여 주는 컴포넌트들의 보안 설계에 대한 좋은 의사결정이 필수적입니다. 

REST API는 HTTP/HTTPS 프로토콜을 통하여 접근되고 데이터 포맷팅에는 JSON과 XML이 사용됩니다. REST는 GET (read or list), POST (create), PUT (update)와 DELETE (delete)의 기본적인 actions를 수행합니다. 

설계에 있어서 API 엔드포인트를 안전하게 하는 첫 번째 단계는 노출된 어떤 actions를 보안할 필요가 있는지를 결정하는 일입니다. 보안 설계는 아키텍트들이 authentication, authorization과 session state를 보호할 방법을 고려할 것을 요구합니다. 어떤 API 설계에 보안을 추가하면 IT 또는 DevOps에 맞추어 개발 자원을 소유하고 그 API를 제어하는 것이 가능해집니다. 또, 그것은 IT와 DevOps 자원을 조직이 공개한 개별 퍼블릭 API를 추적하는 것 보다 좀 더 상위 레벨의 보안 우려사항들에 집중할 수 있게 해 줍니다. 


**인증과 API 키 (Authentication and API Keys)**



개발자나 아키텍트가 REST API를 설계할 때 그것이 오직 인증되고 (authenticated) 허용된 (authorized) 사용자들만 action을 수행할 수 있게 하는 것이 아주 중요합니다.

HMAC (Hash-based message authentication code)는 서버와 클라이언트에 각각 public 키와 private 키를 제공하므로, 이를 해결하는 방법이 될 수 있습니다. public 키는 알려진 것이고, private 키는 오직 해당 서버와 클라이언트에만 저장된 것입니다. 클라이언트는, 서버에 대한 매 요청 마다 그 요청 데이터를 정렬 (combing)하고 해싱하여 private 키와 함께 서버로 보내는 요청의 일부로서 unique HMAC 또는 hash를 생성합니다. 해당 서버는 보내진 요청을 접수하고 그 자신만의 unique HMAC를 재생성 합니다. 서버는 또 이 두 개의 HMACs를 비교하고, 두 개가 동일하면 클라이언트는 신뢰되어 그 요청이 실행됩니다. 이 과정은 secret handshake로 자주 불려집니다.

다른 선택 방안 하나는 해당 API 내에서 open authorization (OAuth)를 JSON Web token (JWT)와 함께 사용하는 것입니다. 전형적으로, OAuth는 네 가지의 역할들을 구체적으로 명시합니다: resource owner, client, resource server, authorization server 가 그것들입니다. 어떤 API를 사용하는 각 클라이언트는 인증 (authentication)을 위한 JWT 안에 내장된 unique API 키를 받습니다. 

위의 두 가지 방법 다 API 인증에 대한 보안을 제공하지만, 둘 다 설치가 복잡합니다. 개발자와 아키텍트 또는 DevOps의 선호도에 따라 어떤 조직의 선택 방안이 결정될 것입니다. 


**Public API의 허가 (Authorization of public APIs)**


허가는 예닐곱 개의 모델을 통하여 가능하지만 HTTP를 보호하는 방법들과 whitelisting이 선호되며, 보안지능시스템 (security intelligence system)을 가지고 모니터링을 하는데도 사용될 수 있습니다. 

REST API를 가지고 HTTP를 보호하는 것은 REST action (GET, POST, PUT, and DELETE)에 대한 사용자의 권한을 설정합니다는 것을 의미합니다. 모든 사용자가 각 API에 대한 모든 action에 대한 접근이 필요한 것은 아니다. 허가를 기반으로 하여 사용자의 권한 수준을 설정하는 것은 예를 들면, 오직 DELETE가 허가된 사용자들만 실제로 데이터 레코드를 지울 수 있습니다는 것을 의미합니다. 최소한 대부분의 사용자들은 레코드나 정보의 목록에 대한 접근을 할 수 있어야 할 것입니다. 해당 API 클라이언트 약관이나 조직의 사용 약관에 근거하여 몇몇 사용자들은 데이터 레코드의 생성과 갱신에 대하여 허용 될 수도 있을 것입니다.

허가 (authorization)을 통한 HTTP 메소드 접근 권한 부여는 사용자에게만 적용 될 수 있는 것이 아니다; 이 방법은 자원 수집 (resource collections)에도 적용될 수 있습니다 권한이나 한 사용자의 역할을 기반으로 허가를 설정하는 것은 비교적 일상적인 것이지만 API의 엔드포인트 보안에 포함되는 효과적인 레이어 입니다.

메소드들을 Whitelisting 하는 것이 다른 대안입니다. 화이트리스팅은 URL을 기반으로 허가 (authorization)를 허용합니다. 메소드들은 GET, POST, PUT 그리고 DELETE로 똑 같지만, 그 메소드들의 사용은 URL이 화이트리스트 (각 URL 별로 할당된 허락된 actions의 세트를 가지고 있음)에 있는지에 따라서 제한됩니다. 만약 그 URL이 그 리스트에 없다면 403-Forbidden과 같은 에러 코드로 응답됩니다. 이 방법을 쓸 때는 서버와 시스템 정보가 표준 에러 메시지로부터 제거 된 것을 확실히 할 것을 권고합니다. 그래야 내부 시스템 정보가 표출되는 것을 막을 수 있습니다.

메소드 화이트리스팅을 사용하면 접근 로그를 통하여 모니터링 할 수 있고 데이터가 로그 내에서 또는 보안지능시스템에 의하여 추적될 수 있습니다는 유리한 장점이 있습니다. 


**세션 상태의 보호 (Protecting session states)**

대부분의 웹 서비스들과 APIs는 state blob가 해당 트랜잭션 내에서 보내지도록 하여 stateless로 설계됩니다. 더 안전한 설계를 위해서, 해당 API가 server-side cache를 사용하는 경우라면 API 키를 클라이언트의 state에서 유지하는 것을 고려해 보라. 이 방법은 웹 애플리케이션에서 흔히 사용되는 것이고, 이것은 anti-replay를 방지하는 추가적인 보안을 제공합니다. Anti-replay는 공격자가 허가된 사용자가 되려고 blob을 copy-paste하는 곳입니다. 효과적 이려면 API 키, 날짜, 시간, 그리고 들어오는 IP 주소에 대하여 작동하는 시간이 제한된 암호 키를 포함하도록 하세요. 

효과적인 보안의 핵심은 활동적인 모니터링과 결합된 계층화 (layering)를 하는 것입니다. 계층화는 하나가 기능을 제대로 수행하지 못할 경우에 하나 또는 그 이상의 백업 시스템을 제공합니다. 데이터와 접근은 다음 레이어에 의해서 여전히 보호됩니다. API에 대한 활동 모니터링은 조직이 그 API에 대한 제어를 확보하고 그것이 원래의 계약과 사용 약관을 일관되게 준수하는 것을 보증하며, 조직의 또는 API 사용자 시스템의 접근 포인트로 들어 오지 못하게 해 줍니다. 

API 아키텍트는 반드시 API 엔드포인트가 퍼블릭 API의 시작점부터 그 조직과 사용자들에게 최대가치를 제공하도록 설계하여야 하고, 개발팀 내에서 보안에 대한 소유권을 이양하여야 합니다. 비록 어떤 API가 비밀 데이터나 보호된 정보의 공통 양식에 연결 또는 전달하는 것이 아니라 하더라도, API 엔드포인트들은 해커들의 접근 지점들이며 네트워크와 데이터에 대한 비인가된 접근을 획득하기 위한 엔진으로 사용되어 왔다. 엔드포인트 보안은 비즈니스와 그에 관련된 고객들에게 안전한 보호구를 제공해 줍니다. 


검색 결과 - 21/21