イベント駆動型アーキテクチャは、より動的に劣るポーリング ベースのシステムを次々に置き換えたり、追い越したりしながら、IoT シナリオ、データ処理タスク、インフラストラクチャ オートメーション ジョブにサーバーレス コンピューティングのメリットをもたらしています。マイクロサービスの自然な流れとして、世界中の企業がイベント駆動型アプローチを採用し、既存のアプリケーションで新しいエクスペリエンスを創造したり、そのようなアプリケーションをクラウドに移行したりして、毎日、より強力で複雑なシナリオを構築しています。

本日は、より高性能でより高度なイベント駆動型アプリケーションをクラウドにもたらす Event Grid の一連の更新を発表させていただきます。

• IoT Hub デバイス テレメトリ イベントのパブリック プレビュー
• イベント ハンドラーとしての Service Bus のパブリック プレビュー
• 自動サーバー側 geo ディザスター リカバリー
• ドメインあたり最大 100,000 トピックになったイベント ドメインの一般提供
• 1 MB イベント サポートのパブリック プレビュー
• リスト検索 API とページネーション API
• フィルタリングの深さが増大した高度なフィルターの一般提供

Azure エコシステムとの拡張統合

Azure IoT Hub と Event Grid の統合の開始以降、最も要望が多かった機能の 1 つがデバイス テレメトリ イベントです。本日は、米国東部、米国西部、およびヨーロッパ西部を除くすべてのパブリック リージョンのパブリック プレビューでこの機能を最終版として公開します。皆様がこの機能をお試しいただき、ビジネスのためにさらに効率的な IoT ソリューションを構築されるのを楽しみにしております。

デバイス テレメトリ イベントにサブスクライブすることにより、データをお客様のデバイスからお客様のソリューションに簡単に統合できるようになります。これには、Azure Functions または Azure Logic Apps を使用したサーバーレス アプリケーションと webhook を使用したその他のサービス (Azure 上かどうかは問わない) が含まれます。これにより、デバイス テレメトリをポーリングしてさらに処理するためのサービスを追加する必要がなくなるため、IoT アーキテクチャが簡略化されます。

Event Grid にデバイス テレメトリ イベントを発行することで、IoT Hub は、メッセージ ルーティングを通してサポートされるエンドポイントを越えて、データが到達できるサービスを拡張します。たとえば、デバイス ツイン タグで識別されるデバイス タイプごとに別々のデバイス テレメトリ イベントへのサブスクリプションを作成し、デバイス タイプごとに異なる計算をするための別々の Azure Functions またはサードパーティ アプリケーションをトリガーすることにより、ダウンストリーム ワークフローを自動化することができます。デバイス テレメトリ イベントへの Event Grid サブスクリプションに基づいて、わたしたちはデバイス テレメトリへのお客様のすべての Event Grid サブスクリプションを処理する IoT Hub 内の既定のルートを作成します。

ドキュメントで IoT Hub デバイス テレメトリに関する詳細を確認し、Azure IoT User Voice フォーラム経由で提案をお送りください。

また、パブリック プレビューには Event Grid のイベント ハンドラーとして Service Bus を追加しているため、今日から、Event Grid 内のお客様のイベントを直接 Service Bus キューにルーティングすることができます。Service Bus は、イベント ソースとイベント ハンドラーのどちらかとしても機能できるようになったため、分散エンタープライズ アプリケーションでより堅牢なイベントとメッセージの配信が体験できます。まだパブリック プレビューの段階であり、Service Bus のトピックやセッションでは動作しませんが、Service Bus キューのすべての階層で動作します。

これにより、作成された BLOB、作成されたデバイス、終了されたジョブなどの他のサービスに対するアクティビティのイベントを受け取って、さらに処理するために転送するコマンドや制御シナリオが可能になります。

ドキュメントで宛先としての Service Bus に関する詳細を確認してください。

サーバー側 geo ディザスター リカバリー

Event Grid に、メタデータの自動 geo ディザスター リカバリー (GeoDR) が組み込まれました。この機能は、新しいものだけでなく、既存のドメイン、トピック、イベント サブスクリプションにも適用できます。これにより、すべてがプラットフォームによって完全に管理されているサービス中断に対する回復力が大幅に向上します。Azure リージョン全体でサービス停止が発生した場合は、Event Grid サービスがお客様のすべてのイベント発生元のインフラストラクチャ メタデータをペアのリージョンに同期させているため、お客様の新しいイベントがお客様の側からの仲介なしに再び流れ出し、サービス中断が自動的に回避されます。

ディザスター リカバリーは、通常、次の 2 つの指標を使用して測定されます。

• 目標復旧ポイント (RPO): 消失した可能性のあるデータの分数または時間数。
• 目標復旧時間 (RTO): サービスがダウンした可能性のある分数または時間数。

Event Grid の自動フェールオーバーでは、お客様のメタデータ (イベント サブスクリプションなど) 用とデータ (イベント) 用で別々の RPO と RTO が使用されます。以下とは異なる仕様が必要な場合は、トピック ヘルス API を使用して、独自のクライアント側フェールオーバーを実装することもできます。

