株式会社キカガクの北田です。 今回はキカガクのバックエンドとインフラストラクチャを支えている API Gateway についてお話ししていきます。
引用元: https://cloud.google.com/api-gateway/docs/about-api-gateway
Google API Gateway を使用することで GCP でサポートしているサーバレス環境（App Engine, Cloud Run, Cloud Functions, …）へのアクセスを REST API を経由して包括的にかつ安全に管理することができます。 詳しい説明やコンセプトは公式ドキュメントをご覧ください。
弊社に必要な導入要件
キカガクではサービスのバックエンド処理の多くを Cloud Functions や Cloud Run といったサーバレス環境で実行しています。 そして新機能開発などでバックエンドの関数を追加する際はその分新しくサーバレス関数のドメインが生成されます。 弊社で API 管理のプロダクトの導入背景として、弊社で提供している 企業様 向け SaaS「キカガク for Business」のご利用企業様が、そのようなドメイン URL をホワイトリストへ追加するコストを削減したいというものがありました。
エンタープライズ向けサービスを提供している企業であれば、このような課題も少なくないのではないでしょうか。 このような手間のかかるフローを簡略化すべくAPI Gateway を立ててカスタムドメイン化しておくことで、バックエンド関数が追加されても API Gatewayに登録するだけで、企業様の負担がなくなることになります。
Google API Gateway の選定
GCP では API を一括で管理する方法として、API Gateway の他に Apigee と Cloud Endpoint というサービスも存在しています。 こちらも Google Cloud からの比較記事が非常にわかりやすくなっているのでこちらをぜひご覧ください。
先述した要件を満たすためキカガクに導入する判断軸として下記３点に着目しました
- 料金
- GUI コンソールの充実度
- スケーラビリティ
などの観点を考えて Apige と API Gateway のいずれかで比較をしました。 先述のサービス比較記事にも記載がありましたが、Google ではまず最初に Apigee の導入を勧めています。実際に弊社のサービスの将来を見据えたときに確実に対応できるスケーラビリティを兼ね備えており、また GUI も充実したものになっている印象でした。
十分な機能性やスケーラビリティを兼ね備えている Apigee は非常に魅力的ですがその一方で、先述した、キカガクに導入する背景となったサーバレス環境のドメイン管理という文脈ではオーバースペックな印象を持ちました。
また、サービスの拡大に伴って必要に応じて API Gateway → Apigee にアップグレードできることもあり、最終的には API Gateway を採用しました。
ただし、Cloud Run などのサーバーレス プロダクトを活用するプロジェクトに取り組んでおり、サードパーティ製 API の管理、大規模環境に向けた最適化、一貫したガバナンスの確立が必要かどうかまだわからない場合は、プロジェクト レベルで API を公開できる軽量プロダクトの API Gateway が適しています。組織は小規模で開始して、組織やプロジェクトがスケールアップまたは拡大して新しい機能が必要になった場合は、Apigee にアップグレードすることを検討できます。
1 点、Apigee をテスト導入する前に注意していただきたのが、その料金です。 Apigee の料金は大まかにわけると下記になります
問題は１つ目の「Apigee ゲートウェイノード」です。ノードとは簡単に言うとAPI トラフィックを処理する Apigee 環境の単位のことで、トラフィック量が増えるにつれてその処理に必要なノードも増えていく構造なのですが、これが Apigee を有効にしたときに 固定費として $1,500 請求されます。 キカガクでもサービス比較をしている際に、従量課金部分に目を向けすぎていたためこちらの記載に気が付かず、billing レポートを見た時に猛省しました（涙）
今後 Apigee の導入を検討される際は、無料トライアルを試す前に確認してみてください。
実際のアーキテクチャ
キカガクでどのように API Gateway を活用しているかわかりやすいように、シーケンス図にしました。
アーキテクチャとしてはとてもシンプルで、クライアントからのリクエストを API Gateway で受け取ります。
リクエストが有効なものであるかを Gateway 側でバリデートし、有効であると判断されたリクエストをバックエンドにプロキシしています。
同じように Cloud Run の実行もセキュアに行なうため、Cloud Run Invoker という実行者権限のみを持たせているサービスアカウントを Gateway で指定して実行させています。
苦労した点
ヘッダーのトークンが上書きされてしまう問題
クライアントから Gateway にリクエストする際に、認証されたリクエストであるかを検証するために、HTTP ヘッダーにリクエストユーザーの ID をセットしてリクエストしています。
ですが、Cloud Run 側でその ID を確認したところ、ヘッダーにセットした ID が上書きされていました。
原因は、 Gateway 側の backend address というところで Cloud Run URL を指定していると元の Authorization ヘッダーが書き変わってしまうそうです。 この問題についてはドキュメントに記載がありました。
OpenAPI 2.0 を使用している点
API Gateway では OpenAPI の 2.0 規格を採用しており、最新の 3.0 が使用できません。 そのため、 3.0 で採用されている機能や改善を取り入れることができません。
実際に弊社が不便だと感じたのが、管理する API バックエンド URL が増えるにつれて OpenAPI ファイルの記述が嵩んでいきます。 その際にファイルの見通しをよくするためにファイル分割を $ref 参照を使って行いたかったのですが、残念ながら利用することができませんでした。
まとめ
API Gateway の導入は開発チームにとって１つの大きなチャレンジでしたが、無事に弊社のプロダクトに組み込み活用することができました。
これからもご利用ユーザー様や企業様にとって最高の価値を提供することができるように、開発チームではさまざまな技術挑戦をしていきます！
そして、キカガクではサービスの成長・拡大に伴って一緒に開発する仲間を募集しています！ カジュアルにお話しする機会も設けているので、一度私たちキカガクのエンジニアとざっくばらんにお話ししましょう！
