Microsoft Fabric の GraphQL 用 API は、データに効率的にクエリを実行する強力な方法を提供しますが、パフォーマンスの最適化は、スムーズでスケーラブルなパフォーマンスを確保するための鍵となります。 複雑なクエリを処理する場合でも、応答時間を最適化する場合でも、次のベスト プラクティスは、GraphQL 実装から最適なパフォーマンスを得て、Fabric で API の効率を最大化するのに役立ちます。
パフォーマンスの最適化が必要なユーザー
パフォーマンスの最適化は、次の場合に重要です。
- トラフィックの多いアプリケーションを構築するアプリケーション開発者は、Fabric lakehouses と warehouses に対してクエリを実行しています。
- 大規模な分析アプリケーションと ETL プロセス用に Fabric データ アクセス パターンを最適化するデータ エンジニア
- 容量の消費を管理し、効率的なリソース使用率を確保するファブリック ワークスペース管理者
- Fabric データに基づいて構築されたカスタム分析アプリケーションの応答時間を改善する BI 開発者
- DevOps チームが Fabric API を使用する運用アプリケーションでの待機時間の問題のトラブルシューティング
GraphQL API で運用環境のワークロードを効率的に処理する必要がある場合、またはパフォーマンスの問題が発生している場合は、次のベスト プラクティスを使用します。
リージョンの配置
リージョン間 API 呼び出しは、待機時間が長くなる一般的な原因です。 最適なパフォーマンスを実現するには、クライアント アプリケーション、ファブリック テナント、容量、データ ソースがすべて同じ Azure リージョンにあることを確認します。
テナント リージョンを確認する
Fabric テナントのリージョンを検索するには:
- 管理者アカウントを使用して Microsoft Fabric ポータルにサインインする
- 右上隅にある [ヘルプ] アイコン (?) を選択します
- [ヘルプ] ウィンドウの下部にある [ファブリックについて] を選択します。
- テナントの詳細に表示されるリージョンに注意してください
容量リージョンを確認する
GraphQL 用 API は、特定の容量内で実行されます。 容量リージョンを見つけるには:
GraphQL 用 API をホストしているワークスペースを開く
ワークスペースの設定に移動します>ライセンス情報
[ライセンス容量] でリージョンを見つける
データ ソースリージョンを確認する
データ ソースの場所もパフォーマンスに影響します。
- ファブリック データ ソース (Lakehouse、Data Warehouse、SQL Database): これらはワークスペースの容量と同じリージョンを使用します
- 外部データ ソース (Azure SQL Database など): Azure portal でリソースの場所を確認する
ベスト プラクティス: ネットワーク待機時間を最小限に抑えるために、Fabric の容量とデータ ソースと同じリージョンにクライアント アプリケーションをデプロイします。
パフォーマンス テストのベスト プラクティス
API のパフォーマンスを評価するときは、信頼できる一貫性のある結果を得るには、次のガイドラインに従ってください。
現実的なテスト ツールを使用する
運用環境と密接に一致するツールを使用してテストします。
- スクリプトまたはアプリケーション: 実際のクライアント動作をシミュレートする Python、Node.js、または .NET スクリプトを使用する
- HTTP 接続プール: HTTP 接続を再利用して待機時間を短縮します。リージョン間のシナリオでは特に重要です
- セッション管理: 実際の使用状況を正確に反映するために、要求間でセッションを維持する
サンプル リソース:
- サンプル パフォーマンス テスト スクリプト (Python ノートブック)
- Python の HTTP セッション オブジェクト
- .NET の HttpClient ガイドライン
意味のあるメトリックを収集する
正確なパフォーマンス評価を行う場合:
- テストの自動化: スクリプトまたはパフォーマンス テスト ツールを使用して、定義された期間にわたって一貫してテストを実行する
- API をウォームアップする: パフォーマンスを測定する前にいくつかのテスト クエリを実行する ( ウォームアップ要件を参照)
- 分布の分析: 平均だけでなくパーセンタイルベースのメトリック (P50、P95、P99) を使用して待機時間パターンを理解する
- 負荷中のテスト: 現実的な同時要求ボリュームを使用してパフォーマンスを測定する
- ドキュメントの条件: 時間、容量使用率、およびテスト中の同時実行ワークロードを記録する
パフォーマンスに関する一般的な問題
これらの一般的な問題を理解することは、パフォーマンスの問題を効果的に診断して解決するのに役立ちます。
ウォームアップの要件
問題: 最初の API 要求は、後続の要求よりも大幅に長くかかります。
これが起こる原因:
- API 初期化: アイドル状態の場合、API 環境は最初の呼び出し中に初期化する必要があります。数秒の待機時間が追加されます
- データ ソースのウォームアップ: 多くのデータ ソース (特に SQL Analytics エンドポイントとデータ ウェアハウス) は、アイドル状態になった後にアクセスするとウォームアップ フェーズが発生します
- 組み合わされた初期化: API とデータ ソースの両方がアイドル状態の場合、初期化時間が増加する
Solution:
- パフォーマンスを測定する前に 2 ~ 3 個のテスト クエリを実行する
- 運用アプリケーションの場合は、API をウォーム状態に保つ正常性チェック エンドポイントを実装します
- スケジュールされたクエリまたは監視ツールを使用して、営業時間中にアクティブな状態を維持することを検討する
リージョンのミスアラインメント
問題: すべての要求で常に待機時間が長くなります。
これが発生する理由: リージョン間のネットワーク呼び出しでは、特にクライアント、API、データ ソースが異なる Azure リージョンにある場合に、大幅な待機時間が発生します。
Solution:
- クライアント アプリケーション、ファブリック容量、データ ソースが同じリージョン内にあることを確認する
- リージョン間アクセスが避けられない場合は、積極的なキャッシュ戦略を実装します
- グローバル アプリケーション用のリージョン API レプリカのデプロイを検討する
データ ソースのパフォーマンス
問題: API がウォームアップされ、リージョンがアラインされている場合でも、API 要求が遅くなります。
これが発生する理由: GraphQL 用 API は、データ ソースに対するクエリ インターフェイスとして機能します。 基になるデータ ソースに、インデックスの不足、複雑なクエリ、リソースの制約など、パフォーマンスの問題がある場合、API はこれらの制限を継承します。
Solution:
- 直接テストする: データ ソースに直接クエリを実行して (SQL またはその他のネイティブ ツールを使用して) ベースライン パフォーマンスを確立する
-
データ ソースを最適化します。
- 頻繁にクエリを実行する列に適切なインデックスを追加する
- ユース ケースに適したデータ ストアを検討する: ファブリックデシジョン ガイド - データ ストアを選択する
- 最適化の機会についてクエリ実行プランを確認する
- 適切なサイズの容量: Fabric 容量 SKU で十分なコンピューティング リソースが提供されていることを確認します。 適切な容量の選択に関するガイダンスについては 、Microsoft Fabric の概念 を参照してください。
クエリのデザイン
問題: 一部のクエリは適切に動作し、他のクエリは低速です。
これが起こる原因:
- 過剰フェッチ: 必要以上に多くのフィールドを要求すると、処理時間が長くなります
- 深い入れ子: 多数のレベルの入れ子になったリレーションシップを持つクエリでは、複数のリゾルバーの実行が必要です
- 不足しているフィルター: 適切なフィルターを使用しないクエリは、過剰なデータを返す可能性があります
Solution:
- GraphQL クエリで必要なフィールドのみを要求する
- 入れ子になったリレーションシップの深さを可能な限り制限する
- クエリで適切なフィルターとページネーションを使用する
- 必要に応じて、複雑なクエリを複数の単純なクエリに分割することを検討する