• メタデータ RPO:0 分。文字どおりです。Event Grid でリソースが作成されるとすぐにリージョン全体にレプリケートされます。フェールオーバーが発生した場合は、メタデータが失われます。
• メタデータ RTO:Event Grid は、60 分以内 (通常は、もっと早く行われます) に、トピックとサブスクリプションに対する作成/更新/削除の呼び出しの受け付けを開始します。
• データ RPO:リージョン内フェールオーバーの発生時にお客様のシステムが正常で、既存のトラフィックに後れを取っていない場合は、イベントの RPO は約 5 分です。
• データ RTO:メタデータと同様に、Event Grid は、60 分以内 (通常は、もっと早く行われます) に、リージョン内フェールオーバー後に新しいトラフィックの受け付けを開始します。

ここが最大のポイントです。Event Grid 上ではメタデータ GeoDR のコストが発生しません。現行のサービス価格に含まれているため、追加料金は発生しません。

高度なイベント駆動型ワークロードの強化

IoT、CRM、金融などのさまざまなシナリオのより高度なイベント駆動型アーキテクチャを見ると、イベント発生時にマルチテナント アプリケーションやワークロードでより大量のデータを処理するための機能拡張のニーズが高まっていることに気が付きます。

イベント ドメインを使用すれば、単一の構造に基づいてイベント発生元のインフラストラクチャ全体を整理し、サブスクライブ可能なトピックごとにきめ細かな認証ルールを設定し、単一のエンドポイントを使用してお客様のすべてのイベント発行を管理することができます。従来のパブリッシュ サブスクライブ アーキテクチャは、トピックとサブスクリプションに基づいて排他的に構築されますが、より高度で忠実度の高いイベント駆動型アーキテクチャを構築すると、メンテナンスにかかる負担が飛躍的に増大します。イベント ドメインは、ユーザーに代わって管理の大半を処理し、その仕事を軽減します。

本日は、イベント ドメインが一般提供されたことを発表いたします。これを使用することにより、ユーザーは、ドメインあたり 100,000 トピックを所有することができます。一般提供に伴うイベント ドメインの制限のすべてを以下に示します。

• イベント ドメインあたり 100,000 トピック
• Azure サブスクリプションあたり 100 イベント ドメイン
• イベント ドメイン内のトピックあたり 500 イベント サブスクリプション
• イベント ドメインの範囲内で 50 ’firehose’ イベント サブスクリプション
• イベント ドメインあたり 5,000 イベント/秒

これまでと同様に、これらの制限がご使用の環境に適合しない場合は、サポート チケット経由でまたは askgrid@microsoft.com にメールを送信して、ご自由にお問い合わせください。

容量を増やすことができます。

また、高度なイベント駆動型アーキテクチャが必ずしも 64 KB の範囲内に収まらないことも認識しています。このようなワークロードでは、よりシンプルなアーキテクチャでより大規模なイベントを処理する必要があります。本日は、最大 1 MB のイベントのパブリック プレビューを発表いたします。

構成を変更することなく既存のイベント サブスクリプションで動作します。64 KB 未満のものは一般提供 SLA で引き続きカバーされます。試してみるには、大きめのイベントをプッシュするだけです。そうすると、64 KB を超えるイベントは 64 KB 増えるごとに課金されることと、JSON 配列として Event Grid に送信されるイベントのバッチ サイズの上限は全部で 1 MB であることがわかります。

簡略化されたイベントの管理

お客様が何千ものイベント サブスクリプションをお持ちの場合もあれば、イベント ドメインの一般提供に伴って、お客様の Azure サブスクリプションの周りに何十万ものトピックが存在する場合もあります。これらのリソースの検索と管理をより簡単にするために、わたしたちは Event Grid 全体にリスト検索 API とリスト ページネーション API を導入しました。詳細については、Azure Event Grid のドキュメントで確認してください。

Event Grid でメッセージをルーティングするために使用される高度なフィルターが一般提供されました。お客様の JSON 内にネストしたオブジェクトの数に制限はありません。これにより、イベントをフィルター処理してから他のサービスに渡してさらに処理する場合の細分性が向上し、このフィルター処理を他の場所で行わないようにすることで計算時間と必要なリソースが削減されます。

高度なフィルターをまだ使ったことがない場合は、イベントの任意の部分で以下の演算子を使用することにより、ほぼ無限の可能性が広がります。StringContains、StringBeginsWith、StringEndsWith、StringIn、StringNotIn、NumberGreaterThan、NumberGreaterThanOrEquals、NumberLessThan、NumberLessThanOrEquals、NumberIn、NumberNotIn、BoolEquals。

今すぐご利用ください

これまでと同様に、これらの新しい機能を試す機会があれば、アイデア、フィードバック、ウィッシュ リストをお送りください。今すぐ、以下のリソースで始めることができます。フィードバックをぜひお寄せください。

1. まだの場合は、Azure 無料アカウントにサインアップする
2. Event Grid を使用して IoT Hub デバイス テレメトリ イベントにサブスクライブする
3. イベント ハンドラーとしての Service Bus の使用に関する詳細を確認する
4. イベント ドメインを使用してより強力なマルチテナント アプリケーションをビルドする
5. これらの新しい API を使用して大量のイベントに対する検索とページネーションを実施する
6. 高度なフィルターを使用して必要なイベントだけをルーティングして処理する