分散ゲートウェイ アクター（DGA）の設計パターンは、エッジ コンピューティングや、クライアントの近くで利用可能なコンピューティングからインスピレーションを得たものです。このアイデアの核心は、各ゲートウェイ アクターをクライアントのできるだけ近くに高度に分散させ、そのトランザクションの間だけゲートウェイ アクターを存在させて、最後に消去することにあります。

次に、このソリューションの基礎となる前提をいくつか示します。

エッジ コンピューティングの普及が進み、地理的にクライアントの近くで利用できる何らかのコンピューティングが見つかるようになりました。ゲートウェイ アクターは、これらのエッジ コンピューティング ノード上でインスタンス化することができます。その目的は、DGAが非常に軽量かつ一時的なものであるため、あらゆるエッジ コンピューティングでインスタンス化できるような実装にすることです。

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

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

図6で説明したすべての機能の分類方法についてはさまざまな見解があるかもしれませんが、API管理インフラストラクチャが多くのコンポーネントで構成され、導入が複雑であり、オーケストレーションを慎重に行う必要があるという点では同意していただけると思います。

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

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

これらはデータ プレーン機能であるため、APIに実装し、アプリケーション ワークロードとともに配置するのが最適です。APIゲートウェイは、最新のマイクロサービス アーキテクチャの重要なコンポーネントであり、すべての外部トラフィックのエントリ ポイントとして機能します。私たちはそのコア機能をルーティング、ロード バランシング、動的ルーティング、健全性チェック、再試行、フォールバックに分類しました。

APIゲートウェイは、受け取ったリクエストを適切なマイクロサービスに転送し、複数のインスタンス間でトラフィックを分散し、動的ルーティングをサポートし、マイクロサービスとそのインスタンスの健全性を監視し、失敗したリクエストを再試行し、マイクロサービスが利用できないか失敗した場合にはフォールバック レスポンスを提供します。認証、許可、レート制限、キャッシュ、ロギングなどの他の機能は、システムの特定の要件に応じてエッジの機能や一元化された機能に分散できます。

このモジュール式のアプローチにより、より柔軟で最適化されたアーキテクチャが可能になるため、このアプローチはエンタープライズAPIインフラストラクチャの簡素化、モダナイズ、拡張に向けた私たちの提案の中核となります。

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

一部のベンダーは、1つの製品の一部としてAPIゲートウェイ機能とAPI管理機能をどちらも提供していますが、これらの機能の違いを理解し、特定の要件に基づいて個別に評価することが重要です。これらの機能を組み合わせると混乱が生じ、組織のAPIインフラストラクチャの柔軟性と拡張性が制限される可能性があります。これは、APIゲートウェイ機能の配布に関する当社の立場を理解する上でも重要です。

ここで挙げた機能は、データ パスにインライン化する必要があるコア機能です。分散ゲートウェイ パターンでは、APIゲートウェイのインライン機能の一部も分散されます。これらの機能には、アクセス制御、レート制限、リクエスト検証、API分析、使用状況レポート、エラー率の監視、アラートとイベント、認証統合、サードパーティ統合、監視とロギング統合、エッジ キャッシュ、圧縮などがあります。

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

• APIゲートウェイの負荷の軽減：集中型APIゲートウェイの負荷が軽減され、システムのパフォーマンスと拡張性が向上します。
• 応答時間の短縮：これらの機能をクライアントの近くに導入することで、応答時間の短縮と遅延の削減が可能になります。データと機能のキャッシュを活用することで、エッジ ホスト型APIゲートウェイは受け取ったリクエストに迅速に応答することができます。

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

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

すべてのAPIを可視化できるため、APIゲートウェイはサービスの構成を行うのに論理的に適した場所となり、開発者は、新しいサービスを作成することなく、ゲートウェイの背後でAPIを組み合わせてビジネス ロジックを強化することができます。APIはサービス構成層で簡単に組み合わせることができます。

GraphQLにおけるサービス構成は、クライアントが利用できるデータの形式を定義する、厳密に型指定されたスキーマを使用することで可能になります。クライアントは、このスキーマを使用して、どのサービスやソースがデータを提供するかに関係なく、必要なデータを正確に指定するクエリを構築できます。クエリをデータ ソースにマップする関数であるリゾルバが、適切なサービスやソースからデータを取得するために使用されます。GraphQLによってセキュリティの強化が約束されますが、最終的なセキュリティは、開発者が作成するコード次第です。

「図6：API管理とインフラストラクチャの機能」には示されていない機能がまだいくつかあります。これらの残りの機能は、個別の管理と運用やデータプレーン機能に移行できる候補となります。

特定の実装やベンダー テクノロジを示唆することを避けるため、私たちは意図的に「アクター」という用語を使いました。ゲートウェイ アクターの実装は、VM、コンテナ、サーバーレス、あるいはベンダー固有のその他のアプローチに基づくインフラストラクチャを使用して実装される、メソッド、関数、ワーカー、スレッド、プロセスなどに基づいたものとなるでしょう。

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

APIゲートウェイ機能とは別に、DGAアーキテクチャでは、モノリシック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ベースのゲートウェイ アクター アプローチを提案します。

レポートのダウンロード