GraphQLの役割と影響

GraphQL は、従来の REST API の制限を超えた、API 開発に対する最新かつ効率的なアプローチとして登場しました。 REST は Web の初期の頃から広く使用されてきましたが、GraphQL は開発者に新たな視点とより優れた制御を提供します。 GraphQL を使用すると、開発者は厳密に型指定されたスキーマを定義して、クライアントが必要なデータを正確に要求できるようにすることができます。 GraphQL は、データの過剰フェッチと不足フェッチを排除することでパフォーマンスを最適化し、複雑なデータ クエリとデータ モデリングの要件を持つ最新のインタラクティブな Web アプリケーションの作成を容易にします。

ただし、GraphQL には課題がないわけではないことは認識しています。 このホワイト ペーパーでは、GraphQL の導入に関連するセキュリティ上の懸念と学習曲線について詳しく説明します。 GraphQL の実装に成功した有名企業が得たメリットを説明する実際のケーススタディを紹介します。

さらに、GraphQL に関する独自の調査を紹介し、経験と発見を共有します。 GraphQL の簡単な入門書を概説し、REST と比較し、GraphQL が解決する課題について詳しく説明します。 組織が十分な情報に基づいて意思決定を行えるよう、セキュリティに関する考慮事項についても説明します。 私たちの研究は、GraphQL の変革の可能性を明らかにしました。 テスト管理スイートのソフトウェア アーキテクチャを簡素化し、GraphQL を通じて JSON オブジェクト内に隠された公開データの量を 300% 以上増加させた方法を紹介します。

結論として、REST API インフラストラクチャの拡張、最適化、または運用に取り組んでいる企業には、GraphQL を実行可能なソリューションとして検討することを強くお勧めします。 私たちの洞察は、GraphQL の導入に着手する人々に実用的なガイダンスを提供し、そのメリットを活用して課題を効果的に克服できるようにします。

REST API の制限により、新しい API テクノロジー アプローチの需要が高まっています。

REST (Representational State Transfer) ベースのアプローチは、もともと Web API を設計するための一連のアーキテクチャ原則として提案されました。 REST は、Common Object Request Broker Architecture (CORBA) などの他のテクノロジよりもサービス指向アーキテクチャ (SOA) を実装するためのより優れた手段として、Web 2.0 の出現とともに 2000 年代から 2010 年代にかけて進化しました。

モバイルの普及により顧客数が増えるにつれ、正確なデータに対する需要が高まりました。 しかし、REST ベースの API では、データの過剰取得または不足取得が発生することが多く、非効率につながります。 Facebook などのアプリに代表されるこのアプローチでは、1 回の更新に多数の REST API 呼び出しが必要になることが多く、ネットワーク トラフィックが増加し、パフォーマンスとユーザー エクスペリエンスが低下します。

GraphQL は、厳密に型指定されたスキーマと、より効率的なデータクエリ方法を提供することで、これらの制限に対処するように特別に設計されました。 これにより、ネットワーク帯域幅を最適化するために特定のデータが必要なユースケースに適しています。 さらに、GraphQL のスキーマをイントロスペクトする機能により、より優れたドキュメントとツールが可能になります。 REST のより標準化された実装が競合相手となる可能性はありますが、GraphQL の独自の機能と利点により、分散型でデータ集約型の最新のアプリケーション アーキテクチャにとって GraphQL は魅力的な選択肢となります。

図 1 は、REST と GraphQL の実装方法のトポロジの違いを示しています。 REST API vs GraphQLで述べられているように、「GraphQL と REST API の主な違いは、GraphQL がクエリ言語であるのに対し、REST はネットワークベースのソフトウェアのアーキテクチャ概念である点です。」 

Meta は、モバイル アプリのパフォーマンスと柔軟性を向上させるために、2012 年に GraphQL を作成しました (2015 年にオープンソース化)。 GraphQL 以前は、Meta のモバイル アプリは RESTful API とネイティブ コードの組み合わせを使用して構築されていたため、アプリがサポートする必要のあるさまざまなデバイス、画面サイズ、ネットワーク条件を処理することが困難でした。 

彼らが直面した主な課題の 1 つは、RESTful API が間違った量のデータを返すことがよくあることでした。データが多すぎる場合もあれば、少なすぎる場合もあります。 API がモバイル アプリに必要のない大量のデータを返すと、読み込み時間が遅くなり、パフォーマンスが低下します。 API が返すデータが少なすぎると、モバイル アプリは必要なすべてのデータを取得するために異なるエンドポイントに複数のリクエストを送信する必要があり、プロセスの遅延と複雑さが増します。

