特定のフロント エンド アプリケーションやインターフェイスによって使用される個別のバックエンド サービスを作成します。 このパターンは、複数のインターフェイスのために 1 つのバックエンドをカスタマイズすることが非効率な場合に役立ちます。 このパターンは、Sam Newman が初めて説明しました。
コンテキストと問題
アプリケーションは、当初デスクトップの Web UI 用に導入される場合があります。 通常、バックエンド サービスは、その UI に必要な機能を提供するために、並行して開発されます。 アプリケーションのユーザー ベースが増えてくると、同じバックエンドとやりとりする、モバイル アプリケーションが開発されます。 その結果、バックエンド サービスは、デスクトップとモバイルの両方のインターフェイスの要件に対応する、汎用的なバックエンドになります。
しかし、モバイル デバイスの機能は、デスクトップ ブラウザーとは大きく異なります (画面サイズ、パフォーマンス、ディスプレイ制限など)。 結果として、モバイル アプリケーションのバックエンド要件も、デスクトップ Web UI のものとは異なります。
これらの違いにより、バックエンドの要件に競合が発生するようになります。 デスクトップ Web UI とモバイル アプリケーションの両方に対応するには、バックエンドを定期的に、かつ大幅に変更する必要があります。 多くの場合、各フロント エンドでは個別のインターフェイス チームが作業するため、バックエンドは開発プロセスのボトルネックになります。 更新要件が競合している場合、両方のフロント エンドに対するサービス提供を維持しようとすると、1 つのリソースをデプロイするのにも、多くの労力が費やされることになります。
開発アクティビティではバックエンド サービスに重点が置かれるため、バックエンドの管理と保守に個別のチームが配備されることがあります。 このことは最終的に、インターフェイスとバックエンドの開発チーム間の分断につながり、各 UI チームのさまざまな要件を調整する必要が生じて、バックエンド チームに負担がかかることになります。 あるインターフェイス チームでバックエンドを変更する必要が生じても、それらの変更を他のインターフェイス チームで検証してからでないと、変更をバックエンドに統合することはできません。
解決策
ユーザー インターフェイスごとに 1 つのバックエンドを作成します。 そうすれば、フロントエンド環境のニーズに応じて各バックエンドの動作やパフォーマンスを調整しても、他のフロントエンドの動作に影響する心配はなくなります。
各バックエンドが 1 つのインターフェイスに対応するので、バックエンドをそのインターフェイス用に最適化できます。 その結果、すべてのインターフェイスの要件を満たそうとする汎用バックエンドよりも、サイズが小さくなり、複雑さが軽減され、多くの場合は処理速度も速くなります。 各インターフェイス チームは、専用のバックエンドを自律的に制御できるようになり、中央のバックエンド開発チームに依存しなくて済むようになります。 その結果インターフェイス チームは、言語の選択、リリース間隔、ワークロードの優先度、およびバックエンドでの機能統合を、柔軟に決められるようになります。
詳細については、「Pattern: Backends For Frontends (パターン: フロントエンド用バックエンド)」をご覧ください。
問題と注意事項
- デプロイするバックエンドの数を検討してください。
- 複数の異なるインターフェイス (モバイル クライアントなど) が同じ要求をする場合は、インターフェイスごとにバックエンドを実装する必要があるか、それとも 1 つのバックエンドで十分かを検討してください。
- このパターンを実装すると、サービス間でコードが重複する可能性が高くなります。
- フロントエンドに特化したバックエンド サービスでは、クライアント固有のロジックと動作だけを実装するようにしてください。 汎用的なビジネス ロジックやその他のグローバル機能は、アプリケーション内の別の場所で管理するようにしてください。
- このパターンが、開発チームの担当業務にどのように影響するかを考えてください。
- このパターンを実装するのにかかる時間を検討してください。 新しいバックエンドの構築によって技術的負債が発生し、既存の汎用バックエンドもサポートし続けなければならなくなりますか。
このパターンを使用する状況
このパターンは次の状況で使用します。
- 共有または汎用目的のバックエンド サービスを保守するために、多大な開発オーバーヘッドが生じている。
- 特定のクライアント インターフェイスの要件に合わせて、バックエンドを最適化する必要がある。
- 複数のインターフェイスに対応するために、汎用バックエンドのカスタマイズが行われている。
- プログラミング言語は、特定のユーザー インターフェイスのバックエンドに適していますが、すべてのユーザー インターフェイスに適しているわけではありません。
このパターンは、次の場合には適切でない可能性があります。
- 各インターフェイスが、バックエンドに対して同一または類似の要求をする。
- バックエンドとのやりとりに使用されされるインターフェイスが 1 つしかない。
ワークロード設計
設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、フロントエンド用バックエンドパターンをワークロードの設計でどのように使用できるかを評価する必要があります。 次に例を示します。
| 重要な要素 | このパターンが柱の目標をサポートする方法 |
|---|---|
| 信頼性設計の決定により、ワークロードが誤動作に対して復元力を持ち、障害発生後も完全に機能する状態に回復することができます。 | 特定のフロントエンドインターフェイスに排他的なサービスを個別に提供すると、誤動作が発生するため、1つのクライアントのアベイラビリティが別のクライアントのアベイラビリティに影響しない可能性があります。 また、さまざまなクライアントを異なる方法で扱う場合は、予想されるクライアントアクセスパターンに基づいて信頼性の向上を優先できます。 - RE:02 クリティカルフロー - RE:07 自己保護 |
| セキュリティ設計の決定により、ワークロードのデータとシステムの機密性、整合性、および可用性が確保されます。 | このパターンで導入されたサービス分離により、あるクライアントをサポートするサービスレイヤのセキュリティと認可は、そのクライアントが必要とする機能に合わせて調整することができ、潜在的にAPIの表面積を減らし、異なる機能を公開するかもしれない異なるバックエンド間の横方向の動きを減らすことができます。 - SE:04 セグメンテーション - SE:08 リソースの強化 |
| パフォーマンスの効率化は、スケーリング、データ、コードを最適化することによって、ワークロードが効率的にニーズを満たすのに役立ちます。 | バックエンド分離を使用すると、共有サービスレイヤでは不可能な方法で最適化できます。 個々のクライアントを異なる方法で処理する場合は、特定のクライアントの制約と機能に合わせてパフォーマンスを最適化できます。 - PE:02 容量計画 - PE:09 クリティカルフロー |
設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。
次のステップ
関連リソース
- Gateway Aggregation pattern (ゲートウェイ集約パターン)
- Gateway Offloading pattern (ゲートウェイ オフロード パターン)
- Gateway Routing pattern (ゲートウェイ ルーティング パターン)