分散ゲートウェイアクター: 進化する API 管理

分散ゲートウェイ アクター (DGA) 設計パターンは、エッジ コンピューティングとクライアントの近くで利用可能なコンピューティングからインスピレーションを得ています。 このアイデアの核心は、各ゲートウェイ アクターをクライアントのできるだけ近くに超分散し、ゲートウェイ アクターをトランザクションの終了時にクリアされるまでの期間のみ存在させることにあります。 

このソリューションの基本的な前提をいくつか示します。

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

API トランスポートは、ゲートウェイ アクターと API ゲートウェイ間のネットワークを確立することを伴うため、インフラストラクチャの重要なコンポーネントです。 必要なインフラストラクチャのタイプはベンダーまたは企業によって異なり、異なる場合があります。 たとえば、大規模なパブリック クラウドでは、独自のバックボーンを使用して API トランスポートを実行する場合があります。 もう 1 つの実装としては、エンタープライズ データ センター内の既存の高帯域幅および低遅延ネットワークの上に低遅延メッセージング バスを重ねるという方法があります。

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

図 6 で説明されているすべての機能をどのように分類するかについてはさまざまな見解があるかもしれませんが、 API 管理インフラストラクチャは、慎重に調整する必要がある多くのコンポーネントの複雑な展開になっていることには同意できます。 

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

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

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

API ゲートウェイは、受信リクエストを適切なマイクロサービスに送信し、トラフィックを複数のインスタンスに分散し、動的ルーティングをサポートし、マイクロサービスとそのインスタンスの状態を監視し、失敗したリクエストを再試行し、マイクロサービスが利用できないか失敗した場合にフォールバック応答を提供します。 認証、承認、レート制限、キャッシュ、ログ記録などのその他の機能は、システムの特定の要件に応じて、エッジまたは集中機能に分散できます。 

このモジュール式のアプローチにより、より柔軟で最適化されたアーキテクチャが可能になり、エンタープライズ API インフラストラクチャの簡素化、最新化、拡張に関する当社の推奨事項の中心となります。

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

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

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

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

• APIゲートウェイの負荷軽減: 集中型 API ゲートウェイの負荷を軽減し、システムのパフォーマンスとスケーラビリティを向上させます。
• 応答時間を短縮: これらの機能をクライアントの近くに展開することで、応答時間が短縮され、待ち時間が短縮されます。 データと関数のキャッシュを活用することで、エッジホスト API ゲートウェイは受信リクエストに迅速に応答できます。

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

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

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

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

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

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

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

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

したがって、API ゲートウェイの簡素化は、すべての API ゲートウェイ ベンダーが共通の構成パラメータ セットを通じて管理できる標準的なコア機能セットを導き出す作業になります。 

この変革を実現したい企業は、既存の展開を妨げたり、フォークリフト操作を必要とせずに、一度に 1 つのアプリケーションずつ DGA アーキテクチャを展開できます。

DGA の重要な側面は、各ゲートウェイ アクターが一時的であり、API セッションの期間中のみインスタンス化されることです (つまり、1 つのクライアントが 1 つの API 呼び出しを行う)。 

分散ゲートウェイ アクターは、従来の API ゲートウェイよりも柔軟性、拡張性、コスト効率に優れています。 ゲートウェイ アクターを使用すると、API トラフィックを集約して処理するために、異なるベンダーの複数のモノリシック API ゲートウェイに依存するのではなく、開発者はネットワークのエッジに近い各 API に対して個別のゲートウェイ インスタンスを指定して展開できます。 API 自体により、特定のニーズに合わせてより高度な制御とカスタマイズが可能になります。

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

ゲートウェイ アクターは技術的な利点に加えて、企業が使用する一時的なゲートウェイ アクター インスタンスに対してのみ料金を支払うことができるため、従来の API ゲートウェイに比べてコストを節約できます。 この展開モデルにより、追加の収益モデルの機会が生まれます。 

DGA は、API トランスポート層を活用することで、API イングレス ロケーションを API ゲートウェイから本質的に分離します。 DGA はエッジ、つまり API 呼び出しを行うクライアントの近くに移動できます。 API は DGA で終了し、その後任意の手段で転送できます。 これは図3とは異なります。 レガシー API ゲートウェイ アーキテクチャ クライアント トラフィックが API ゲートウェイにトポロジ的に隣接して入力される場合。 

したがって、私たちの意図は、ベンダーやデプロイメントに依存しないアプローチを提案することです。異なるベンダーが、概説した同様の目的を達成するためにこれらのコンポーネントを構築するための独自の知的財産を持っている可能性があるためです。

このホワイト ペーパーでは、 API の拡散、 Edge 2.0アーキテクチャ、 API エコノミー、GraphQL の調査を複数四半期にわたって調査した結果をまとめています。 従来の API インフラストラクチャについてはまだ結論が出ていませんが、新しいアプローチが必要であると考えています。

世界中のあらゆる個別のデバイスやエンティティ内の価値を解き放つという約束だけでも、新しいアプローチを模索する十分な理由になります。 今日では、従来の API インフラストラクチャから脱却する必要があります。分散されているように見えても、内部的にはモノリシックだからです。

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

レポートをダウンロード