分散型ゲートウェイの担い手：進化するAPI管理

Rajesh Narayanan 著

レビューおよび寄稿：Ian Smith、Sam Bisbee、Andrew Stiefel、Lori MacVittie、Mike Wileyほか

F5 Office of the CTOの見解

F5のOffice of the CTOチームは、1年以上にわたりAPI関連の技術分野を調査してきました。この最新のホワイトペーパーは、進化し続けるAPIエコシステムへの理解を深める取り組みの一環です。

これまで詳述してきたAPIスプロールの管理上の課題は、APIゲートウェイスプロールという新たな課題につながり、従来のアプローチだけでは十分に対処できません。GraphQLなどのグラフ技術は、APIに伴う複雑さの抑制に大きく貢献する可能性がありますが、課題は接続性、セキュリティ、ルーティングの範囲を超えるため、解決策の一部にすぎません。システムとアプリケーションのスケーリングに関する約30年の専門知識に基づく適切なアプローチは、GraphQLを採用しつつも、それだけに依存しない、フェデレーション型ではなく分散型のアーキテクチャを基盤とするものです。

本書では、APIゲートウェイの乱立という課題に対処するための分散アーキテクチャアプローチについて考察します。

概要

デジタル経済はAPIによって支えられ、やがて「API駆動型経済」が実現します。API Sprawlホワイトペーパーに続き、今回はAPIスプロールの影響を解消または軽減する方法を探りました。GraphQLはAPIスプロールの影響を軽減する有望な手段に見えますが、APIコードベースの大部分を書き直す負担が開発者にかかる傾向があります。しかし、GraphQLを効果的な「ゲートウェイアクター」として利用するという新たな考え方が注目されています。ゲートウェイアクターとは、クライアントの近くに作成され、APIリクエストを開始する関数またはプロセスです。最初のAPIゲートウェイとして機能し、APIリクエストを終端します。また、一時的なものとして、リクエストの処理後に破棄することもできます。

開発者と運用チームがAPIゲートウェイよりもAPI管理を優先していることに加え、APIスプロールによってAPIゲートウェイスプロールという問題が生じることも明らかになりました。開発者にとって最大の関心事は、APIが適切かつタイムリーに機能するようにすることです。一方、運用チームは、検出、セキュリティ、ユーザビリティ、アクセス制御などをより重視します。現在、APIゲートウェイはAPIインフラストラクチャの重要な構成要素であるため、APIの増加に伴ってAPIゲートウェイの導入も増え、APIゲートウェイスプロールにつながることが明らかになりました。

今後のAPIアーキテクチャには、デプロイと運用を簡素化しながら、APIスプロールを受け入れられるよう進化することが求められます。ここで提案するアーキテクチャは、APIゲートウェイの設計パターンが目指すべき次の進化形です。GraphQLは、このアーキテクチャの中核でも必須要素でもありませんが、ゲートウェイアクターパターンを強化できます。

まとめ

API管理エコシステムは、モノリシックなAPIゲートウェイを管理する方式から、より現代的なシステム設計アプローチへ移行する必要があります。これにより、API管理エコシステムの俊敏性と有効性が向上します。

“新たに形成されつつあるAPIエコシステムの規模と複雑さを従来のAPIゲートウェイではもはや管理しきれず、APIアーキテクチャは今、転換点を迎えています。”

APIゲートウェイの乱立 — 分散モノリスの管理

APIエコノミーにおいてすでに課題となっているAPIスプロールは、APIゲートウェイスプロールも引き起こします。これは、多様なAPIゲートウェイベンダーのテクノロジーと、独自の方針に固執するAPIゲートウェイ管理チームによって、APIの管理が制御不能になった状態です。新たに形成されつつあるAPIエコシステムの規模と複雑さを管理するには、API呼び出しのエントリーポイントとして機能する専用ソフトウェアレイヤーである従来型APIゲートウェイ（API-GW）では、もはや不十分です。そのため、APIアーキテクチャは今、転換点を迎えています。

図1は、管理対象がAPIスプロールからAPIゲートウェイスプロールへと移行してきた経緯を示しています。

図1：APIの乱立からAPIゲートウェイの乱立へ

上記の設計パターンは、図2に示すように、APIゲートウェイが分散データプレーンを構成し、コントロールプレーンが一元化される構成を示唆しています。

APIゲートウェイは、APIの制御とセキュリティを一元化する、最新のソフトウェアアーキテクチャに不可欠なコンポーネントです。しかし、提供する機能が増えるにつれて複雑さが増し、管理も難しくなっています。多くの場合、こうしたゲートウェイは、幅広い機能を単一のパッケージにまとめたモノリシックなシステムへと発展しています。

