よく使われる Apigee 用語の解説
Google Cloud Japan Team
Apigee は Google Cloud のネイティブな API 管理プロダクトです。Apigee を使うと、ユースケース、環境、規模を問わず、API を構築、管理、保護、モニタリング、運用できます。Apigee は、内部と外部の API を抽象化レイヤでつなぐことで、デベロッパーと API チームによるさまざまな革新的な機能の実現を支援します。
実にパワフルな Apigee ですが、市場に存在するその他の API 管理プラットフォームとは使用する用語が異なります。Google Cloud のエコシステム外において一般的に API リバース プロキシと呼ばれているものは、Apigee では別の名前で呼ばれます。とはいえ、そんなに身構える必要はありません。以下の表は、Apigee フォーラムにおける Apigee デベロッパー、ユーザー、関係者による用語の使用頻度を示しています。
Apigee をもっとすばやく理解するために、Apigee プロダクト特有の用語の一覧をご覧ください。API 関連用語のほか、ネットワークや製品化に関する用語も含まれています。また、関連情報へのリンクも掲載します。
API 分析 - 複数のさまざまなチームによる使用に向け、幅広い分析データを取得できるよう設計されています。ただし、このデータは通常、非リアルタイムの分析で使用されます。
API コンシューマ - API プロバイダが作成した API を使用するアプリ デベロッパーと同義。
API デベロッパー - API プロバイダ組織内で API を作成するソフトウェア エンジニア。アプリ デベロッパー（API コンシューマ）はこれらの API を使用してアプリを構築します。
API パッケージ - デベロッパーに提供される API プロダクトをまとめたもの。1 つのバンドルとして提供されます。通常は料金プランに関連付けられます。
API プロダクト - API リソース（URI）のコレクションに、サービスプランを組み合わせたもので、デベロッパーにバンドルで提供されます。また API プロダクトには、モニタリングや分析のために、ビジネスに固有のメタデータを付加することもできます。1 つ以上のリソースを API プロダクトに付加して収益化することが可能です。さらに、こうした API プロダクトを API パッケージにバンドルして収益化できます。
API プロバイダ - API プロバイダは、API コンシューマ（アプリ デベロッパー）が使用する API を（Apigee を使用して）構築します。
API デベロッパー - アプリ デベロッパーは、作成したアプリを API プロバイダに登録することで、プロバイダの API プロキシの呼び出しに必要な API キーを取得します。
Apigee API - 環境、組織、API プロキシ、その他のハイブリッド サービスの構成に使用するエンドポイント。
Apigee Analytics - API プロキシを介して送受信される多くの情報を収集して計算します。このデータは、Apigee UI のグラフやチャートを使用して可視化できます。また、Apigee API を使用して元データをダウンロードし、オフラインで分析することもできます。
API プロキシ - 既存の API のファサードとして機能するプロキシ。デベロッパーは、既存の API を呼び出すのではなく、Apigee によって生成された新しい API を呼び出します。ファサードによって、公開インターフェースがバックエンド API から切り離され、デベロッパーがバックエンドの変更を気にする必要がなくなります。また、内部の開発チームに影響を与えることなくエッジを刷新できます。
バックエンドを変更しても、中断せずに引き続き同じ API を使い続けることができます。たとえば、Apigee では、複数のインターフェースを同じ API に公開し、API のシグネチャをカスタマイズして、デベロッパーのさまざまな分野におけるニーズを同時に満たせる高度なシナリオも実現できます。
環境 - API のランタイム実行コンテキスト。実行時にアクセスできるようにするには、API を環境にデプロイする必要があります。
環境グループ - リクエストを個々の環境にルーティングする方法を定義する基本機能です。個々の環境ではなく、環境グループにホスト名を定義します。Apigee はこれらのホスト名定義を使用して、グループ内の環境にリクエストを転送します。
組織 - API プロキシ、API プロダクト、API パッケージ、アプリ、デベロッパーを含む、Apigee アカウント内のすべてのエンティティのコンテナ。このドキュメントでは、「Apigee 組織」と「ハイブリッド対応組織」を同じ意味で使用しています。
Apigee または Apigee ハイブリッドをインストールして使用するには、Google Cloud プロジェクトにバインドされた Apigee 組織が必要です。この操作は、プロビジョニングというプロセスで組織の作成時に行います。
Apigee 組織は、Google Cloud 組織とは異なります。意味が曖昧になる可能性がある場合、このドキュメントでは組織が Apigee 組織であることを明記します。
従量課金制 - Apigee の従量課金制を使用すると、以下の料金が請求されます。
Apigee 組織内の Apigee ゲートウェイ ノードの数 - Apigee ゲートウェイ ノードは、API トラフィックを処理する Apigee 環境の単位（またはレプリカ）です。処理する API トラフィック量が増えるに従い、より多くのノードが必要になります。Apigee 組織が使用した Apigee ゲートウェイ ノードの数は、常に測定されます。従量課金制では分単位で使用したノードの数が測定され、それに応じて料金が発生します。プロビジョニングしたノードの最小課金時間は 1 分です。
Apigee Analytics サービスによって処理された API リクエストの数 - API リクエストは、成功したものも失敗したものも、Apigee Analytics で処理されます。1 か月あたりに分析された API リクエストの合計数に対して課金されます。分析データは 3 か月間保持されます。
ネットワーク使用量 - Apigee インスタンスは、インスタンスがピアリングされているネットワークでのみ使用できます。Google Cloud ロードバランサを作成することで、インスタンスを外部に公開できます。IP アドレス、下り（外向き）ネットワーク、転送ルールなど、ピアリングされたネットワークに関連するすべてのネットワーク料金は、実際の使用量に基づいて課金されます。
プロモーション特典として、Apigee インスタンスの下り（外向き）ネットワーク料金（1 か月あたり最大 1 TB）は、2023 年 2 月 18 日までは発生しません。
その他のリソース: 従量課金制とは
ポリシー - API フロー内において、アトミックかつ再利用可能なロジックの単位として実行される処理ステップ。通常、ポリシーには、適切なエンドポイントへのルーティング リクエスト、メッセージの形式変換、アクセス制御の強制、追加情報を要求するためのリモート サービスの呼び出し、外部ユーザーに対する機密情報のマスキング、潜在的な脅威を見つけるためのメッセージ内容の検証、一般的なレスポンスのキャッシュ処理を通じたパフォーマンス向上などが含まれます。
ポリシーは、リクエスト メッセージやレスポンス メッセージの内容やコンテキストに基づき、条件に応じて実行できます。たとえば、リクエスト メッセージがスマートフォンから送信された場合に、変換ポリシーを実行してレスポンスの形式をカスタマイズできます。
プロキシ - または API プロキシ。API プロキシは、バックエンド サービス API のフロントエンドとして機能する抽象化レイヤで、セキュリティ、レート制限、割り当て、分析などの付加価値機能を提供します。
リソース、リソースパス - RESTful コンセプトの一つであり、特定のリソースまでのネットワーク パスを指定する統一リソース識別子（URI）です。
リビジョン - API プロキシにバンドルされた構成やポリシーの番号付きのバージョン管理されたパッケージです。この用語は、バージョンとは用途が区別されます。バージョンは、デベロッパーに公開されている API インターフェースを指します。
バージョン - デベロッパー向け API インターフェースのバージョン。
pivotaltracker.com/services/v3、api.enterprise.apigee.com/v1 など。この用語は、リビジョンと区別されます。リビジョンは、API プロキシにバンドルされた構成やポリシーの番号付きのバージョン管理されたパッケージです。つまり、API インターフェースにはバージョンがあり、API プロキシにはリビジョンがあるということです。
次のステップ
Apigee の用語を理解できたところで、Apigee の世界をさらに詳しく見ていきましょう。理解を深めるために、Apigee X についてもチェックし、API で reCAPTCHA Enterprise を使用することをおすすめします。また、Apigee のコミュニティにも参加し、他のユーザーから学び、API の環境の変化に関する知識を深めましょう。
- Cloud テクニカル レジデント Adarsh Sivadas