Meta は GraphQL を開発し、どのアプリでも 1 回のリクエストで必要なデータのみをリクエストできるようにしました。 これにより、モバイル アプリとバックエンド サービス間のデータ転送を最適化できるようになり、読み込み時間が短縮され、パフォーマンスが向上しました。 さらに、GraphQL の強力な型付けと自己文書化機能により、開発者は API を理解して利用しやすくなりました。 

GraphQL は、データの取得と操作のための強力な機能を提供し、従来の API アプローチに比べて大きな利点をもたらします。 

GraphQL は、API からクエリできるデータの構造とタイプを定義する際の明確さと正確性を保証する、厳密に型指定されたスキーマを備えています。書籍、著者、出版社を含むライブラリの API があるとします。 

a) GraphQLスキーマ: GraphQL では、厳密に型指定されたスキーマは以下の図 2 のようになります。 

GraphQL の厳密に型指定されたスキーマは、入力検証を有効にし、データの過剰フェッチと不足フェッチを防止し、明確なドキュメントとツールのサポートを提供し、バージョン管理を容易にし、承認とアクセス制御を支援することで、セキュリティ関連の利点を提供します。 これらの機能は、一般的な脆弱性のリスクを軽減し、適切なデータ処理とアクセス管理を保証することで、API セキュリティを強化します。

示されている例 (図 2) では、スキーマは書籍、著者、出版社のデータ型と、それらの相互関係を定義しています。 スキーマは厳密に型指定されており、すべてのフィールドには特定のデータ型があり、クライアントはスキーマを簡単にイントロスペクトして、使用可能なフィールドとその型を検出できます。

b) RESTスキーマ: REST では、スキーマ定義は、以下の図 3 に示すように緩く型付けされます。 

これらのエンドポイントは、書籍、著者、出版社を表す JSON オブジェクトを返しますが、スキーマ自体は明示的に定義されておらず、プログラマーのスキルと解釈に委ねられています。 クライアントは、データの構造を理解するためにドキュメントに頼る必要があります。

GraphQL は、REST のより優れた代替手段という枠を超えて進化しており、より優れたデータ戦略を検討している企業にとって好ましいアプローチになる可能性があります。 REST の制限を解決することに加えて、GraphQL が API 設計への新しいアプローチに進化した理由は他にもいくつかあります。 表 (図 4) は REST に対する GraphQL の利点を示していますが、GraphQL は REST 自体の問題の特定に対する対応ではなく、インターネットとさまざまなアプリケーションの進化に対する対応として考えるのが最適です。

GraphQL は従来の RESTful API に比べて多くの利点を提供しますが、使用にあたってはいくつかの課題もあります。 一般的な課題は次のとおりです。

1. 学習曲線: ほとんどの開発者は REST に慣れているため、GraphQL の導入を計画している組織では、チームが GraphQL を効果的に使用する方法を学習するための時間を割く必要があります。 GraphQL では、API の構築と使用に関して異なる考え方が必要であり、これを採用するには、基盤となるアプリケーション アーキテクチャの変更が必要になる可能性があります。 開発者は、スキーマ、リゾルバ、タイプなどの新しい概念や、新しいツールやライブラリを学習する必要がある場合があります。 GraphQL を使用すると、クライアントはアクセスできるデータをより細かく制御できるため、API のセキュリティ保護が困難になる可能性があります。 入力検証、認証、承認などの手法は、RESTful API とは異なる方法で適用する必要がある場合があります。
2. キャッシュ: GraphQL では、クライアントがクエリごとに異なるデータを要求できるため、キャッシュがより複雑になり、応答をキャッシュして再利用することが難しくなります。
3. パフォーマンス： GraphQL を使用すると、クライアントは必要なデータのみをリクエストできますが、より複雑でリソースを大量に消費するクエリも可能になります。 GraphQL API では、特に大規模なデータセットをクエリする場合や、多数の同時リクエストが行われる場合に、パフォーマンスの問題が発生する可能性があります。 開発者は、クエリの深さを制限したり、クライアントが必要な特定のデータにのみアクセスできるように許可したりするなどの戦略を実装する必要があります。
4. エラー処理: GraphQL では、エラーが個別の HTTP ステータス コードとしてではなく、レスポンスの一部として返される可能性があるため、エラー処理がより複雑になる可能性があります。
5. テスト: GraphQL を使用したテストでは、クエリの複雑さ、標準化されたテスト手法の欠如、スキーマの進化、実行時のクエリ検証などの課題が生じます。 開発者は、これらの課題に対処するために適切なテスト フレームワークとツールを見つけるために時間を費やす必要があります。 開発者は、GraphQL API を効果的にテストし、その機能性と安定性を確保するために、適切なツールを選択し、スキーマの進化を考慮して包括的なテスト範囲を確保する必要があります。
6. 監視： GraphQL API の監視は、クエリの複雑さ、標準化されたログとメトリックの欠如、パフォーマンスの問題が発生する可能性があるため、困難な場合があります。 GraphQL クエリの動的な性質により、要求されたデータの構造とサイズを予測および監視することが難しくなります。 GraphQL API 専用の標準化された監視ツールがないため、GraphQL クエリのパフォーマンス、エラー追跡、API の健全性に関する洞察を得ることが困難です。 開発者は、GraphQL の独自の特性に対応し、効率的なパフォーマンスと信頼性の高い操作を確保できる、専用の監視ツールとプラクティスを採用する必要があります。 

