フロントエンドのバックエンド パターン

このパターンでは、バックエンド サービスをフロントエンド実装から切り離して、さまざまなクライアント インターフェイスのエクスペリエンスを調整する方法について説明します。 このパターンは、複数のインターフェイスを提供するバックエンドをカスタマイズしないようにする場合に便利です。 このパターンは、 Sam Newman によるフロントエンドのバックエンド パターンに基づいています。

コンテキストと問題

デスクトップ Web UI と対応するバックエンド サービスを使用して最初に設計されたアプリケーションを考えてみましょう。 ビジネス要件が時間の経過と同時に変化すると、モバイル インターフェイスが追加されます。 両方のインターフェイスが同じバックエンド サービスと対話します。 ただし、モバイル デバイスの機能は、画面サイズ、パフォーマンス、表示制限の点でデスクトップ ブラウザーとは大きく異なります。

バックエンド サービスでは、複数のフロントエンド システムからの競合する要求が頻繁に発生します。 これらの要求により、頻繁に更新が行われ、開発のボトルネックが発生する可能性があります。 更新プログラムが競合し、互換性を維持する必要がある場合、単一のデプロイ可能なリソースに対して過剰な要求が発生します。

バックエンド サービスを別のチームで管理することで、フロントエンド チームとバックエンド チームの間で切断を作成できます。 この切断により、コンセンサスの獲得と要件の分散が遅れる可能性があります。 たとえば、あるフロントエンド チームによって要求された変更は、統合前に他のフロントエンド チームと検証する必要があります。

解決策

インターフェイスに固有の要件のみを処理する新しいレイヤーを導入します。 このレイヤーは、バックエンド for フロントエンド (BFF) サービスと呼ばれ、フロントエンド クライアントとバックエンド サービスの間に配置されます。 アプリケーションが Web インターフェイスやモバイル アプリなどの複数のインターフェイスをサポートしている場合は、インターフェイスごとに BFF サービスを作成します。

このパターンは、他のインターフェイスに影響を与えることなく、特定のインターフェイスのクライアント エクスペリエンスをカスタマイズします。 また、フロントエンド環境のニーズを満たすためにパフォーマンスを最適化します。 各 BFF サービスは、共有バックエンド サービスよりも小さく複雑ではないため、アプリケーションの管理が容易になります。

フロントエンド チームは独自の BFF サービスを個別に管理し、言語の選択、リリース周期、ワークロードの優先順位付け、機能の統合を制御できます。 この自律性により、一元化されたバックエンド開発チームに依存することなく、効率的に運用できます。

従来、多くの BFF サービスは REST API に依存していましたが、GraphQL の実装が代替として登場しています。 GraphQL を使用すると、クライアントは定義済みのエンドポイントに依存せずに必要なデータを要求できるため、クエリ メカニズムによって個別の BFF レイヤーが不要になります。

詳細については、「 Sam Newman によるフロントエンドのバックエンド パターン」を参照してください。

問題と考慮事項

• 関連するコストに応じて、最適なサービス数を評価します。 より多くのサービスを維持およびデプロイすることは、運用上のオーバーヘッドの増加を意味します。 個々のサービスには、独自のライフ サイクル、デプロイとメンテナンスの要件、およびセキュリティ ニーズがあります。

• 新しいサービスを追加するときに、サービス レベルの目標を確認します。 クライアントがサービスに直接接続せず、新しいサービスによって追加のネットワーク ホップが導入されるため、待機時間が長くなる可能性があります。

• 異なるインターフェイスが同じ要求を行う場合は、要求を 1 つの BFF サービスに統合できるかどうかを評価します。 複数のインターフェイス間で 1 つの BFF サービスを共有すると、クライアントごとに異なる要件が発生し、BFF サービスの成長とサポートが複雑になることがあります。

  コードの重複は、このパターンの可能性のある結果です。 コードの重複と、各クライアントに合わせたエクスペリエンスのトレードオフを評価します。

• BFF サービスでは、特定のユーザー エクスペリエンスに関連するクライアント固有のロジックのみを処理する必要があります。 効率を維持するには、監視や承認などの横断的な機能を抽象化する必要があります。 BFF サービスで表面化する可能性がある一般的な機能は、 ゲートキーピング、 レート制限、 およびルーティング パターンを使用して個別に処理されます。

• このパターンの学習と実装が開発チームにどのように影響するかを検討します。 新しいバックエンド システムを開発するには時間と労力が必要であり、技術的負債が発生する可能性があります。 既存のバックエンド サービスを維持することは、この課題に追加されます。

• このパターンが必要かどうかを評価します。 たとえば、組織でフロントエンド固有のリゾルバーで GraphQL を使用している場合、BFF サービスによってアプリケーションに価値が追加されない可能性があります。

  もう 1 つのシナリオは、 API ゲートウェイ とマイクロサービスを組み合わせたアプリケーションです。 BFF サービスが通常推奨されるシナリオによっては、この方法で十分な場合があります。

このパターンを使用する場合

このパターンは次の状況で使用します。

• 共有または汎用のバックエンド サービスでは、保守にかなりの開発オーバーヘッドが必要です。

• 特定のクライアント インターフェイスの要件に合わせてバックエンドを最適化する必要があります。

• 複数のインターフェイスに対応するために、汎用バックエンドにカスタマイズを行います。

• プログラミング言語は、特定のユーザー インターフェイスのバックエンドに適していますが、すべてのユーザー インターフェイスには適していません。

このパターンは、次の場合に適さない場合があります。

