SPECIALIST

多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。

BACK

NGINXにたどり着くまでの軌跡 API Gatewayの夢と本当に必要だったもの

湯川 勇太

2024.9.30

この記事について

2024年9月4日にF5ネットワークスジャパン合同会社様が主催するF5 AppWorld 2024 TOKYO※1が開催されました。

私はこのイベントで「NGINXにたどり着くまでの軌跡 API Gatewayの夢と本当に必要だったもの」というタイトルで発表させていただきました。

この記事は本発表の中で話しきれなかったことを補足させていただくものです。

前置き

私が担当している企業様ではAPIを保護するための手段としてNGINX Plus※2を活用しています。NGINX PlusはF5 Networks社が機能拡張し、商用サポートしたNGINXです。

APIを保護する手段としては、もともとAzureが提供するAPI Managementを利用していましたが、AzureからAWSへの基盤移行をきっかけにAPI ManagementをNGINX Plusに置き換えました。

NGINX Plusを採用した主な理由は以下の3点です。

  1. なぜNGINXなのか：
    現行で利用している機能が限られていたので、構成がシンプルでトラブル対応の不安が少なく、コスト的にもスモールスタートしやすいNGINXが最適であると考えました。
  2. なぜNGINX Plusなのか：
    API認証で必要な機能を提供してくれていて、サポートのレベルが高いこと。これがNGINX Plusを採用した理由です。
  3. なぜNGINX Ingress Controllerではないのか：
    NGINXのノウハウを活用したかったので、Ingress Controllerではない、NGINX Plusを採用しています。

ここまでが前置きです。今回ご紹介するのは、この方針に至る前日譚、API Gatewayの検討初期からNGINX Plusまでの検討経緯について取り上げたいと思います。

※2 NGINX Plusは、F5 Networks社が機能拡張し、商用サポートしたNGINXです。

API Gatewayの夢

当初、API Gatewayには多くの役割を期待していましたが、現状では以下のように整理されています。

なぜこんなに多くの役割を期待したのか。それはなるべく簡単に以下を実現したかったからです。

  • APIを純化したい
    ○API本体をビジネスロジックに集中させ、それ以外のものをAPI Gatewayに担わせたい
    ○バリデーション、複数APIの統合、キャッシュ、リトライ、CORS、ルーティング、ヘッダ書き換え、レガシーシステムへの窓口
  • APIの利用を促進したい
    ○有識者の確保や関係者間の調整を減らし、スムーズにAPIを利用できるようにしたい
    ○API利用申請ワークフロー、問い合わせ窓口、開発サーバ
  • APIを保護したい
    ○APIの利用を制限し、想定外の利用による問題を防止したい
    ○通信制限、流量制限、API認証、API認可、API権限管理、オンラインの冗長化、開発ポータル、利用状況の可視化

多機能なAPI Gateway製品は、少なくともカタログ上はこれらの機能を提供しています。
そのため、API Gatewayを使いこなせばすべての課題が解決するのではないかという夢をみたのです。

夢のあと

最終的にAPI Gatewayで実現しているものは多くありませんが、要件がなくなったわけではありません。

ほとんどの要件はAPI Gateway以外の手段で実現しています。API Gatewayの機能が足りなかったというわけではありません。機能としては多くのものをカバーしていましたが、それをあえて利用せず、別の手段で実現しました。

F5 AppWorld 2024 TOKYOでは夢と現実のギャップが大きかった青枠の３項目について取り上げました。

ここではその他の項目について取り上げたいと思います。具体的には以下の6項目です。

  1. リトライ
  2. バリデーション、キャッシュ、複数APIの統合
  3. 開発者ポータル、問い合わせ窓口
  4. API利用申請ワークフロー
  5. 利用状況の可視化
  6. API認証、API権限管理

リトライ

どんな夢をみたのか

リトライで見た夢は以下でした。

  • API Gatewayにリトライを入れて、アプリロジックをリトライを排除した単純なものにする