GraphQL は、API の構築からモバイル アプリの強化まで、幅広いアプリケーションで使用できる強力なツールです。 柔軟性とデータ ソースを統合する機能により、さまざまな使用パターンに適しています。

1. 効率的なAPIの構築: GraphQL の主な用途の 1 つは、Web アプリケーションやモバイル アプリケーションで使用できる API を構築することです。 GraphQL は、データの定義とアクセスを行う柔軟かつ強力な方法を提供するため、幅広いクライアントとユースケースをサポートする必要がある API の構築に適しています。
2. データの取得と操作: GraphQL を使用すると、データベース、クラウド サービス、その他の API など、さまざまなソースからデータを取得して操作できます。 GraphQL は、データにアクセスするための統一された方法を提供することで、データ駆動型アプリケーションの構築と保守のプロセスを簡素化するのに役立ちます。
3. リアルタイムのユースケース: GraphQL は、クライアントが特定のデータの更新をサブスクライブし、データが変更されたときに通知を受け取ることができるため、リアルタイムのユースケースに適しています。 これは、チャット、ライブ ストリーミング、リアルタイム ダッシュボードなどのアプリケーションで使用できます。
4. マイクロサービス: GraphQL を使用すると、さまざまなマイクロサービスが一貫性のある明確に定義された方法で相互に通信できるようにする、柔軟で疎結合のアーキテクチャを構築できます。
5. バックエンドからフロントエンドへ: GraphQL を使用すると、バックエンド フロントエンド (BFF) アーキテクチャを構築できます。これにより、さまざまなフロントエンド クライアントが一貫性のある効率的な方法でデータやサービスにアクセスできるようになります。
6. モバイル開発: GraphQL は、プラットフォームやデバイスに関係なく、データやサービスに一貫性と効率性を持ってアクセスする方法を提供することで、モバイル アプリを強化するために使用できます。 

GraphQL が必要な理由は、次の業界の導入例からも明らかです。

Netflix は、GraphQL 実践者なら誰もが必読の 2 部構成のブログ シリーズで、2020 年のGraphQL の取り組みをまとめました。 彼らが発表したケーススタディは、スタジオ API を採用し、GraphQL 向けに再設計したStudio Edge システムでした。 Netflix の Studio API は、コンテンツ チームによって、テレビ番組や映画の制作、ポストプロダクション、配信の管理と監視に使用されます。 API は、タイトルやタレント情報などのメタデータを含む膨大な量のデータへのアクセスを提供します。

当初、Studio API は従来の RESTful アーキテクチャを使用して構築され、エンドポイントは JSON 形式でデータを返します。 しかし、API が拡大し、それにアクセスするクライアントの数が増えるにつれて、より効率的なソリューションが必要であることが明らかになりました。

Netflix は、Studio API の潜在的なソリューションとして GraphQL の検討を開始しました。まず、Studio API 用にキュレートされたグラフを構築しました。その結果、ネットワーク使用量の削減、データ アクセスの簡素化、クライアントが必要なデータのみをリクエストできるようにすることでパフォーマンスを向上するなど、いくつかの重要なメリットが明らかになりました。

Netflix は、Studio API に GraphQL を採用する際に、特にスキーマの複雑さの管理や、クライアントが閲覧を許可されたデータにのみアクセスできるようにするといった、いくつかの特有の課題にも直面しました。

これらの課題に対処するために、Netflix は「Netflix GraphQL Federation」と呼ばれるカスタム ソリューションを開発しました。これは、Apollo Federation 仕様を使用して、Studio API スキーマをより小さく管理しやすい部分に分割します。 また、権限とアクセス制御を管理するシステムも実装し、スキーマの特定の部分へのクライアント アクセスを制限できるようになりました。

