フェデレーテッド・ゲートウェイとは

集中型システムでは、単一のゲートウェイ（それ自体が複数のAPIに接続され、管理を担当します）がすべてのクライアント・クエリーを処理します。一方、ゲートウェイ・フェデレーションにより、組織は、それぞれが独自の一連のサービスを担うAPIゲートウェイの分散ネットワークを使用できるようになります。

フェデレーテッド・ゲートウェイ・システムでは、システム全体に影響を与えることなく、必要に応じてサービスを追加できるため、効率的なリソースの使用とトラフィック管理が可能になります。別々の部門が異なるプロトコルを使用して、それぞれのゲートウェイを管理することもできます。このフレームワークにより、チームは独自のAPIを管理できるようになり、柔軟性や運用のレジリエンスなどが向上します。

このアプローチは、集中型APIゲートウェイに関連するトラフィックのボトルネックやその他の問題を回避するのにも役立ち、ゲートウェイ機能をエンドユーザーの近くに導入することでパフォーマンスのメリットを実現できます。ゲートウェイ・フェデレーション戦略は、REST、gRPC、SOAPなど各種APIアーキテクチャー方式とプロトコルに適用できますが、それぞれに利点と欠点があります。

ITの観点から見ると、フェデレーテッド・ゲートウェイは、DevOpsチームが会社全体のAPIプラットフォーム管理、ガバナンス、セキュリティー・ポリシーを遵守しながら独自のAPIを開発および展開できるため、有益です。チームは、組織全体の基準を維持し、チームの自律性と一元的な監督のバランスをとりながら、それぞれの領域におけるプロジェクトを完了するために迅速かつ独立して行動することができます（イノベーションの促進と市場投入までの時間の短縮）。

GraphQLフェデレーションは、統合されたGraphQL APIの作成に使われる代替の概念とアーキテクチャー・アプローチです。これは、単一のAPIクエリーで複数のサービスからのリソースを正確に対象にできるクエリー言語、GraphQLに基づいています。

GraphQLフェデレーションは、管理するデータを定義する独自のスキーマを持つさまざまなサービス（サブグラフと呼ばれる）を、スーパーグラフと呼ばれる統一されたスキーマに接続します。単一のゲートウェイは、このスーパーグラフ・スキーマをクライアント・アプリケーションに公開し、基礎となる複数のサービスとフィールドを統合し、すべてのAPIクエリーをルーティングします。対照的に、ゲートウェイ・フェデレーションは、中央コントロール・プレーンを通じて複数のAPIゲートウェイを接続し、各ゲートウェイが独自のクエリーを実行します。

フェデレーションは、共通のコントロール・プレーンを介して自律型コンポーネントを接続するシステム管理への一般的なアプローチです。

中央ゲートウェイ・システムでは、すべてのクライアント要求が単一のゲートウェイを通過します。このゲートウェイは、ルーティング、認証、承認、監視などの機能を管理します。フェデレーテッド・アーキテクチャーとは異なり、これらの役割は複数のインスタンスに分散されません。

このアプローチでは、各プロセスがゲートウェイを通過するため、ロギング、トラフィック管理、セキュリティーの適用、およびその他のタスクを簡素化できます。組織は単一のポイントからロールアウトを開始できるため、複数のゲートウェイやサービス間でバージョン更新を行う必要がなくなります。

ただし、一元化されたフレームワークを使用している企業は、特に業務の規模が拡大するにつれて、ボトルネックに遭遇する可能性が高くなります。システムの単一の通過ポイントであるゲートウェイは、容易に輻輳する可能性があります。さらに、単一障害点となるため、エラーが発生するとシステム全体に影響が及びます。

集中型システムとは異なり、フェデレーテッド・ゲートウェイ・アーキテクチャーは複数のゲートウェイで構成され、それぞれが一連の個別のサービスと関連APIを担います。ゲートウェイは独立して機能しますが、それぞれが中央コントロール・プレーンによって管理されます。

集中型フレームワークと比較して、フェデレーテッド・システムでは、開発チームがそれぞれのドメインをより高いレベルで制御できるため、柔軟性と自律性が促進されます。この分散型レイアウトにより、フェデレーテッド・システムの停止やシステム障害に対する回復力も高まります。

