조직 이해

조직은 Apigee의 최상위 컨테이너입니다. 여기에는 모든 API 프록시 및 관련 리소스가 포함됩니다. 이 주제의 나머지 부분에서는 조직에 대해 좀 더 깊게 다루며 몇 가지 유용한 점은 다음과 같습니다.

  • 만든 뒤에 조직 이름은 변경할 수 없습니다.
  • 조직 이름은 Apigee UI의 URL에 있습니다. 예를 들면 다음과 같습니다.
    https://apigee.google.com/organizations/org_id
  • Apigee API를 사용해 호출을 수행하는 경우 조직은 대부분의 호출에서 경로의 필수 부분입니다. 예를 들어 다음 curl 요청은 Organizations API를 사용하여 조직의 모든 API 프록시 목록을 반환합니다.
    curl https://apigee.googleapis.com/v1/organizations/your_org_id/apis
  • 하나의 조직만 만들 수 있지만 다른 권한을 가진 사용자 또는 관리자로 다른 조직에 속할 수 있습니다. 조직 간 전환에 설명된 대로 다른 조직으로 전환할 수 있습니다.
  • Apigee 조직Google Cloud 조직과 다릅니다. 모호성을 가질 수 있으므로 이 문서에서 '조직'은 Apigee 조직을 의미합니다.

동영상: 조직에서 API 관리를 위한 멀티테넌시 아키텍처를 지원하는 방법을 알아보려면 짧은 동영상을 시청하세요.

조직 유형

조직에는 두 가지 유형이 있습니다.

  • 유료: 완전한 확장성을 갖춘 영구 조직입니다. 프로덕션 조직이라고도 합니다. 유료 조직을 만들려면 Apigee와의 계약이 필요합니다.

    Apigee는 개요 및 기본 요건에 설명된 대로 이러한 종류의 조직을 만들 수 있도록 계약별로 사용 권한을 부여합니다.

  • 평가: Apigee를 테스트하기 위한 임시 셀프서비스 조직입니다. 평가 조직이라고도 하는 이러한 조직에는 시간 제한이 있으며 프로덕션 조직의 확장성과 유연성이 부족합니다.

    평가 조직 만들기에 설명된 대로 자격 없이 자체 평가 조직을 만들거나 프로비저닝합니다.

평가 조직 수명

평가 조직에는 수명이 제한되어 있습니다.

  1. 0일: 평가 조직을 만듭니다.
  2. 30일: Google에서는 예정된 평가 만료에 대한 경고가 포함된 이메일 알림을 보냅니다.
  3. 60일: Google에서는 평가 조직을 삭제합니다.

평가 및 유료 조직 비교

유료 및 평가 조직 모두 모든 기능을 이용할 수 있습니다. 차이점은 주로 다음 표와 같이 확장성과 인프라 허용성에 있습니다.

함수 조직 유형 설명
유료/프로덕션 평가
수명 계약 기반 60일 평가 조직의 경우 30일이 지나면 수명에 제한이 있다는 알림을 받습니다. 60일이 지나면 Google에서 평가 조직을 삭제합니다. 수명을 연장할 수는 없습니다.
VPC 피어링이 필요한가요? 둘 모두 VPC 피어링이 필요합니다.
프록시 액세스 외부 또는 비공개/로컬 액세스 외부 또는 비공개/로컬 액세스 기본적으로 API 프록시는 내부적으로만 액세스할 수 있습니다. API 프록시를 런타임에 배포한 후에는 네트워크 내에 새 VM을 만든 다음 해당 VM에서 요청을 보내야 합니다. 프로덕션 및 평가 조직 모두에 이 작업을 수행할 수 있습니다.
지원되는 인스턴스 계약 기반 1 런타임 인스턴스 수입니다.
런타임 내결함성 리전 영역

평가 조직의 런타임은 단일 영역에서만 실행되며 해당 영역이 다운될 경우 평가 조직을 사용할 수 없게 됩니다.

프로덕션 조직의 런타임은 리전 클러스터링을 사용합니다. 즉, 영역이 다운되면 Apigee가 리전 내 다른 영역의 런타임으로 요청을 다시 라우팅할 수 있습니다.

리전 및 영역에 대한 자세한 내용은 리전 및 영역을 참조하세요.