ブログでは、モノリスからフェデレーテッド ゲートウェイへの API アーキテクチャの進化についても公開されています。 図5は彼らのブログからの写真の改変です。

業界では普及しているものの、正式には採用されていない別のアプローチが欠けていると私たちは考えています。

図 5 のゲートウェイ集約レイヤーとフェデレーション ゲートウェイを次のように組み合わせることができます。

各歯車アイコンは基本的に、エッジ、つまりトポロジ的にクライアントに近い場所でリアルタイムにインスタンス化され、安全な API トランスポートを介してマイクロサービスに接続できる、一時的かつフェデレーションされた GraphQL インスタンス (別名ゲートウェイ アクター) を表します。 この組み合わせは本質的に、ゲートウェイ集約層またはフェデレーション層を、両方の機能の長所を組み合わせた分散ゲートウェイ アクターに置き換えます。 図 7 に示すように、この分散 GraphQL ゲートウェイ アクターのアーキテクチャと呼びます。

PayPalはGraphQLの取り組みを始めて以来、2018彼らが Checkout アプリに REST を導入したとき、Meta と同様に、REST に関する彼らの主な懸念は、設計原則が Web アプリやモバイル アプリ、およびそのユーザー向けに最適化されていないことでした。 クライアント アプリケーションはクライアントからサーバーへの往復を何度も実行し、データの取得に約 700 ミリ秒かかっていました。 その結果、レンダリング時間が遅くなり、ユーザーの不満が募り、コンバージョン率が低下しました。 PayPal は、チェックアウト アプリに関して、ユーザー インターフェイス (UI) 開発者が UI の構築に 3 分の 1 未満の時間を費やし、残りの時間をデータの取得と処理方法の検討に費やしていることを発見しました。

PayPal エンジニアリング チームが検討したその他のテクノロジーは、オーケストレーション API と Bulk REST でした。 オーケストレーション API を構築すると、過剰なフェッチが発生し、クライアントがサーバーに結合されることになります。 PayPal は、時間が経つにつれてこのアプローチによって API が重くなり、不格好になり、複数の目的を果たすようになる可能性があると結論付けました。 彼らの Bulk REST 実験も失敗に終わりました。 これにより、エンジニアリング チームはオーケストレーション API を微調整する必要がなくなりましたが、クライアントは API の動作に関する詳細な知識を持つ必要がありました。

PayPal が GraphQL を使用して新しい製品を構築した最初の経験は、PayPal Checkout をアプリに統合するためのモバイル SDK でした。 GraphQL を評価してから 1 週間以内に、エンジニアリング チームはそれを新しい製品に使用することを決定しました。 API がまだ準備できていなかったにもかかわらず、PayPal 固有の知識をほとんど必要とせずに、予定より早く製品を完成させることができました。 開発者は、効率的でユーザーフレンドリーなアプリを迅速に構築し、エンジニアリング チームにテクノロジー スタックに GraphQL を完全に採用するよう説得することができました。 

スターバックスは、自社のプログレッシブ ウェブ アプリ(PWA)。

チームの任務は、複雑なビジネス ロジックに効率的かつ効果的に対応する注文システムを作成することでした。 顧客は注文をカスタマイズできるため、開発チームは、システムが独自のビジネス ロジックの複数のインスタンスに対応し、適切なデータを適切な場所に適切なタイミングで送信できるようにする必要がありました。

GraphQL により、チームはサーバー側のキャッシュとレンダリングを備えた効率的な API を作成し、オフライン機能を向上させることができました。 チームは React を使用してアニメーションを組み込み、ダイナミックで魅力的なユーザー エクスペリエンスを実現しました。

F5 CTO オフィスの目的は、F5 エコシステム内で GraphQL をどのように使用できるかを理解することでした。 GraphQL の使用を検討するプロジェクトが 2 つ進行中です。

F5 が提供するテスト管理スイート(TMS) を使用すると、顧客は自社システムのエンドポイントまたはクライアントをテストし、それが人間かボットかを確認することができます。

これは、TMS ソフトウェアの開発とテストを効率化するための社内向けプロジェクトでした。 主な目標は、既存の SQL データベースに閉じ込められた JSON データを抽出し、グラフ データに変換し、クエリ用の GraphQL API を実装することでした。

これが必要だったのは、現在のデータベースが、メタデータを JSON オブジェクトとして表形式データベースに保存することによって生じる「JSON-BLOB 問題」などの課題を抱えているためです。 これらのオブジェクトの解析と処理は、本質的にコストがかかり、非効率的です。 さらに、JSON-BLOB はグラフの性質上、F5 の製品とセキュリティをさらに向上できる貴重なデータが含まれています。 有向グラフ データベースに移行することで、JSON BLOB を有向関係で効率的に解析および管理できるようになり、データ転送と利用が最適化されます。 

