tl;dr
- Apigee は、企業の API 公開を支援するための API 管理プラットフォーム
- Apigee X は Google Cloud との統合が進んだ Apigee ラインナップにおける最新サービス
- 無償の評価組織で Apigee X をプロビジョニングすれば、コスト面でも手軽に Apigee X を評価出来る
はじめに
みなさん、こんにちは。Google Cloud パートナーエンジニアの Yusuke です。
この記事は Google Cloud Japan Advent Calendar 2022(今から始める Google Cloud) の 12/16 の記事です。本記事では、2016 年に Google Cloud のプロダクトファミリーの一員となった API 管理プラットフォーム である Apigee において、2021 年に発表された Apigee X という最新リリースのサービスに焦点を当てていきます。プロダクトの概要を一通り説明した後、記事の最後には、Apigee X を使って、初めての API を公開してみようと思います。
Apigee とは
Apigee は、Google Cloud が提供する統合 API 管理プラットフォームです。API というのは Application Programing Interface の略で、サービスや機能を使いやすい便利な形（インターフェース）で内部 / 外部に対して公開するものですが、昨今ではデジタル エコシステムの構築、社内 IT のモダナイズ等において、この API の普及が急速に進んでいます。
企業がシステムを API 公開することに際し、考慮すべきこと、利便性の向上、利用状況の把握といった必要な機能を提供してくれる、高機能でスケーラブルな API 基盤を提供するのが、この Apigee です。
Apigee X とは
Apigee X は、複数ある Apigee ラインナップのうち、特に Google Cloud との統合が進んだ最新リリースのサービスです。Google Cloud との統合という観点で例を上げると、例えば Cloud CDN との連携です。Apigee X のサービスエンドポイントに対して Cloud CDN を連携させることにより、API の保護と管理ができるだけでなく、関係者のグローバル エコシステム全体で API を利用可能にすることができます。その他にも、Cloud Identity and Access Management(IAM)を簡単に活用して、Apigee プラットフォームへのアクセスの認証と承認を行ったり、顧客管理の暗号鍵(CMEK)で暗号化データをより細かく管理したりすることもできます。
※ 各 Apigee ラインナップの比較を確認したい場合はこちらのリンクをご確認ください。
Apigee X アーキテクチャの概要
Apigee X のアーキテクチャの概要についても触れてみます。
Apigee X の初期構築のやり方にもよりますが、一通り環境構築が完了すると、Google が管理する VPC 上に、GKE クラスタで実行される Apigee インスタンス、Apigee インスタンスのエンドポイントとなる内部 TCP/UDP 負荷分散、Apigee インスタンスからインターネットに向かってサウスバウンド通信を行う為の Cloud NAT が作成されます(これらをまとめて Apigee ランタイムと言います)。ただし、顧客管理の VPC と Google 管理の VPC はこの段階のままでは通信をすることが出来ません。双方向の通信を許可するには、更に幾つかの設定が必要です。
顧客管理の VPC と Google が管理する Apigee の VPC は、追加の構成を行わなければ相互に通信することはできません。
VPC のネットワークピアリング(厳密には、VPC ネットワークピアリングを経由したプライベート サービスアクセス)を使用することで、顧客管理の VPC と Google 管理の VPC を接続することが出来、2 つの VPC 間で通信が可能になります。これにより、後述するネットワークブリッジ VM との接続性が生まれる他、顧客管理の VPC 上のワークロードや、顧客管理の VPC の先にあるオンプレミスのワークロードに対しても、Apigee プロキシを経由して API を公開することが出来ます。
VPC ネットワーク ピアリングにより VPC 間の通信が可能になります。
更に、インターネット上のクライアント アプリから Apigee ランタイムにトラフィックをルーティングする為には、外部 HTTPS 負荷分散と、ネットワークブリッジとして機能する仮想マシンのマネージドインスタンスグループ(MIG) をプロビジョニングする必要があります。ネットワークブリッジ VM は顧客管理の VPC 上にデプロイされ、外部 HTTPS 負荷分散と Google 管理の VPC 上に作成される内部 TCP/UDP ロードバランサとの双方向通信を可能にします。
ネットワークブリッジ VM によって、ピア ネットワーク間でリクエストとレスポンスをやり取りできます。
ここまで、Apigee X のアーキテクチャ概要を説明してきました。より詳細な説明はこちらのリンクを御覧ください。
Google Cloud リソース階層と Apigee のリソースの関係
ここまで、Apigee X のアーキテクチャを記載してきましたが、Apigee X のリソースをプロビジョニングする前に、Apigee 独自のリソース階層を理解する必要があります。本項では、Google Cloud リソース階層と Apigee リソースの関連性、Apigee 固有の用語について軽く触れてみたいと思います。
Google Cloud プロジェクトと Apigee リソースの関係
Apigee X のリソースをプロビジョニングするには、Google Cloud プロジェクトが必要です。Google Cloud プロジェクトを作成していないと、Apigee X のリソース作成も出来ないため、まだの場合はこちらの手順を参考に Google Cloud プロジェクトを用意する必要があります。
組織
Apigee X のリソース階層にも、Google Cloud リソース階層のルート階層に位置する言葉と同じ組織という要素があります。Apigee 組織は 1 つの Google Cloud プロジェクトに属し、1 つのプロジェクトには最大 1 つの組織を含めることができます。そして、Apigee 組織の中に、環境、環境グループ、API プロキシ、API プロダクト、API パッケージ、アプリ、ユーザーが含まれます。つまり、Apigee リソース階層において最上位のコンテナになるのがこの組織であるということを理解しましょう。組織についての詳細はこちらのリンクを御覧ください。
有料組織と評価組織
Apigee 組織は 2 つの選択肢からプロビジョニングすることが出来、大きく有料組織と無償の評価組織に別れます。また有料組織においても、従来のサブスクリプションモデルだけでなく、PAYG(従量課金)モデルも 2022 年 8 月から利用することが出来るようになっており、ユーザーは 2 つの選択肢から有料組織をプロビジョニングすることが出来るようになっています。
評価組織はユーザーが Apigee の機能を手軽に検証出来る一番のオプションとなります。機能的には有料版とほぼ同等となりますが、以下に上げるような制限があります。
- 利用可能期間：60 日（延長不可。放置しても有料にならないのでご安心を）
- Apigee インスタンスの上限: 1 つ
- 環境の上限: 2 つ
- 有償版への移行パスなし（有料組織への変換不可）
- Apigee ランタイム以外(例: 外部 HTTPS 負荷分散、マネージドインスタンスグループ(MIG))のコンポーネントは無償にはならないので注意
※ 無償評価版の仕様は予告なく変更される場合があります。
※ 評価組織と有料組織の詳細な比較はこちらのリンクを確認してください。
環境
Apigee のリソース階層には、環境(Environment)という、API プロキシをデプロイする為の組織内の分離されたソフトウェア環境があります。各環境は、最低一つの Apigee インスタンスに接続されている必要があり、API プロキシをデプロイする際は、環境を指定して API プロキシをデプロイします。
環境内で定義されたリソースにアクセスするには、環境が少なくとも 1 つの環境グループ(後述)のメンバーであることが必要です。つまり環境を使用するには、環境グループに環境を割り当てる必要があります。
環境グループ
Apigee の環境を複数まとめて環境グループ(Env Group)を作る事ができます。環境グループは最低 1 つの環境を含んでおり、環境グループごとに 1 つ以上のホスト名を持つ事ができます。個々の環境ではなく、環境グループにホスト名を定義することにより、Apigee がこれらのホスト名定義を使用して、グループ内の環境にリクエストを転送出来るようになります。
※ ここまでの組織 / 環境 / 環境グループについての関係性および留意事項はこちらを御覧ください。
インスタンス(Apigee インスタンス)
環境の中に含まれる、デプロイした API プロキシが稼働する実環境です。インスタンスは 1 つ以上の環境に紐付ける事ができます。インスタンスの実態は、Google が管理する VPC 上に GKE クラスタで実行される Google 管理のマネージドなリージョナル リソースです。
その他、Apigee の基本的な用語について調べる場合はこちらの用語集を御覧ください。
Apigee X 評価組織をプロビジョニングしてみる
前段の話はこれぐらいとして、そろそろ実際に Apigee リソースをデプロイして、本来の目的である API プロキシのデプロイに進んでみたいと思います。事前準備である Apigee 組織をプロビジョニングするには幾つかのやり方がありますが、本記事では、最も簡単なやり方である Apigee プロビジョニングウィザードを使って Apigee 組織をデプロイしていこうと思います。
※手順の詳細はこちらを参考にしています。
1. Google Cloud プロジェクトを作成する
上述したように、Apigee 組織を作成する為には Google Cloud プロジェクトが必要です。そのため、まずは Google Cloud プロジェクトを作成しておきます。今回は、ynakaya-eval-apigeex-project というプロジェクト名で準備をしていきます。
- プロジェクト名: ynakaya-eval-apigeex-project
Google Cloud プロジェクトを作成します
2. ネットワークブリッジ VM 用の VPC / サブネットの作成
今回はインターネット公開された API をデプロイする想定として、ネットワークブリッジ VM をデプロイする為の VPC とサブネットを準備します。asia-northeast1 リージョンに、192.168.200.0/24 という適当なサブネットを準備しておきます。(書いてませんが、Compute Engine API の有効化も事前にやっておきます。)
- VPC 名: ynakaya-eval-apigeex-vpc
- サブネット名: ynakaya-eval-apigeex-subnet
先程作成した Google Cloud プロジェクトに、VPC とサブネットを作成します
3. Apigee プロビジョニングウィザードを使った Apigee 組織のデプロイ
Apigee プロビジョニングウィザードを使って Apigee 組織をデプロイしていきます。URL をクリックすると、こんな画面が出てきます。Apigee 組織を紐付ける Google Cloud プロジェクトに、ynakaya-eval-apigeex-project を選択して、START EVALUATION のボタンをクリックします。これで、評価組織の選択が完了しました。
プロジェクト ID を入力した後に、評価組織を選択します
4. Enable APIs の項目
ウィザードに沿って進めていきます。1 番は Apigee 組織をデプロイしていく上で必要な API 群を有効化していきます。難しいことはなく、ENABLE APIS をクリックします。
Apigee X 環境を立てていく為に必要となる API を有効化します
5. Networking の項目
Google 管理の Apigee ランタイムが稼働する VPC と、顧客管理の VPC との接続設定をここで行います。Authorized network には、VPC ネットワークピアリングを経由して、プライベートサービスアクセスを構成する顧客管理の VPC を選択します。今回は、ynakaya-eval-apigeex-vpc を選択します。
プライベート サービスアクセスを構成する VPC を選択します
続いて、Apigee ランタイムが稼働する VPC に割り当てる CIDR レンジを入力します。 Automatically allocate IP range と Select one or more existing IP ranges or create a new one とありますが、今回は折角なので、後者を選択して指定した IP レンジを Apigee ランタイム側 VPC に Allocate します。こちらのサイトには、
各 Apigee インスタンスには、重複しない /22 CIDR 範囲が必要です。Apigee ランタイム プレーン（別名データプレーン）には、CIDR 範囲内の IP アドレスが割り当てられます。このため、範囲が Apigee 用に予約されており、お客様の VPC ネットワークの他のアプリケーションでは使用されないことが重要です。
https://cloud.google.com/apigee/docs/api-platform/system-administration/peering-ranges?hl=ja#sizing
とあるので、重複しない 22 ビットの CIDR を準備します。今回は、192.168.8.0/22 という CIDR を確保しようと思います。
- IP range name: apigeex-runtime-cidr-range
- Allocated IP address range: 192.168.8.0/22 (192.168.8.1 - 192.168.11.254 のレンジ)
プライベート サービスアクセスで Google 側 VPC に割り当てる CIDR レンジを決定します
ALLOCATE AND CONNECT を押して、次に進みます。約 10 分ほど、待ちます。
6. Apigee evaluation organization の項目
Analytics hosting region と Runtime location を選択します。今回はどちらも asia-northeast1 を選択して、Apigee ランタイムが ynakaya-eval-apigeex-subnet と同じ東京リージョンでデプロイされるようにします。
Analytics hosting region と Runtime location の選択
PROVISION を押して、45 分ぐらい待ちます。
45 分くらい待つ必要があります
7. Access routing の項目
インターネットから Apigee ランタイムに対してアクセスできるようにするか？というのをネットワークレベルで聞いています。今回はインターネット公開された API をデプロイする想定なので、下の Enable internet access を選択します。
Enable internet access を選択することにより、インターネットから API プロキシにアクセス出来る様にするためのコンポーネントの作成画面に移ります
この項目をチェックすることにより、次の入力項目がいくつか現れます。適切に入力することにより、インターネット経由のリクエストが外部 HTTPS 負荷分散へ到達し、更にバックエンドサービスとして登録しているネットワークブリッジ VM を経由して Apigee ランタイムまで到達し、これからデプロイする API からのレスポンスを得ることが出来るようになります。今回の設定項目としては以下の通り、
- Use wildcard DNS service: オフ (独自ドメインを使います)
- Domain: 環境グループに紐付けるホスト名(= 外部 HTTPS 負荷分散に付与される静的外部 IP と紐付ける DNS レコード名)
- Subnetwork: ynakaya-eval-apigeex-subnet
- SSL Certificate: 入力しない (Google マネージド SSL 証明書を使用します)
この設定により、顧客管理のプロジェクト(今回でいうと ynakaya-eval-apigeex-project) に 外部 HTTPS 負荷分散が、顧客管理のサブネット(今回でいうとynakaya-eval-apigeex-subnet)内に、ネットワークブリッジ VM が構成されます。なお、評価組織に作成される環境グループのホスト名も、ここで入力した Domain の値となります。
インターネット アクセスをさせるための追加設定
SET ACCESS を選択して完了です。特に問題なく構築が完了すると、以下のような画面が出てきますので、CONTINUE を押します。
一通りの環境構築が完了しました
8. Recommended next steps
Recommended next steps
一通りの構築が完了しましたが、最後に幾つか必要な対応が残っています。
-
Configure DNS: 割り当てられた外部 HTTPS 負荷分散向けの静的外部 IP を、Access routing の項で設定したホスト名で DNS レコード登録します。人によって DNS 空間の管理は異なりますので、今回ここの手順は割愛します。
-
Test your Apigee runtime end to end: デプロイした Apigee インスタンス上にサンプルプロキシがデフォルトで構成されているので、それをテストします。外部 HTTPS 負荷分散向けに設定したドメイン名は非公開ですが、ベースパスは /hello-world だそうです。試しにアクセスしてみましょう。使用するのは Postman です。
Postman を使って GET メソッドで 外部 HTTPS 負荷分散にアクセスすると、"Hello, Guest!"と 200 番が返ってきました。成功です。
無事にサンプルプロキシにアクセス出来ることを確認できました。 -
Add developers and other collaborators: デプロイした Apigee 組織における IAM 役割を設定します。今回ここは割愛しますが、Google Cloud IAM での制御の仕方の詳細はこちらを御覧ください。
OPEN APIGEE CONSOLE を押すと、以下の画面に遷移しました。こちらもうまく出来ていそうです。
Apigee コンソールの TOP 画面
右メニューの Develop → API Proxies を辿れば、先程 Postman 経由でアクセスしたサンプルプロキシがデプロイされていることも確認することが出来ます。
API Proxies でサンプルプロキシがあることが確認できる
Admin → Environments → Instances を選択すると、Google 管理の VPC 上にある Apigee インスタンスを確認することが出来ます。プライベート サービスアクセスで Allocate した 192.168.8.0/22 から、2 つの /28 ビットのレンジが使われていることも確認できます。
Admin→Environments→Instances では、Google 管理の VPC で稼働する Apigee インスタンスの設定を確認することが可能
Admin → Environments → Overview を開くと、評価組織でデフォルトで作成される環境である eval 環境があることを確認できます。
Admin→Environments→Overview と進むと、環境の一覧が表示されます
Admin → Environments → Groups を開くと、eval 環境を含んだ eval-group 環境グループがあることも確認することが出来ます。
Admin → Environments → Groups を開くと、eval 環境を含んだ eval-group 環境グループがあることも確認出来ます。
Google Cloud コンソール側を見ても、顧客管理の VPC と、Google 管理の VPC が VPC ネットワークピアリングを経由して接続されていることを確認することが出来ますね。
VPC ネットワークピアリングが構成されていることが確認できる
お見せしたいスクリーンショットはたくさんあるのですが、一旦ここまででいわゆる初期の環境構築は一旦終了です。
サンプル API のデプロイ
いよいよ最後の項目です。先程構築した Apigee 組織に、自前で API プロキシをデプロイしてみたいと思います。API プロキシがアクセスするバックエンドサービスには、デモサイトとして用意されている https://mocktarget.apigee.net/iloveapis を使います。このターゲット自体、インターネットに公開されているものでちょっとつまらない気はしますが、自分で作った Apigee ランタイム上に API プロキシをデプロイして、それが動くだけでも嬉しいですよね。ということで、初めての API プロキシのデプロイに進んでみたいと思います。
ブラウザから直接 https://mocktarget.apigee.net/iloveapis を叩くとこんな感じです。<3 でハートを表したいんだと思います
1. API プロキシをデプロイする環境を選択して、API プロキシ作成画面に行く
改めて、環境は、Apigee インスタンスに紐付いている分離されたソフトウェア環境です。API プロキシをデプロイする際は、この環境を指定するところから始まります。下のスクリーンショットであれば、評価組織を作成すると自動的に命名される eval という環境を指定しています。今回はこのまま、赤枠で囲っている CREATE NEW を押して、API プロキシの作成画面に進みます。
eval 環境が選択されていることを確認して、CREATE NEW を押します
2. Create Proxy ウィザード
Create Proxy ウィザードが起動します。ここでは、Reverse proxy(most common) を選択します。
Reverse proxy(most common) を選択します
3. デプロイする API プロキシの詳細入力
Apigee コンソール上に表示されるプロキシの表示名と、外部 HTTPS 負荷分散の IP に紐付けたホスト名に続くベースパスを指定します。今回は、両方ともに myfirstproxy を指定します(Base pathでは /myfirstproxy という表記になります)。また、Target Expsting API の部分がいわゆる API プロキシがアクセスするバックエンドサービスの URL です。今回はここで先程申し上げた https://mocktarget.apigee.net/iloveapis を入力します。
プロキシの名前 / ベースパス /ターゲット(バックエンドサービス) を入力します
4. Common Policies 画面
この API プロキシに対する認証やクオータの設定等、本番実装の際よく使われるポリシーをこの段階で設定することが出来ます。ポリシーは、メッセージの形式の変換、アクセス制御の適用、リモート サービスの呼び出し、ユーザーの認証の追加などをコーディングレスで API プロキシに実装することが出来ます。Apigee のポリシーについてより理解したい場合は、こちらのリンクを参照するとよいでしょう。ここでは、Pass through (no authorization) のラジオボタンだけ選択して、次に行きます。
API プロキシに追加するポリシー、基本的なポリシーはここで追加することが可能
5. サマリ画面の確認
今まで設定してきた項目が正しいことを確認します。今回はそのまま eval 環境にデプロイしてしまうので、下の Optional Deployment にチェックを入れて、 Create and Deploy をクリックします。
問題なさそうであれば、Create and Deploy を押して完了
6. API プロキシの確認とインターネット経由でのアクセス確認
ということで、一通りの設定が完了しましたので、まずは Apigee コンソールから作成した myfirstproxy が正しくあるかを確認してみます。
myfirstproxy の存在を確認
はい、myfirstproxy が出来ていることがわかりますね。それでは、Postman 経由で、作成した https://{外部 HTTPS 負荷分散のホスト名}/myfirstproxy にアクセスしてみましょう。
I <3 APIs の表示を確認できました
無事に自分の環境でデプロイした API プロキシを経由して、I <3 APIs と表示されましたね。
おまけ: Private Service Connect を使った Apigee ランタイムの接続
Private Service Connect を使うと、初期環境構築時に作成した外部 HTTPS 負荷分散から、ネットワークブリッジ VM を経由せず、サービスアタッチメントと呼ばれる Google 管理の VPC にある単一のアタッチメントポイントに直接到達させることが出来ます。ネットワークブリッジ VM の管理をどうする？と考えるお客様には有益なオプションかと思います。記事執筆時点で幾つかの制約がありますので、概要含め、こちらの記事をご参考いただければと思います。
終わりに
今回は「Apigee X の評価組織を使った初めての API プロキシ」ということで、Apigee X の概要を一通り説明した後、Apigee X の環境を作って、初めての API を公開してみました。実際の API 公開に際しては、複数の API プロキシをバンドルして他の企業や一般ユーザーに API を使ってもらう為の API プロダクトや、API プロダクトに紐付いて、API ドキュメントの生成や API へのアクセスの管理をユーザー主体で利用出来る統合ポータル等、便利な機能がたくさんあります。是非、今回紹介した部分で Apigee の最初の理解と環境構築を皆様でも試して頂き、Apigee のドキュメントを活用して、楽しい API ライフを送っていただきたいと思います！！
Discussion