図2：分散モノリスを管理

複数のゲートウェイを管理する構成は分散設計のように見えますが、実際には真の分散には至っていません。ゲートウェイ同士が依然として密結合であり、分離が難しいリソースや構成を共有しているためです。その結果、多くの企業が分散モノリスと、それに伴うあらゆる課題を抱えることになります。

従来型APIゲートウェイアーキテクチャ

図3は、従来のAPIゲートウェイのアーキテクチャを示しています。クライアントから送信されたAPIリクエストは、まず共有ネットワークまたは専用ネットワークを経由し、ファイアウォールを通過してAPIゲートウェイに到達します。次に、リバースプロキシとして機能するAPIゲートウェイが、トラフィックをAPIワークロードに転送します。

図3：従来のAPIゲートウェイアーキテクチャ

APIゲートウェイが企業全体に展開される場合や、APIの乱立に対処しながら、APIワークロードをリージョン、ゾーン、複数のクラウド、エッジへと運用上移行する場合、従来型のAPI-GWはAPI管理のボトルネックになります。企業全体を一元的に管理、制御する仕組みがないまま、複数のAPI-GWが異なるチームによって立ち上げられます。個別または一群のAPIサービスを別のインフラストラクチャ（クラウドなど）に移行する場合、運用チームには、登録、検出、認証、ネットワーク、セキュリティ、ガバナンス・リスク・コンプライアンス（GRC）ポリシーなど、API管理のあらゆる要素を移行する手段が必要です。

したがって、図3に示すアーキテクチャは、時間の経過とともに分散モノリス（図2）の管理につながるため、長期的には拡張性がなく、実用的でもありません。

APIゲートウェイがボトルネックとなる原因には、2つの問題があります。（1）APIゲートウェイベンダーの乱立、（2）企業がより多くの場所でより多くのアプリケーションを実行するようになるにつれて、段階的な拡張が必要になることです。

APIゲートウェイベンダーの乱立：APIゲートウェイベンダーの乱立への対応は、組織や人に関わる課題です。すべてのチームに単一のAPIゲートウェイベンダーを採用するよう納得してもらうことは難しく、新しいベンダーへの移行にも多大な手間がかかる場合があります。その結果、組織は複数のゲートウェイベンダーの管理に時間とリソースを費やすことになります。この問題への対処は可能ですが、現実には完全な解決が難しい場合があります。
アプリケーションのスケーリング：単一拠点でより多くのユーザーに対応する必要がある場合や、複数の拠点にデプロイする必要がある場合、アプリケーションのスケーリングが課題となります。そのため、アプリケーションを水平方向または垂直方向にスケーリングする必要があります。しかし、アプリケーションのスケーリングに伴い、APIゲートウェイもスケーリングする必要があります。また、現在のアーキテクチャパターンに基づいてスケーリングに対応するため、複数の拠点へのデプロイが必要になる場合もあります。その結果、APIゲートウェイの運用管理が複雑になる可能性があります。

解決策：分散ゲートウェイアクターパターン

図4は、APIゲートウェイの乱立に対処するための分散ゲートウェイアクターパターンを示しています。分散パターン自体は新しいものではありませんが、本書ではAPIゲートウェイのコンテキストでこのパターンを形式化しています。クライアントがAPIリクエストを開始すると、一時的な分散ゲートウェイアクターが、可能な限りクライアントに近い場所でオンデマンドにインスタンス化されます。APIトランスポート層は、ゲートウェイアクターから簡素化されたAPIゲートウェイにAPIリクエストを送信します。その後、APIゲートウェイが適切なAPIワークロードにリクエストをルーティングします。分散アクターでのGraphQLサポートは、このパターンを機能させるための要件というより実装上の詳細ですが、サービスオーケストレーションなどの機能をサポートできます。そのため、新たなサービスオーケストレーション層を構築する代わりに、GraphQLでその役割を担える可能性があります。

図4：GraphQLベースの分散ゲートウェイアクター

明確にすると、トラフィックは右から左へ流れます。つまり、図5に示すように、クライアントは右側にあり、APIリクエストはクライアントから開始されます。

図5：トラフィックはクライアント（右）からAPIワークロード（左）へ流れます

企業内および企業間のAPI管理において、APIゲートウェイへの過度な依存を解消または軽減するために、ゲートウェイアクターを使用する新たなデプロイパターンが登場しています。このアーキテクチャにGraphQLは必須ではありませんが、ゲートウェイアクターはGraphQLのサポートに適しているため、今こそ導入に適したタイミングです。

“企業内および企業間のAPI管理において、APIゲートウェイへの過度な依存を解消または軽減するために、ゲートウェイアクターを使用する新たなデプロイパターンが登場しています。”

