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")  
                


Reqs를 여러 개의 다른 백엔드 엔드포인트로 포워딩 하기

오픈 뱅킹의 개념은 수  년 동안 존재해 왔지만 업계는 대부분, 특별한 이유가 있어서가 아니라, 규정 준수를 위해 이를 지지했습니다. 그러나 팬데믹이 초래되면서 전 세계적으로 오픈 뱅킹 접근 방식과 수용이 결정적이고 신속하게 채택되었습니다. 예를 들어, 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가 필요)   


Leading Tyk Partner in South Korea

Latest Posts

K8s 기본 빌딩 블럭

K8s 클러스터 아키텍처

Reqs를 여러 개의 다른 백엔드 엔드포인트로 포워딩 하기

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

Tyk 멀티테넌시 (Multi-tenancy)

Tyk API Gateway
Licenses

Launch

Flex

Multi-Team

Global Multi-Team

Leading Tyk Partner in South Korea

Latest Posts

K8s 기본 빌딩 블럭

K8s 클러스터 아키텍처

Reqs를 여러 개의 다른 백엔드 엔드포인트로 포워딩 하기

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

Tyk 멀티테넌시 (Multi-tenancy)

Tyk API Gateway Licenses

Launch

Flex

Multi-Team

Global Multi-Team

Tyk API Gateway
Licenses