ソリューションのアイデア
このアーティクルはソリューションのアイデアです。 このコンテンツにさらに多くの情報 (想定されるユース ケース、代替サービス、実装に関する考慮事項、価格ガイダンスなど) の掲載をご希望の方は、GitHub のフィードバックでお知らせください。
この記事では、データ プロデューサーおよびコンシューマーが、検証およびキュレーションされたコンテンツまたはデータを作成したり使用したりするための、伸縮性と柔軟性を備えたパブリッシュ/サブスクライブ モデルについて説明します。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
データ プロデューサー アプリがデータを Azure Event Hubs にパブリッシュし、そこからデータが Azure Functions のイベント処理関数に送信されます。
またデータ プロデューサーは、Azure Storage コンテナーのストレージ用に JSON スキーマを送信します。
イベント処理関数は、待ち時間の短縮のために Azure Cache for Redis から JSON スキーマを取得し、そのスキーマを使用してデータを検証します。
スキーマがまだキャッシュされていない場合、イベント処理関数は、Azure Storage コンテナーからスキーマを取得します。 スキーマが要求されると、今後の取得に備えて Azure Cache for Redis へのスキーマの格納も行われます。
注意
Event Hubs の Azure Schema Registry は、JSON スキーマを格納およびキャッシュするための代替手段として使用できます。 詳細については、Event Hubs の Azure スキーマ レジストリ (プレビュー) に関するページをご覧ください。
トピックが既に存在し、データが有効である場合、イベント処理関数は、Azure Service Bus の既存の有効なデータ トピックにデータをマージし、そのトピックをデータ コンシューマー アプリに送信します。
トピックが既に存在し、データが無効である場合、イベント処理関数は、Service Bus の既存の無効なデータ トピックにデータをマージし、そのトピックをデータ プロデューサーに戻します。 データ プロデューサーは無効なデータ トピックをサブスクライブすることで、プロデューサーが作成した無効なデータに関するフィードバックを取得します。
トピックがまだ存在しない場合、イベント処理関数は、新しいデータを Service Bus の新しいデータ トピックにパブリッシュし、そのトピックを Service Bus トピック マネージャー関数に送信します。
新しいデータが有効な場合、イベント処理関数はさらに、そのデータを新しいスナップショット データ レコードとして Azure Cosmos DB に挿入します。
新しいデータが有効な場合、Service Bus トピック マネージャー関数は、Service Bus の新しい有効なデータ トピックを作成し、そのトピックを Event Hubs に送信します。
新しいデータが無効な場合、Service Bus トピック マネージャー関数は、Service Bus の新しい無効なデータ トピックを作成し、そのトピックをデータ プロデューサー アプリに戻します。
Azure Data Factory のスナップショット データ フラット ファイル プロセッサがスケジュールに従って実行され、スナップショット データ Azure Cosmos DB データベースからすべてのスナップショット データが抽出されます。 プロセッサはフラット ファイルを作成し、ダウンロード用に Azure Storage のスナップショット データ フラット ファイルにパブリッシュします。
データ コンシューマー アプリは、サブスクリプション用に用意された、Service Bus トピック マネージャーにあるすべての Service Bus トピックのリストを取得します。 アプリは、Service Bus トピックをサブスクライブするために Service Bus トピック マネージャーに登録します。
Components
- Azure Event Hubs
- Azure Service Bus
- Azure Functions
- Azure Data Factory
- Azure Cosmos DB
- Azure Blob Storage
- Azure Cache for Redis
シナリオの詳細
転送ハブとは、データ プロデューサーとデータ コンシューマーが、検証およびキュレーションされたコンテンツまたはデータを作成したり使用したりするための、動的なパブリッシュ/サブスクライブ モデルです。 このモデルは、スケーリングおよびパフォーマンスの要求に対応できる伸縮性を備えています。 データ プロデューサーは、サービスにすばやくデータをオンボードおよびアップロードできます。 サービスは、データ プロデューサーが提供するスキーマに照らしてデータを検証します。 次にサービスは、サブスクライバーが関心のあるデータを使用できるように、検証済みのデータをサブスクライバーに提供します。
データを検証するサービスは、ペイロードについて把握する必要がありません。プロデューサーが提供するスキーマに照らして有効かどうかを判別するだけです。 こうした柔軟性があるため、サービスは新しいペイロードの種類を、再デプロイせずに受け入れることができます。 また、このソリューションでは、データ コンシューマーは、サブスクライブ前にパブリッシュされた履歴データを取得することもできます。
考えられるユース ケース
このモデルは、次のシナリオで特に役立ちます。
- ユーザーのボリュームと状態が不明または予想外に変化する、メッセージング システム
- 新しいまたは不明なデータ ソースをサポートする必要が生じる可能性のある、パブリッシング システム
- データを継続的に更新し、キャッシュして迅速に配信する必要がある、コマースまたはチケット システム
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Rick Weyenberg | プリンシパル クラウド ソリューション アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- Azure Web PubSub サービスに関するドキュメント
- Service Bus のキュー、トピック、サブスクリプション
- チュートリアル: Azure Functions と Azure Web PubSub サービスを使用してサーバーレス通知アプリを作成する