API管理におけるAPIゲートウェイの役割

APIゲートウェイへの理解を深めるには、まず最新のAPI管理インフラストラクチャを構成するさまざまな要素を確認することが重要です。

API管理のインフラストラクチャと機能

図6は、API管理に不可欠なさまざまな機能とコンポーネントを包括的に図示しています。バックエンドサービスへのトラフィックのルーティングと管理に必要なAPIゲートウェイに加え、重要なインフラストラクチャコンポーネントがほかにもいくつかあります。たとえば、認証、レート制限、キャッシュ、サービスメッシュなどのソリューションが含まれます。これらの機能を組み込むことで、組織はAPIを制御し、セキュリティを強化して、パフォーマンスを最適化できます。

図6：API管理とインフラストラクチャの機能

API Gatewayの共通機能

APIゲートウェイで広く知られている一般的な機能を見ていきましょう。

ルーティング：リクエストのパスまたは内容に基づいて、適切なバックエンドサービスにリクエストをルーティングします。
認証と認可：単一のイングレスポイントとしてリクエストを認証および認可し、認可されたクライアントのみがバックエンドサービスにアクセスできるようにします。
レート制限：クライアントが基盤となるAPIにリクエストを送信できる頻度を制限することで、過剰な利用を防ぎ、バックエンドサービスを過負荷から保護します。
キャッシュ：基盤となるAPIからのレスポンスをキャッシュすることで、バックエンドサービスへのリクエスト数を削減し、パフォーマンスを向上させます。
プロトコル変換：HTTPやWebSocketsなど、異なるプロトコル間の変換を行い、クライアントがさまざまなプロトコルを使用して基盤となるAPIにアクセスできるようにします。
負荷分散：リクエストを複数のバックエンドサービスに分散し、スケーラビリティと信頼性を向上させます。
セキュリティ：暗号化や復号などのセキュリティタスクを処理し、データを安全に送信できるようにします。
分析と監視： 使用状況の指標とエラー情報を追跡してレポートすることで、システムの利用状況を可視化し、パフォーマンスのボトルネックやエラーの特定を支援します。
バージョン管理：基盤となるAPIのバージョンを管理し、クライアントがニーズに応じて異なるバージョンのAPIにアクセスできるようにします。
サービスディスカバリ：利用可能なバックエンドサービスを検出し、リクエストを動的にルーティングすることで、より動的で柔軟なサービスディスカバリを実現します。

コンテキスト：APIゲートウェイに注目

API管理インフラストラクチャの機能を分析した結果、APIゲートウェイの役割について理解を深め、現在のモノリシックなAPIゲートウェイ設計に代わる選択肢を検討する必要があることが明らかになりました。

API数の増加によって、すでにAPIの乱立やAPIゲートウェイの乱立が生じています。また、モバイル化または高度に分散化されたクライアントが増え、エッジを含むあらゆる場所でコンピューティングインフラストラクチャを利用できるようになっています。そのため、APIエコシステムの俊敏性、柔軟性、拡張性、パフォーマンス、セキュリティの向上につながるアプローチが必要です。

この新たなアプローチには、真の分散アーキテクチャのメリットを最大限に活用できる、合理化された設計が必要です。

APIゲートウェイ

APIゲートウェイの機能と適用範囲をさらに分析し、その特性と制約を明らかにします。

APIゲートウェイは、今日のAPI管理インフラストラクチャに欠かせないコンポーネントです。その中核となるのはリバースプロキシであり、受信リクエストに対してさまざまな処理を実行しながら、クライアントとバックエンドサービスの仲介役を果たします。たとえば、ゲートウェイはリクエストを適切なバックエンドサービスに転送する前に、認証、レート制限、ルーティング、セキュリティポリシーの適用、監視、バージョニングなどを実行できます。バックエンドサービスがリクエストを処理してレスポンスを返すと、APIゲートウェイはそのレスポンスをクライアントに転送する前に、キャッシュ、プロトコル変換、レスポンス処理などを実行できます。

APIの数が増えるにつれ、APIゲートウェイは基本的なルーティングにとどまらない多様な新機能を備えるようになり、実質的にモノリシックなシステムへと進化してきました。現在では、認証やレート制限などの処理も担い、パフォーマンスの向上とバックエンドサービスの負荷軽減に寄与しています。しかし、こうした機能強化が進んでも、APIゲートウェイは依然としてバックエンドサービスへの単一のアクセスポイントであるため、高度に分散した環境では課題となる可能性があります。

