このページの内容は Apigee と Apigee ハイブリッドに該当します。
Apigee Edge のドキュメントを表示する
組織は、Apigee Edge の最上位コンテナです。組織にはすべての API プロキシと関連リソースが含まれています。このトピックの残りの部分では組織について詳しく解説しますが、ここではいくつかの実践的なポイントを紹介します。
- 作成した組織名は、変更できません。
- 組織名は、Apigee UI の URL に含まれます。次に例を示します。
https://apigee.google.com/organizations/ORG_ID
- Apigee API を使用して呼び出しを行う場合、組織はほとんどの呼び出しでパスに必須の要素となります。たとえば、次の
curlリクエストは、組織 API を使用する組織内のすべての API プロキシのリストを返します。curl https://apigee.googleapis.com/v1/organizations/YOUR_ORG_ID/apis
- 組織を 1 つしか作成していない場合でも、特定の権限を持つユーザーまたは管理者として他の組織に所属できます。別の組織に切り替えるには、組織の切り替えをご覧ください。
- Apigee 組織は、Google Cloud 組織とは異なります。どちらとも取れる場合、このドキュメントにおける「組織」は Apigee 組織を指します。
動画: 組織により、API 管理のマルチテナンシー アーキテクチャがどのようにサポートされるかについての短い動画をご覧ください。
組織の種類
組織には、次の 2 種類があります。
有料: 完全なスケーラビリティを備えた永続的な組織。本番環境組織とも呼ばれます。有料組織には、サブスクリプションまたは従量課金制の Apigee 料金モデルの一部として作成された組織が含まれます。
評価: Apigee をテストするための一時的なセルフサービスの組織。この組織は「評価組織」とも呼ばれます。時限的であり、本番環境組織のようなスケーラビリティと柔軟性はありません。
評価組織と有料組織の比較もご覧ください。
評価組織の存続期間
評価組織の存続期間は限られています。
- 0 日目: 評価組織を作成します。
- 30 日目: Google により、評価の有効期限が近づいていることを知らせるメール通知が送信されます。
- 60 日目: Google により、評価組織が削除されます。
組織のコンポーネント
次の図では、Apigee 組織モデルの主要コンポーネントを示します。このモデルは、API、API プロダクト、アプリ、アプリ開発者が Apigee 内でどのように関係しているかを定義しています。
この図は Apigee のすべての機能を示しているわけではありませんが、この図から、組織がデプロイの root であることがわかります。
次の表では、組織モデルのコンポーネントの詳細を説明します。
| コンポーネント | 説明 |
|---|---|
| 組織 |
各 Apigee 組織は 1 つの Google Cloud プロジェクトに属し、1 つのプロジェクトには最大 1 つまでの組織しか含めることができません。組織には、環境、API プロキシ、API プロダクト、API パッケージ、アプリ、ユーザーが含まれます。 アカウント所有者は、1 つの組織に制限されません。アカウント所有者は、異なるアプリ開発者コミュニティをサポートする複数の組織のメンバーを定義すること、またはそうしたメンバーが該当することがあります。 |
| 環境と環境グループ | 環境は、API プロキシをデプロイする組織内の分離されたソフトウェア環境です。1 つの組織に複数の環境を作成できます。 環境グループは、1 つ以上のホスト名を持つ環境のグループです。ホスト名は、環境グループ内の任意の環境にデプロイされた API プロキシの呼び出しに使用される URL の一部です。 |
|
API プロキシ |
API プロキシは、受信リクエストとバックエンド サービスの間のインターフェースです。プロキシ エンティティには、クライアントからのリクエストとバックエンドからのレスポンスを処理する際に Apigee が実行する手順とポリシーが含まれます。 |
|
API プロダクト |
API を公開するためのエンティティ。API プロダクトは、外部のデベロッパーが使用できるようにデベロッパー ポータルに公開されます。API プロダクトは、1 つ以上の公開 API にアクセスするためのインターフェースを提供します。インターフェース（OpenAPI 仕様を使用して記述できます）には、1 つ以上の API プロキシによって処理される 1 つ以上の API リクエストの組み合わせを含めることができます。 API プロダクトは、組織内のユーザーが作成します。その際、各 API プロダクトに任意のメタデータを追加できます。よく使用されるタイプのメタデータの 1 つでサービスプランを定義できます。このサービスプランでは、API 呼び出しのアクセス制限の指定、セキュリティ要件の規定、モニタリングと分析の許可、追加機能の提供を行えます。 API プロダクトの分析用のデータは、Apigee により収集されます。 |
|
API プロバイダ |
API プロキシとプロダクトを作成および管理する個人またはエンティティ。これらの公開された API には、クライアントのアプリ開発者がアクセスします。 |
|
アプリ開発者 |
組織には、組織が定義した API（API プロダクトとして公開）を使用するアプリを構築する 1 人以上の開発者が属します。開発者は API を使用しますが、組織内で API の作成などのアクションは行えません。 開発者は、会社内部のユーザーやパートナーの場合もあれば、外部のデベロッパー（API へのアクセスのために料金を支払う場合と料金が発生しない場合がある）の場合もあります。開発者は、API を使用する顧客と考えることができます。 開発者は、組織に登録された後、アプリを登録して API にアクセスするための API キーを受け取る必要があります。組織内の開発者を追加、更新、削除する方法は API プロバイダが判断します。UI を使用して手動で追加する方法、ウェブサイトで登録するためのデベロッパー ポータルを作成する方法、Apigee API を使用して独自の登録メカニズムを定義する方法を選択できます。 |
|
Apigee アプリ（またはアプリ） |
API を使用するクライアント アプリは、Apigee 開発者が 1 つ以上作成します。 認証情報のチェックを必要とする API（API キーや OAuth トークンなど）を呼び出すクライアント アプリケーションを作成する開発者は、まず組織でのアプリ登録を作成する必要があります。アプリを登録すると、クライアント アプリケーションが API を呼び出す際に使用する必要がある API キー、キーとシークレットのペア、その他の認証情報が開発者に提供されます。 すべてのアプリが組織に登録されているため、アプリと API の使用に関する分析情報は Apigee でモニタリングおよび収集できます。 |
図に示されていない Apigee のその他のコンポーネントは、API キーと OAuth トークンです。
Apigee は、シンプル API キー、Two-legged OAuth、3-legged OAuth など、さまざまな種類の認証をサポートしています。
API プロバイダが認証メカニズムとして API キー検証を指定している場合、クライアント アプリケーションは API へのリクエストごとに API キーを渡す必要があります。そのキーが有効な場合、Apigee はリクエストを許可します。または、API プロバイダが認証メカニズムとして OAuth トークン検証を指定している場合、クライアント アプリケーションはまず OAuth トークンを取得してから、API に対するすべてのリクエストでそのトークンを渡す必要があります。そのトークンが有効な場合、Apigee はリクエストを許可します。他のカスタム認証スキームが使用される可能性があります。
API プロバイダは、開発者が自分のアプリを登録する方法を定める必要があります。各アプリ登録には、1 つ以上のキーまたは認証情報が関連付けられます。開発者がデベロッパー ポータルを介して独自のアプリケーションを登録できるようにする場合、開発者は、便利なセルフサービス エクスペリエンスを介して、API へのアクセスに必要なキーまたは認証情報を取得できます。
開発者は、アプリの登録時に単独の API プロダクトにアクセスするか、複数の API プロダクトにアクセスするかを選択できます。開発者のアプリは、アプリに関連付けられているすべての API プロダクトに、同じキーまたは認証情報を使用してアクセスします。
キーを取り消して開発者のアプリが API にアクセスできないようにすることは、いつでも（開発者によるアプリの登録済み表現が組織内に存在する場合も）可能です。または、キーに有効期限を定義して、開発者が所定の期間後にキーを更新しなければならないようにすることもできます。
Apigee ユーザー
Apigee ユーザーは、組織の API チームの構成し、そのチームに、管理者、API プロキシおよび API プロダクトの作成者など、分析や他の統計情報をモニタリングするユーザーを含めることができます。エンドユーザーは Apigee 開発者が構築したアプリを使用するユーザーです。このドキュメントで「ユーザー」と表記した場合、通常は Apigee ユーザーを指します。
管理者はユーザーを組織に追加できます。
ユーザーはそれぞれ、異なるロールやアクセス権限を持つことができます。たとえば、一部のユーザーを、組織とそのコンポーネントを変更する権限を持つ組織管理者や運用管理者として定義します。他のユーザーは、API プロキシと API プロダクトの作成権限を持つが、他のユーザーを変更する権限は持たないように定義します。
ユーザーは、複数の組織のメンバーになることができます。たとえば、社内で同一の人物がすべての API プロキシと API プロダクトを構築しており、そのため全部の組織のメンバーである場合でも、会社は Apigee でさまざまなデベロッパー コミュニティをサポートするための複数の組織を定義できます。
ユーザーとなるために Apigee 組織を作成する必要はありません。管理者から既存の組織に追加してもらうことができます。
すべてのユーザーは、Apigee UI から Apigee にログインします。
利用資格
組織の利用資格は、有料組織がサブスクリプションと従量課金制のどちらの料金モデルを使用しているかによって異なります。
サブスクリプションの利用資格
組織: 組織の利用資格はユニットで表されます。組織ユニットの利用資格を取得すると、その利用資格を使用して任意のリージョンで 1 つの新しい組織を有効にしたり、（ドメイン名の拡張を使用して）既存の組織を単一の新しいリージョンに拡張したりできます。利用資格の目的において、N 個のリージョンに属する組織は N 個の組織ユニットを消費します。たとえば、新しい組織ユニットを 4 つ購入した場合、次のことができます。
- 既存の組織を 4 つの新しいリージョンに拡張する
- または、既存の 2 つの組織をそれぞれ 2 つの新しいリージョンに拡張する
- または、4 つの新しい組織を作成して、それぞれを 1 つのリージョンで利用する
組織ユニットの利用資格の合計数は、サブスクリプション階層と関連する組織パックの総数となります。
環境: 環境の利用資格もユニットで表されます。これらは組織の利用資格とは独立しており、異なる振る舞いをします。環境ユニットの利用資格を使用するには、2 段階のプロセスで、まず環境を作成してから、その環境を組織に接続します。環境が組織に接続されている場合、環境ユニットの利用資格にカウントされます。
環境ユニットの使用量は、すべての組織と各リージョンで使用される環境の数として計算されます。つまり、ある組織の 2 つのリージョンにプロビジョニングされた環境は、2 つの環境ユニットを利用資格から消費します。
環境ユニットの利用資格の合計は、サブスクリプション階層で指定された利用資格と、環境パックまたは組織パックを介して取得した追加の利用資格の合計となります。組織パックを購入すると、1 つの組織ユニットといくつかの環境ユニットが提供されます。組織パックによって追加された環境ユニットの利用資格は、作成または拡張することを選択した組織とは無関係です。組織パックで追加された環境ユニットの利用資格は、単に環境ユニットの利用資格全体に追加されます。組織ユニットを追加購入せずに環境ユニットを追加するには、環境パックを購入します。
詳しくは、サブスクリプションの利用資格をご覧ください。
従量課金制の利用資格
組織: 従量課金制モデルでは、アカウント所有者が 1 つの組織の権利を取得します。
環境: 環境の利用資格は、組織の利用資格とは無関係です。また、環境の利用資格は、2 段階のプロセスを経て使用するという点で、組織の利用資格とは異なる振る舞いをします。つまり、まず環境を作成してから、環境を組織に接続します。環境を組織に接続するまで、その環境は利用資格上限の対象として計上されません。
言い換えると、利用資格に計上される環境の数は、組織に接続されている環境の数になります。
従量課金制モデルには、すべてのリージョンで 85 の環境の利用資格が含まれます。
詳しくは、従量課金制の利用資格をご覧ください。