Apigee について

Apigee X のドキュメントが表示されています。
Apigee Edge のドキュメントを参照する。

Apigee は API の開発と管理を行うためのプラットフォームです。プロキシレイヤをサービスのフロントにして、Apigee はバックエンド サービス API の抽象化またはファサードを提供し、セキュリティ、レート制限、割り当て、アナリティクスなどの機能を提供します。

動画: Apigee API 管理の概要を説明する短い動画をご覧ください。

アーキテクチャの概要

次の図は、Apigee のアーキテクチャの概要を示したものです。

Apigee アーキテクチャの概要。

図で示されているように、Apigee は次の主要コンポーネントで構成されています。

  • Apigee サービス: API プロキシの作成、管理、デプロイに使用する API。
  • Apigee ランタイム: Google が管理する Kubernetes クラスタ内のコンテナ化された一連のランタイム サービス。すべての API トラフィックは、これらのサービスを通過して処理されます。

さらに、Apigee は次のような他のコンポーネントも使用します。

  • GCP サービス: ID 管理、ロギング、アナリティクス、指標、プロジェクト管理の各機能を提供します。
  • バックエンド サービス: API プロキシのデータにランタイム アクセスをするためにアプリで使用されます。

詳しい説明については、Apigee のコンポーネントをご覧ください。

次の図は、プライベート ピアリング ネットワークを介した Cloud プロジェクトと Google サービスとの接続をさらに詳しく示しています。

VPC 接続を示す構成図。

Apigee の使用例については、Walgreens 社での API と Apigee の使用方法に関するこのウェブキャストをご購入ください。API と Apigee により、写真印刷、処方などのサービスを中心にした豊富なアプリ エコシステムが提供されます。

お疲れさまでした。

Apigee を設定し、 次に 最初のプロキシを構築する  

Apigee のフレーバー

Apigee には次のフレーバーがあります。

  • Apigee: Apigee によって環境が管理されるホスト型の SaaS バージョン。サービスの構築とそのサービスに対する API の定義に集中できます。
  • Apigee ハイブリッド: オンプレミスまたは任意のクラウド プロバイダにインストールされたランタイム プレーンと、Apigee のクラウドで実行されている管理プレーンで構成されるハイブリッド バージョン。このモデルでは、API のトラフィックとデータが企業の承認済み境界内に制限されます。

デジタル アクセラレーション

この動画では、お客様がデジタル ビジネスへと進展していくうえで Apigee がどのように役立つかについて簡単に説明します。

サービス管理と API 管理の選択

この動画は、サービス管理と API 管理との重要な違いを理解するうえで役立ちます。ビジネス

サービスをウェブで利用できるようにする

今日の企業は、自社のバックエンド サービスをウェブ上で利用可能にし、それらのサービスがモバイル デバイスやパソコン上で実行されるアプリから使用できるようになるよう望んでいます。企業では、商品価格と在庫情報を提供するサービス、販売サービス、注文サービス、注文追跡サービス、クライアント アプリに必要なその他のサービスを公開する必要がある場合があります。

企業は、多くの場合、HTTP エンドポイントのセットとしてサービスを公開しています。一方、クライアント アプリ デベロッパーは、これらのエンドポイントに対して HTTP リクエストを行います。エンドポイントによっては、XML または JSON としてフォーマットされたデータがサービスからクライアント アプリに返される場合があります。

これらのサービスを使用するクライアント アプリは、モバイル デバイスまたはタブレット用のスタンドアロン アプリ、ブラウザで実行される HTML5 アプリ、または HTTP エンドポイントに対するリクエストを行い、いずれかのレスポンス データを使用できるその他の任意のタイプのアプリとして実装できます。こうしたアプリの開発、リリースは、そのサービスを公開した会社自身が行う場合も、公開されているサービスを利用するサードパーティのアプリ デベロッパーによって行われる場合もあります。

次の図に、このタイプのモデルを示します。

モバイルアプリ、POS アプリ、パートナー、ウェブアプリなどのさまざまな種類のアプリが、ESB、SOA、アプリサーバー、データベースなどのバックエンド サービスに接続されます。

ウェブを介してこれらのサービスを使用できるようにするため、プロバイダは不正アクセスから当該サービスのセキュリティを確保し、保護するために必要なすべての措置を講じていることを保証する必要があります。サービス プロバイダは、次のことを考慮しなければなりません。

  • セキュリティ: 不正アクセスを防ぐため、サービスへのアクセスを制御する方法。
  • 互換性: サービスがさまざまなプラットフォームやデバイスで機能するかどうか。
  • 測定可能性: 自社のサービスの可用性を確認するためにサービスをモニタリングする方法。
  • その他多数の考慮事項

サービスにアクセスするクライアント アプリがリリースされたら、サービス プロバイダは、時間の経過とともにサービスが追加、変更、削除されたときに、それらのサービスが引き続き機能することを保証する必要があります。またサービス プロバイダは、クライアント アプリがサービスの変更に対応できるよう、変更内容をアプリ デベロッパーに周知させる手段を確保する必要もあります。