特に、クラウド、ハイブリッドマルチクラウド、エッジインフラストラクチャの普及に伴い、APIゲートウェイを使用するアプローチでは、俊敏性、セキュリティ、管理性の維持が難しくなっています。クライアント、デバイス、アプリケーションワークロードが広範な場所に分散する可能性があるため、APIゲートウェイは、必要なレベルのエッジ対応アーキテクチャを実現するには適していない場合があります。

APIゲートウェイの課題

APIゲートウェイは、幅広いタスクを処理し、複数のシステムと連携する必要があるため、一般に導入と管理が容易ではありません。APIゲートウェイの管理は複雑になり得ますが、APIの可用性、セキュリティ、スケーラビリティを確保するうえで重要な作業です。企業では、APIゲートウェイをより効果的に管理、監視するために、API管理プラットフォームなどの専用ツールを使用する傾向があります。

以下は網羅的なリストではありませんが、APIゲートウェイを複雑にする要素には次のようなものがあります。

構成管理：APIゲートウェイには、ルーティングルール、レート制限、セキュリティ設定など、管理および保守が必要な構成オプションや設定が多岐にわたる場合があります。特に、基盤となるAPIやクライアントの数が増えるにつれて、これらの設定の管理は複雑になり、時間もかかる可能性があります。
他のシステムとの統合：ゲートウェイは、認証・認可システム、ロードバランサー、データベースなど、さまざまなシステムと統合する必要があります。基盤となるシステム間の統合が不十分な場合や、APIゲートウェイで複数のプロトコルまたはデータ形式を処理する必要がある場合は、特に複雑になる可能性があります。企業が複数のベンダーのAPIゲートウェイを複数導入している場合、この問題はさらに深刻になります。
スケーラビリティと可用性：APIゲートウェイには、大量のリクエストを処理し、高可用性を確保する能力が求められます。特に、多数のバックエンドサービスやクライアントを扱う場合、その管理は複雑になる可能性があります。
セキュリティ：APIセキュリティの重要なコンポーネントであるセキュリティAPIゲートウェイは、機密データを保護し、アクセスを制御できるように設定・管理する必要があります。これには複雑な作業が伴う場合があり、継続的な監視と管理が必要です。
バージョン管理：基盤となるAPIやクライアントの数が増えるにつれて、APIの異なるバージョンを管理し、クライアントが正しいバージョンにアクセスしていることを確認するのが次第に難しくなる場合があります。
監視とトラブルシューティング：APIゲートウェイは、大量のデータを収集、生成できます。大規模な企業では、ゲートウェイが多数の拠点に分散している場合があり、アプリケーション全体の健全性に影響するイベントの関連付けや、問題のトラブルシューティングが困難になります。

APIゲートウェイの乱立

APIゲートウェイの乱立とは、組織内に複数の独立したAPIゲートウェイが増え続ける状況を指します。多くの場合、チームや事業部門ごとに独自のAPIを作成するため、それぞれのAPIに対応する複数の独立したAPIゲートウェイが構築されることがあります。また、APIの種類に応じて、チームごとに異なるベンダーのAPIゲートウェイや異なるソリューションを使用する場合もあります。

その結果、それぞれ異なる機能を備えた複数のAPIゲートウェイが導入されることになります。

APIゲートウェイの乱立により、さらに次のような課題が生じます。

APIゲートウェイ管理のスケーリング：独立したAPIゲートウェイが複数存在すると、特に基盤となるAPIやクライアントの数が増えるにつれて、ゲートウェイの管理と保守が困難になる可能性があります。
東西トラフィックの非効率性：複数のゲートウェイがあると、リクエストがそれらのゲートウェイを複数経由する必要が生じ、遅延の増加やパフォーマンスの低下につながる可能性があります。
セキュリティポリシーの統一性：複数のゲートウェイは管理が難しく、セキュリティポリシーに不整合が生じる可能性があります。その結果、機密データの保護やアクセス制御を確実に行うことが難しくなります。
標準化されたガバナンス：複数のゲートウェイがある場合、すべてのAPIが適切に管理され、標準やベストプラクティスに準拠していることを確実にするのが難しくなる可能性があります。
コストの増加：複数のゲートウェイを使用すると、インフラストラクチャ、開発リソース、保守にかかるコストが増加する可能性があります。
統合に関する課題の増大：複数のゲートウェイがあると、他のデータベース、データウェアハウス、データ分析ツールなど、ほかのシステムやテクノロジーとの統合が難しくなります。

企業は、APIの管理とガバナンスの一元化を進め、単一タイプのAPIゲートウェイを使用するよう努める必要があります。これにより、前述したAPIゲートウェイの乱立に伴う課題は軽減されますが、APIゲートウェイを統一する戦略は決して容易ではありません。

企業におけるAPIゲートウェイ標準化の課題

