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