확장성 및 크기 조정 평가 조직에는 인프라가 제한되어 있습니다. 성능/부하 테스트에 적합하지 않습니다.

자세한 내용은 Apigee 가격 책정을 참조하세요.

조직 구성요소

다음 이미지는 Apigee 조직 모델의 주요 구성요소를 보여줍니다. 이 모델은 API, API 제품, 앱, 앱 개발자가 모두 Apigee 내에서 어떻게 연결되는지 정의합니다.

조직을 Apigee 배포의 루트로 보여주는 계층적 다이어그램

이 모델에는 Apigee의 모든 기능이 표시되지는 않지만 조직이 배포의 루트임을 알 수 있습니다.

다음 표에서는 조직 모델의 구성요소를 자세히 설명합니다.

구성요소 설명
조직

모든 Google Cloud 계정은 조직 하나에 매핑됩니다. 조직에는 모든 환경 및 API 프록시, API 제품, API 패키지, 앱, 사용자에 대한 표현이 포함됩니다.

계정 소유자는 단일 조직에 제한되지 않습니다. 일부 계정 소유자는 여러 앱 개발자 커뮤니티를 지원하는 여러 조직을 정의하거나 구성원일 수 있습니다.

환경 및 환경 그룹 조직의 API 프록시 런타임 실행 컨텍스트입니다. 자세한 내용은 환경 및 환경 그룹 정보를 참조하세요.

API 프록시

API 프록시는 공개적으로 사용 가능한 HTTP 엔드포인트의 백엔드 서비스에 대한 매핑을 정의합니다. 또한 API 프록시가 요청, 응답, 서비스 콜아웃에 대해 보안(예: OAuth)을 포함하고, 메시지 변환(예: XML에서 JSON으로)을 수행하고, 트래픽을 백엔드 서비스로 제한하고, 요청에 대한 다른 유용한 작업을 수행하도록 구성할 수 있습니다.

조직의 사용자는 API 프록시를 하나 이상 만듭니다.

Google에서는 API 프록시에 대한 분석 데이터를 수집합니다.

API 제품

서비스 계획과 결합된 API 프록시 번들입니다. 이 서비스 계획은 API 프록시에 대한 액세스 한도를 지정하고, 보안을 제공하고, 모니터링 및 분석을 허용하고, 추가 기능을 제공할 수 있습니다.

조직의 사용자가 API 제품을 만듭니다.

Apigee는 API 제품의 분석을 위한 데이터를 수집합니다.

API 공급업체

API 프록시를 만들고 관리하는 항목입니다. 클라이언트 앱 개발자는 API 프록시에 액세스합니다.

앱 개발자

조직에는 조직에서 정의한 API(API 제품에 어셈블됨)를 사용하는 앱을 빌드하는 개발자 한 명 이상이 포함됩니다. 개발자는 API를 사용하지만, 조직에서 API를 만들거나 다른 작업을 수행할 수는 없습니다.

개발자는 회사 내부에 있을 수 있고, 파트너일 수 있고, API 액세스 권한에 대해 비용을 지불하는 외부 개발자일 수 있습니다. 일부 개발자를 고객이라고 생각하면 됩니다.

개발자가 앱을 등록하고 API 키를 받은 후 API에 액세스하려면 개발자가 조직에 등록되어 있어야 합니다. 조직에서 개발자를 추가, 업데이트 또는 삭제하는 방법은 API 제공업체가 결정합니다. UI를 통해 수동으로 추가하거나, 웹사이트를 통해 등록할 개발자 포털을 만들거나, Apigee API를 사용하여 자체 등록 메커니즘을 정의할 수 있습니다.

Apigee 앱(또는 앱)

개발자가 API를 사용하는 하나 이상의 클라이언트 앱을 만듭니다.

개발자는 조직에 앱을 등록해야 합니다. 앱은 API에 대한 모든 요청을 전달할 API 키를 개발자에게 제공하는 실제 개발자 앱의 표현입니다.

모든 앱이 조직에 등록되었으므로 Apigee를 사용하여 앱과 API 사용에 대한 분석 정보를 모니터링하고 수집할 수 있습니다.

표시되지 않는 Apigee의 추가 구성요소는 API 키와 OAuth 토큰입니다.

