このシナリオでは、リアルタイム サービスを使用して、ページの更新を必要とせずに、Web ビュー内の基になるデータへの変更を処理するソリューションを設計する方法について説明します。 このシナリオを使用する例としては、製品と商品のリアルタイム追跡や、ソーシャル メディア ソリューションなどがあります。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
コンポーネント
- Azure Service Bus。アプリケーションとサービスの間の (1 つ以上がオフラインの場合でも) 信頼性の高いクラウド メッセージング サービスです。
- Azure SignalR Service。これにより、お使いの Web アプリケーションへのリアルタイム通信の追加が簡単になります。
- Azure Functions は、複雑なオーケストレーションの問題も解決できる、イベントドリブン型のサーバーレス コンピューティング プラットフォームです。
代替
このシナリオに対応するために、Pusher などの代替手段があります。 これは、スケーラブルなリアルタイム通信機能を構築するアプリ開発者向けの堅牢な API におけるカテゴリ リーダーです。
PubNub もあります。 PubNub を使用すると、インフラストラクチャを気にすることなく、アプリへのリアルタイム機能の追加が簡単になります。 モバイル、ブラウザー、デスクトップ、およびサーバーにわたってユーザーがリアルタイムで参加できるようにするアプリを構築してください。
Ably は別の選択肢です。 サーバーレスの発行/サブスクライブ (pub/sub) メッセージングを提供します。これは、ニーズに合わせて確実に拡張できます。 メッセージングは WebSocket を使用して、エッジで配信されます。 Ably プラットフォームは API の呼び出し時に、可用性が高く、弾力的にスケーラブルで、グローバルな分散型リアルタイム インフラストラクチャを提供します。
Pusher、PubNub、および Ably がリアルタイム メッセージング用に広く採用されているプラットフォームであることは間違いありませんが、このシナリオではすべてを Azure で実行します。 SignalR では、サーバーとクライアント間の双方向通信が可能になるため、Go-to プラットフォームとしてお勧めします。 また、これは、79,000 の GitHub スターと 22,000 の GitHub フォークを持つオープンソース ツールでもあります。
詳細については、GitHub の SignalR オープン ソース リポジトリ を参照してください。
シナリオの詳細
このシナリオでは、食品配達サービス トランザクションの現在地を共有するためにリアルタイム メッセージング サービスを設定する方法を見ていきます。 この例は、Web またはモバイルのアプリケーション用に位置情報のリアルタイム共有プラットフォームを構築しようとしているユーザーにも役立ちます。
サーバーレス モードで構成された SignalR サービスを使用して、Service Bus によってトリガーされる Azure Functions アプリと統合します。これらはすべて .NET Core を使用して行います。
考えられるユース ケース
これらの他のユース ケースにも、同様の設計パターンがあります。
- クライアント デバイスとの位置情報のリアルタイム共有
- ユーザーへのプッシュ通知
- タイムラインの更新
- チャット ルームの作成
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
このシナリオを開発する際の考慮事項の一部をこちらに示します。ServiceBusTrigger 内の Azure Service Bus 接続文字列にパラメーターを構成する方法のほか、次のものがあります。
- ハブ: ハブは、ビデオ ストリーミング サービスになぞらえることができます。 ハブをサブスクライブして、そのハブとの間でメッセージを送受信できます。
- ターゲット: ターゲットは、ラジオ チャンネルに似ています。 これには、ターゲット チャネルをリッスンしているすべてのユーザーが含まれており、新しいメッセージがあると通知されます。
SignalR プラットフォームの上記の 2 つの機能を覚えていれば、簡単に素早く開始して実行できます。
可用性、スケーラビリティ、セキュリティ
このソリューションでは、次の 2 つのセクションで説明されている内容に従って高可用性を実現できます。
リージョンのペアリング
各 Azure リージョンは、同じ地区内の別のリージョンとペアリングされます。 通常は、同じリージョン ペアからリージョンを選択します (たとえば、米国東部 2 と米国中部)。 これには、次のような利点があります。
- 広範囲にわたる停止が発生した場合は、すべてのペアで、少なくとも 1 つのリージョンの復旧が優先的に実行されます。
- Azure システムの計画的更新は、起こり得るダウンタイムを最小限に抑えるために、ペアになっているリージョンに対して順にロールアウトされます。
- ほとんどの場合、リージョン ペアは、データの所在地要件を満たすために同じ地区内に所在します。
- ただし、両方のリージョンでアプリケーションに必要なすべての Azure サービスがサポートされていることを確認してください。 リージョン別サービスに関する記事を参照してください。 リージョン ペアの詳細については、「ビジネス継続性とディザスター リカバリー (BCDR):Azure のペアになっているリージョン」をご覧ください。
Azure Front Door
このアーキテクチャの Visio ファイルをダウンロードします。
Azure Front Door は、グローバルなアプリケーションを高速にデリバリーするためのセキュリティで保護されたスケーラブルなエントリ ポイントです。 優先順位によるルーティングを使用すると、プライマリ リージョンが使用できなくなった場合に、自動的にフェールオーバーします。 マルチリージョン アーキテクチャは、単一のリージョンにデプロイするよりも高い可用性を提供できます。 地域的な停止がプライマリ リージョンに影響する場合は、Front Door を使用して、セカンダリ リージョンにフェールオーバーできます。
このアーキテクチャは、ソリューションの個々のサブシステムで障害が発生した場合にも役立ちます。 Web アプリケーション ファイアウォールと DDoS Protection を使用して、ネットワークとアプリケーション レイヤーの攻撃を水際で阻止してください。 Microsoft が管理するルール セットを使用してご利用のサービスを強化し、独自ルールを作成してアプリをカスタム保護します。
Front Door は、システムの障害ポイントになる可能性があります。 このサービスに障害が発生すると、クライアントは、ダウンタイム中はアプリケーションにアクセスできなくなります。 Front Door のサービス レベル アグリーメント (SLA) に関するページを確認し、Front Door の使用だけで高可用性のビジネス要件が満たされるかどうかを判断してください。 満たされない場合は、フォールバックとして別のトラフィック管理ソリューションを追加することを検討してください。 Front Door サービスで障害が発生した場合は、他のトラフィック管理サービスを参照するように、DNS の正規名 (CNAME) レコードを変更します。 この手順は手動で実行する必要があり、DNS の変更が反映されるまでアプリケーションを使用することはできません。
コスト最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
お客様の事業で 1 日に 1,000 件の注文があり、それらすべてで位置データを同時に共有する必要があるとします。 このシナリオをデプロイするための Azure の推定使用量は、発行時点の価格に基づくと、月額 192 米国ドル近くになります。
| サービスの種類 | 推定の月間コスト |
|---|---|
| Azure Functions | 119.40 米国ドル |
| Azure SignalR Service | 48.97 米国ドル |
| Azure Service Bus | 23.71 米国ドル |
| 合計 | 192.08 米国ドル |
このシナリオのデプロイ
Azure Functions の開発
Azure Functions および Azure SignalR Service で構築されたサーバーレスのリアルタイム アプリケーションは、通常、2 つの Azure Functions が必要です。
- 有効な SignalR Service アクセス トークンおよびサービスエンドポイント URL を取得するためにクライアントが呼び出す
negotiate関数。 - メッセージを送信し、グループ メンバーシップを管理する 1 つ以上の関数。
SignalRFunctionApp
SignalRFunctionApp は、SignalR を使用した Service Bus トリガーを含む Azure Functions インスタンスを作成する関数アプリです。
Negotiate.cs
この関数は、HTTP 要求によってトリガーされます。 これは、クライアントがハブをサブスクライブするために使用できるトークンを SignalR サービスから取得するためにクライアント アプリケーションで使用されます。 この関数は negotiate という名前にする必要があります。 詳しくは、「Azure SignalR Service を使用した Azure Functions の開発と構成」を参照してください。
Message.cs
この関数は、Service Bus トリガーによってトリガーされます。 これには、SignalR サービスとのバインドがあります。 これによって、キューからメッセージがプルされ、SignalR ハブに渡されます。
Instructions
作業を開始する前に、次のことを行います。
- Service Bus キューが Azure でプロビジョニングされていることを確認します。
- Azure で SignalR サービスがサーバーレス モードでプロビジョニングされていることを確認します。
- local.settings.json に接続文字列 (Service Bus および SignalR) を入力します。
- CORS (クロス オリジン リソース共有) にクライアント アプリケーション (SignalR クライアント) の URL を入力します。 最新の構文については、「Azure SignalR Service を使用した Azure Functions の開発と構成」を参照してください。
- Message.cs ファイル内の Service Bus トリガーに Service Bus キュー名を入力します。
次に、テストするクライアント アプリケーションを構成しましょう。 最初に、ソリューション アーキテクチャの GitHub ページからサンプル ソースを取得します。
SignalR クライアント
このシンプルな .NET Core Web アプリケーションは、SignalRFunctionApp によって作成されたハブをサブスクライブします。 Service Bus キューで受信したメッセージをリアルタイムで表示します。 SignalRFunctionApp を使用してモバイル クライアントを操作できますが、このリポジトリのこのシナリオでは、Web クライアントを対象とします。
Instructions
SignalRFunctionApp が実行されていることを確認します。
negotiate 関数によって生成された URL をコピーします。 次のような画面が表示されます
http://localhost:7071/api/。chat.js ファイルの
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();の中に URL を貼り付けます。アプリケーションを実行します。
Web クライアントが SignalR ハブを正常にサブスクライブすると、接続されている状態になります。
SendToQueue.js
この node.js スクリプトは、完了したばかりのデプロイをテストできるように、メッセージを Service Bus にプッシュします。
Instructions
ノード Azure Service Bus モジュール (@azure/service-bus) をインストールします。
スクリプトに接続文字列とキュー名を入力します。
スクリプトを実行します。
次のステップ
このシナリオを運用環境に取り入れます。 ただし、Azure サービスがスケーリングするように設定されていることを確認してください。 たとえば、Azure Service Bus は Standard または Premium プランに設定する必要があります。
コードは Visual Studio から直接 Azure Functions にデプロイできます。 Visual Studio からコードを Azure Functions に発行する方法については、「ソフトウェアの作成方法」ガイドに従ってください。
Azure Functions で Azure Service Bus のバインドと連携する方法をご覧ください。 Azure Functions は、Service Bus のキューおよびトピックのトリガーおよび出力バインドをサポートしています。
Azure Functions で SignalR Service のバインドを使用して、Azure SignalR Service に接続されたクライアントに対して認証を行い、リアルタイム メッセージを送信する方法をご覧ください。 Azure Functions は、SignalR Service の入力および出力バインドをサポートしています。