このアーキテクチャのコア コンポーネントは、クライアント要求を処理する Web フロント エンドと、リソースを消費するタスク、実行時間の長いワークフロー、またはバッチ ジョブを実行するワーカーです。 Web フロント エンドはメッセージ キューを通じてワーカーと通信します。
このアーキテクチャで一般的に使用されているその他のコンポーネントは次のとおりです。
- 1 つまたは複数のデータベース。
- データベースから高速でデータを読み取るために値を格納するキャッシュ。
- 静的コンテンツを提供するための CDN
- 電子メールや SMS サービスなどのリモート サービス。 多くの場合、これらの機能は、サード パーティによって提供されます。
- 認証 ID プロバイダー。
Web とワーカーはいずれもステートレスです。 セッション状態は、分散キャッシュに格納することができます。 ワーカーによる実行時間の長い作業は、非同期的に実行されます。 ワーカーは、キューのメッセージによってトリガーされるか、またはバッチ処理のためにスケジュールに従って実行できます。 ワーカーは、オプションのコンポーネントです。 処理時間が長い操作がない場合は、ワーカーを省略できます。
フロント エンドは、Web API で構成されている可能性があります。 クライアント側では、Web API は、AJAX 呼び出しを実行する単一ページ アプリケーションまたはネイティブ クライアント アプリケーションが使用できます。
このアーキテクチャを使用する状況
Web キュー ワーカーのアーキテクチャは、通常、マネージド コンピューティング サービス、Azure App Service または Azure Cloud Services のいずれかを使用して実装されます。
次の場合に、このアーキテクチャ スタイルを検討してください。
- 比較的単純なドメインのアプリケーション。
- 実行時間の長いワークフローやバッチ操作があるアプリケーション。
- サービスとしてのインフラストラクチャ (IaaS) ではなく、マネージド サービスを使用する場合。
メリット
- 比較的単純でわかりやすいアーキテクチャ。
- 展開と管理が容易。
- 懸念事項の明確な分離。
- フロント エンドは、非同期メッセージングを使用してワーカーから切り離されます。
- フロント エンド ロールとワーカーはそれぞれ個別に拡張できます。
課題
- 慎重に設計しないと、フロント エンドおよびワーカーが、大型のモノリシック コンポーネントになり、管理や更新が困難になる。
- フロント エンド ロールとワーカーがデータ スキーマまたはコード モジュールを共有している場合、依存関係が潜在することがある。
- Web フロントエンドは、データベースに正常に永続化した後、キューにメッセージを出力する前に誤動作する可能性があります。 これにより、worker がロジックの一部を実行できないため、一貫性の問題が発生する可能性があります。 トランザクション送信トレイ パターンなどの手法は、この問題を軽減するために使用できますが、送信メッセージのルーティングを別のキューを介して最初に "ループ バック" するように変更する必要があります。 この手法をサポートするライブラリの 1 つが、NServiceBus の TransactionalSession です。
ベスト プラクティス
- クライアントに適切に設計された API を公開する。 API 設計のベスト プラクティスに関するページをご覧ください。
- 負荷の変化に対応するために自動スケールする。 自動スケールのベスト プラクティスに関するページをご覧ください。
- 半静的なデータをキャッシュする。 キャッシュのベスト プラクティスに関するページをご覧ください。
- CDN を使用して、静的コンテンツをホストする。 CDN のベスト プラクティスに関するページをご覧ください。
- 適切な場合は、多言語永続化を使用する。 「ジョブに最適なデータ ストアの使用」や「ポリグロット」に関する記事をご覧ください。
- 拡張性を向上し、競合を予防し、パフォーマンスを最適化するためにデータを分割する。 データのパーティション分割のベスト プラクティスに関するページをご覧ください。
Azure App Service の Web キュー ワーカー
このセクションでは、Azure App Service を使用する、推奨 Web キュー ワーカー アーキテクチャについて説明します。
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
フロント エンドは、Azure App Service Web アプリとして実装され、worker は、Azure Functions アプリとして実装されます。 Web アプリと関数アプリの両方が VM インスタンスを提供する App Service プランに関連付けられています。
メッセージ キューには、Azure Service Bus または Azure Storage キューのいずれかを使用できます。 (図は、Azure Storage キューを示しています)。
Azure Cache for Redis は、セッション状態と短い待ち時間でアクセスが必要なその他のデータを格納します。
Azure CDN を使用して、画像、CSS、HTML などの静的なコンテンツをキャッシュします。
ストレージは、アプリケーションのニーズに最適なストレージ テクノロジを選択します。 複数のストレージ テクノロジ (多言語持続性) を使用することもできます。 この概念を示すために、この図には、Azure SQL Database と Azure Cosmos DB を示しています。
詳細については、App Service Web アプリケーションの参照アーキテクチャに関するページと、「NServiceBus と Azure Service Bus を使用してメッセージ駆動型ビジネス アプリケーションを構築する」を参照してください。
その他の考慮事項
ストレージまでキューやワーカーを経由しないトランザクションもあります。 Web フロント エンドは、単純な読み取り/書き込み操作を直接実行できます。 ワーカーは、リソースを消費するタスクまたは実行時間の長いワークフローの設計されています。 ワーカーがまったく必要ない場合もあります。
App Service の組み込み自動スケール機能を使用して、VM インスタンスの数をスケール アウト。 アプリケーションで負荷が、予測可能なパターン通りの場合は、スケジュールに基づく自動スケールを使用します。 負荷が予測可能でない場合は、メトリックに基づいた自動スケール ルールを使用します。
Web アプリと関数アプリを個別の App Service プランに配置することを検討してください。 これにより、個別にスケールできます。
運用環境とテスト環境では、異なる App Service プランを使用してください。 運用環境とテスト環境で同じプランを使用すると、テストが、運用環境の VM で実行されます。
デプロイ スロットを使用して展開を管理します。 このメソッドにより、ステージング スロットに更新されたバージョンを展開してた後、新しいバージョンに交換できます。 また、更新バージョンで問題があった場合は、前のバージョンに戻ることもできます。