結果は有望です。 TMS リレーショナル データベースのどのテーブルに JSON BLOB があるかを特定することで、GraphDB に移行して GraphQL を使用すると、システムの可視性が何倍にも向上することがわかりました。 

図 9 は、このプロジェクトの可能な進化または実装の選択肢を示しています。 それぞれの選択には独自の意味合いがあります。

オプション 1 では、クライアントを変更する必要がないため、UI への影響は最も少なくなります。 オプション 1 または 2 のようなハイブリッド モードは、特に JSON オブジェクトを含む列の数が少ない場合、状況に応じて適切に機能する可能性があります。 これに加えて、各 JSON の派生スキーマも小さくなります。

しかし、これを計画する際に、JSON オブジェクトには SQL データベースの他の列に格納されているコンテキストが必要であることに気付きました。 各 JSON オブジェクトに格納されるスキーマのサイズもかなり大きかったです。 これにより、コードベースを維持するための作業が増えてしまいます。 そこで、慎重に検討した結果、オプション 3 に示すように、GraphQL と Neo4J をサポートするようにアプリケーションを再設計することにしました。

CloudGraph は、AWS、Azure、GCP、Kubernetes (K8s) 向けの無料のオープンソース ユニバーサル GraphQL API およびクラウド セキュリティ ポスチャ管理 (CSPM) ツールです。 このプロジェクトの目的は、CloudGraph を使用して「CloudGraph プラグイン」(図 10) を構築し、F5 Distributed Cloud (F5XC) データを表示して、F5 Distributed Cloud を使用して接続されたクラウド リソースの可視性を向上させることです。

私たちの目標は、CloudGraph と統合してテクノロジーを深く理解し、将来の CloudGraph 統合、洞察、および F5XC データ用の GraphQL API を構築することです。

カスタム F5XC プロバイダーを CloudGraph プラットフォームに統合し、プラットフォームの関係作成機能を使用すると、F5XC を使用して接続されたクラウド リソースと、他のクラウド間の関係の可視性が向上します。 その後、同じテナントの複数のクラウドにわたるリソースに対して複雑なクエリを生成できます。 これにより、関係者に包括的な F5XC の概要を提供し、追加の GraphQL プラグインと F5 とその顧客に関連するクラウド運用のカスタム分析情報のための CloudGraph のより深い統合を検討できるようになります。

上記の取り組みに基づいて、当社の初期の調査は、先に紹介したケーススタディで概説した経験と一致しています。

セキュリティの面で GraphQL が REST より優れているという当初の認識は誤りでした。GraphQL も他のテクノロジーと同様に、正しく実装されなければ独自のリスクを伴うからです。 GraphQL が本質的に他のテクノロジーよりも安全であるわけではないことを認識することが重要です。 GraphQL API のセキュリティを確保するには、適切な実装とベスト プラクティスの遵守が不可欠です。 この誤解を払拭することで、GraphQL のセキュリティ上の考慮事項を現実的に理解した上で GraphQL に取り組むことができ、潜在的なリスクを軽減するための適切な対策を講じることができます。

GraphQL は、開発者にイントロスペクションと呼ばれる強力なツールを提供します。これにより、開発者は GraphQL サービスで使用されるスキーマに関する情報を要求できます。 このツールを使用すると、開発者はサービスとその構造について学ぶことができます。 ただし、内省にはリスクが伴います。 本番環境の GraphQL サービスでイントロスペクションを有効にすると、スキーマ内の機密情報にもアクセスできるようになります。 悪意のあるユーザーがイントロスペクションを悪用して機密データを取得し、潜在的に危害を加える可能性があるため、これは重大なリスクとなります。 さらに、イントロスペクションにより、ユーザーはスキーマ全体を表示して実行するクエリを決定できるため、潜在的に有害な操作を簡単に識別できるようになります。 このようなリークの結果は、スキーマとそれに含まれるデータの性質に応じて、悲惨なものになる可能性があります。

緩和： イントロスペクションのリスクを軽減する解決策は、さまざまなフレームワークを使用して本番 API でイントロスペクションを無効にすることです。 イントロスペクションを無効にすると、開発者はイントロスペクションが提供する便利な機能の一部を失うことになります。 ただし、使いやすさを取り戻すために、開発者は GraphOS などのツールを使用して本番 API の GraphQL スキーマを登録できます。 これにより、スキーマとその情報への制御されたアクセスを維持できます。

