WebQueue-Worker アーキテクチャ スタイル
このアーキテクチャのコア コンポーネントは、クライアント要求を処理する Web フロントエンド と、リソースを大量に消費するタスク、実行時間の長いワークフロー、またはバッチ ジョブを実行する ワーカー です。 Web フロントエンドは 、メッセージ キューを介してワーカーと通信します。
このアーキテクチャに一般的に組み込まれるその他のコンポーネントは次のとおりです。
- 1 つ以上のデータベース。
- データベースからの値を格納してクイック読み取りを行うキャッシュ。
- 静的コンテンツを提供する CDN
- 電子メールや SMS サービスなどのリモート サービス。 多くの場合、これらの機能はサード パーティによって提供されます。
- 認証用の ID プロバイダー。
Web と worker はどちらもステートレスです。 セッション状態は分散キャッシュに格納できます。 実行時間の長い作業は、ワーカーによって非同期的に実行されます。 ワーカーは、キュー上のメッセージによってトリガーすることも、バッチ処理のスケジュールに従って実行することもできます。 worker は省略可能なコンポーネントです。 実行時間の長い操作がない場合は、ワーカーを省略できます。
フロントエンドは Web API で構成される場合があります。 クライアント側では、Web API は、AJAX 呼び出しを行うシングルページ アプリケーションまたはネイティブ クライアント アプリケーションによって使用できます。
このアーキテクチャを使用する場合
WebQueue-Worker アーキテクチャは、通常、マネージド コンピューティング サービス (Azure App Service または Azure Cloud Services) を使用して実装されます。
次のアーキテクチャ スタイルについて考えてみましょう。
- 比較的単純なドメインを持つアプリケーション。
- 実行時間の長いワークフローまたはバッチ操作を含むアプリケーション。
- サービスとしてのインフラストラクチャ (IaaS) ではなく、マネージド サービスを使用する場合。
メリット
- 理解しやすい比較的単純なアーキテクチャ。
- 展開と管理が容易。
- 懸念事項の明確な分離。
- フロントエンドは、非同期メッセージングを使用してワーカーから切り離されます。
- フロントエンドとワーカーは個別にスケーリングできます。
課題
- 慎重に設計しないと、フロントエンドとワーカーは、保守や更新が困難な大型のモノリシック コンポーネントになる可能性があります。
- フロントエンドとワーカーがデータ スキーマまたはコード モジュールを共有している場合は、非表示の依存関係が存在する可能性があります。
- Web フロントエンドは、データベースに正常に永続化した後、キューにメッセージを出力する前に誤動作する可能性があります。 これにより、ワーカーがロジックの一部を実行できないため、一貫性の問題が発生する可能性があります。 トランザクション送信トレイ パターンのような手法を使用すると、この問題を軽減できますが、送信メッセージのルーティングを別のキューを介して最初の "ループ バック" に変更する必要があります。 この手法をサポートする 1 つのライブラリは 、NServiceBus トランザクション セッションです。
ベスト プラクティス
- 適切に設計された API をクライアントに公開します。 API 設計のベスト プラクティスを参照してください。
- 負荷の変化を処理するための自動スケーリング。 自動スケールのベスト プラクティス
参照してください。 - 半静的データをキャッシュします。 キャッシュのベスト プラクティス
参照してください。 - CDN を使用して静的コンテンツをホストします。 CDN のベスト プラクティスを参照してください。
- 必要に応じて、ポリグロット永続化を使用します。 「[ジョブに最適なデータ ストアを使用する][polyglot]」を参照してください。
- スケーラビリティを向上させ、競合を減らし、パフォーマンスを最適化するためにデータをパーティション分割します。 データのパーティション分割のベスト プラクティスを参照してください。
Azure App Service での Web-Queue-Worker
このセクションでは、Azure App Service を使用する推奨される WebQueue-Worker アーキテクチャについて説明します。
このアーキテクチャの 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 で実行されていることを意味します。
デプロイ スロットを使用してデプロイを管理します。 この方法では、更新されたバージョンをステージング スロットにデプロイし、新しいバージョンにスワップできます。 また、更新に問題がある場合は、以前のバージョンに戻すこともできます。