企業が自律的な成長や買収を通じて拡大するにつれ、特定の事業部門（BU）に属する社内チーム間で、APIゲートウェイのテクノロジーやベンダーの選定をめぐって意見が対立することがあります。その理由として、次のような点が挙げられます。

テクノロジー：チームやビジネスユニットごとにテクノロジースタックが異なる、または選好するAPIゲートウェイソリューションが異なるため、単一タイプのゲートウェイに標準化することが困難になります。
レガシーシステム：一部のチームでは、異なる種類のAPIゲートウェイを使用して構築された既存システムがあり、特に現在も稼働中の場合、これらを新しいゲートウェイに置き換えることは困難です。
カスタマイズ：特定の要件を満たすために既存のAPIゲートウェイをカスタマイズしているチームでは、そのカスタマイズを新しいゲートウェイで再現することが難しい場合があります。
置き換えコスト：既存のAPIゲートウェイを新しい標準化されたゲートウェイに置き換えると、開発と保守の両面でコストがかさむ可能性があります。
開発者のトレーニング：チームによって専門知識のレベルが異なるため、別のベンダーが提供する新しいゲートウェイ技術を習得したり、そのトレーニングを受けたりする必要が生じる場合があります。このプロセスには時間とコストがかかる可能性があります。
限られたリソース：組織では、変更に必要な開発者、予算、時間が限られているため、新しいゲートウェイの導入が困難です。
アプリケーションの依存関係：チームや事業部門ごとに、特定のシステムとの連携やその他のカスタム連携など、既存のゲートウェイに対する依存関係が異なるため、新しいゲートウェイへの切り替えが困難になります。
サードパーティソリューション：ゲートウェイと連携するサードパーティソリューションを使用しているチームにとって、それらをサポートしていない新しいソリューションへの移行は困難です。

したがって、既存のアプリケーションを担当するチームに確立された方針がある場合、サービスの中断を避けるため、別のデプロイパターンへの移行を望まないでしょう。

したがって、既存のAPIインフラストラクチャが抱える複数の制約を考慮しつつ、特に重要な検討事項の1つであるAPIゲートウェイの乱立に重点を置いた、新たなアプローチが必要だと結論付けられます。

設計上の考慮事項

以下は網羅的なリストではありませんが、ソリューションの構築時に取り入れるべきと考えられる、主な設計上の考慮事項をまとめたものです。

現在のデプロイメントとの共存：組織が絶えず変化するテクノロジー環境への対応に努めるなか、企業では多様なAPIゲートウェイがデプロイされていることが一般的です。既存のAPIインフラストラクチャを全面的に置き換えると、重要な業務が中断する可能性があるため、現実的ではありません。そのため、新たなデプロイメントは、現在デプロイされているアーキテクチャと共存できるように設計する必要があります。
APIゲートウェイ機能の標準化：企業のAPI戦略では、APIゲートウェイ機能の標準化を最優先の目標とする必要があります。APIの種類が多岐にわたり、事業部門ごとにニーズも異なるため、標準化は容易ではありません。それでも、組織のデジタルトランスフォーメーションを支える、安定したセキュアなインフラストラクチャを構築するうえで、この標準化は不可欠です。
エッジ展開を活用：エッジインフラストラクチャには、APIの数を飛躍的に増加させる可能性があるだけでなく、企業がゲートウェイアクターをエッジの近くに配置できるという利点もあります。APIの作成に使用するものと同じインフラストラクチャを、分散型ゲートウェイアクターの作成にも利用できるためです。したがって、ソリューションでは、APIリクエストを開始するクライアントとエッジインフラストラクチャとの近接性を最大限に活用する必要があります。
トランスポート非依存：分散ゲートウェイアクターのアーキテクチャを実装する際は、特定のトランスポートメカニズムに依存しないことが重要です。従来のIPネットワーク、オーバーレイネットワーク、VPN、低遅延メッセージングインフラストラクチャのいずれを企業が利用する場合でも、ソリューションはトランスポートメカニズムに依存しない必要があります。これにより柔軟性が高まり、企業は固有のニーズや要件に最適なトランスポートメカニズムを選択できます。
GraphQLサポート：GraphQLは、従来のREST APIに比べて多くの利点があるため、API開発でますます広く採用されています。主な利点の1つは、データにきめ細かくアクセスできることです。これにより、クライアントは1回のリクエストで必要なデータを正確に指定できます。また、GraphQLは複数のサービスからデータを集約するプロセスを簡素化できるため、サービスのコンポーザビリティとオーケストレーションに適したアーキテクチャです。特に、1回のリクエストを処理するために複数のAPIサービスを使用する分散システムでは、ネットワークのオーバーヘッドを削減し、パフォーマンスを向上できます。さらに、GraphQLは厳密に型付けされたスキーマとクエリ言語により、APIの検出性を高め、クライアント開発を容易にします。
セキュリティは必須条件：最も重要な設計目標は、企業のAPIセキュリティ態勢を強化することです。このソリューションは、APIリクエストの認証と認可、アクセス制御の実装、クロスサイトスクリプティング（XSS）やSQLインジェクション攻撃などの一般的なセキュリティ脅威に対する保護といった機能の一部を取り込むことができます。新しいソリューションによって既存の脅威モデルが損なわれたり、攻撃対象領域が変わるほど大幅に変更されたりすることは、いかなる場合も許されません。セキュリティを設計目標として優先することで、このアーキテクチャはAPI通信によりセキュアな環境を提供し、データ侵害やその他のセキュリティインシデントのリスクを低減する必要があります。