SQL インジェクションは、データの操作からデータベースの完全な削除に至るまでのリスクをもたらす、広く認識されている一般的な攻撃です。 この単純な攻撃は文字列の連結を利用し、攻撃者が入力内に実行可能コードを挿入して、データベースへの不正アクセスを許可し、悪意のある変更を可能にします。 興味深いことに、この攻撃ベクトルは SQL データベースだけに限定されず、Neo4j のようなグラフィカル データベースにも影響を与える可能性があります。 Neo4j は、SQL に似ていてその脆弱性を継承する Cypher クエリ言語を採用しています。 サイファー インジェクションと呼ばれるこのタイプの攻撃は、類似点を悪用しますが、新しい発明を必要とせずに既存のソリューションの恩恵も受けます。

緩和： 対策としては、ユーザー入力をサニタイズして悪用を検出して防止することや、パラメータ化を使用してユーザー入力を直接クエリ作成から抽象化することなどが挙げられます。 これらの対策により、インジェクション攻撃のリスクが効果的に軽減されます。 GraphQL 実装ではこのセキュリティ問題に対処することが重要ですが、幸いなことに、よく知られており簡単に実装できるソリューションが利用可能です。 

REST API の上に GraphQL API を重ねると、サーバー側リクエスト偽造 (SSRF) の脆弱性が発生する可能性があります。 攻撃者は、GraphQL プロキシを介して REST API に送信されるパラメータを変更することで、これを悪用する可能性があります。 どちらの API も特定の呼び出しのパラメータを検証しない場合、攻撃者はバックエンド システムを制御できるようになります。 たとえば、GraphQL クエリのユーザー ID に「/delete」を追加すると、REST API に渡されたときにデータが意図せず削除される可能性があります。

緩和： この脆弱性は正当な懸念事項ですが、GraphQL スキーマで型を定義し、パラメータを外部 API またはサービスに送信する前に徹底的に検証することで効果的に対処できます。 この脆弱性は、GraphQL に関連する他の脆弱性と同様に、GraphQL 自体に固有の問題ではなく、実装の問題から生じていることに注意することが重要です。 このような問題は、GraphQL というテクノロジーが大きな可能性を秘めているにもかかわらず、短期的な考え方によって GraphQL が誤用されたときに発生します。

認証の脆弱性は、GraphQL を含むさまざまなシステムでよく見られる攻撃ベクトルです。 GraphQL は単一のリクエストで複数のクエリやミューテーションを送信できるため、ブルート フォース メソッドを含むバッチ攻撃にさらされる可能性があります。

最初のタイプの攻撃は、ログイン パスワードの総当たり攻撃です。 攻撃者は、ログイン資格情報のペアを含む多数のミューテーションを含むリクエストを送信します。 GraphQL では 1 つのリクエストで多くの変更が許可されるため、この攻撃はレート制限チェックをバイパスし、パスワードの総当たり攻撃によってセッションの作成を可能にします。

2 番目のタイプの攻撃は同様に動作しますが、ワンタイム パスワード (OTP) と呼ばれる一般的な形式の 2 要素認証 (2FA) をターゲットにします。 1 つのリクエストが複数のミューテーションとともに送信され、各ミューテーションには異なる OTP バリエーションとペアになった有効なログイン資格情報が含まれます。 いずれかのミューテーションに正しい OTP が含まれている場合、リクエストは認証され、セッションが確立されます。

緩和： 絶対確実な解決策は存在しないため、これらの脆弱性に対処するには包括的なアプローチが必要です。 開発者は、安全なコーディング手法を採用し、ビジネス ロジックの観点を重視することで重要な役割を果たします。 Web サーバー側では、ログイン試行の制限やユーザー入力の検証などの対策を実装することが重要です。 さらに、正当なログイン試行では通常、複数の変異は発生しないため、複数の変異のリクエストをスキャンする場合は特に注意が必要です。

これらの攻撃では、GraphQL サービスに過剰なトラフィックが流入し、正当なユーザーからのリクエストを処理できなくなり、サーバーがクラッシュする可能性があります。 DoS 攻撃は、再帰的な GraphQL クエリを通じて、または大規模なクエリ リクエストを送信することによって実行される可能性があります。

再帰クエリのシナリオでは、攻撃者は GraphQL スキーマ定義の循環的な性質を悪用します。 たとえば、スキーマに著者と書籍の種類が含まれている場合、攻撃者はループ内で著者と書籍を繰り返し照会し、再帰呼び出しでサーバーを圧倒して操作を中断させることができます。

