Apigee ハイブリッドは、API の管理をオンプレミスで、または Google Cloud Platform（GCP）で、あるいは両方を組み合わせて行えます。
すべての API を 1 か所で管理 |
Apigee ハイブリッドでは、Google Cloud Platform を使用して内部 API と外部 API を管理できます。 統合された API 管理により、デベロッパー、パートナー、お客様に一貫性のある API プログラム エクスペリエンスを提供できます。 |
セキュリティとコンプライアンスに対処 |
コンプライアンスとセキュリティの観点から、アプリケーションをオンプレミスにデプロイする必要がある場合は、エンタープライズ クラスのハイブリッド ゲートウェイを使用することにより、オンプレミスで Apigee ハイブリッド ランタイム プレーンをホストおよび管理できます。 ランタイムを管理、制御することで、既存のコンプライアンス、ガバナンス、セキュリティのインフラストラクチャを利用できます。 |
マルチクラウド戦略をサポート |
コストとパフォーマンスのバランスをとるためにハイブリッド戦略を選択する場合があります。 さまざまなクラウド プロバイダを検討している段階でも、すでにハイブリッド戦略を選択済みの場合でも、API 管理プラットフォームには柔軟性が必要です。データセンター、Google Cloud Platform、またはその両方で、エンタープライズ グレードのハイブリッド ゲートウェイをホスト、管理します。 |
|
ハイブリッドの詳細情報をご覧になりたい場合:
|
ハイブリッドのインストールの準備ができている場合:
|
ハイブリッド環境における API プログラム
Apigee ハイブリッドは、Google が管理する管理プレーンと、Kubernetes オンプレミスまたは GCP にインストールしたランタイム プレーンで構成されます。次の図に示すように、どちらのプレーンも Google Cloud Platform サービスを使用します。
ご覧のように、Hybrid は次の主要コンポーネントで構成されています。
- Apigee が実行する管理プレーン: クラウドでホストされ、Google が管理する一連のサービス。このサービスには、UI、Management API、分析が含まれます。
お客様が管理するランタイム プレーン: 独自の Kubernetes クラスタでお客様が設定・管理する、コンテナ化された一連のランタイム サービス。すべての API トラフィックは、ランタイム プレーンを通過し、その中で処理されます。
Kubernetes クラスタ上でコンテナ化されたランタイムを管理することで、俊敏性が高まり、段階的な公開や自動スケーリングなど、運用上のコンテナの利点を活用できます。
- Google Cloud Platform: Google がホストする一連の Cloud サービスです。
ハイブリッドについて知っておくべき重要なことは、すべての API トラフィックがネットワークの境界内の管理下で処理される一方で、UI や API 分析などの管理サービスはクラウドで実行され、Google が管理するということです。詳細については、データの保存場所をご覧ください。
次の動画は、ハイブリッド アーキテクチャについて詳しく説明しています。
ランタイム プレーンについて
ランタイム プレーンは、お客様が所有・管理する Kubenernetes クラスタで実行されます。
次の図は、ランタイム プレーンで実行される主なサービスを示しています。
ランタイム コンポーネントの概要については、以降のセクションをご覧ください。また、ランタイム サービス構成の概要もご覧ください。
以降のセクションでは、これらの主なランタイム プレーン サービスについて個々に詳しく説明します。
Message Processor
ハイブリッドの Message Processor（MP）は、ランタイム プレーンで API リクエストの処理とポリシー実行を行います。MP は、デプロイされたプロキシ、リソース、ターゲット サーバー、証明書、キーストアのすべてをローカル ストレージから読み込みます。クラスタ外部からのリクエストに MP を公開するよう、Istio Ingress コントローラを構成します。
Synchronizer
Synchronizer は、管理プレーンから API 環境に関する構成データを取得し、ランタイム プレーン全体に反映します。このダウンロードされたデータは、コントラクトとも呼ばれます。
Synchronizer は変更の有無について定期的に Management Server にポーリングし、変更が検出されるたびに新しい構成をダウンロードします。構成データが取得され、JSON ファイルとして Message Processor がアクセスできる場所にローカルに保存されます。
構成データがダウンロードされることで、ランタイム プレーンは管理プレーンとは独立して機能します。コントラクトにより、ランタイム プレーン上の Message Processor は、ローカルに保存されたデータを構成として使用します。管理プレーンとランタイム プレーン間の接続がダウンしても、ランタイム プレーン上のサービスは引き続き機能します。
Synchronizer がダウンロードする構成データには次のものが含まれます。
- プロキシ バンドルと共有フローのデプロイ
- API プロダクト
- フローフック
- 環境情報
- 共有 API のリソース
- ターゲット サーバーの定義
- TLS 設定
- 環境キャッシュ
- Key-Value マップ（KVM）の名前
- データマスク
Cassandra データストア
Apache Cassandra は、ランタイム プレーンに Core Persistence Services（CPS）を提供するランタイム データストアです。
Cassandra は、ランタイム プレーンにデータ永続性をもたらす分散データシステムです。Cassandra データベースを StatefulSet ノードプールとして、Kubernetes クラスタにデプロイします。これらのエンティティをランタイム処理サービスの近くに配置すると、セキュリティの要件と高スケーラビリティに対応できます。
Cassandra データベースには、次のエンティティに関する情報が保存されます。
- 鍵管理システム（KMS）
- Key-Value マップ（KVM）
- レスポンス キャッシュ
- OAuth
- 割り当て
Management API for Runtime データ（MART）
組織に属していて、アプリケーション構成、鍵管理システム（KMS）データ、キャッシュ、Key-Value マップ（KVM）などのランタイム API 呼び出し時にアクセスされるデータは、Cassandra がランタイム プレーンに保存します。新しい KVM を追加する、環境を削除するなど、データにアクセスして更新する場合は、Apigee ハイブリッド UI や Apigee API を使用できます。MART サーバー（Management API for Runtime データ）は、ランタイム データストアに対して API 呼び出しを処理します。
このセクションでは、Apigee API を呼び出してランタイム データストアにアクセスするときに MART が果たす役割について説明します。
| MART が行うこと | Apigee API を呼び出すには、認証済みリクエストを管理プレーンの Management Server（MS）に送信します。MS はリクエストを認証および認可して、ランタイム プレーンの MART に転送します。そのリクエストには、MS が事前構成されたサービス アカウントで生成したトークンが添付されます。 MART はリクエストを受信し、認証および認可した後で、ビジネス検証を行います（たとえば、アプリが API プロダクトの一部である場合、MART はそのアプリが有効なリクエストであることを確認します）。リクエストが有効であると判断された後、MART はそれを処理します。 Cassandra は、MART が処理するランタイム データを保存します（それは結局、ランタイム データストアです）。MART は、リクエストのタイプに応じて、Cassandra からデータを読み取るか、そのデータを更新します。 ほとんどのハイブリッド サービスと同様、MART はステートレスです。ランタイム時に独自の状態を保持しません。 |
| MART が行わないこと | MART がポートをパブリック クラウドに公開するとしても、MART は直接呼び出すものではありません（ポートは、MART がサービス アカウント経由で MS から呼び出しを受け取れるように、公開する必要があります）。 さらに、MART はお客様から API プロキシへのランタイム呼び出しを受け取りません。これらの呼び出しは Ingress コントローラによって処理され、クラスタの Message Processor に転送されます。 |
MART と Message Processors は両方とも同じランタイム データストア（Cassandra）にアクセスでき、これにより、KMS、KVM、キャッシュなどのデータが共有されることに注意してください。
次の図は、Apigee API 呼び出しのフローを示しています。
管理プレーンについて
管理プレーンは Google Cloud Platform 上で動作します。次のような管理サービスがあります。
- Apigee ハイブリッド UI: API プロキシの作成とデプロイ、ポリシーの構成、API プロダクトの作成、デベロッパー アプリの作成を行うための UI をデベロッパーに提供します。管理者は Apigee ハイブリッド UI を使用してデプロイのステータスをモニタリングできます。
- Apigee API: 組織や環境を管理するためのプログラマティック インターフェースを提供します。
- 統合分析プラットフォーム（UAP）: ランタイム プレーンから分析とデプロイのステータス データを受信して処理します。
次の図は、管理プレーンで実行される主なサービスを示しています。
GCP サービスについて
次の表に、ハイブリッドで使用する主要な GCP サービスを示します。
| GCP サービス | 説明 |
|---|---|
| ID | ユーザー アカウント認証では、Google Cloud Platform アカウントを使用します。認証では、GCP サービス アカウントが使用されます。 |
| 役割 | ハイブリッドのアクセス管理では、Google の役割エンジン、IAM を使用し、デフォルトの Apigee の役割をサポートします。 |
| リソース階層 | リソースは、GCP プロジェクトにまとめられ、Apigee の組織にリンクされています。 |
| Stackdriver | ロギングと指標データの分析を行います。 |
ユーザーの種類
Apigee では、ハイブリッド ユーザーの主な種類を次のように特定しています。
| 役割 | 一般的な責任 / タスク | 関心のある分野 |
|---|---|---|
| システム管理者 / 運用担当者 |
|
|
| デベロッパー |
|
|
利点
Apigee ハイブリッドには次のような利点があります。
- 所有コストの削減
- Apigee Edge for Private Cloud をご利用の場合は、管理と運用に必要なソフトウェア サービスの数を大幅に減らして、オンプレミス API ランタイムを運用できます。
- 俊敏性の向上
- ハイブリッドはコンテナで配信、実行されるため、段階的な公開や自動スケーリングなど、運用上のコンテナの利点を活用できます。
- レイテンシの短縮
- ハイブリッド管理プレーンとの通信はすべて非同期で、クライアント API リクエストの処理の一部として行われるものではありません。
- API の採用の増加
- Apigee Edge Public Cloud を使用して内部 API を処理することは可能ですが、ハイブリッドを使用するとレイテンシが短縮され効率性が向上するため、ハイブリッドによる内部 API の処理が魅力的な選択肢となります。この効率性が実現する理由の 1 つは、API ゲートウェイがバックエンド サービスのすぐ近くのオンプレミスで実行されることにあります。また、Apigee Edge Public Cloud を使用している場合は、内部 API をハイブリッドで処理することにより、Apigee の採用も増やせます。Edge Microgateway を使用している場合は、ハイブリッドにより Edge Microgateway の主な制約を克服できるため、API の採用を拡大できます。
- より高度な制御
- 多くの企業がハイブリッド戦略に乗り出しています。プライベート データセンターにデプロイされた API ランタイムを管理できることが、大企業にとって重要な要件です。現在、ハイブリッド ランタイム プレーンは GCP または独自のデータセンターにデプロイできます。
次のステップ
ハイブリッド インストール プロセスの概要については、全体像をご覧ください。