これらの設計上の考慮事項に基づいて具体的な要件を導き出すことができます。これらの要件は、F5のdistributed gateway actors（DGA）ソリューションに組み込まれています。

分散ゲートウェイアクター

ここまでAPIゲートウェイについて詳しく見てきたので、次に分散ゲートウェイアクターソリューションについて説明します。

分散ゲートウェイアクターの設計

分散ゲートウェイアクター（DGA）設計パターンは、エッジコンピューティングと、クライアントの近くで利用できるコンピューティングリソースから着想を得ています。この考え方の要点は、各ゲートウェイアクターを可能な限りクライアントの近くに高度に分散配置し、トランザクションの実行中のみ存在させ、終了時に消去することです。

“分散ゲートウェイアクター（DGA）設計パターンは、エッジコンピューティングと、クライアントの近くで利用可能なコンピューティングリソースから着想を得ています。”

前提条件

このソリューションは、以下の前提に基づいています。

エッジコンピューティングは広く普及し、クライアントに地理的に近い場所で利用できる何らかのコンピューティングリソースを確保できるようになりました。ゲートウェイアクターは、これらのエッジコンピューティングノード上にインスタンス化できます。DGAを非常に軽量かつ一時的なものとして実装し、あらゆるエッジコンピューティング環境でインスタンス化できるようにすることを意図しています。

APIトランスポートは、ゲートウェイアクターとAPIゲートウェイ間のネットワーク構築に関わるため、インフラストラクチャの重要なコンポーネントです。必要なインフラストラクチャの種類はベンダーや企業によって異なります。たとえば、大規模なパブリッククラウドでは、独自のバックボーンを使用してAPIトランスポートを実行する場合があります。また、企業のデータセンター内にある既存の広帯域・低遅延ネットワーク上に、低遅延のメッセージングバスを構築する実装も考えられます。

APIゲートウェイの機能

繰り返しになりますが、APIゲートウェイは基本的にリバースプロキシであり、その主な機能はHTTPトラフィックを適切なAPIワークロードにルーティングすることです。このアプローチは、ローカルのオンプレミスネットワーク内や、アベイラビリティゾーン内の仮想プライベートクラウド（VPC）など、すべてのAPIが同じ場所に配置されている場合には合理的です。しかし、APIの数が増え、ハイブリッドインフラストラクチャ全体に分散したり、単に移動するようになったりすると、このAPIゲートウェイの設計アプローチは非効率になり、運用が複雑化し、コストも増大します。

図6に示す各機能の分類方法についてはさまざまな見解が考えられますが、API管理インフラストラクチャが、慎重なオーケストレーションを必要とする多数のコンポーネントで構成された複雑なデプロイメントになっている点では、見解が一致するでしょう。

図7：GraphQベースの分散ゲートウェイアクター

図7は、図6に示したAPI管理のさまざまな機能を、分散ゲートウェイアクターアーキテクチャに対応付けたものです。この対応関係により、各機能がDGAアプローチにどのように整合しているかを視覚的に示し、API管理コンポーネントがアーキテクチャ内にシームレスに統合されていることを明確にしています。

一元管理機能

上記の機能の大半には、論理的に一元化できる管理コンポーネントが含まれています。目標は管理プレーンを再設計することではなく、可能であれば特定の機能を削除することです。

APIゲートウェイのコア機能

これらはデータプレーンの機能であるため、APIに実装し、アプリケーションワークロードと同じ場所に配置するのが最適です。APIゲートウェイは、すべての外部トラフィックのエントリーポイントとして機能する、最新のマイクロサービスアーキテクチャに不可欠なコンポーネントです。その中核機能は、ルーティング、負荷分散、動的ルーティング、ヘルスチェック、再試行、フォールバックに分類されます。

