目次
F5 Office of the CTOの見解
F5 Office of the CTOチームは、1年以上にわたり、API関連のテクノロジ分野を検討してきました。この最新のホワイト ペーパーでは、進化し続けるAPIエコシステムを理解するための私たちの継続的な取り組みの成果をご紹介します。
APIスプロールの管理で詳しく説明した課題は、APIゲートウェイ スプロールにおける課題をもたらし、従来のアプローチでは、これらの課題に対処するには十分ではないでしょう。GraphQLなどのグラフ テクノロジは、APIに関連する複雑さを緩和するという点で大きな期待が寄せられていますが、こうした課題は接続、セキュリティ、ルーティングの範囲を超えているため、グラフ テクノロジは部分的な解決策にすぎません。システムとアプリケーションのスケーリングにおける30年近くに及ぶ専門知識に基づいた適切なアプローチは、GraphQLを採用するが、それだけに依存しない、分散アーキテクチャ（フェデレーション アーキテクチャではない）を基盤としています。
このペーパーでは、APIゲートウェイ スプロールという課題に対処するための分散アーキテクチャ アプローチについて検討します。
要旨
デジタル経済はAPIで動き、API主導の経済を私たちにもたらしています。APIスプロールに関するホワイト ペーパーに続き、私たちが取り組んだのは、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-GW）、つまりAPI呼び出しのエントリ ポイントとして機能する専用ソフトウェア層では、新興のAPIエコシステムの規模と複雑さを管理するには不十分であり、APIアーキテクチャは変換点に来ています。
図1は、APIスプロールの管理からAPIゲートウェイ スプロールの管理へと遷移してきた様子を示しています。
上記の設計パターンは、図2に示すように、APIゲートウェイが分散データ プレーンを形成している集中型コントロール プレーンを示唆しています。
APIゲートウェイは、最新のソフトウェア アーキテクチャの重要なコンポーネントであり、APIの制御とセキュリティの中心です。しかし、APIゲートウェイが提供する機能が増えるにつれて、APIゲートウェイはますます複雑になり、管理が困難になっています。多くの場合、こうしたゲートウェイは、幅広い機能が1つのパッケージにまとめられたモノリシック システムへと進化しています。
複数のゲートウェイの管理は分散設計のように見えるかもしれませんが、実際には真の分散には程遠いものです。なぜなら、ゲートウェイは依然として緊密に結合されていて、分離するのが難しいリソースと構成を共有しているからです。その結果、多くの企業は分散モノリスとそれが生み出すあらゆる課題を管理することになります。
レガシーAPIゲートウェイのアーキテクチャ
図3は、既存のAPIゲートウェイのアーキテクチャを示しています。クライアントから発信されたAPIリクエストは、まず共有ネットワークまたは専用ネットワークを介して送信され、APIゲートウェイに到達する前にファイアウォールを通過します。APIゲートウェイはリバース プロキシとして機能し、トラフィックをAPIワークロードに転送します。
レガシーAPI-GWがAPI管理のチョーク ポイントとなるのは、APIゲートウェイが企業全体に展開されている場合や、APIスプロールと戦いながらAPIワークロードの運用をリージョン、ゾーン、複数のクラウド、あるいはエッジへと移行している場合です。さまざまなチームが複数のAPI-GWを立ち上げていて、そこに企業規模の単一の管理・制御ポイントはありません。個々の、または一連のAPIサービスを別のインフラストラクチャ（クラウドなど）に移行する場合、運用チームには、登録、検出、認証、ネットワーキング、セキュリティ、さらにはガバナンス、リスク、コンプライアンス（GRC）ポリシーといった、API管理のすべての側面を移行する手段が必要です。
図3に示したアーキテクチャは拡張性に欠け、長期的な実用性がなく、時間が経つと分散モノリスを管理しなければならなくなります（図2）。
APIゲートウェイのチョーク ポイントを生む2つの問題があります。1つ目は、APIゲートウェイ ベンダーのスプロール、2つ目は、企業がより多くの場所でより多くのアプリケーションを実行するのに合わせて拡張していくことです。
- APIゲートウェイ ベンダーのスプロール：APIゲートウェイ ベンダーのスプロールに対処することは人的な課題です。単一のAPIゲートウェイ ベンダーを採用するようすべてのチームを説得するのは難しく、新しいベンダーへの移行は面倒な作業になりかねません。その結果、組織は複数のゲートウェイ ベンダーの管理に時間とリソースを費やすことになります。この問題の解決は可能ではあっても、実際には完全に実現可能とは限りません。
- アプリケーションの拡張：アプリケーションが1つの場所でサポートするユーザーの数が増える場合や、アプリケーションを複数の場所に導入する必要がある場合、アプリケーションの拡張が問題になります。こうした場合は、アプリケーションを水平または垂直に拡張する必要があります。しかし、アプリケーションの拡張に伴い、APIゲートウェイも同様に拡張する必要があり、場合によっては、現在のアーキテクチャ パターンに基づいた拡張をサポートするために、APIゲートウェイを複数の場所に導入しなければなりません。これにより、運用面でAPIゲートウェイの管理が複雑になる可能性があります。
解決策：分散ゲートウェイ アクター パターン
図4は、APIゲートウェイ スプロールに対処するための分散ゲートウェイ アクターのパターンを示しています。分散パターン自体は新しいものではありませんが、このホワイトペーパーでは、それをAPIゲートウェイの文脈で捉えています。クライアントがAPIリクエストを開始します。分散ゲートウェイ アクターは一時的であり、可能な限りクライアントの近くで、オンデマンドでインスタンス化されます。APIリクエストをゲートウェイ アクターから簡素化されたAPIゲートウェイに送信するのはAPIトランスポート層の役割となり、その後、リクエストは適切なAPIワークロードにルーティングされます。分散アクターにおけるGraphQLサポートの使用は、このパターンが機能するための要件というよりは細部に過ぎませんが、これによってサービス オーケストレーションなどの機能をサポートできます。したがって、新しいサービス オーケストレーション層を作成しなくても、GraphQLがそのサポートを提供できます。
確認ですが、トラフィック パターンは右から左に流れます。つまり、図5に示すように、クライアントは右側にあり、APIリクエストはクライアントによって開始されます。
企業内と企業全体のAPIを管理する上でAPIゲートウェイへの過剰な依存を置き換えたり軽減したりするために、ゲートウェイ アクターを使用する新たな導入パターンが登場しています。ゲートウェイ アクターはGraphQLをサポートするのに適した手段であるため、GraphQLはアーキテクチャに必須ではありませんが、その導入はタイムリーな選択です。
可能性のある解決策としてゲートウェイ アクターをより深く理解するには、APIインフラストラクチャ、特にAPIゲートウェイの現状を詳しく調べる必要があります。なぜなら、ゲートウェイ スプロールがAPIインフラストラクチャの運用と拡張の課題に大きく関係していることがわかったからです。
APIゲートウェイをより深く理解するには、まず最新のAPI管理インフラストラクチャのさまざまなコンポーネントを検証することが重要です。
図6は、API管理に不可欠なさまざまな機能とコンポーネントを包括的に表したものです。APIゲートウェイはバックエンド サービスへのトラフィックのルーティングと管理に必要なものですが、その他にもいくつかの重要なインフラストラクチャ コンポーネントがあります。これには、認証、レート制限、キャッシュ、サービス メッシュなどのソリューションが含まれる場合があります。こうした機能を組み込むことで、組織はAPIを制御し、セキュリティを強化し、パフォーマンスを最適化することができます。
一般的に知られている、馴染みのあるAPIゲートウェイの機能を見てみましょう。
- ルーティング：リクエストのパスや内容に基づいて、リクエストを適切なバックエンド サービスにルーティングします。
- 認証と認可：リクエストを単一のイングレス ポイントとして認証・認可することで、認可されたクライアントのみがバックエンド サービスにアクセスできるようにします。
- レート制限：クライアントが基礎となるAPIにリクエストを送信できるレートを制限することで、過剰使用を防ぎ、バックエンド サービスを過負荷から守ります。
- キャッシュ：基礎となるAPIからのレスポンスをキャッシュすることで、バックエンド サービスに対する必要なリクエストの数を減らし、パフォーマンスを向上させます。
- プロトコル変換：HTTPやWebSocketなどの異なるプロトコル間で変換することで、クライアントが異なるプロトコルを使用して基盤となる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つのリクエストで必要なデータを正確に指定できます。さらに、GraphQLは複数のサービスからデータを集約するプロセスを簡素化できるので、サービスの構成とオーケストレーションを行うのに最適なアーキテクチャとなります。これにより、単一のリクエストを実行するために複数のAPIサービスが使用される分散システムでは特に、ネットワークのオーバーヘッドが削減され、パフォーマンスが向上します。最後に、GraphQLは厳密に型指定されたスキーマとクエリ言語を使用することで、APIの検出可能性を高め、クライアント開発を容易にすることができます。
- セキュリティは必須：最も重要な設計目標は、企業のAPIセキュリティ体制を強化することです。ソリューションには、APIリクエストの認証と認可、アクセス制御の実装、クロスサイト スクリプティング（XSS）やSQLインジェクション攻撃などの一般的なセキュリティ脅威からの保護といった機能の一部を組み込むことができます。どのような状況でも、新しいソリューションが既存の脅威モデルを損なうものであったり、攻撃対象領域が変わるほど脅威モデルを大幅に変更するものであってはなりません。設計目標としてセキュリティを優先することで、アーキテクチャは、API通信により安全な環境を提供し、データ侵害やその他のセキュリティ インシデントのリスクを軽減するものとなる必要があります。
分散ゲートウェイ アクター（DGA）ソリューションに組み込まれたこれらの設計上の検討事項に基づいて、特定の要件を導き出すことができます。
分散ゲートウェイ アクター
ここまでは、APIゲートウェイを詳しく見てきました。次に分散ゲートウェイ アクター ソリューションを見ていきましょう。
分散ゲートウェイ アクターの設計
分散ゲートウェイ アクター（DGA）の設計パターンは、エッジ コンピューティングや、クライアントの近くで利用可能なコンピューティングからインスピレーションを得たものです。このアイデアの核心は、各ゲートウェイ アクターをクライアントのできるだけ近くに高度に分散させ、そのトランザクションの間だけゲートウェイ アクターを存在させて、最後に消去することにあります。
前提
次に、このソリューションの基礎となる前提をいくつか示します。
エッジ コンピューティングの普及が進み、地理的にクライアントの近くで利用できる何らかのコンピューティングが見つかるようになりました。ゲートウェイ アクターは、これらのエッジ コンピューティング ノード上でインスタンス化することができます。その目的は、DGAが非常に軽量かつ一時的なものであるため、あらゆるエッジ コンピューティングでインスタンス化できるような実装にすることです。
APIトランスポートは、ゲートウェイ アクターとAPIゲートウェイの間のネットワークの確立に関与するため、インフラストラクチャの重要なコンポーネントです。必要なインフラストラクチャのタイプはベンダーや企業によって異なります。例えば、大規模なパブリック クラウドでは、独自のバックボーンを使用してAPIトランスポートを実行する場合があります。また、企業のデータ センター内にある高帯域幅、低遅延の既存のネットワーク上に低遅延メッセージング バスを階層化する実装も考えられます。
APIゲートウェイの機能
繰り返しになりますが、APIゲートウェイは本質的にリバース プロキシであり、その主な機能はHTTPトラフィックを適切なAPIワークロードにルーティングすることです。このアプローチは、ローカルのオンプレミス ネットワーク内やアベイラビリティ ゾーン内の仮想プライベート クラウド（VPC）内など、すべてのAPIが同じ場所に配置されている場合には合理的です。しかし、APIの数が増大したり、ハイブリッド インフラストラクチャに移行したり、モバイル化したりすることで、このAPIゲートウェイ設計のアプローチは非効率的になり、運用が複雑になり、コストが高くなります。
図6で説明したすべての機能の分類方法についてはさまざまな見解があるかもしれませんが、API管理インフラストラクチャが多くのコンポーネントで構成され、導入が複雑であり、オーケストレーションを慎重に行う必要があるという点では同意していただけると思います。
図7は、図6のAPI管理のさまざまな機能を分散ゲートウェイ アクター アーキテクチャに対応させたものです。この対応付けは、各機能がDGAアプローチとどのように連携しているかを視覚的に示し、アーキテクチャ内のAPI管理コンポーネントのシームレスな統合を強調しています。
機能の一元化
上記の機能のほとんどには、論理的に一元化できる管理コンポーネントが含まれています。私たちの目標は、管理プレーンを再設計することではなく、可能であれば一部の機能を削除することです。
APIゲートウェイのコア機能
これらはデータ プレーン機能であるため、APIに実装し、アプリケーション ワークロードとともに配置するのが最適です。APIゲートウェイは、最新のマイクロサービス アーキテクチャの重要なコンポーネントであり、すべての外部トラフィックのエントリ ポイントとして機能します。私たちはそのコア機能をルーティング、ロード バランシング、動的ルーティング、健全性チェック、再試行、フォールバックに分類しました。
APIゲートウェイは、受け取ったリクエストを適切なマイクロサービスに転送し、複数のインスタンス間でトラフィックを分散し、動的ルーティングをサポートし、マイクロサービスとそのインスタンスの健全性を監視し、失敗したリクエストを再試行し、マイクロサービスが利用できないか失敗した場合にはフォールバック レスポンスを提供します。認証、許可、レート制限、キャッシュ、ロギングなどの他の機能は、システムの特定の要件に応じてエッジの機能や一元化された機能に分散できます。
このモジュール式のアプローチにより、より柔軟で最適化されたアーキテクチャが可能になるため、このアプローチはエンタープライズAPIインフラストラクチャの簡素化、モダナイズ、拡張に向けた私たちの提案の中核となります。
混同
APIゲートウェイとAPI管理をAPIゲートウェイ機能の一部としてベンダーが誤って混同していることがよくありますが、実際には、これらは2つの異なる機能であり、別々に扱う必要があります。APIゲートウェイはクライアントからのリクエストをバックエンド サービスにルーティングする役割を果たしますが、API管理にはアクセス制御、レート制限、分析、開発者ポータルの管理など、幅広い機能が含まれます。
一部のベンダーは、1つの製品の一部としてAPIゲートウェイ機能とAPI管理機能をどちらも提供していますが、これらの機能の違いを理解し、特定の要件に基づいて個別に評価することが重要です。これらの機能を組み合わせると混乱が生じ、組織のAPIインフラストラクチャの柔軟性と拡張性が制限される可能性があります。これは、APIゲートウェイ機能の配布に関する当社の立場を理解する上でも重要です。
ゲートウェイ アクターのインライン機能
ここで挙げた機能は、データ パスにインライン化する必要があるコア機能です。分散ゲートウェイ パターンでは、APIゲートウェイのインライン機能の一部も分散されます。これらの機能には、アクセス制御、レート制限、リクエスト検証、API分析、使用状況レポート、エラー率の監視、アラートとイベント、認証統合、サードパーティ統合、監視とロギング統合、エッジ キャッシュ、圧縮などがあります。
これらの機能を分散ゲートウェイ パターンに移行することには、次のメリットがあります。
- APIゲートウェイの負荷の軽減：集中型APIゲートウェイの負荷が軽減され、システムのパフォーマンスと拡張性が向上します。
- 応答時間の短縮：これらの機能をクライアントの近くに導入することで、応答時間の短縮と遅延の削減が可能になります。データと機能のキャッシュを活用することで、エッジ ホスト型APIゲートウェイは受け取ったリクエストに迅速に応答することができます。
例えば、アクセス制御、レート制限、リクエストの検証は、クライアントの近くに導入されたエッジ ゲートウェイ アクターで処理できます。これにより、集中型APIゲートウェイで処理するリクエストの数が減り、パフォーマンスと拡張性が向上します。同様に、API分析、使用状況レポート、エラー率の監視、アラートとイベント、監視とログの統合は、複数のマイクロサービスからデータを収集して集約できるエッジ ゲートウェイで処理することができます。
ゲートウェイ アクター：GraphQLが候補
現在、APIゲートウェイがサポートする重要な機能は、サービスの構成とオーケストレーションです。これはかなり複雑になるため、この機能が簡素化されたAPIゲートウェイでサポートされないとすれば、懸念材料となります。私たちは、GraphQLが既存のAPIに対する一種のミドルウェアとして機能し、サービス構成に対する興味深いアプローチになり得ると考えています。
すべてのAPIを可視化できるため、APIゲートウェイはサービスの構成を行うのに論理的に適した場所となり、開発者は、新しいサービスを作成することなく、ゲートウェイの背後でAPIを組み合わせてビジネス ロジックを強化することができます。APIはサービス構成層で簡単に組み合わせることができます。
GraphQLにおけるサービス構成は、クライアントが利用できるデータの形式を定義する、厳密に型指定されたスキーマを使用することで可能になります。クライアントは、このスキーマを使用して、どのサービスやソースがデータを提供するかに関係なく、必要なデータを正確に指定するクエリを構築できます。クエリをデータ ソースにマップする関数であるリゾルバが、適切なサービスやソースからデータを取得するために使用されます。GraphQLによってセキュリティの強化が約束されますが、最終的なセキュリティは、開発者が作成するコード次第です。
その他の機能
「図6：API管理とインフラストラクチャの機能」には示されていない機能がまだいくつかあります。これらの残りの機能は、個別の管理と運用やデータプレーン機能に移行できる候補となります。
特定の実装やベンダー テクノロジを示唆することを避けるため、私たちは意図的に「アクター」という用語を使いました。ゲートウェイ アクターの実装は、VM、コンテナ、サーバーレス、あるいはベンダー固有のその他のアプローチに基づくインフラストラクチャを使用して実装される、メソッド、関数、ワーカー、スレッド、プロセスなどに基づいたものとなるでしょう。
コンポーネントの機能と動作
分散ゲートウェイ アクター（DGA）アーキテクチャで採用されたアプローチにより、APIゲートウェイ機能が簡素化され、他のインライン機能がエッジやコントロール プレーンに移行されます。
コントロール プレーン
APIゲートウェイ機能とは別に、DGAアーキテクチャでは、モノリシックAPIゲートウェイ内に実装するのではなく、論理的に集中化したコンポーネントとしてコントロール プレーンで適切に提供できる機能を特定することも推奨しています。この追加機能を含めるように、既存のAPIインフラストラクチャの管理と制御を拡張することができます。
簡素化されたAPIゲートウェイ
したがって、APIゲートウェイの簡素化は、すべてのAPIゲートウェイ ベンダーが共通の設定パラメータ セットを使用して管理できる、コア機能の標準セットを導き出す作業になります。
こうした変革を望む企業は、アプリケーション1つずつに順番にDGAアーキテクチャを展開することができます。既存の導入環境を中断させる必要も、完全に置き換える必要もありません。
分散ゲートウェイ アクター
DGAの重要な特長として、各ゲートウェイ アクターが一時的なものであり、1つのAPIセッションの間（つまり、1つのクライアントが1つのAPI呼び出しを行う間）だけインスタンス化されることが挙げられます。
分散ゲートウェイ アクターは、従来のAPIゲートウェイよりも柔軟性、拡張性、コスト効率に優れています。APIトラフィックを集約して処理するために、さまざまなベンダーの複数のモノリシックAPIゲートウェイに依存するのではなく、ゲートウェイ アクターを使用することで、開発者はネットワークのエッジに近いAPIごとに個別のゲートウェイ インスタンスを指定して導入することができます。API自体は、優れた制御性を備え、特定のニーズに合わせてカスタマイズすることができます。
また、この新しいアプローチにより、開発者は大規模な集中型ゲートウェイの管理のオーバーヘッドを心配することなく、増加したトラフィックを処理するために必要に応じてゲートウェイ アクター インスタンスを簡単に立ち上げることができるため、拡張性も向上します。
ゲートウェイ アクターでは技術的なメリットに加え、企業は使用する一時的なゲートウェイ アクター インスタンスの料金のみを支払うことができるため、従来のAPIゲートウェイに比べてコストも削減できます。この導入モデルは、収益モデルの追加につながる可能性があります。
ゲートウェイ アクターの配置
DGAは、APIトランスポート層を利用することで、基本的にAPIのイングレス ポイントをAPIゲートウェイから切り離します。DGAはエッジ、つまりAPI呼び出しを行うクライアントの近くに移動できます。APIはDGAで終了し、任意の手段で転送できます。これは、クライアント トラフィックのイングレスがトポロジ的にAPIゲートウェイに隣接している「図3：レガシーAPIゲートウェイ アーキテクチャ」とは異なります。
まとめ
さまざまなベンダーが、ここで概説したような目標の達成に向けて、コンポーネントを構築するための独自の知的財産を持っていることから、私たちは、ベンダーと導入環境に依存しないアプローチを提案することを目指しています。
このホワイトペーパーでは、APIスプロール、Edge 2.0アーキテクチャ、APIエコノミー、GraphQLの調査など、複数の四半期にわたって私たちが得た知見をまとめました。レガシーAPIインフラストラクチャに関してはまだ結論が出ていませんが、私たちは新しいアプローチが必要であると考えています。
個々のデバイスやエンティティの価値をグローバルに解き放つことが約束されるだけでも、新しいアプローチを検討する十分な理由となります。分散しているように見えても、内部ではモノリシックであるレガシーAPIインフラストラクチャから、すぐにでも移行する必要があるからです。
私たちは、新興のAPIエコノミーの可能性を最大限に引き出す、ベンダーに依存しない手段として、分散型GraphQLベースのゲートウェイ アクター アプローチを提案します。