이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.
Apigee Edge 문서 보기
조직은 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를 테스트하기 위한 임시 셀프서비스 조직입니다. 평가 조직이라고도 하는 이러한 조직에는 시간 제한이 있으며 프로덕션 조직의 확장성과 유연성이 부족합니다.
또한 평가 및 유료 조직 비교를 참조하세요.
평가 조직 수명
평가 조직에는 수명이 제한되어 있습니다.
- 0일: 평가 조직을 만듭니다.
- 30일: Google에서는 예정된 평가 만료에 대한 경고가 포함된 이메일 알림을 보냅니다.
- 60일: Google에서는 평가 조직을 삭제합니다.
조직 구성요소
다음 이미지는 Apigee 조직 모델의 주요 구성요소를 보여줍니다. 이 모델은 API, API 제품, 앱, 앱 개발자가 모두 Apigee 내에서 어떻게 연결되는지 정의합니다.
이 모델에는 Apigee의 모든 기능이 표시되지는 않지만 조직이 배포의 루트임을 알 수 있습니다.
다음 표에서는 조직 모델의 구성요소를 자세히 설명합니다.
| 구성요소 | 설명 |
|---|---|
| 조직 |
모든 Apigee 조직은 정확히 Google Cloud 프로젝트 하나에 속하며 한 프로젝트에는 조직이 최대 1개까지 포함될 수 있습니다. 조직에는 환경, API 프록시, API 제품, API 패키지, 앱, 사용자가 포함됩니다. 계정 소유자는 단일 조직에 제한되지 않습니다. 일부 계정 소유자는 여러 앱 개발자 커뮤니티를 지원하는 여러 조직을 정의하거나 구성원일 수 있습니다. |
| 환경 및 환경 그룹 | 환경은 API 프록시를 배포하는 조직 내에 있는 격리된 소프트웨어 환경입니다. 한 조직에 환경을 여러 개 만들 수 있습니다. 환경 그룹은 호스트 이름이 하나 이상 있는 환경의 그룹입니다. 호스트 이름은 환경 그룹의 모든 환경에 배포된 API 프록시를 호출하는 데 사용되는 URL의 일부입니다. |
|
API 프록시 |
API 프록시는 수신 요청과 백엔드 서비스 간의 인터페이스입니다. 프록시 항목은 Apigee가 클라이언트의 요청과 백엔드의 응답을 처리할 때 실행하는 지침과 정책을 포함합니다. |
|
API 제품 |
API 게시를 위한 항목입니다. API 제품은 외부 개발자가 사용할 수 있도록 개발자 포털에 게시됩니다. API 제품은 하나 이상의 게시된 API에 액세스하는 인터페이스를 제공합니다. OpenAPI 사양을 사용하여 설명할 수 있는 인터페이스에는 하나 이상의 API 프록시에서 처리하는 하나 이상의 API 요청이 조합되어 포함될 수 있습니다. 조직의 사용자가 API 제품을 만듭니다. 이 과정에서 각 API 제품에 임의의 메타데이터를 연결할 수 있습니다. 흔히 사용되는 메타데이터 유형 중 하나로서 API 호출에 대한 액세스 한도를 지정하고, 보안 요구사항을 규정하고, 모니터링 및 분석을 허용하고, 추가 기능을 제공하는 서비스 요금제를 정의할 수 있습니다. Apigee는 API 제품의 분석을 위한 데이터를 수집합니다. |
|
API 공급업체 |
API 프록시 및 제품을 만들고 관리하는 개인 또는 항목입니다. 클라이언트 앱 개발자는 이렇게 게시된 API에 액세스합니다. |
|
앱 개발자 |
조직에는 조직에서 정의한 API(API 제품으로 게시됨)를 사용하는 앱을 빌드하는 개발자 한 명 이상이 포함됩니다. 개발자는 API를 사용하지만, 조직에서 API를 만들거나 다른 작업을 수행할 수는 없습니다. 개발자는 회사 내부 인력일 수도 있고, 파트너일 수도 있고, API 액세스 비용을 지불하거나 지불하지 않는 외부 개발자일 수도 있습니다. 개발자를 API 사용 고객이라고 생각하면 됩니다. 개발자가 앱을 등록하고 API 키를 받은 후 API에 액세스하려면 개발자가 조직에 등록되어 있어야 합니다. 조직에서 개발자를 추가, 업데이트 또는 삭제하는 방법은 API 제공업체가 결정합니다. UI를 통해 수동으로 추가하거나, 웹사이트를 통해 등록할 개발자 포털을 만들거나, Apigee API를 사용하여 자체 등록 메커니즘을 정의할 수 있습니다. |
|
Apigee 앱(또는 앱) |
개발자가 API를 사용하는 하나 이상의 클라이언트 앱을 만듭니다. 사용자 인증 정보 확인(예: API 키 또는 OAuth 토큰)이 필요한 API를 호출하는 클라이언트 애플리케이션을 만드는 개발자는 먼저 조직에 앱 등록을 만들어야 합니다. 앱 등록을 통해 클라이언트 애플리케이션이 API를 호출할 때 사용해야 하는 API 키, 키/보안 비밀 쌍 또는 기타 사용자 인증 정보가 개발자에게 제공됩니다. 모든 앱이 조직에 등록되었으므로 Apigee를 사용하여 앱과 API 사용에 대한 분석 정보를 모니터링하고 수집할 수 있습니다. |
표시되지 않는 Apigee의 추가 구성요소는 API 키와 OAuth 토큰입니다.
Apigee에서는 간단한 API 키, 2-legged OAuth, 3-legged OAuth 등 여러 유형의 인증을 지원합니다.
API 제공업체에서 API 키 확인을 승인 메커니즘으로 지정하면 클라이언트 애플리케이션은 API를 요청할 때마다 API 키를 전달해야 합니다. 이 키가 유효하면 Apigee가 요청을 허용합니다. 또는 API 제공업체가 OAuth 토큰 확인을 승인 메커니즘으로 지정하면 클라이언트 애플리케이션은 먼저 OAuth 토큰을 가져온 다음 API를 요청할 때마다 해당 토큰을 전달해야 합니다. 이 토큰이 유효하면 Apigee가 요청을 허용합니다. 다른 커스텀 승인 스키마도 가능합니다.
API 제공업체는 개발자가 앱을 등록하는 방법을 정의해야 합니다. 각 앱 등록에는 하나 이상의 키 또는 사용자 인증 정보가 연결됩니다. 개발자가 개발자 포털을 통해 자신의 애플리케이션을 등록하도록 허용하면 개발자가 편리한 셀프서비스 환경을 통해 API에 액세스하는 데 필요한 키 또는 사용자 인증 정보를 검색할 수 있습니다.
앱 등록 시점에 개발자는 단일 API 제품 또는 여러 API 제품에 액세스하도록 선택할 수 있습니다. 개발자의 앱은 동일한 키/사용자 인증 정보를 사용하여 앱과 연결된 모든 API 제품에 액세스합니다.
언제든지 키를 취소하여 개발자의 앱이 더 이상 API에 액세스할 수 없도록 할 수 있습니다(개발자 앱의 등록된 표현은 조직에 여전히 존재함). 개발자가 특정 시간 후에 키를 새로고침해야 하도록 키에 만료를 정의할 수도 있습니다.
Apigee 사용자
Apigee 사용자는 관리자, API 프록시, API 제품 생성자, 분석 및 기타 통계를 모니터링하는 사용자 등을 포함할 수 있는 조직의 API팀을 구성합니다. 최종 사용자는 Apigee 개발자가 빌드하는 앱을 사용하는 사람입니다. 대부분의 경우 이 문서에서는 Apigee 사용자를 나타내기 위해 '사용자'라는 용어를 사용합니다.
관리자는 조직에 사용자를 추가할 수 있습니다.
사용자마다 다른 역할과 액세스 권한을 가질 수 있습니다. 예를 들어 조직 및 조직 구성요소를 수정하는 권한을 가진 사용자를 조직 관리자 및 작업 관리자로 정의합니다. API 프록시 및 API 제품을 만들 수 있는 권한이 있지만 다른 사용자를 수정할 수 있는 권한이 없는 다른 사용자를 정의합니다.
사용자는 여러 조직의 구성원일 수 있습니다. 예를 들어 회사에서 Apigee에 여러 조직을 정의하여 서로 다른 개발자 커뮤니티를 지원하면서 내부적으로는 모든 조직에 속하는 동일한 인원이 모든 API 프록시와 API 제품을 빌드할 수 있습니다.
사용자가 되기 위해 Apigee 조직을 만들 필요는 없습니다. 관리자는 사용자를 기존 조직에 추가할 수 있습니다.
모든 사용자는 다음 페이지에서 Apigee에 로그인합니다. Apigee UI
자격
조직 권한은 유료 조직이 구독 또는 사용한 만큼만 지불 가격 책정 모델을 사용하는지 여부에 따라 다릅니다.
구독 권한
조직: 조직 사용 권한은 단위로 표현됩니다. 조직 단위 사용 권한을 획득하면 이 권한을 사용하여 원하는 리전에 새 조직 하나를 사용 설정하거나 기존 조직을 새 리전 하나로 확장(도메인 이름 확장 사용)할 수 있습니다. 사용 권한의 목적에 따라 N개 리전의 조직은 조직 단위 N개를 사용합니다. 예를 들어 새 조직 단위 4개를 구매하면 다음을 수행할 수 있습니다.
- 기존 조직을 새 리전 4개로 확장
- 또는 기존 조직 2개를 각각 새 리전 2개로 확장
- 각각 리전 하나에서 사용 가능한 새 조직 4개 생성
총 조직 단위 사용 권한은 구독 계층과 관련 조직 팩의 합계입니다.
환경: 환경 사용 권한도 단위로 표현됩니다. 조직 사용 권한과 무관하며 다르게 작동합니다. 환경 단위 사용 권한을 사용하는 프로세스는 먼저 환경을 만든 후 해당 환경을 조직에 연결하는 2단계 프로세스입니다. 환경이 조직에 연결될 때 환경 단위 사용 권한이 차감됩니다.
환경 단위 사용량은 모든 조직에서 각 리전에 사용되는 환경 수로 계산됩니다. 즉, 한 조직의 두 리전에 프로비저닝된 환경은 사용 권한에서 환경 단위 2개를 사용합니다.
총 환경 단위 사용 권한은 구독 계층에 제공된 사용 권한과 환경 또는 조직 팩을 통해 추가로 획득한 사용 권한의 합계입니다. 조직 팩을 구매하면 조직 단위 하나와 환경 단위 여러 개가 제공됩니다. 조직 팩을 통해 추가된 환경 단위 사용 권한은 사용자가 만들거나 확장하도록 선택한 조직과 무관합니다. 조직 팩을 통해 추가된 환경 단위 사용 권한은 총 환경 단위 사용 권한에 단순히 합산됩니다. 조직 단위를 추가로 구매하지 않고 환경 단위를 추가하려면 환경 팩을 구입하면 됩니다.
자세한 내용은 구독 권한을 참조하세요.
사용한 만큼만 지불 권한
조직: 사용한 만큼만 지불 가격 책정 모델은 계정 소유자에게 단일 조직에 대한 권한을 부여합니다.
환경: 환경 사용 권한은 조직 사용 권한과 무관합니다. 또한 이를 사용하는 데에는 환경을 먼저 생성하고 해당 환경을 조직에 연결하는 2단계 프로세스가 있다는 점에서 조직 사용 권한과 다르게 작동합니다. 환경은 조직에 연결될 때까지 사용 권한 한도에 포함되지 않습니다.
다시 말해서 사용 권한에 합산되는 환경 수는 조직에 연결된 환경 수입니다.
사용한 만큼만 지불 가격 책정 모델에는 모든 리전에서 85개 환경의 사용 권한이 포함됩니다.
자세한 내용은 사용한 만큼만 지불 권한을 참조하세요.