しかし、統合システムは運用がより複雑であり、チーム間にガバナンスの不一致やコミュニケーションのミスが生じる可能性があります。各ゲートウェイは個別に管理し、更新する必要があるため、ロールアウトには時間がかかることがあり、保守にコストがかかる可能性があります。

企業がフェデレーテッド・ゲートウェイ・システムを選択する理由にはいくつかあります。

たとえば、ゲートウェイ・フェデレーションは、企業が買収先の企業からさまざまなテクノロジー ・タックやAPI管理システムを継承する合併や買収の際によく使用されます。企業は、それぞれに異なるセキュリティー・プロトコル、技術標準、ガバナンス構造を備えた複数の別個のアーキテクチャーを個別に管理したり、取得したシステムを既存のエンタープライズ・システムに改造したりする代わりに、ゲートウェイ・フェデレーションに目を向けています。このアプローチにより、組織は既存のAPIゲートウェイとその基盤となるシステムを、中央コントロール・プレーンによって提供される上位構造に組み込むことができます。

同様に、複数のチームによって構築され、さまざまな設定に分散されている多数のマイクロサービスが存在する環境では、複数のゲートウェイが使用されることがよくあります。企業は、パフォーマンス上のメリットのためにフェデレーテッド・システムを選択する場合もあります。

たとえば、世界中に複数のオフィスがあり、それぞれが特定の地域にサービスを提供している物流会社を考えてみましょう。ゲートウェイ、サーバー、サービス、その他のリソースを、それらにアクセスするクライアントの近くに配置することで、企業は待ち時間 関連するパフォーマンス要因を最適化できます。

ゲートウェイ・フェデレーションでは、中央コントロール・プレーンが管理、監視、ガバナンスを行いますが、一般にクライアントからはアクセスできません。APIコンシューマーは、フェデレーテッド・システムを構成するゲートウェイと直接やりとりしますが（関連サービスを担うエンドポイントに問い合わせます）、コントロール・プレーン自体には照会しません。コントロール・プレーンは、API呼び出しが発生した後にのみ、メタデータを受信し、ログに記録します。

このアプローチは運用上の複雑さを招く可能性がありますが、独立性も促進します。たとえば、特定のニーズに応じて独自のゲートウェイとサービスを構成し、独自のプロトコルを選択し、独自にロールアウトを展開できるようにプラットフォーム・チームを支援できます。フェデレーテッド・アーキテクチャーは、エラーが発生したゲートウェイに隔離されて、ネットワーク内の他のゲートウェイに広がる可能性が低いため、構成ミスやセキュリティー侵害への耐性が高くなります。

一方、GraphQLフェデレーションでは、複数の独立したサービス（サブグラフ）のスキーマが1つの統合されたスーパーグラフ・スキーマに結合されます。単一のゲートウェイまたはルーターは、クライアント・クエリーの単一エントリーポイントを提供し、統合されたAPIエクスペリエンスを実現します。

ルーターはクエリをより小さなサブリクエストにインテリジェントに分割し、複数のサブグラフから関連情報を取得し、それをクライアント向けの一貫性のある応答にコンパイルします。

次のような個別のサービスを備えた医療プラットフォームを想像してください。

• 患者：患者の詳細、連絡先情報、病歴の管理
  
  
• 予約：今後の訪問のスケジュール設定と追跡
  
  
• 請求： 請求書と請求通知の処理

GraphQLフェデレーションは、これらのエンドポイントのそれぞれを個別のAPI呼び出しで照会する代わりに、クライアント（この場合は医師や患者にサービスを提供するアプリまたはダッシュボード）が、3つの個別のリクエストではなく、1回のAPI呼び出しで患者の病歴にアクセスし、次の予約を特定し、未払い残高を確認できる統合インターフェースを提供します。

