Apigee Edge は、API の開発と管理を行うためのプラットフォームです。プロキシレイヤを使用してサービスを公開することにより、Edge は、バックエンド サービス API の抽象化またはファサードを提供し、セキュリティ、レート制限、割り当て、アナリティクスなどの機能を提供します。
一例として、写真印刷、処方箋、その他の提供サービスに関する高機能なアプリ エコシステムを提供するために Walgreens 社が API と Apigee Edge をどのように使用しているかに関するウェブキャストをご覧ください。
デジタル ビジネスの促進
この動画では、お客様がデジタル ビジネスへと進展していくうえで Apigee がどのように役立つかについて簡単に説明します。
サービスをウェブで使用可能にする
今日の企業は、自社のバックエンド サービスをウェブ上で利用可能にし、それらのサービスがモバイル デバイスやパソコン上で実行されるアプリから使用できるようになるよう望んで��ます。企業では、商品価格と在庫情報を提供するサービス、販売サービス、注文サービス、注文追跡サービス、クライアント アプリに必要なその他のサービスを公開する必要がある場合があります。
企業は、多くの場合、HTTP エンドポイントのセットとしてサービスを公開しています。一方、クライアント アプリ デベロッパーは、これらのエンドポイントに対して HTTP リクエストを行います。エンドポイントによっては、XML または JSON としてフォーマットされたデータがサービスからクライアント アプリに返される場合があります。
これらのサービスを使用するクライアント アプリは、モバイル デバイスまたはタブレット用のスタンドアロン アプリ、ブラウザで実行される HTML5 アプリ、または HTTP エンドポイントに対するリクエストを行い、いずれかのレスポンス データを使用できるその他の任意のタイプのアプリとして実装できます。こうしたアプリの開発、リリースは、そのサービスを公開した会社自身が行う場合も、公開されているサービスを利用するサードパーティのアプリ デベロッパーによって行われる場合もあります。
次の図に、このタイプのモデルを示します。
ウェブを介してこれらのサービスを使用できるようにするため、プロバイダは不正アクセスから当該サービスのセキュリティを確保し、保護するために必要なすべての措置を講じていることを保証する必要があります。サービス プロバイダは、次のことを考慮しなければなりません。
- セキュリティ: 不正アクセスを防ぐため、サービスへのアクセスを制御する方法。
- 互換性: サービスがさまざまなプラットフォームやデバイスで機能するかどうか。
- 測定可能性: サービスの可用性を確認するためにサービスをモニタリングする方法。
- 収益化: サービスへのアクセスに関して顧客を追跡し、請求する方法。
- その他多くの考慮事項
サービスにアクセスするクライアント アプリがリリースされたら、サービス プロバイダは、時間の経過とともにサービスが追加、変更、削除されたときに、それらのサービスが引き続き機能することを保証する必要があります。またサービス プロバイダは、クライアント アプリがサービスの変更に対応できるよう、変更内容をアプリ デベロッパーに周知させる手段を確保する必要もあります。
クライアント アプリ デベロッパーは、さまざまなプロバイダのサービスを使用しようとするときに課題に直面します。今日ではサービス プロバイダがサービスを公開するために使用できるさまざまなテクノロジーがあります。同一のクライアント アプリで、あるプロバイダのサービスを使用するためにある 1 つのメカニズムを使用し、別のプロバイダのサービスを使用するために別のメカニズムを使用しなければならない場合があります。同じプロバイダのサービスを使用するために異なるメカニズムを使用しなければならない状況に直面する場合さえあります。
Apigee Edge を介してサービスを使用可能にする
Apigee Edge では、サービス実装を問わず、すべてのサービスで一貫して明確に定義された API を使用して、サービスへのセキュリティが確保されたアクセスを提供できます。一貫性のある API とは、次のような API のことです。
- アプリ デベロッパーがサービスをより簡単に使用できる。
- 公開 API に影響を与えることなく、バックエンド サービス実装を変更できる。
- アナリティクス、収益化、デベロッパー ポータル、Edge に組み込まれているその他の機能の利点を活用できる。
次の図に、クライアント アプリからバックエンド サービスへのリクエストを処理する Edge のアーキテクチャを示します。
アプリ デベロッパーにサービスを直接使用させるのではなく、Edge 上に作成された API プロキシにアクセスさせるようにします。API プロキシは、一般公開される HTTP エンドポイントからバックエンド サービスへのマッピングとして機能します。API プロキシを作成することで、サービスの保護に必要なセキュリティ タスクと認可タスクを Edge で処理するだけでなく、それらのサービスの分析、モニタリング、収益化も Edge で行うことができます。
アプリ デベロッパーは、サービスに対して直接ではなく、API プロキシに対して HTTP リクエストを行うため、サービス実装についてすべてを把握している必要はありません。把握している必要があるのは、次のもののみです。
- API プロキシ エンドポイントの URL。
- リクエストに渡されるすべてのクエリ パラメータ、ヘッダー、本文パラメータ。
- 必要な認証および認可の認証情報。
- XML、JSON などのレスポンス データ形式を含むレスポンスの形式。
API プロキシにより、アプリ デベロッパーはバックエンド サービスから分離されます。そのため、公開 API の一貫性が維持されている限り、サービス実装を自由に変更できます。たとえば、データベース実装を変更したり、新しいホストにサービスを移動したり、サービス実装にその他の変更を行ったりできます。一貫性のあるフロントエンド API を維持することで、既存のクライアント アプリはバックエンドでの変更に関係なく引き続き動作します。
API プロキシのポリシーを使用すると、バックエンド サービスに変更を加えることなく、サービスに機能を追加できます。たとえば、プロキシにポリシーを追加することで、データ変換やフィルタリングを行ったり、セキュリティを強化したり、条件ロジックやカスタムコードを実行したりするなど、多くのアクションを行うことができます。念頭に置くべき重要なことは、ポリシーはバックエンド サーバーではなく、Edge で実装するということです。
詳細については、API と API プロキシについてをご覧ください。
API プロダクトを作成する
API プロキシは、デベロッパーがバックエンド サービスへのアクセスに使用する Apigee Edge 上の HTTP エンドポイントです。API プロキシを個別に使用可能にすることはできますが、通常は行いません。代わりに、1 つ以上の API プロキシを 1 つの API プロダクトにグループ化します。
API プロダクトとは、複数の API プロキシをバンドルしたうえでサービスプランを組み合わせたものです。サービスプランでは、API プロキシに対するアクセス制限の設定、セキュリティ保護の提供、モニタリングや分析を可能にするなどの機能を提供できます。また、API プロダクトは、Edge が API の認可とアクセス制御に使用する中心的なメカニズムでもあります。
API プロダクトを作成するときに、著しい柔軟性が得られます。たとえば、複数の API プロダクトで同じ API プロキシを共有できます。次の図に、3 つの API プロダクトを示します。すべてのプロダクトで API プロキシ 3 へのアクセスが許可されますが、API プロキシ 1 へのアクセスが許可されるのはプロダクト A のみであることに注目してください。
各 API プロダクトに異なるプロパティを設定できます。たとえば、アクセス数の上限値を低くした（1 日あたり 1,000 リクエストなど）バーゲン価格の API プロダクトを設定する一方で、同一の API プロキシに対し�����クセス制限��������に緩和される代わりに、より高額な別の API プロダクトを設定することができます。または、サービスへの読み取り専用アクセスを可能にする無料の API プロダクトを作成し、次に、読み取り / 書き込みアクセスを可能にする、同一の API プロキシへの API プロダクトを販売する場合があります。
詳細については、API プロダクトを作成するをご覧ください。
クライアント側アプリに API プロダクトへのアクセスを許可する
アプリ デベロッパーはサービスにアクセスすることを決定した場合、まずクライアント アプリを API プロダクトに登録する必要があります。
アプリ デベロッパーは、登録時に API キーを受け取ります。このキーは、それ以降 API プロダクトに含まれる API プロキシに対するすべてのリクエストに含める必要があります。そのキーが認証され、認証が成功すると、リクエストはバックエンド サービスへのアクセスを許可されます。
キーを取り消してクライアント アプリがサービスにアクセスできないようにすることはいつでもできます。または、キーに時間制限を設けて、デベロッパーが所定の期間後にキーを更新しなければならないようにすることもできます。
API プロダクトにアクセスするためのデベロッパーからの登録リクエストを処理する方法を決定します。Apigee Edge デベロッパー サービスを使用すると、登録プロセスを自動化したり、手動プロセスを使用してアクセスを制御したりできます。
API プロダクトを作成してデベロッパーが使用できるようにする
- 公開されている URL をバックエンド サービスにマッピングする 1 つ以上の API プロキシを作成します。
- API プロキシをバンドルする API プロダクトを作成します。
- API プロキシと API プロダクトをデプロイします。
- API プロダクトが使用可能であることをデベロッパーに通知します。
アプリ デベロッパーに API プロダクトが使用可能であることを通知した後、デベロッパーは次の手順を行います。
- クライアント アプリを API プロダクトに登録します。
- API プロダクトの API キーを受け取ります。
- API プロキシ（API プロダクトにバンドルされている）を使用してサービスにリクエストを行い、各リクエストで API キーを渡します。
Apigee Edge のコンポーネント
Apigee Edge は、その組み合わせによって、API の作成、セキュリティ、管理、運用のための包括的なインフラストラクチャを提供する API ランタイム、モニタリングおよびアナリティクス、デベロッ���ー サービスで構成されています。
次の図に、Edge サービスを示します。
Edge API ランタイム
Apigee Edge API サービスには、サービス プロバイダとして API プロキシを構築する場合でも、アプリ デベロッパーとして API、SDK、その他の有用なサービスを使用する場合でも、API の作成および使用に関するあらゆることに対応します。
API Management Server には、API プロキシの追加と構成、API プロダクトの設定、アプリ デベロッパーとクライアント アプリの管理のためのツールが用意されています。API Management Server を使用することで、バックエンド サービスの管理に関する一般的な懸念事項が解消されます。API プロキシを追加する際には、セキュリティの強化、レート制限、仲介、キャッシュ保存などを追加するために API プロキシにポリシーを適用できます。また、カスタム スクリプトを適用して、サードパーティの API およびサービスに対する呼び出しを行うなどの方法により、API プロキシの動作をカスタマイズできます。詳細については、API と API プロキシについてをご覧ください。
Node.js デベロッパーの場合、API と API マッシュアップを作成するために Edge に Node.js モジュールをシームレスに追加できるだけでなく、メッセージ変換からセキュリティやアナリティクスに至るまで、Edge がもたらす利点を活用できます。
Edge のモニタリングとアナリティクス
Apigee Edge API Analytics には、API の使用状況の傾向を短期、長期の両面で確認できる充実したツールが用意されています。上位のデベロッパーやアプリによって対象ユーザーを分類したり、API メソッドで使用状況を理解して投資すべき分野を把握したりするほか、ビジネスまたは運用レベルの情報に関するカスタム レポートを作成することもできます。
データが Edge を通過すると、いくつかのデフォルトのタイプの情報（API 呼び出し情報の URL、IP、ユーザー ID、レイテンシ、エラーデータなどを含む）が収集されます。ポリシーを作成して他の情報（ヘッダー、クエリ パラメータ、XML や JSON から抽出したリクエストまたはレスポンスの一部など）を追加することもできます。この情報は、実際のリクエスト / レスポンス フローから非同期に収集されるため、API のパフォーマンスには影響を及ぼしません。
管理 UI では、次の図に示すように、複数の指標と分割項目をブラウザで表示できます。
ただし、コマンドライン インターフェースまたは RESTful API を使用して Analytics Service にアクセスし、制御することもできます。詳細については、API Analytics の概要をご覧ください。
Edge デベロッパー エコシステム
Apigee Edge には、次のことを可能にするデベロッパー サービスが用意されています。
- サービスを使用しているアプリ デベロッパーのコミュニティを管理する。
- 組織の内外のデベロッパーと連携して、財務モデルを使用して関係性を形式化する。
- デベロッパーをオンボーディングし、デベロッパー ポータルを作成する。アプリ デベロッパーはポータルに接続して API ドキュメントにアクセスし、公開されている API プロダクトの詳細を確認したり、API キーを管理したりします。
Edge のすべてのお客様は、クラウドまたは Apigee Edge for Private Cloud によるオンプレミスのいずれかで、独自のデベロッパー ポータルを作成できます。
Apigee Edge では、次の 2 種類のポータルを作成できます。
- 統合ポータル。すぐにプロビジョニングできます（新しい Edge UI でのみ使用可能）。統合ポータルの構築をご覧ください。
- Drupal ベースのポータル。Drupal ベースのポータルを構築するをご覧ください。
収益化
収益化機能は、課金のインフラストラクチャやシステムを提供し、デベロッパー コミュニティをデジタル アセットの実際のチャネルに変えることができます。収益化を使用すれば、多様な料金プランを作成できます。API プロダクトの使用についてデベロッパーに課金するか、収益を分配するモデルの場合はデベロッパーへの支払いを行うことも可能です。
前払いプラン、後払いプラン、固定料金プラン、変動料金プラン、「フリーミアム」プラン、特定のデベロッパー向けのカスタマイズ プラン、デベロッパー グループを対象とするプランなどを設定することができます。また、収益化機能には、レポート作成機能と請求機能も含まれます。
詳細については、収益化の概要をご覧ください。
Edge の種類
Apigee Edge にはいくつかの種類があります。
- Public Cloud: Apigee が環境を保守するホスト型の SAAS バージョン。ユーザーは、サービスの構築やサービスに対する API の定義に集中できます。
- Apigee ハイブリッド: API の管理をオンプレミスで、または Google Cloud Platform（GCP）で、あるいは両方を組み合わせて行えます。詳細については、Apigee ハイブリッドとはをご覧ください。
- Private Cloud: ユーザーがハードウェア環境を制御し、インストール、アップグレード、保守、その他の管理プロセスを行うオンプレミス インストール。
機能的には、Public Cloud バージョン���ハイブリッド バージョンおよび、Private Cloud バージョンはよく似ています。ただし、Private Cloud バージョンでは、Public Cloud バージョンのすべての機能がサポートされているわけではありません。Private Cloud バージョンでサポートされていない機能は次のとおりです。
- Hosted Targets
- 拡張機能
- 統合デベロッパー ポータル（注: Drupal ベースのデベロッパー ポータルはサポートされている）
- API Monitoring
- Sense
種類の違いについてのリストは、Apigee ハイブリッドと Edge の比較をご覧ください。
さらに、Edge for Public Cloud API と Private Cloud API の違いで説明されているように、API 間にわずかな違いがあります。
さらに、Public Cloud バージョンでは無料と有料の両方のアカウントがサポートされています。Private Cloud と Apigee ハイブリッドには有料アカウントが必要です。
オンプレミス インストールを完全にサポートするために、Private Cloud バージョンには、Apigee Management Server、Apache Cassandra NoSQL データベース、OpenLDAP サーバー、Message Router、Message Processor などのコンポーネントが含まれています。