Apigee ハイブリッドは、ハイブリッド デプロイ モデルの API プロキシを開発し、管理するためのプラットフォームです。ハイブリッド モデルには、クラウドで Apigee がホストする管理プレーンと、サポートされている Kubernetes プラットフォームにユーザーがインストールして管理するランタイム プレーンがあります。
すべての API を 1 か所で管理 |
Apigee ハイブリッドを使用すると、内部 API と外部 API を Google Cloud で管理できます。 統合された API 管理により、デベロッパー、パートナー、お客様に一貫性のある API プログラム エクスペリエンスを提供できます。 |
セキュリティとコンプライアンスに対応 |
コンプライアンスとセキュリティの観点から、アプリケーションをオンプレミスにデプロイする必要がある場合は、エンタープライズ クラスのハイブリッド ゲートウェイを使用することで、オンプレミスに Apigee ハイブリッド ランタイム プレーンをホストし、管理できます。 ランタイムを管理、制御することで、既存のコンプライアンス、ガバナンス、セキュリティのインフラストラクチャを利用できます。 |
マルチクラウド戦略をサポート |
コストとパフォーマンスのバランスをとるためにハイブリッド戦略を選択する場合があります。 さまざまなクラウド プロバイダを検討している段階でも、すでにハイブリッド戦略を選択している場合でも、API 管理プラットフォームには柔軟性が必要になります。データセンター、Google Cloud、またはその両方にエンタープライズ クラスのハイブリッド ゲートウェイをホストし、管理します。 |
ハイブリッドについて詳しく知りたい場合:
|
ハイブリッドをインストールする準備ができている場合:
|
ハイブリッド環境の API プログラム
Apigee ハイブリッドは、Google が管理する管理プレーンと、サポートされている Kubernetes プラットフォーム上にインストールされるランタイム プレーンから構成されています。次の図のように、両方のプレーンが Google Cloud Platform サービスを使用します。
ご覧のように、ハイブリッドは次の主要コンポーネントから構成されています。
- Apigee が実行される管理プレーン: クラウド上にホストされ、Google が管理する一連のサービス。これらのサービスには、UI、Management API、分析が含まれます。
お客様が管理するランタイム プレーン: お客様が独自の Kubernetes クラスタに設定して維持する、コンテナ化された一連のランタイム サービス。API トラフィックはすべてランタイム プレーンを通過し、その中で処理されます。
Kubernetes クラスタ上でコンテナ化されたランタイムを管理することで、段階的な公開や自動スケーリングなど、コンテナを使用する利点により、アジリティを高めることができます。
- Google Cloud: Google がホストする一連のクラウド サービス。
API トラフィックはすべてネットワーク境界内でお客様の管理下において処理されますが、UI や API 分析などの管理サービスはクラウド上で実行され、Google が維持します。これは、ハイブリッドについて理解しておくべき重要なポイントの 1 つです。詳細については、データの保存場所をご覧ください。
ハイブリッド アーキテクチャの詳細については、次の動画をご覧ください。
ランタイム プレーンについて
ランタイム プレーンは、サポートされている Kubernetes プラットフォーム上で動作する独自の Kubernetes クラスタでお客様が設定と維持を行う、コンテナ化された一連のランタイム サービスです。API トラフィックはすべてランタイム プレーンを通過し、その中で処理されます。ランタイム プレーンには次の主要コンポーネントが含まれています。
ランタイム プレーンは、サポートされている Kubernetes プラットフォーム上の Kubernetes クラスタで実行されます。これは、お客様が維持します。
次の図に、ランタイム プレーンで実行される主なサービスを示します。
ランタイム コンポーネントに関する一般的な情報については、以降のセクションをご覧ください。また、ランタイム サービス構成の概要もご覧ください。
以降のセクションでは、これらの主なランタイム プレーン サービスについて詳しく説明します。
Message Processor
ハイブリッドの Message Processor(MP)は、ランタイム プレーンで API リクエストの処理とポリシー実行を行います。MP は、デプロイされたプロキシ、リソース、ターゲット サーバー、証明書、キーストアのすべてをローカル ストレージから読み込みます。クラスタの外部からのリクエストに MP を公開するように、Istio Ingress コントローラを構成します。
Synchronizer
Synchronizer は、管理プレーンから API 環境に関する構成データを取得し、ランタイム プレーン全体に反映します。このダウンロードされたデータは、コントラクトとも呼ばれ、ローカル ファイル システムに保存されます。
Synchronizer は、定期的に Management Server にポーリングして変更の有無を確認し、変更が検出されるたびに新しい構成をダウンロードします。取得した構成データは、Message Processor からアクセス可能なローカル ファイル システムに JSON ファイルとして保存されます。
構成データがダウンロードされるので、ランタイム プレーンは管理プレーンとは独立して機能します。ランタイム プレーン上の Message Processor は、コントラクトにより、ローカルに保存されたデータを構成として使用します。管理プレーンとランタイム プレーン間の接続がダウンしても、ランタイム プレーン上のサービスは引き続き機能します。
Synchronizer がダウンロードする構成データには次のものが含まれます。
- プロキシ バンドルと共有フローのデプロイ
- フローフック
- 環境情報
- 共有 API リソース
- ターゲット サーバーの定義
- TLS の設定
- Key-Value マップ(KVM)名
- データマスク
Cassandra データストア
Apache Cassandra は、ランタイム プレーンにデータ永続性を提供するランタイム データストアです。
Cassandra は、ランタイム プレーンにデータの永続性を提供する分散データシステムです。Cassandra データベースを StatefulSet ノードプールとして、Kubernetes クラスタにデプロイします。これらのエンティティをランタイム処理サービスの近くに配置すると、セキュリティとスケーラビリティの要件に対応できます。
Cassandra データベースには、次のエンティティに関する情報が保存されます。
- 鍵管理システム(KMS)
- Key-Value マップ(KVM)
- レスポンス キャッシュ
- OAuth
- 割り当て
Management API for Runtime data(MART)
組織に属していて、ランタイム API 呼び出しでアクセスされるデータは、Cassandra によってランタイム プレーンに保存されます。
このデータには以下のものが含まれます。
- アプリケーションの構成
- 鍵管理システム(KMS)データ
- キャッシュ
- Key-Value マップ(KVM)
- API プロダクト
- デベロッパー アプリ
データにアクセスして更新する(新しい 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 が行わないこと | 管理プレーンは、Apigee Connect エージェントのロールを持つサービス アカウント(多くのインストールでは MART サービス アカウント)を使用して MART と通信します。MART を直接呼び出すことはありません。 さらに、MART は API プロキシ リクエストを受信しません。それらの呼び出しは、ランタイム Ingress コントローラによって処理され、クラスタの Message Processor にルーティングされます。 |
MART と Message Processor は両方とも同じランタイム データストア(Cassandra)にアクセスできます。これにより、KMS、KVM、キャッシュなどのデータが共有されるので注意してください。
次の図に、Apigee API 呼び出しのフローを示します。
UDCA
Universal Data Collection Agent(UDCA)は、ランタイム プレーンのデータ収集 Pod 内で実行されるサービスです。UDCA は分析、トレース、デプロイのステータス データを抽出して UAP に送信します。
詳細については、デバッグ、分析、デプロイのステータス データの収集をご覧ください。
管理プレーンについて
管理プレーンは Google Cloud Platform 上で動作します。次のような管理サービスがあります。
- Apigee ハイブリッド UI: API プロキシの作成とデプロイ、ポリシーの構成、API プロダクトの作成、デベロッパー アプリの作成を行うための UI をデベロッパーに提供します。管理者は Apigee ハイブリッド UI を使用してデプロイのステータスをモニタリングできます。
- Apigee API: 組織や環境を管理するためのプログラマティック インターフェースを提供します。
- 統合分析プラットフォーム(UAP): 分析とデプロイのステータス データをランタイム プレーンから受信して処理します。
次の図に、管理プレーンで実行される主なサービスを示します。
Google Cloud サービスについて
次の表に、ハイブリッドで使用される主な Google Cloud サービスを示します。
Google Cloud サービス | 説明 |
---|---|
ID | ユーザー アカウント認証では、Google Cloud アカウントが使用されます。認可では、Google Cloud サービス アカウントが使用されます。 |
ロール | ハイブリッドのアクセス管理では、Google のロールエンジンである IAM を使用し、デフォルトの Apigee ロールをサポートします。 |
リソース階層 | リソースは、Google Cloud プロジェクトにまとめられ、Apigee の組織にリンクされます。 |
Cloud Operations | ロギングと指標データの分析を行います。 |
ユーザーの種類
Apigee では、ハイブリッド ユーザーを次のように定義しています。
ロール | 一般的な責任 / タスク | 関心のある分野 |
---|---|---|
システム管理者 / 運用担当者 |
|
|
デベロッパー |
|
|
利点
Apigee ハイブリッドには次のようなメリットがあります。
- アジリティの向上
- ハイブリッドは、コンテナで配信され実行されるため、段階的な公開や自動スケーリングなど、コンテナの運用上の利点を活用できます。
- レイテンシの短縮
- ハイブリッド管理プレーンとの通信はすべて非同期です。クライアント API リクエストの処理の一部として行われるものではありません。
- API 採用の増加
- Apigee を使用して内部 API を処理することは可能ですが、ハイブリッドを使用するとレイテンシの短縮と効率性が達成できるため、ハイブリッドによる内部 API の処理が魅力的な選択肢となります。API ゲートウェイがバックエンド サービスに近いオンプレミスで実行されるため、こうした効率性の一部が達成されます。また、Apigee を使用している場合は、内部 API をハイブリッドで処理することで、Apigee の採用も増やせます。
- より詳細な管理
- 多くの企業がハイブリッド戦略に乗り出しています。大企業にとって、プライベート データセンターにデプロイされた API ランタイムの管理能力は非常に重要な要件となります。現在、ハイブリッド ランタイム プレーンは Google Cloud またはご利用のデータセンターにデプロイできます。
次のステップ
全体的な方針で、ハイブリッド インストール プロセスの概要を確認する。