GraphQLフェデレーションは、分散環境でスケーラブルなGraphQL APIを構築する方法を提供します。このフレームワークは、クライアントからの問い合わせに統一されたフロントエンドを提供しながら、サービスの独立した開発と展開を可能にします。ただし、コストと複雑さの課題、セキュリティーの脆弱性、輻輳、冗長性が発生する傾向にあります。

2019年に導入されたApolloフェデレーションは、GraphQLスキーマ定義言語内の特別なディレクティブ（@keyや@extendsなど）を使用して、サブグラフ全体の異なるタイプ間の関係を定義するGraphQLフェデレーション実装の一つです。

Apolloは一般的なソリューションですが、利用可能なGraphQLフェデレーション・オプションはこれだけではありません。一般的な代替手段には、Hive、Mesh、Indigo、WunderGraph Cosmoなどがあり、それぞれ異なるレベルのカスタマイズが可能です。

調査会社Gartnerによると、2024年にGraphQLフェデレーテッド。システムを導入していた企業は5%未満でしたが、2027年までにその数字は30%に達すると予想されています。Amazon Web Services（AWS）やMicrosoft Azureなどの大手クラウド・プロバイダーや、GitHubなどのコード・リポジトリーも、監視および検証ツールが組み込まれたGraphQL APIをサポートしています。

GraphQLフェデレーションには、特にクライアントのAPIアクセスを簡素化できるという点で、いくつかの明確な利点があります。チームは独自のサブグラフを導入、管理、スケーリングすることで、ある程度の独立性を維持できます。

ただし、一元化されたフレームワークであるGraphQLフェデレーションは、セキュリティー違反、輻輳の問題、性能の非効率性に対してより脆弱です。APIゲートウェイ・フェデレーションが複数のプロトコルと互換性があるのに対し、GraphQLフェデレーションはGraphQLスキーマにも依存します。

API 戦略を策定する際、組織はGraphQL APIフレームワークを採用するか、RESTなど別のアーキテクチャー方式をAPIに使用するかを決定します。

組織は最終的に、GraphQLフェデレーションとその他のアーキテクチャー方式の両方をシステムに組み込み、それぞれが異なる機能を処理することを選択する場合があります。ある一般的な構成では、企業はGraphQLを内部で使用し（セキュリティー、コスト、複雑さの懸念を軽減するための厳密なガードレール付き）、外部APIにはRESTなどの異なるアーキテクチャー方式（より深いレベルの制御とより簡単な導入を提供できます）を使用します。このシナリオでは、フェデレーテッドAPIゲートウェイを使用して、中央コントロール・プレーンを通じてこれらの異種アーキテクチャー方式を統合することもできます。

標準のAPIゲートウェイ構成では、1つのゲートウェイがすべてのユーザー・トラフィック、ルーティング、分析を処理します。このアプローチは単純なセットアップを簡素化するのに役立ちますが、より複雑な環境ではすぐにボトルネックになる可能性があります。

フェデレーテッド・ゲートウェイは、単一のAPIゲートウェイだけではなく、多くのAPIゲートウェイに依存しています。各ゲートウェイは、特定の一連のサービスへのAPI呼び出しを管理するために使用され、管理とガバナンスを処理するコントロール・プレーンに接続されます。

一方、サービス・メッシュはマイクロサービス間の接続を管理しますが、ユーザー自身とのインターフェースはとらないため、東西構成と見なされます。サービスメッシュは主に、単一の環境またはクラスター内の通信とオブザーバビリティーを促進します。ただし、ハイブリッドクラウド・メッシュと呼ばれるバリアントは、複数のクラスターと環境（マルチクラウド、ハイブリッドクラウド、オンプレミス環境を含む）にわたって暗号化、負荷分散、認証などの機能を実行するように最適化されています。

組織は、さまざまな戦略を使用してフェデレーテッド・ゲートウェイの分散アーキテクチャーを活用しながら、フェデレーテッド・システムに関連する運用の複雑さと保守コストの一部を削減できます。これらの手法は、チーム間のオープンなコミュニケーションと統一された監視を維持しながら、チームの自律性を維持するのに役立ちます。