直面した現実

  • 呼び出し元のクライアントにリトライを実装してもらえるケースが大半だった

API Gatewayでリトライを実装すること自体はNGではありません。呼び出し元にリトライの実装を依頼できない場合に、リトライをAPI側で実装する手段としてAPI Gatewayを活用するのは良い方法だと思います。

たまたま今回はリトライを呼び出し元のクライアントに実装してもらえるケースが大半であったというだけです。

そもそも正しくリトライを設計するのは難しい

話題が変わってしまうので深く触れませんが、そもそもリトライを設計するのは難しいです。

以下、リトライ設計の注意点を列挙しておきます。

バリデーション、キャッシュ、複数APIの統合

どんな夢をみたのか

バリデーション、キャッシュ、複数APIの統合で見た夢は以下でした。

  • API Gatewayでバリデーションやキャッシュ、API統合などを実装すればアプリロジックを簡単にできる
  • スキーマとバリデーションチェックで問題があるリクエストをAPI Gatewayではじければセキュリティ対策にもなる

直面した現実

  • API Gatewayにロジックを記述することはできるが、アプリよりテストがしにくい

API Gatewayにはスクリプトを使ってロジックを記述することはできるものがありますが、通常のアプリを開発する場合と比べるとテストがやりづらく、開発環境もテスト環境も確保しにくいという問題があります。

例外的に一部でロジックを書いているものはありますが、なるべくスクリプト利用するのは避けるという方針にしました。

開発者ポータル、問い合わせ窓口

どんな夢をみたのか

開発者ポータル、問い合わせ窓口で見た夢は以下でした。

  • API Gatewayの開発者ポータルがあれば、有識者ボトルネックを解消できる
  • コミュニケーションによる誤解や思い込みがなくなり、開発者が皆同じ仕様を理解できるようになる

直面した現実

  • 社内向けの開発者ポータルの場合、APIだけのポータルではなく、ファイル連携まで含めたポータルが必要
  • ポータル整備のモチベーションとコストを認めることが難しい
  • 社外向けの開発者ポータルの場合、API Gatewayが機能として提供できるのは社外向け提供しなければならない内容の一部だけ

社内のシステム間連携はファイルの方が多い

特に巨大企業の場合、もっとも一般的なシステム間連携の手段はAPIではなくファイル連携だと思います。

そのため開発者ポータルが管理する対象がAPIだけでは不十分で、ファイル連携についてもポータルがあってほしいのです。

ファイル連携の場合は、データを提供する側のプロダクトが管理しているデータを元に必要なものを抽出して渡すので、既存のファイルIFの仕様だけをまとめたポータルというよりも、プロダクトが管理しているデータをまとめたカタログ化したデータカタログが必要になります。

ポータル整備のモチベーションとコスト

データカタログ製品は稼働環境からツールを使ってメタデータを収集し、ポータルに反映するような機能を持っていますが、項目名以上の意味を読み取ってポータルに掲載することは難しく、人が情報を補う必要があります。こうした場合に高いハードルになるのが、データ登録作業のモチベーションとコストを維持することです。

このデータ登録作業をプロダクトの維持保守担当者が片手間でやることになると、作業が進まず現実との乖離が発生します。

こうした課題の手段としてAIの活用を試みているサービスも出てきているので、現状の問題はいずれ緩和されるのかもしません。

社外向けの開発者ポータルでは様々な機能が求められる

社外向けの開発者ポータルを社外の開発者に提供するためには、事前に審査や約束事ができている必要があります。

本件については「API利用申請ワークフロー」の中でご説明します。

API利用申請ワークフロー

どんな夢をみたのか

API利用申請ワークフローで見た夢は以下でした。

  • API Gatewayの開発者ポータルから利用を申請すればすぐにアクセス手段が提供され、開発を開始できる

直面した現実

  • 利用者が社外の場合は契約等が必要。API Gatewayだけで契約手続きのワークフローまでまかなえない

社外向けには与信や契約手続きが必要になることが多い