API에 대해 정의한 승인 메커니즘에 따라 Apigee 앱은 API에 대한 모든 요청이 포함된 API 키를 전달합니다. 이 키가 유효하면 요청이 허용됩니다.

Apigee에서는 간단한 API 키, 2-legged OAuth, 3-legged OAuth 등 여러 유형의 인증을 지원합니다.

API 제공업체는 개발자가 앱을 등록하는 방법을 정의해야 합니다. 이렇게 하려면 개발자에게 API에 액세스하는 데 필요한 키를 반환하는 앱을 등록하면 됩니다.

앱 등록 시점에 개발자는 단일 API 제품 또는 여러 API 제품에 액세스하도록 선택할 수 있습니다. 개발자 앱은 동일한 키를 사용하여 앱과 연결된 모든 API 제품에 액세스합니다(Apigee에서 개발자 앱의 등록된 표현).

언제든지 키를 취소하여 개발자의 앱이 더 이상 API에 액세스할 수 없도록 할 수 있습니다(개발자 앱의 등록된 표현은 조직에 여전히 존재함). 또는 개발자가 특정 시간 후에 키를 새로 고침하도록 키에 시간 한도를 정의할 수 있습니다.

Apigee 사용자

Apigee 사용자는 관리자, API 프록시, API 제품 생성자, 분석 및 기타 통계를 모니터링하는 사용자 등을 포함할 수 있는 조직의 API팀을 구성합니다. 최종 사용자는 Apigee 개발자가 빌드하는 앱을 사용하는 사람입니다. 대부분의 경우 이 문서에서는 Apigee 사용자를 나타내기 위해 '사용자'라는 용어를 사용합니다.

관리자는 더 많은 사용자를 만들 수 있습니다.

사용자마다 다른 역할과 액세스 권한을 가질 수 있습니다. 예를 들어 조직 및 조직 구성요소를 수정하는 권한을 가진 사용자를 조직 관리자 및 작업 관리자로 정의합니다. API 프록시 및 API 제품을 만들 수 있는 권한이 있지만 다른 사용자를 수정할 수 있는 권한이 없는 다른 사용자를 정의합니다.

사용자는 여러 조직의 구성원일 수 있습니다. 예를 들어 회사는 Apigee에 여러 조직을 정의하여 여러 개발자 커뮤니티를 지원할 수 있습니다. 내부적으로는 같은 사용자가 모든 API 프록시 및 API 제품을 빌드하므로 모든 조직의 구성원입니다.

사용자가 되기 위해 Apigee 계정(즉, Apigee 조직)을 만들 필요는 없습니다. 관리자는 사용자를 기존 조직에 추가할 수 있습니다.

모든 사용자는 다음 페이지에서 Apigee에 로그인합니다. Apigee UI

자격

조직: 새 조직에 사용 권한을 부여하면 이를 원하는 리전의 새 조직으로 사용하거나 기존 조직을 새 리전으로 확장(도메인 이름 확장 사용)할 수 있습니다. 예를 들어 새 조직을 4개 구매하면 기존 조직 하나를 4개의 새 리전으로 확장할 수 있습니다. 사용 권한의 목적에 따라 두 리전의 조직 하나가 2개 조직에 해당합니다.

총 조직 사용 권한은 구독 계층과 관련 조직 팩의 합계입니다.

환경: 환경 사용 권한은 조직 사용 권한과 무관합니다. 또한 이를 사용하는 데에는 환경을 먼저 생성하고 해당 환경을 조직에 연결하는 2단계 프로세스가 있다는 점에서 조직 사용 권한과 다르게 작동합니다. 환경은 조직에 연결될 때까지 사용 권한 한도에 포함되지 않습니다.

다시 말해서 사용 권한에 합산되는 환경 수는 조직에 연결된 환경 수입니다.

총 환경 사용 권한은 구독 계층과 관련 팩의 합계입니다. 조직 팩에서 추가된 환경은 모두 독립적이며 새 조직에 연결되지 않습니다. 총 환경 사용 권한에 추가됩니다.

환경 사용량은 모든 조직과 각 리전에서 사용되는 환경 수입니다. 즉, 한 조직의 두 리전에서 프로비저닝되는 환경 하나가 사용 권한 한도에 2개 환경으로 반영됩니다.

추가 조직을 구매하지 않고 환경을 추가하려면 환경 팩을 구입하면 됩니다.