APIゲートウェイは、受信したリクエストを適切なマイクロサービスに転送し、複数のインスタンスにトラフィックを分散します。また、動的ルーティングをサポートし、マイクロサービスとそのインスタンスの正常性を監視するほか、失敗したリクエストを再試行し、マイクロサービスが利用できない場合や障害が発生した場合にはフォールバックレスポンスを返します。認証、認可、レート制限、キャッシュ、ロギングなどのその他の機能は、システム固有の要件に応じて、エッジに分散することも、一元化された機能として実装することもできます。

このモジュール型のアプローチにより、柔軟性と最適化に優れたアーキテクチャが可能になります。これは、エンタープライズAPIインフラストラクチャの簡素化、モダナイゼーション、スケーリングに関するF5の推奨事項の中核を成すものです。

混同

ベンダーは、APIゲートウェイとAPI管理をAPIゲートウェイ機能の一部として混同しがちですが、実際には別個の機能であり、分けて扱う必要があります。APIゲートウェイはクライアントからバックエンドサービスへのリクエストのルーティングを担う一方、API管理にはアクセス制御、レート制限、分析、開発者ポータル管理など、より幅広い機能が含まれます。

“ベンダーによっては、APIゲートウェイとAPI管理の両方の機能を単一の製品として提供している場合もありますが、両者の違いを理解し、それぞれの要件に基づいて個別に評価することが重要です。”

一部のベンダーは、APIゲートウェイ機能とAPI管理機能の両方を単一の製品として提供している場合がありますが、両者の違いを理解し、それぞれの具体的な要件に基づいて個別に評価することが重要です。これらの機能を統合すると、混乱を招き、組織のAPIインフラストラクチャの柔軟性と拡張性が制限される可能性があります。また、APIゲートウェイ機能の分散に関するF5の立場を理解するうえでも、この点は極めて重要です。

ゲートウェイアクター – インライン機能

ここに記載する機能は、データパス上にインラインで配置する必要がある中核機能です。分散ゲートウェイパターンでは、APIゲートウェイの一部のインライン機能も分散されます。これらの機能には、アクセス制御、レート制限、リクエスト検証、API分析、使用状況レポート、エラー率の監視、アラートとイベント処理、認証連携、サードパーティ連携、監視およびログ連携、エッジキャッシュ、圧縮が含まれます。

これらの機能を分散ゲートウェイパターンに移行すると、次のメリットが得られます。

APIゲートウェイの負荷軽減：一元化されたAPIゲートウェイの負荷を軽減し、システムのパフォーマンスとスケーラビリティの向上に役立ちます。
応答時間を短縮：これらの機能をクライアントの近くにデプロイすることで、応答時間を短縮し、レイテンシを低減できます。データと機能のキャッシュを活用することで、エッジでホストされるAPIゲートウェイは受信リクエストに迅速に応答できます。

たとえば、アクセス制御、レート制限、リクエスト検証は、クライアントの近くにデプロイされたエッジゲートウェイアクターで処理できます。これにより、集中型APIゲートウェイで処理する必要があるリクエスト数を削減し、パフォーマンスとスケーラビリティの向上に役立ちます。同様に、API分析、使用状況レポート、エラー率の監視、アラートとイベント処理、監視およびログ統合も、複数のマイクロサービスからデータを収集して集約できるエッジゲートウェイで処理できます。

ゲートウェイアクター – GraphQLの候補

現在、APIゲートウェイがサポートする重要な機能の1つに、サービスの構成とオーケストレーションがあります。これはかなり複雑になる場合がありますが、簡素化されたAPIゲートウェイでこの機能がサポートされなければ、懸念材料となります。GraphQLは既存のAPIに対する一種のミドルウェアとして機能するため、サービス構成への有望なアプローチになり得ると考えています。

APIゲートウェイはすべてのAPIを把握できるため、サービスコンポジションを行うのに適した場所となります。これにより開発者は、サービスコンポジションレイヤーで容易に組み合わせられる新たなサービスを作成することなく、ゲートウェイの背後にあるAPIを組み合わせてビジネスロジックを強化できます。

GraphQLでは、クライアントが利用できるデータの構造を定義する強い型付けのスキーマを使用することで、サービスコンポジションが可能になります。クライアントはこのスキーマを使用して、データを提供するサービスやソースにかかわらず、必要なデータを正確に指定するクエリを構築できます。クエリをデータソースにマッピングする関数であるリゾルバーを使用して、適切なサービスまたはソースからデータを取得します。ただし、GraphQLはセキュリティの向上をうたっているものの、その実効性はコードを記述する開発者の力量に左右されます。

その他の機能

ここまで取り上げていない機能が、図6：API管理およびインフラストラクチャ機能にいくつか残っています。これらの機能は、個別の管理・運用機能またはデータプレーン機能に移行できる候補です。