クライアント アプリ デベロッパーは、さまざまなプロバイダのサービスを使用しようとするときに課題に直面します。今日ではサービス プロバイダがサービスを公開するために使用できるさまざまなテクノロジーがあります。同一のクライアント アプリで、あるプロバイダのサービスを使用するためにある 1 つのメカニズムを使用し、別のプロバイダのサービスを使用するために別のメカニズムを使用しなければならない場合があります。同じプロバイダのサービスを使用するために異なるメカニズムを使用しなければならない状況に直面する場合さえあります。

Apigee を介してサービスを利用できるようにする

Apigee では、サービスの実装に関係なく、すべてのサービスで一貫性があり明確に定義された API を使用して、サービスに安全にアクセスできるようになります。一貫性のある API とは次のような API のことです。

  • アプリ デベロッパーがサービスをより簡単に使用できる。
  • パブリック API に影響を与えることなく、バックエンド サービスの実装を変更できる。
  • アナリティクス、デベロッパー ポータルなど、Apigee に組み込まれている機能の利点を活用できる。

次の図に、クライアント アプリからバックエンド サービスへのリクエストを処理する Apigee のアーキテクチャを示しています。

Apigee は、クライアント アプリケーションとバックエンド サービスの間に位置します。

アプリ デベロッパーはサービスを直接使用するのではなく、Apigee 上に作成された API プロキシにアクセスします。API プロキシは、一般公開される HTTP エンドポイントからバックエンド サービスへのマッピングとして機能します。API プロキシを作成することで、サービスの保護に必要なセキュリティ タスクと認可タスクを Apigee で処理するだけでなく、それらのサービスの分析とモニタリングも Apigee で行うことができます。

アプリのデベロッパーは、HTTP リクエストをサービスに対して直接送るのではなく API プロキシに送るため、サービスの実装についてすべてを把握している必要はありません。デベロッパーが把握しておく必要があるのは、次のことだけです。

  • API プロキシ エンドポイントの URL。
  • リクエストに渡されるすべてのクエリ パラメータ、ヘッダー、本文パラメータ。
  • 必要な認証および認可の認証情報。
  • XML、JSON などのレスポンス データ形式を含むレスポンスの形式。

API プロキシにより、アプリ デベロッパーはバックエンド サービスから分離されます。そのため、公開 API の一貫性が維持されている限り、サービス実装を自由に変更できます。たとえば、データベース実装を変更したり、新しいホストにサービスを移動したり、サービス実装にその他の変更を行ったりできます。一貫性のあるフロントエンド API を維持することで、既存のクライアント アプリはバックエンドでの変更に関係なく引き続き動作します。

API プロキシのポリシーを使用すると、バックエンド サービスに変更を加えることなく、サービスに機能を追加できます。たとえば、プロキシにポリシーを追加して、データ変換やフィルタリング、セキュリティの追加、条件付きロジックやカスタムコードの実行、その他多くのアクションを行えます。覚えておくべき重要なことは、バックエンド サーバーではなく Apigee でポリシーを実装することです。

詳細については、API と API プロキシについてをご覧ください。

API プロダクトを作成する

API プロキシは、デベロッパーがバックエンド サービスへのアクセスに使用する Apigee 上の HTTP エンドポイントです。API プロキシを個別に使用可能にすることはできますが、通常は行いません。代わりに、1 つ以上の API プロキシを 1 つの API プロダクトにグループ化します。

API プロダクトとは、複数の API プロキシをバンドルしたうえでサービスプランを組み合わせたものです。サービスプランでは、API プロキシに対するアクセス制限の設定、セキュリティ保護の提供、モニタリングや分析を可能にするなどの機能を提供できます。また、API プロダクトは、Apigee が API の承認とアクセス制御に使用する中心的なメカニズムでもあります。

API プロダクトは、非常に柔軟に作成できます。たとえば、複数の API プロダクトで同じ API プロキシを共有できます。次の図に、3 つの API プロダクトを示します。すべてのプロダクトで API プロキシ 3 へのアクセスが許可されますが、API プロキシ 1 へのアクセスが許可されるのはプロダクト A のみであることに注目してください。

プロダクト A はプロキシ 1 とプロキシ 3 にアクセスします。プロダクト B はプロキシ 3 にアクセスします。
    プロダクト C はプロキシ 2、プロキシ 3、プロキシ 4 にアクセスします。

各 API プロダクトに異なるプロパティを設定できます。たとえば、アクセス数の上限値を低くした(1 日あたり 1,000 リクエストなど)バーゲン価格の API プロダクトを設定する一方で、同一の API プロキシに対し、アクセス制限が大幅に緩和される代わりに、より高額な別の API プロダクトを設定することができます。あるいは、サービスへの読み取り専用アクセスを可能にする無料の API プロダクトを作成し、次に、同じ API プロキシに対して読み取り / 書き込みアクセスが可能な API プロダクトを販売することもできます。