• インターフェイスは、バックエンドに対して同じまたは類似の要求を行います。

• バックエンドと対話するインターフェイスは 1 つだけです。

ワークロード設計

ワークロードの設計でフロントエンド用バックエンド パターンを使用して、 Azure Well-Architected Framework の柱で説明されている目標と原則に対処する方法を評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。

このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。

例

この例では、モバイル アプリとデスクトップ アプリケーションの 2 つの異なるクライアント アプリケーションが Azure API Management (データ プレーン ゲートウェイ) と対話するパターンのユース ケースを示します。 このゲートウェイは抽象化レイヤーとして機能し、次のような一般的な横断的な懸念事項を管理します。

• 承認。 適切なアクセス トークンを持つ検証済み ID のみが、Microsoft Entra ID で API Management を使用して保護されたリソースを呼び出すことができることを確認します。

• モニタリング。 監視のために、要求と応答の詳細をキャプチャして Azure Monitor に送信します。

• 要求キャッシュ。 API Management の組み込み機能によってキャッシュからの応答を提供することで、繰り返される要求を最適化します。

• ルーティングと集計。 受信要求を適切な BFF サービスに転送します。

各クライアントには、ゲートウェイと基になるマイクロサービス間の仲介役として機能する Azure 関数として実行される専用の BFF サービスがあります。 これらのクライアント固有の BFF サービスにより、改ページやその他の機能に合わせて調整されたエクスペリエンスが保証されます。 モバイル アプリでは、帯域幅の効率が優先され、キャッシュを利用してパフォーマンスが向上します。 これに対し、デスクトップ アプリケーションは 1 つの要求で複数のページを取得するため、よりイマーシブなユーザー エクスペリエンスが作成されます。

モバイルクライアントの最初のページ要求に対するフローA

1. モバイルクライアントは、ページ GET の 1 要求において、認証ヘッダーに OAuth 2.0 トークンを含めて送信します。

2. 要求は API Management ゲートウェイに到達し、それをインターセプトし、次の手順を実行します。

   1. 承認の状態を確認します。 API Management は多層防御を実装するため、アクセス トークンの有効性を確認します。

   2. 要求アクティビティをログとして Azure Monitor にストリーミングします。 要求の詳細は、監査と監視のために記録されます。

3. ポリシーが適用され、API Management によって要求が Azure 関数モバイル BFF サービスにルーティングされます。

4. その後、Azure 関数モバイル BFF サービスは、必要なマイクロサービスと対話して 1 つのページをフェッチし、要求されたデータを処理して軽量なエクスペリエンスを提供します。

5. 応答がクライアントに返されます。

フロー B はモバイルクライアントからの最初のページキャッシュ要求に関するものです。

1. モバイル クライアントは、承認ヘッダーに OAuth 2.0 トークンを含め、ページ GETに対して同じ1要求を再度送信します。

2. API管理ゲートウェイは、この要求が以前に行われたことを認識しており、次の前に行われたと判断します。

   1. ポリシーが適用されます。 その後、ゲートウェイは、要求パラメーターと一致するキャッシュされた応答を識別します。

   2. キャッシュされた応答を直ちに返します。 この迅速な応答により、Azure 関数モバイル BFF サービスに要求を転送する必要がなくなります。

デスクトップクライアントからの最初のリクエストにおけるFlow C

1. デスクトップ クライアントは、承認ヘッダーに OAuth 2.0 トークンを含む、 GET 要求を初めて送信します。

2. 要求は API Management ゲートウェイに到達します。ここで、横断的な懸念が処理されます。

   1. 認可： トークンの検証は常に必要です。

   2. 要求アクティビティをストリーミングします。 要求の詳細は、監視のために記録されます。

3. すべてのポリシーが適用されると、API Management によって Azure 関数デスクトップ BFF サービスに要求がルーティングされ、データ負荷の高いアプリケーション処理が処理されます。 デスクトップ BFF サービスは、基になるマイクロサービス呼び出しを使用して複数の要求を集計してから、複数のページ応答でクライアントに応答します。

設計

• Microsoft Entra ID は、クラウドベースの ID プロバイダーとして機能します。 モバイルクライアントとデスクトップクライアントの両方に合わせたオーディエンスクレームを提供します。 その後、これらの要求が承認に使用されます。

• API Management は、境界を確立するクライアントとその BFF サービスの間のプロキシとして機能します。 API Management は、 JSON Web トークンを検証 するポリシーを使用して構成され、トークンがない要求や、対象の BFF サービスに対する無効な要求が含まれている要求を拒否します。 また、すべてのアクティビティ ログを Azure Monitor にストリーミングします。

• Azure Monitor は、一元化された監視ソリューションとして機能します。 すべてのアクティビティ ログを集計して、包括的でエンドツーエンドの可観測性を確保します。

• Azure Functions は、複数のエンドポイントにわたって BFF サービス ロジックを効率的に公開するサーバーレス ソリューションです。これにより、開発が簡略化されます。 また、Azure Functions はインフラストラクチャのオーバーヘッドを最小限に抑え、運用コストの削減にも役立ちます。

次のステップ

• Sam Newman によるフロントエンドのバックエンド パターン
• API Management での API への認証と承認
• API Management と Application Insights を統合する方法

関連リソース

• Gateway Aggregation pattern (ゲートウェイ集約パターン)
• Gateway Offloading pattern (ゲートウェイ オフロード パターン)
• Gateway Routing pattern (ゲートウェイ ルーティング パターン)
• サーバーレス Web アプリケーション参照アーキテクチャ