あるいは、攻撃者はデータベースから大量のデータを要求するクエリを発行することもできます。 たとえば、クエリによって多数の著者とそれに関連するすべての書籍が取得される場合があります。 このような大量のデータ要求は、システムを大幅に遅くしたりクラッシュさせたりする可能性があります。

緩和： この問題を軽減するための解決策はいくつかあります。 最初のアプローチは、クエリにタイムアウトを設定し、ユーザーが指定された期間を超えるリクエストを行わないようにすることです。 ただし、割り当てられた時間内に損傷が発生する可能性があるため、これでは問題が完全に解決されない可能性があります。 もう 1 つの解決策は、クエリの深さと複雑さに制限を課すことです。 指定された深さまたは複雑さを超え、スキーマの定義から逸脱するクエリは拒否される可能性があります。 最後に、ユーザースロットリングを実装すると効果的です。 ユーザーが大量のリクエストや連続したリクエストを送信した場合、サーバーが追加のリクエストを処理できる準備ができるまで、サーバーへのアクセスが一時的に拒否されることがあります。

示されているように、GraphQL にはいくつかのデプロイメント パターンがあり、それぞれに独自のトレードオフと考慮事項があります。 最も一般的なパターンには次のようなものがあります。

これは、GraphQL API をデプロイするための最もシンプルで一般的なパターンです。モノリシック デプロイメントでは、GraphQL サーバー、データベース、およびその他の必要なサービスがすべて 1 つのユニットとして一緒にデプロイされます。 これにより、GraphQL の使用を開始するのは簡単になりますが、アプリケーションの規模が大きくなるにつれて、拡張と保守が難しくなる可能性があります。 

合成モノリスとは、モノリシックとマイクロサービスの組み合わせを使用してモノリシック アプリケーションを構築し、GraphQL を API レイヤーとして利用するアーキテクチャを指します (図 12)。 このパターンでは、システム全体を個別のマイクロサービスに分割するのではなく、アプリケーションは最初にすべてのビジネス ロジックとデータ アクセス レイヤーをカプセル化する個別のモノリスとして開発されます。 

このモノリシック構造内では、GraphQL が API レイヤーとして実装されており、クライアントは基盤となるさまざまなマイクロサービスからデータを要求して取得できます。 つまり、アプリケーションはデプロイメントの観点からはモノリシックなままですが、さまざまなサービスからデータを作成し、柔軟かつ効率的にクライアントに提示する手段として GraphQL を活用します。

このパターンには、開発とデプロイメントの簡素化、GraphQL の強力なクエリ機能とデータ取得機能を活用できるなどの利点があります。 これにより、開発者は GraphQL が提供する柔軟性と使いやすさのメリットを享受しながら、マイクロサービス アーキテクチャを段階的に導入できるようになります。 

GraphQL デプロイメント パターンのフェデレーション グラフでは、サブグラフと呼ばれる複数の GraphQL サービスを 1 つの統合された GraphQL スキーマに結合します。 各サブグラフは、独自のデータと機能を持つ個別のドメインまたはマイクロサービスを表します。 このアーキテクチャでは、要求されたフィールドに基づいてクライアントのクエリを適切なサブグラフにルーティングする中央ゲートウェイを使用します。 これらのサブグラフを統合することで、開発者はクライアントがさまざまなサービス間でシームレスにクエリやトラバースを実行できる統合グラフを作成できます。

このアプローチにより、サービスのモジュール性、スケーラビリティ、独立した開発が促進され、GraphQL API の構築におけるパフォーマンスと柔軟性が向上します。 フェデレーテッド サブグラフ (図 13) は、さまざまなサービスからデータを構成し、分散型でスケーラブルなアーキテクチャを作成する強力な方法を提供します。

GraphQL デプロイメント パターンのハイブリッド グラフ (図 14) は、ステッチング技術を使用して、フェデレーション サブグラフと非フェデレーション スキーマを組み合わせます。 このアプローチにより、組織は既存の GraphQL API またはレガシー システムをフェデレーション マイクロサービスと統合することができ、両方のアプローチの利点を享受できる統合 GraphQL API が実現します。 ハイブリッド グラフ アーキテクチャは、スキーマをマージし、型とフィールド間の関係を解決することで、柔軟性、モジュール性、およびスケーラビリティを実現します。

ハイブリッド グラフ パターンにより、組織は既存のリソースを活用しながら段階的にフェデレーションを導入できるようになります。 これにより、フェデレーション サブグラフと非フェデレーション スキーマをシームレスに統合し、多様な要件に対応して相互運用性を促進することができます。 このアプローチにより、組織は進化するニーズに合わせて拡張および適応できる包括的な GraphQL API を構築できるようになります。 ハイブリッド グラフは、フェデレーション サービスと非フェデレーション サービスの両方の長所を組み合わせることで、GraphQL デプロイメントを構築するための柔軟で強力なソリューションを提供します。