詳細については、API プロダクトを作成するをご覧ください。

クライアント側アプリに API プロダクトへのアクセスを許可する

アプリ デベロッパーはサービスにアクセスすることを決定した場合、まずクライアント アプリを API プロダクトに登録する必要があります。

クライアント アプリには、API プロダクトに関連付けられている API を呼び出すためのキーが必要です。

アプリ デベロッパーは、登録時に API キーを受け取ります。このキーは、それ以降 API プロダクトに含まれる API プロキシに対するすべてのリクエストに含める必要があります。そのキーが認証され、認証が成功すると、リクエストはバックエンド サービスへのアクセスを許可されます。

キーを取り消してクライアント アプリがサービスにアクセスできないようにすることはいつでもできます。または、キーに時間制限を設けて、デベロッパーが所定の期間後にキーを更新しなければならないようにすることもできます。

API プロダクトにアクセスするための、デベロッパーからの登録リクエストを処理する方法を決定します。Apigee Developer Services を使用すると、登録プロセスを自動化できます。また、手動プロセスを使用してアクセスを制御することもできます。

API プロダクトを作成してデベロッパーが使用できるようにする

  1. 公開されている URL をバックエンド サービスにマッピングする 1 つ以上の API プロキシを作成します。
  2. API プロキシをバンドルする API プロダクトを作成します。
  3. API プロキシと API プロダクトをデプロイします。
  4. API プロダクトが使用可能であることをデベロッパーに通知します。

アプリ デベロッパーに API プロダクトが使用可能であることを通知した後、デベロッパーは次の手順を行います。

  1. クライアント アプリを API プロダクトに登録します。
  2. API プロダクトの API キーを受け取ります。
  3. API プロキシ(API プロダクトにバンドルされている)を使用してサービスにリクエストを行い、各リクエストで API キーを渡します。

Apigee のコンポーネント

Apigee は、その組み合わせによって、API の作成、セキュリティ、管理、運用のための包括的なインフラストラクチャを提供する API ランタイム、モニタリングおよびアナリティクス、デベロッパー サービスで構成されています。

次の図は、Apigee のアーキテクチャの概要を示したものです。

Apigee のアーキテクチャの概要

Apigee ランタイム

Apigee サービスは、サービス プロバイダとして API プロキシを構築する場合でも、アプリ デベロッパーとして API、SDK、その他の有用なサービスを使用する場合でも、API の作成および使用に関するあらゆることに対応します。

API ランタイムには、API プロキシの追加と構成、API プロダクトの設定、アプリ デベロッパーとクライアント アプリの管理のためのツールが備わっています。これにより、バックエンド サービスからの一般的な管理上の問題が解消されます。API プロキシを追加する際には、セキュリティの強化、レート制限、仲介、キャッシュ保存などを追加するために API プロキシにポリシーを適用できます。カスタム スクリプトの適用、サードパーティの API やサービスの呼び出しなどを行って、API プロキシの動作をカスタマイズすることもできます。詳細については、API と API プロキシについてをご覧ください。

Apigee のモニタリングと分析

Apigee API Analytics には、API の使用状況の傾向を短期、長期の両面で確認できる強力なツールが用意されています。上位のデベロッパーやアプリによって対象ユーザーを分類したり、API メソッドで使用状況を理解して投資すべき分野を把握したりするほか、ビジネスレベルまたは運用レベルの情報に関するカスタム レポートを作成することもできます。

データが Apigee を通過すると、いくつかのデフォルト タイプの情報(URL、IP、ユーザー ID などの API 呼び出しに関する情報、レイテンシ、エラーデータなど)が収集されます。ポリシーを作成して他の情報(ヘッダー、クエリ パラメータ、XML や JSON から抽出したリクエストまたはレスポンスの一部など)を追加することもできます。この情報は、実際のリクエスト / レスポンス フローから非同期的に収集されるため、API のパフォーマンスには影響しません。

Apigee UI では、次の図に示すとおり、複数の指標と分割項目をブラウザで表示できます。

ポリシーエラーの数をグラフと表形式で示すアナリティクス ダッシュボード。

ただし、コマンドライン インターフェースまたは RESTful API を使用して Analytics Service にアクセスし、制御することもできます。詳細については、API Analytics の概要をご覧ください。

Apigee デベロッパー エコシステム

Apigee が提供するデベロッパー サービスを利用すると、以下のことが可能になります。

  • サービスを使用しているアプリ デベロッパーのコミュニティを管理する。
  • 社内外のデベロッパーと連携して、財務モデルを使用して関係性を形式化する。
  • デベロッパーをオンボーディングし、デベロッパー ポータルを作成する。アプリ デベロッパーは、ポータルに接続して API ドキュメントにアクセスし、公開されている API プロダクトの詳細を確認したり、API キーを管理したりします。

Apigee をご利用のお客様は、クラウドに独自のデベロッパー ポータルを作成できます。

次の 2 種類のポータルを作成できます。