ビジネスを飛躍させるのは、あなたの仕事を知っている AI。
国内外の事例、新たなAIの取り組みをご紹介
GraphQL Federationは、開発者が単一のAPIを複数のGraphQLサービス(オープンソースのクエリ言語であるGraphQLで記述されたサービス)で使用できるようにする分散アーキテクチャー・アプローチです。
Federationは、スキーマ(バックエンドとフロントエンド運用の間の契約)を、より管理しやすいコンポーネントとマイクロサービスに分割し、チームがスキーマの一部を独自に構築、展開、管理できるようにする一方で、クライアントが操作できる統一されたデータ・グラフを維持します。
Federate GraphQL環境では、GraphQLゲートウェイは、複数のスキーマ(サブグラフまたはサービスとも呼ばれます)を1つのグラフ(またはルーター)に統合します。各サブグラフはスキーマ全体の一部を定義し、独自のタイプとフィールドのビジネス・ロジックとデータ取得を処理します。その後、ゲートウェイはスタンドアロンのサブグラフをつなぎ合わせてスーパーグラフにし、クライアントが単一のGraphQLスキーマを操作しているかのように、サービス全体のデータ・ソースをクエリできるようにします。
Federationは、複数のGraphQLスキーマを組み合わせる主な方法の1つは、異なるスキーマとリゾルバーを手動で組み合わせるスキーマ・スティッチングでした。開発者は、スキーマをどのようにマージするか、およびデータがどのようにスティッチングするかを定義する必要がありました。スキーマ・スティッチングは、GraphQLスキーマの統合ソリューションを提供しましたが、複雑でエラーが発生しやすいため、管理が困難でした。
これらの問題に対処し、スキーマ・スティッチング・プロセスを合理化するために、製品とアプリ・エンジニアリングのためのGraphQL実装であるApolloのエンジニアは、Apollo Federationを開発しました。Apollo Federationは、異なるサービスのタイプ間の接続を定義するために、「キー」、「外部」、「要件」、および「拡張」のキーワードを導入しました。新しい相互参照機能により、開発者はApollo Gatewayを使用して、過度に複雑なスティッチング・ロジックに依存せずに一貫性のあるデータ・グラフを構築できるようになりました。
しかし、Apollo GraphQL Federationは、単なる新しいツールとライブラリーのセットではありませんでした。また、アーキテクチャーと、サービスが通信して分散グラフを形成する方法を説明したシステムの仕様でもありました。これにより、他の実装とツールでもFederationの原則を採用できるようになり、Federation GraphQL APIを構築するための標準が確立されるようになりました。
GraphQL Federationは誕生以来、数多くの改良を重ねてきました。たとえば、Managed Federationは、手動介入やシステムのダウンタイムを必要とせずに、メトリクスの収集を容易にし、サブグラフの変更に応じた自動ゲートウェイ更新を有効にします。
また、サービス間のスキーマのマージとクエリの実行を簡素化するイノベーションである Federation 21の開発、スキーマ構成の制御を強化するためのモジュール性の向上、追跡とデバッグを容易にするエラーの可視性の向上も進歩しています。
Apollo Federationは、合理化されたAPIエコシステムを構築するための大きな進歩であり、フェデレーションITアーキテクチャーの導入を検討している企業の選択肢となっています。
それでも、ApolloベースのFederationの手法では、開発者は単一ベンダーの実装に縛られます。Apollo Federation環境では、ApolloまたはApollo準拠のバックエンド・テクノロジーであるApollo定義のディレクティブとタイプのみしか受け入れることができないからです。言い換えれば、Apollo Federationは、新しいテクノロジーが登場しても、システムの柔軟性を制限することがよくあります。
Apollo Federationの統合レイヤー機能を維持しながら柔軟性を最適化したい開発者は、Open Federationを好むかもしれません。Open Federationのアプローチにより、システムはGraphQL以外のAPIを含めて、あらゆるAPIベンダーやタイプのデータを組み合わせることができます。IBM API Connectなどのツールを使用することで、企業は互換性の制限なしにIT資産をカスタマイズおよび拡張でき、さまざまな技術コミュニティからのイノベーションを採用できます。
GraphQL は、リソースを過剰プロビジョニングまたはプロビジョニング不足になることなく、クライアントが必要なデータを正確に要求するのに役立つため、運用効率の最適化を目指す企業にとって最適なオプションとなります。
その柔軟性から、GraphQLがAPI用のクエリ言語およびランタイムとしてますます注目されていることも理解できます。2しかし、Webアプリやモバイル・アプリが洗練されるにつれて、単一のモノリシックなGraphQLサーバー(およびそのすべての依存関係)を展開することは困難になる可能性があります。Federationは、異種のサブグラフが1つの一貫したGraphQLサービスとして連携できるようにすることで、GraphQLエコシステムを簡素化します。
Federated GraphQLアーキテクチャの実装には、次の主要なプロセスが含まれます。
サブグラフ・スキーマを定義するには、ドメイン境界を特定し、それらの境界がどのように相互作用するかを決定することが含まれます。
フェデレーション・アーキテクチャーでは、各サブグラフ・スキーマはデータ・グラフ全体の特定の部分を表します。これには、サービスまたはドメインに適用されるタイプ、構成、クエリ、ミューテーション、およびサブスクリプションが含まれます。たとえば、製品サービスには製品やレビューなどのタイプを含むサブグラフ・スキーマがあり、ユーザー・サービスにはユーザーやプロファイル・タイプがある場合があります。
サブグラフ・スキーマは、標準のGraphQLスキーマとほぼ同じ方法で定義されますが、Federation固有のディレクティブが追加されています。Federationディレクティブは、システムがスキーマ間でエンティティーを拡張する方法と、ゲートウェイがサービス全体で特定のフィールドを解決する方法についての指示を提供します。また、エンティティーを参照するためのキーも定義します。
一例として、 @keyディレクティブは、フェデレーション・グラフ全体でタイプを識別するフィールドを指定します。このディレクティブは、ゲートウェイに、指定されたタイプを所有するサービスからエンティティーを取得するように求めます。@extendsディレクティブは、あるサブグラフ・スキーマで定義されたタイプが別のサブグラフスキーマに由来するタイプを拡張し、別のサービスでのタイプの拡張(追加フィールドを含む)を容易にすることを示します。
サブグラフ・サービスは、対応するサブグラフAPIのビジネス・ロジックを実装するバックエンド・サービスです。各サブグラフ・サービスは、データ・グラフの一部を定義し、そのドメインに関連するクエリとミューテーションを処理します。それぞれのリゾルバーは、適切なデータソース、データベース、またはREST APIから関連データを取得します。
また、サブグラフ・サービスはそのGraphQLエンドポイントをフェデレーション・ゲートウェイに明らかにし、フェデレーション・ゲートウェイはそれを使用して、フェデレーション・スキーマ全体を構成します。これらのサービスは、言語がGraphQLをサポートしていることを前提に、任意のプログラミング言語で記述することができます。
フェデレーション・ゲートウェイは、スキーマ構成とクエリ計画を調整します。フェデレーション・サーバーの助けを借りて、ゲートウェイは個々のサブグラフ・サービスを偽装し、統合されたAPIをクライアントに提示します。
フェデレーション・ゲートウェイを構成するために、チームは通常、各サブグラフ・サービスの場所を指定し、スキーマの取得、クエリ計画、実行、エラー処理に必要なインフラストラクチャーをセットアップします。導入すると、ゲートウェイはサブグラフ・サービスからスキーマを継続的に取得し、フェデレーテッド・スキーマの最新バージョンが確保されるようにします。
サブグラフ・サービスとフェデレーション・ゲートウェイが構成されると、管理者はシステム全体をデプロイします。これには、ハードウェアとクラウド・リソースのプロビジョニング、デプロイメント・パイプラインのセットアップ、システム・パフォーマンスの監視、高いリソース可用性の確保が含まれます。
Federated GraphQL環境を最適化するには、一貫したリアルタイム監視が不可欠であることは明らかです。慎重に監視することで、チームはパフォーマンスのボトルネック、システム・エラー、計画外のダウンタイムを、より大きな問題を引き起こす前に検知して解決することができます。監視により、サブグラフ・サービスとフェデレーション・ゲートウェイの正常性の追跡も可能になります。
GraphQL Federationは、大規模な分散システム向けのGraphQL APIの開発における大きな進歩をもたらしました。これにより、チームはエンドユーザー・エクスペリエンスを中断することなく、その作業を統合されたAPIにシームレスに統合しながら、GraphQLスキーマのさまざまな部分に独立して作業できるようになります。
GraphQL Federationには、マイクロサービス・アーキテクチャーの展開とキャッシュから製品開発と運用の洞察まで幅広いユースケースがあり、Netflix、Airbnb、GitHub、Expediaなどの企業で採用されています。
GraphQL Federationは、以下も促進します。
フェデレーション環境では、開発者は特定のデータ・ドメインに対する責任を複数のサービスに分散できるため、個々のサービス(およびその機能)をより俊敏に調整および拡張できるようになります。
フェデレーション・サービスは独立して管理できるため、チーム・メンバーは互いに干渉することなく、それぞれのドメインで作業できます。
REST API環境とは異なり、GraphQL Federationでは、クライアントは必要なすべてのリソースとデータを1回のリクエストで取得できるため、冗長性が排除され、リソースのデプロイが最適化されます。
IBM API Connectの無料評価版を試すか、IBMのエキスパートにご相談ください。API管理を最適化する準備ができている場合でも、詳細を検討中の場合でも、貴社のデジタル・トランスフォーメーションをサポートします。
AIを活用したソリューションで、統合プロセスの可能性を最大限に引き出します。まずは、IBMのエキスパートへの相談を予約するか、製品資料をご覧ください。
セキュアかつ高パフォーマンスなメッセージング・ソリューションであるIBM MQは、貴社のビジネスを強化します。無料評価版を試すか、IBMのエキスパートに相談して、IBM BQでどのように貴社の業務を変革できるかをご確認ください。
サイズや距離にかかわらず、高速でセキュアなファイル転送が行われます。IBM Asperaを今すぐお試しください。データ・ワークフローを合理化して高速で効率的なものにしましょう。
ハイブリッド・マルチクラウド・プラットフォームであるIBM webMethodsを使用してアプリケーションを統合し、作業を自動化します。
IBMインテグレーション・ソリューションでビジネスの可能性を解き放つ、アプリケーションとシステムを接続してクリティカルなデータに迅速かつ安全にアクセスできます。
IBMのクラウド・コンサルティング・サービスで新しい機能にアクセスし、ビジネスの俊敏性を高めましょう。ハイブリッドクラウド戦略や専門家とのパートナーシップを通じて、ソリューションを共創し、デジタル・トランスフォーメーションを加速させ、パフォーマンスを最適化する方法をご覧ください。
1 「Apollo GraphQL Introduces Federation 2 to Get More Organizations to the Graph」、BusinessWire社、2021年11月3日。
2 「Why GraphQL Needs an Open Federation Approach」、The New Stack社、2023年11月16日。
IBM web domains
ibm.com, ibm.org, ibm-zcouncil.com, insights-on-business.com, jazz.net, mobilebusinessinsights.com, promontory.com, proveit.com, ptech.org, s81c.com, securityintelligence.com, skillsbuild.org, softlayer.com, storagecommunity.org, think-exchange.com, thoughtsoncloud.com, alphaevents.webcasts.com, ibm-cloud.github.io, ibmbigdatahub.com, bluemix.net, mybluemix.net, ibm.net, ibmcloud.com, galasa.dev, blueworkslive.com, swiss-quantum.ch, blueworkslive.com, cloudant.com, ibm.ie, ibm.fr, ibm.com.br, ibm.co, ibm.ca, community.watsonanalytics.com, datapower.com, skills.yourlearning.ibm.com, bluewolf.com, carbondesignsystem.com, openliberty.io