このアーキテクチャのコア コンポーネントは、クライアント要求を処理する Web フロントエンド と、リソースを集中的に使用するタスク、実行時間の長いワークフロー、またはバッチ ジョブを実行する ワーカー です。 Web フロントエンドは 、メッセージ キューを介してワーカーと通信します。
このアーキテクチャには、一般的に次のコンポーネントが組み込まれています。
1 つ以上のデータベース
データベースから値を格納してクイック読み取りを行うキャッシュ
静的コンテンツを提供するコンテンツ配信ネットワーク
Microsoft 以外のサービス プロバイダーが通常提供するリモート サービス (電子メールやショート メッセージ サービス (SMS) など)
認証用の ID プロバイダー
Web と worker はどちらもステートレスであり、セッション状態は分散キャッシュに格納できます。 ワーカーは、実行時間の長い作業を非同期的に処理します。 キュー上のメッセージはワーカーを開始することも、スケジュールでバッチ処理のために実行することもできます。 アプリケーションに実行時間の長い操作がない場合、worker は省略可能です。
フロントエンドには Web API が含まれる場合があります。 シングルページ アプリケーションでは、AJAX 呼び出しを行って Web API を使用できます。または、ネイティブ クライアント アプリケーションが Web API を直接使用できます。
このアーキテクチャを使用する場合
WebQueue-Worker アーキテクチャは、通常、Azure App Service や Azure Kubernetes Service などのマネージド コンピューティング サービスを使用して実装されます。
次のユース ケースでは、このアーキテクチャを検討してください。
比較的単純なドメインを持つアプリケーション
実行時間の長いワークフローまたはバッチ操作があるアプリケーション
サービスとしてのインフラストラクチャ (IaaS) よりもマネージド サービスを優先するシナリオ
メリット
理解しやすくて単純なアーキテクチャ
最小限の労力でデプロイと管理
責任の明確な分離
非同期メッセージングによるフロントエンドとワーカーの切り離し
フロントエンドとワーカーの独立したスケーリング
課題
慎重に設計しないと、フロントエンドとワーカーは、保守や更新が困難な大きなモノリシック コンポーネントになる可能性があります。
フロントエンドとワーカーがデータ スキーマまたはコード モジュールを共有している場合は、非表示の依存関係が存在する可能性があります。
Web フロントエンドは、データベースに永続化した後、キューにメッセージを送信する前に失敗する可能性があります。これにより、ワーカーがロジックの一部を実行しないため、一貫性の問題が発生します。 この問題を軽減するには、トランザクション アウトボックス パターンのような手法を使用できます。このパターンでは、送信メッセージを最初に別のキューを通してループバックするようにルーティングする必要があります。 NServiceBus トランザクション セッション ライブラリでは、この手法がサポートされています。
ベスト プラクティス
適切に設計された API をクライアントに公開します。 詳細については、 API 設計のベスト プラクティスを参照してください。
負荷の変化に対応するように自動的にスケーリングします。 詳細については、「 自動スケールのベスト プラクティス」を参照してください。
半静的データをキャッシュします。 詳細については、「 キャッシュのベスト プラクティス」を参照してください。
コンテンツ配信ネットワークを使用して、静的コンテンツをホストします。 詳細については、「 コンテンツ配信ネットワークのベスト プラクティス」を参照してください。
必要に応じて、ポリグロット永続化を使用します。 詳細については、「 データ モデルについて」を参照してください。
スケーラビリティを向上させ、競合を減らし、パフォーマンスを最適化するためにデータをパーティション分割します。 詳細については、「 データのパーティション分割のベスト プラクティス」を参照してください。
App Service での Web-Queue-Worker
このセクションでは、App Service を使用する推奨される WebQueue-Worker アーキテクチャについて説明します。
このアーキテクチャの Visio ファイル をダウンロードします。
Workflow
フロントエンドは App Service Web アプリとして実装され、worker は Azure Functions アプリとして実装されます。 Web アプリと Functions アプリはどちらも、仮想マシン (VM) インスタンスを提供する App Service プランに関連付けられています。
メッセージ キューには 、Azure Service Bus キューまたは Azure Storage キュー を使用できます。 前の図では、ストレージ キューを使用しています。
Azure Managed Redis には、セッション状態や、待機時間の短いアクセスが必要なその他のデータが格納されます。
Azure Content Delivery Network は、画像、CSS、HTML などの静的コンテンツをキャッシュするために使用されます。
ストレージの場合は、アプリケーションのニーズに最も適したテクノロジを選択します。 このアプローチは、 ポリグロット永続化と呼ばれ、同じシステム内の複数のストレージ テクノロジを使用して、さまざまな要件を満たします。 このアイデアを示すために、この図は Azure SQL Database と Azure Cosmos DB の両方を示しています。
詳細については、「 ベースラインの高可用性ゾーン冗長 Web アプリケーション 」および 「NServiceBus と Service Bus を使用したメッセージ駆動型ビジネス アプリケーションの構築」を参照してください。
その他の考慮事項
すべてのトランザクションがキューやワーカーを経由してストレージに移動しなければならないわけではありません。 Web フロントエンドは、単純な読み取りと書き込みの操作を直接実行できます。 ワーカーは、リソースを集中的に使用するタスクまたは実行時間の長いワークフロー用に設計されています。 場合によっては、ワーカーがまったく必要ない場合があります。
コンピューティング プラットフォームの組み込みの自動スケール機能を使用して、インスタンスの数をスケールアウトします。 アプリケーションの負荷が予測可能なパターンに従う場合は、スケジュールベースの自動スケーリングを使用します。 読み込みが予測できない場合は、メトリックベースの自動スケーリングを使用します。
Web アプリと Functions アプリを別々の App Service プランに配置して、個別にスケーリングできるようにすることを検討してください。
運用環境とテストには、個別の App Service プランを使用します。
デプロイ スロットを使用してデプロイを管理します。 この方法では、更新されたバージョンをステージング スロットにデプロイし、新しいバージョンにスワップできます。 また、更新中に問題が発生した場合は、以前のバージョンに戻すこともできます。