Google Cloud の API Gateway を眺めてみる
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 14 日目の記事です。
はじめに
2020 年の 9 月に全世界待望 (?) の API Gateway のベータ版がリリースされました。このサービスにより、Google Cloud のサーバーレス系サービスをバックエンドにした API をより簡単に作成・管理することができるようになりました。
ところで、元々 Google Cloud には Apigee や Cloud Endpoints といった API 系サービスがありました。今回の API Gateway はそれらとどのように違うのでしょうか？
本記事では新しく Google Cloud の仲間に加わった API Gateway の立ち位置を整理し、実際に API Gateway を試してみたいと思います。
Apigee と Cloud Endpoints おさらい
Apigee
Apigee はエンタープライズ向けの API 管理プラットフォームです。以下のように、API を作成・運用していく上で必要となる多くの機能が実装されています。
- 設計 (Open API エディタや GUI フロー)
- 保護 (Apigee Sense)
- 公開 (柔軟にカスタマイズ可能なデベロッパー ポータルなど)
- 分析とモニタリング
- 収益化 (課金レポートや支払いゲートウェイなど)
Apigee はビジネス上の課題にフォーカスしており、大規模なシステム連携を必要とするエンタープライズや、API 自体をビジネスとして展開している企業向けの製品と言えるでしょう。また、価格モデルも GCP 料金とは別の Apigee ライセンスを購入する形になっています。
Cloud Endpoints
一方で Cloud Endpoints はよりライトウェイトな API 管理サービスです。Apigee とは異なり、GCP 上のアプリケーション (GCE, GKE など) の隣に ESP (Extensible Service Proxy) と呼ばれる Proxy をデプロイし、API としての機能を持たせています。
一般に API 管理というとゲートウェイ的なものがクライアントとアプリの間に入るイメージですが、Cloud Endpoints ではユーザが Proxy をアプリ毎にデプロイし、その設定を Cloud API やコンソールを通して管理するイメージです。
Cloud Endpoints は開発者がアプリに API の機能を持たせる際の共通機能 (作成、テスト、管理、認証など) を開発者目線で提供しているサービスです。価格モデルは他の GCP サービスと同様、使った分だけお支払いいただく従量課金制となっています。
API Gateway の立ち位置と使い分け
Apigee と Cloud Endpoints は同じ API 系のサービスであっても解決しようとしている問題が異なることを復習できました。それでは今回リリースされた API Gateway はどのような問題を解決しようとしているのでしょうか？
さて、実は Cloud Endpoints にはひとつ問題がありました。一例として、Cloud Functions を使った API サーバを作成することを考えてみてください。もちろん、Cloud Endpoints はバックエンド サービスとして Cloud Functions もサポートしています！
Cloud Endpoints はユーザが自ら ESP をデプロイする必要があります。Cloud Functions をバックエンドとして使う場合、コンテナ イメージとして提供されている ESP を Cloud Run として起動する必要があります。
それでは Google App Engine をバックエンドに使う場合は？
はい。
ついでに Cloud Run も見てみましょうか。皆さんご想像の通りですよ。
いずれのケースも ESP をデプロイした Cloud Run を前に置く必要があるんですね。これ、少し面倒くさくないですか？ Google がこれを管理してくれたらどうでしょうか？
というわけで、出てきたのが API Gateway です！
今まで皆さんが ESP をデプロイしていたところに API Gateway が出てきましたね！これがまさに今回リリースされたサービスです。
解決したい問題は Cloud Endpoints のそれとほぼ変わりません。GCP ネイティブのサービスとして開発者目線で API を作成する時の共通機能を集約し、安全かつ素早く API を開発・運用することです。ただ、もう皆さんがご自身で Proxy を管理する必要はありません。
ベータ版時点では前述のような課題を解決するため、サーバーレス サービス (GAE, Cloud Run, Cloud Functions) をバックエンドとするケースにフォーカスしているようです。
API Gateway を試してみる
さて、それでは実際に API Gateway を触ってみます。なお、公式ドキュメントにある通り、以下はベータ版 (2020/12/14 執筆時) での結果であり、今後変更される可能性があります。実際に試される場合は最新の公式ドキュメントをご参照ください。
API の作成
まずバックエンド サービスを Cloud Functions で作成します。単純に文字列を返すだけの非常にシンプルな HTTP トリガーの Function です。
今回はコンソールからこの Function に対して API Gateway をセットアップしてみます。
まず API Gateway から “Create API” で Sample API を作ります。
続いて API Config というものを作ります。これは API の挙動を OpenAPI 仕様に基づいて記述したものになります。ここでは公式ドキュメントのサンプルをベースに以下の YAML ファイルを使いました。
重要なのは info.title に API ID を設定することと、x-google-backend.address にバックエンド サービスの URL を設定することです。今回で言えば先ほどデプロイした Function の Trigger URL ですね。
このファイルを使って API Config を作ります。
ここで “Select a Service Account” とありますが、これが Gateway がバックエンドサービスを呼び出す時に使うサービス アカウントになります。API Gateway を利用する場合、通常はバックエンド サービスへの直接アクセスを防ぎたいと思いますが、こちらのサービス アカウントを利用することで簡単に実現できますね。
最後に Gateway を作成します。
Gateway 毎に “https://[gateway-name]-[文字列].de.gateway.dev” のような URL が払い出されるので、そちらにアクセスすることで Cloud Functions に正しくルーティングされていることが確認できました。
API Gateway の構成をざっくり図解すると次のようになります。
その他の機能
長くなってきたのでこの辺にしておきますが、その他の機能にも少し触れておきます。
まず認証ですが、Cloud Endpoints と同じく API キーやサービス アカウントに加え、
- Firebase authentication
- Google ID
- Auth0
- Okta
といったサービスの JWT をサポートしています。
追記: 23 日目の記事として Yuki Suwa さんが「Firebase Authentication を使って API Gateway の認証を行う」でこの部分について詳細に書かれています！
また、割り当て制限の設定により、Cloud Endpoints と同様に API リクエストの制限を行えるようです。
Cloud Endpoints に比べるとまだベータ版ということで機能は少ないですが、今後の展開に期待できるサービスではないかと感じています。
終わりに
業界最高レベルの機能を揃えた Apigee に、自分で Proxy をデプロイする必要のある開発者目線の Cloud Endpoints と、これまで Google Cloud の API サービスはなかなか両極端だったと思います。今回の API Gateway はそのギャップを埋める良いサービスになりそうです。
明日 15 日目は Kazuu さんによる「Cloud Run と Buildpacks で簡単にコンテナ使えるよ！」です。お楽しみに！