企業はチーム間に明確な線を引き、各チームどのサービスの構築と保守を担当するかについて曖昧さをなくす必要があります。この実践により、説明責任が促進され、チームが同僚の作業を誤って重複したり構成したりするのを防ぐことができます。さらに、このアプローチにより、チームは自分の目標と責任（およびそれに基づいて行動する自由）をしっかりと理解できるため、生産性が向上します。

ゲートウェイとAPI全体でセキュリティーとコンプライアンス・プロトコルと標準が一貫して実装されていない場合、セキュリティーのリスク、法的リスク、評判のリスクが生じるおそれがあります。分散システムでは、ゲートウェイ全体でのロギング、暗号化、認証、およびその他のセキュリティー実装の標準の維持を優先する必要があります。そうすることで、脅威がどのドメインから発生していても、中央管理プレーンを使用してインシデント・レポートに効率的に対応し、包括的な監査を行い、将来の攻撃を防止することができます。

分散システムにおけるオブザーバビリティーのギャップは、セキュリティー上のリスクや性能の問題につながる可能性があります。中央管理プレーンにより、システムの正常性と性能の確認に必要な包括的な可視性をチームに提供することが非常に重要です。この機能によって、問題が発生した場合の修復が可能になるだけでなく、セキュリティーとパフォーマンスのメトリクスに基づいて先見的に改善を行うことができます。

統合開発者ポータルは、ホストされている場所や構造に関係なく、開発者がシステム内のあらゆるAPIにアクセスして学習できる集中ハブとして機能します。これらは、 DevOpsチームにAPIの構築、導入、保守方法に関する明確なフレームワークを提供するためのガイドライン、ドキュメンテーション、およびサンプルを提供するので、フェデレーテッド・システムでは特に重要です。

これらのユニバーサル標準は、API キーやその他の アクセス制御とともに、開発者がセキュリティーと一貫性を維持しながらAPIをシステムにシームレスに追加し、独自のゲートウェイを管理できるようにするのに役立ちます。

各チームはある程度の自律性をもって行動するので、ベスト・プラクティスを共有し、持続可能なネットワークを維持するには、オープンなコミュニケーションラインが不可欠です。ダッシュボードやその他の協働ツールを使用すると、特に1つのドメインの変更が関連サービスに影響を及ぼす可能性がある場合に、チームは共通の目標と手順に沿って同期できます。

包括的なレポート・メカニズムにより、DevOpsチームはレイテンシー、サービスの中断、その他の異常を迅速に検知して対処できるようになり、よりシームレスなユーザー体験が実現します。性能メトリクスによって、システムのどの部分がキャパシティーに達し、どの部分がパフォーマンスを下回っているかを特定することで、スケール効率を向上させることもできます。

コードとしてのインフラストラクチャー（コードを使用して、通常は手動による監視とプロビジョニングが必要なITプロセスを自動化）やAIOps（AIを使用してIT運用を効率化）などの最新のDevOpsアプローチは、フェデレーテッド・ゲートウェイをより効率的に運用するのに役立ちます。自動化技術は、人為的エラーの可能性を減らし、ITチームがより複雑な問題に集中できる余裕を与えるので、ネットワークの回復力の強化にも貢献します。

ゲートウェイ・フェデレーションは、分散型アーキテクチャーの柔軟性とカスタマイズを、一元化されたガバナンス構造と組み合わせたもので、従来のアーキテクチャーに比べていくつかの利点があります。

フェデレーションにより、チームは独自のゲートウェイを制御できるようになり、ランタイム構成の調整や更新の管理、クライアントやサービスのニーズに最適なコーディング環境のカスタマイズが可能になります。たとえば、集中型システムでAPIのレート制限を調整するには、チームは組織の単一のゲートウェイを通じてリクエストを送信する必要があります。フェデレーテッド・システムにより、チームはネットワーク内の他のゲートウェイに影響することなく、独立してリアルタイムで調整を行うことができます。

中央プレーンにより、複数のゲートウェイが独自の構成を持っていても、共有の互換性と安全性基準に確実に準拠させることができます。チームは、コントロール・プレーンによる外部監視のメリットを受けながら、パラメーターを自律的に調整できる柔軟性を利用できます。