GraphQL デプロイメントにおけるハイブリッド グラフの課題には、マージされたスキーマの複雑さの管理、潜在的なパフォーマンス オーバーヘッドへの対処、データの一貫性と整合性の確保、システムの進化とバージョン管理の処理、分散アーキテクチャでの監視とデバッグの複雑さへの対処などがあります。 これらの課題を克服し、ハイブリッド グラフの展開をスムーズに運用するには、慎重な計画、最適化、堅牢な開発手法が必要です。 

このパターンでは、AWS Lambda や Google Cloud Functions などのサーバーレス関数のセットとして GraphQL API をデプロイします。 これは、GraphQL API をデプロイするためのコスト効率が高くスケーラブルな方法ですが、追加のレイテンシが発生し、アーキテクチャの複雑さが増す可能性もあります。

サーバーレス ルーティングには多くの課題があります。 1 つの問題は、アプリケーションの拡張時に分散サブグラフをシームレスに接続することです。 複数のチームとデプロイメントの調整は複雑になる可能性があり、サブグラフを効果的に管理および拡張することが困難になります。 これらのサブグラフ間のデータの一貫性と同期を確保することも、もう 1 つのハードルです。 分散サーバーレス環境での監視とデバッグはより困難になる可能性があり、適切なログ記録とエラー処理のメカニズムが必要になります。 さらに、複数のサーバーレス関数とサブグラフにわたるアクセス制御と承認の管理には課題があります。 これらの課題に対処することは、サーバーレスベースの GraphQL デプロイメントのスムーズな運用とスケーラビリティにとって不可欠です。

GraphQL API のエッジ デプロイメント パターンでは、CDN サービスを使用して API がクライアントの近くに配置されます。 これにより、応答速度の向上のための待ち時間の短縮、オリジン サーバーの負荷軽減、DDoS 攻撃からの保護など、さまざまな利点がもたらされます。

API インフラストラクチャを世界中のエッジ サーバーに分散することで、トラフィックをより効率的に処理し、世界中でより優れたユーザー エクスペリエンスを提供できます。 CDN のキャッシュ機能とフィルタリング機能は、スケーラビリティを向上させ、トラフィック量の増加や悪意のある攻撃が発生した場合でも API の可用性を確保するのに役立ちます。 エッジ デプロイメントでは、CDN のサーバー ネットワークを活用して API のパフォーマンスと信頼性を最適化できる可能性があります。 

GraphQL テクノロジーは、従来のエンタープライズ企業に採用されるほど成熟しています。 ガートナーの 2022 年 API ハイプ サイクルでは、広範な導入にはまだ数年かかると示されていますが、必要なツールがすでに整っている重要な転換点に到達しています。 GraphQL はまだ比較的新しいものですが、既存の大規模企業のニーズを満たすことができるレベルにまで進化しました。

GraphAPI テクノロジーの成熟は、GraphQL やその他のグラフ データベース テクノロジーを採用する企業の増加に根ざしています。 これらのテクノロジーを採用する企業が増えるにつれて、それらをサポートするために必要なツールやリソースがますます利用可能になり、他の企業が追随しやすくなります。 さらに、データクエリの改善や複雑さの軽減など、GraphAPI テクノロジーの利点が広く認識されるようになり、エンタープライズ企業における導入がさらに加速しています。

業界として、GraphQL などの GraphAPI テクノロジの重要性と、REST の制限を克服する可能性を認識する必要があります。 企業は、特にデータ モデリング、多様性、不透明性の観点から、GraphQL に投資して理解する緊急の必要性を見逃してはなりません。 GraphQL の機能と可能性に夢中になるのは簡単ですが、過大な期待がピークに達した後に幻滅の谷間が訪れる可能性があることも認識する必要があります。 ベンダーは、GraphQL を完全にサポートするために自社製品の強化を優先する必要があり、一方で、ベンダーを含むエンタープライズ IT 部門は、生産性を向上させるために GraphQL の公開からメリットを得られるデータを特定する必要があります。

顧客は、自社のデータを理解することを優先し、平均的な企業の運営方法が、当初 GraphQL を導入したハイパースケーラーとは異なることを認識する必要があります。 GraphQL を効果的なソフトウェア アーキテクチャ パターンとして採用し、生産性とイノベーションの向上に向けて業界を前進させるために協力していきましょう。

レポートをダウンロード