特定の実装やベンダー技術を示唆しないよう、ここでは意図的に「アクター」という用語を使用します。ゲートウェイアクターは、メソッド、関数、ワーカー、スレッド、プロセスをベースに実装でき、そのインフラストラクチャには、VM、コンテナ、サーバーレス、またはベンダー固有のその他のアプローチを使用できます。

コンポーネントの機能と動作

分散ゲートウェイアクター（DGA）アーキテクチャで採用されているアプローチにより、APIゲートウェイの機能が簡素化され、その他のインライン機能はエッジまたはコントロールプレーンに移行されます。

コントロールプレーン

APIゲートウェイ機能に加えて、DGAアーキテクチャでは、モノリシックなAPIゲートウェイ内に実装するよりも、論理的に一元化されたコンポーネントとしてコントロールプレーンで提供する方が適している機能を特定することも推奨しています。既存のAPIインフラストラクチャの管理および制御を拡張し、この追加機能を組み込むことができます。

簡素化されたAPIゲートウェイ

したがって、APIゲートウェイの簡素化とは、すべてのAPIゲートウェイベンダーが共通の設定パラメーター群を通じて管理できる、標準的なコア機能群を導き出す取り組みとなります。

この変革を進める企業は、既存のデプロイ環境に影響を与えず、大規模な一括移行を行うことなく、DGAアーキテクチャをアプリケーションごとに順次導入できます。

分散ゲートウェイアクター

DGAの重要な特徴は、各「ゲートウェイアクター」が一時的な存在であり、APIセッションの継続中（つまり、1つのクライアントが1回のAPI呼び出しを行う間）に限ってインスタンス化されることです。

分散型ゲートウェイアクターは、従来のAPIゲートウェイよりも柔軟性、拡張性、コスト効率に優れたものになり得ます。異なるベンダーの複数のモノリシックなAPIゲートウェイに依存してAPIトラフィックを集約・処理するのではなく、ゲートウェイアクターを使用することで、開発者はAPIごとに個別のゲートウェイインスタンスを指定し、ネットワークエッジにより近い場所へデプロイできます。これにより、API自体がそれぞれの固有のニーズに応じて、より高度な制御とカスタマイズを提供できる可能性があります。

この新しいアプローチでは、トラフィックの増加に応じて、開発者が必要な数のゲートウェイアクターインスタンスを容易に起動できます。大規模な集中型ゲートウェイの管理に伴うオーバーヘッドを懸念する必要がないため、スケーラビリティも向上します。

ゲートウェイアクターには、技術面のメリットに加え、従来のAPIゲートウェイよりもコストを削減できるという利点もあります。企業は、使用した一時的なゲートウェイアクターインスタンスの料金のみを支払えばよいためです。このデプロイモデルにより、新たな収益モデルの可能性も広がります。

“ゲートウェイアクターには、技術面のメリットに加え、企業が使用した一時的なゲートウェイアクターインスタンスの料金のみを支払うことで、従来のAPIゲートウェイよりもコストを削減できるという利点もあります。”

Gateway Actorの配置

APIトランスポート層を活用することで、DGAはAPIの受信位置をAPIゲートウェイから実質的に分離します。DGAはエッジ、つまりAPI呼び出しを行うクライアントにより近い場所へ移動できます。APIはDGAで終端し、その後、任意の手段で転送できます。これは、図3：従来のAPIゲートウェイアーキテクチャに示す、クライアントトラフィックがAPIゲートウェイとトポロジー上隣接する位置から流入する構成とは異なります。

まとめ

したがって、ここでの目的は、ベンダーや導入形態に依存しないアプローチを提案することです。各ベンダーは、ここで示したものと同様の目的を達成するために、独自の知的財産を用いてこれらのコンポーネントを構築する場合があるためです。

本稿では、複数四半期にわたるAPIスプロール、Edge 2.0アーキテクチャ、APIエコノミー（https://www.f5.com/company/blog/inverting-the-api-is-the-digital-transformation-that-enterprises-need-to-participate-and-compete-in-an-api-economy）、およびGraphQLに関する調査から得た知見をまとめています。従来のAPIインフラストラクチャについてはまだ結論が出ていませんが、新たなアプローチが必要だと考えています。

世界中のあらゆるデバイスやエンティティが持つ価値を引き出せる可能性だけでも、新たなアプローチを模索する十分な理由になります。従来のAPIインフラストラクチャは、分散型に見えても内部はモノリシックであるため、今こそ脱却する必要があります。

新たに台頭するAPIエコノミーの可能性を最大限に引き出す、ベンダーに依存しない手法として、GraphQLベースの分散型ゲートウェイアクターアプローチを提案します。

レポートをダウンロード