フェデレーテッド・アプローチでは、多くの場合、開発チームが独自のドメインを改善および維持する方法について最良のアイデアを持っていることが認識されています。チームには、問題が発生したらすぐにAPIまたはサービスを調整する権限が与えられるため、適応性と俊敏性が向上します。

チームは、サービスと中央コントロール・プレーンの関係を維持しながら、さまざまなコーディング言語で作業することもできます。最後に、各部門は変更の承認を権限のある中央の部署に頼るのではなく、必要に応じて更新を展開できるため、新しい機能の市場投入までの時間が短縮され、ワークフローが簡素化されます。

フェデレーテッド・システムは、チームが自身の遂行能力を監視し、それに応じてレート制限やトラフィック分散を調整できるようにすることで、より効率的なリソース・プロビジョニングを実現できます。組織は、追加のキャパシティーを必要とするサービスと機能のみをスケールアップでき、あまり使用されていないサービスや地域から需要の高いサービスや地域にリソースを集中させることができます。

さらに、APIゲートウェイは独立しているため、ゲートウェイから別のゲートウェイに脆弱性が移りづらくなります。その結果、フェデレーテッド・システムは、障害がシステム全体ではなく単一のゲートウェイにのみ影響する可能性が高いため、一般に攻撃や停止に対して耐性が強くなります。

フェデレーテッド・システムでは、個々のDevOpsチームが独自のゲートウェイの運用とメンテナンスを担います。責任範囲が狭まることで、中央チームは、コンプライアンス規制の実施、チーム間の相互コミュニケーションの促進、システム・アーキテクチャーの改善など、より高度な問題に集中できます。

フェデレーテッド・ゲートウェイはパフォーマンスを分析し、ドメイン全体にガードレールを適用できるため、データサイロが発生する可能性がはるかに低くなります。クロスゲートウェイのメトリクスにより、特定のサービスが関連する製品やサービスにどのような影響を及ぼしているかを、より全体的に把握できます。

分散された所有権と柔軟性は、特にガバナンスや監視機能に障害が発生したときに複数の課題を引き起こす可能性があります。フェデレーテッド・ゲートウェイがもたらす課題には以下が含まれます。

チームの自律性はイノベーションの促進に役立ちますが、システムのアーキテクチャーの複雑さも増し、インフラストラクチャーとコンピューティングのコストが上昇します。フェデレーテッド・システムの構造は分散化されているため、保守やセキュリティーのためのリソースが多く必要になる傾向があります。

メトリクスとログは複数のAPI Gatewayに分散されているため、組織が全体的なシステム性能について一貫性のある全体像を把握することがより困難になる可能性があります。データ・ソースは断片化し、より広範なネットワークから切り離される可能性があるため、潜在的な誤構成の特定やトラブルシューティングがより困難になります。組織は、強力な標準化プロトコルと原則、およびオブザーバビリティー・ツールでこの課題を対処できます。

個々のチームは独自の判断で更新を行うことができますが、企業全体への展開には集中管理環境よりも時間がかかる可能性があります。フェデレーテッド・ゲートウェイは、単一の中央コードベースを更新するのではなく、複数のドメインに更新を配布し、各チームがこれらの変更を個別に承認し、統合する責任を負います。

分散ゲートウェイ全体で一貫した構成とポリシーを維持することが難しい場合があります。企業のガバナンス基準から逸脱するプロトコル、ロールアウト・スケジュール、データ形式をチームが採用すると、非互換性やセキュリティーの脆弱性が生じる可能性があります。逆に、標準とガバナンス・ポリシーが厳しすぎると、企業が実験を抑制して、イノベーションのペースが遅くなるリスクがあります。フェデレーテッド・システムでは、バランスが非常に重要です。

企業がフェデレーテッド・システムの下で成長し進化するにつれて、複数のチームが意図せず冗長なAPIを開発すると、APIの無秩序な増加など、新たな非効率性が生じるリスクがあります。この問題が拡大すると、ゲートウェイは管理不能になり、中央のプレーンが変更を追跡できなくなる可能性があります。この問題は、効率的なガバナンスを通じて軽減できます。