与信や契約手続きのために必要な仕組みの方が重要で、業務的にもこの部分に時間がかかっていることが多いです。

ここに踏み込んで検討をしないと利用開始までのリードタイムを短縮できないため、API Gateway以外の検討事項をしっかり検討し、APIキーの発行や権限付与についてもその検討結果に合わせた仕組みにした方が良いと思います。

利用状況の可視化

どんな夢をみたのか

利用状況の可視化で見た夢は以下でした。

  • コミュニケーションによる誤解や思い込みがなくなり、開発者が皆同じ仕様を理解できるようになる

直面した現実

  • 社内向けの開発者ポータルの場合、APIだけのポータルではなく、ファイル連携まで含めたポータルが必要

現状はAPIの利用状況に応じて制限と課金を行うような要求がない

システム運用として利用状況を可視化するという意味ではAPMを利用している

API認証、API権限管理

どんな夢をみたのか

API認証、API権限管理で見た夢は以下でした。

  • APIの認証も権限管理もAPI Gatewayの中で一元的に管理できる

直面した現実

  • API認証といっても社内システム同士のものもあれば、社外システムからのものも、スマートフォン端末から社員が呼び出すものも、委託業者が呼び出すものも、エンドユーザ向けのものもあり、それぞれに求められる要件が異なる
  • ユーザ種毎に要件を整理し、必要な認証基盤を整理する必要がある

結果として、認証にはユーザ種毎に異なるIDaaSを利用しています。また、権限管理は認証時の返却項目と権限管理用のシステムを組み合わせています。

JWTの検証はNGINX PlusやAzureのAPI Managementで実装しているのですが、こちらについても場合によってはAPIの中の共通ロジックとして実装している場合もあります。

まとめ

イベントでご紹介した内容も含めて、当初API Gatewayでの実現を想定していたものがどうなったのかをまとめました。

要件 実装先 一言解説
開発用サーバ SoapUIなどのツール＋遅延発生させるツール さくっと開発で使うサーバはAPI Gatewayを使わなくても、SoapUIなど様々な方法で立てられる。応答遅延を発生させることが重要
レガシーシステムへの総合窓口 一旦断念。ゼロトラの文脈で復活するかも 総合窓口化されたAPI Gatewayは誰が運用するのか。可用性も懸念
オンライン冗長化 断念 不完全な対応しかできない
リトライ APIの呼び出し元 リトライを多段で仕込むと輻輳などの問題が起きる 。管理可能な一番外側のリトライに集約した方が設計・管理が簡単になる
バリデーション、キャッシュ、複数APIの統合 API提供システム内部 API Gatewayにロジックを記述することはできるが、アプリよりテストがしにくい 。現在はアプリで対応している
開発者ポータル、問い合わせ窓口 API Gatewayとは別に検討中 APIだけで必要なわけではなく、ファイル連携やメッセージ連携でも必要である データカタログ等と合わせて検討中
API利用申請ワークフロー 利用者種別毎の申請システムなど 利用者が社外の場合は契約等が必要でAPI Gatewayだけでまかなえない。 社内の場合は担当者間のやりとりをしているのが現状
利用状況の可視化 APM 現状はAPIの利用状況に応じて制限と課金を行うような要求がない 。システム運用としての利用状況の可視化はAPMを利用している
API認証、API権限管理 認証・権限管理サービス 認証にはIDaaSを利用している 権限管理は認証時の返却項目と権限管理用のシステムを組み合わせている

一つ誤解しないでいただきたいのは、API Gatewayがダメだと言いたいわけではないということです。API Gatewayに限らず何を手段とする場合であっても、以下の2点については気をつけた方が良いと思います。

  • 一つの仕組みにあまりにも多くのことを要求しすぎると結果としてコスト高になる
  • 多機能なものを採用してすべての課題解決を目指そうとしてもなかなか進まない

皆さんも夢を見すぎかなと思ったら、一度立ち止まって考えてみてください。