メッセージング プラットフォームを選択する

  • 8 分

分散アプリケーションの信頼性を向上させるために利用できる通信プラットフォームは数多くあり、Microsoft Azure にもいくつかあります。 各プラットフォームは、異なる目的を実現するためのツールです。 アプリケーションの要件ごとに適切なツールを選択することが重要です。 Azure Service Bus でのオプションを見ていきましょう。

提案されている Contoso Bicycles の注文および追跡アプリケーションの分散アーキテクチャには、Web サイト、データ ストレージ、バックエンド サービスなど、いくつかのコンポーネントが必要です。 アプリケーションのコンポーネントはさまざまな方法でまとめてバインドでき、単一のアプリケーションで複数の手法を利用できます。

どの手法を新しい Contoso Bicycles アプリケーションで使用するかを決定する必要があります。 最初のステップは、複数の部分の間で通信が行われる各場所を評価することです。 アプリケーションでそのジョブを実行するには、一部のコンポーネントが適切なタイミングで実行される "必要があります"。 一部は、重要ではあっても、タイム クリティカルではないかもしれません。 最後に、モバイル アプリ通知のようなその他のコンポーネントは、もう少し自由度が高くなります。

メッセージかイベントのどちらかを決定する

メッセージとイベントの両方がデータグラムである: これはコンポーネント間で送信されるデータのパッケージです。 これらの違いは一見したところわずかなようですが、アプリケーションを設計する方法には大きな違いとなる場合があります。

メッセージ

アプリケーションの全体的な整合性は受信するメッセージによって異なる場合があります。これは分散アプリケーションの用語において、メッセージの特性をよく表しています。 メッセージを送信することを、ワークフローのバトンを別のコンポーネントに渡す1つのコンポーネントとして考えることができます。 ワークフロー全体が重要なビジネス プロセスとなる可能性があり、メッセージはコンポーネントをまとめて保持するモルタルです。

一般的にメッセージには、データへの (ID や URL のような) 単なる参照ではなく、実際のデータが含まれます。 データをデータグラムの一部として送信することは、参照を送信するよりも不安定さが軽減されます。 メッセージングのアーキテクチャによってメッセージの配信が保証され、追加の検索は不要であるため、メッセージは確実に処理されます。 しかし、送信側のアプリケーションでは、含めるデータを正確に把握して過度のデータ送信を回避することで、受信側のコンポーネントで不要な作業を行わなくても済むようにする必要があります。 このような意味で、メッセージの送信側と受信側は、多くの場合、厳格なデータ コントラクトで結合されます。

Contoso Bicycles の新しいアーキテクチャでは、注文を受けるときに、メッセージを使用することが考えられます。 Web フロントエンドまたはモバイル アプリによって、バックエンド処理コンポーネントにメッセージが送信されます。 バックエンドでは、顧客の最寄りの店へのルーティングやクレジット カードへの課金などの手順が行われます。

イベント

イベントによって、何かが発生したことを知らせる通知がトリガーされます。 イベントはメッセージよりも "軽量" で、ほとんどの場合はブロードキャスト通信に使用されます。

イベントには次の特性があります。

  • 送信されたイベントの受信側が複数のこともあれば、まったくいないこともあります。
  • 多くの場合、イベントは "ファンアウト" を意図しています。つまり、パブリッシャーのそれぞれに対して多数のサブスクライバーが存在します。
  • パブリッシャーは、受信側のコンポーネントが実行するアクションについて何も期待していません。

自転車パーツのチェーン店では、状態変更に関するユーザー通知にイベントを使用することが考えられます。 状態変更イベントは、Azure Event Grid に送信でき、その後、Azure Functions、Azure Notification Hubs の順に送信され、完全に "サーバーレス" なソリューションが実現します。

通信プラットフォームは一般的にどちらか一方を処理するように設計されているため、イベントとメッセージのこのような違いは根本的なものです。 Service Bus はメッセージを処理するように設計されています。 イベントを送信する場合は、Event Grid を選択する可能性が高いです。

Azure には Azure Event Hubs もありますが、これは、ほとんどの場合、分析のために使用される通信の特定の種類の高フロー ストリームで使用されます。 たとえば、製造工場にネットワーク接続されたセンサーを取り付けていた場合、Azure Stream Analytics と結合された Event Hubs を使用して、望ましくない火災やコンポーネントの摩耗を示す可能性のある温度変化のパターンを監視できます。

Service Bus のトピックとキュー

Azure Service Bus では、キューとトピックという 2 つの異なる方法でメッセージを交換できます。

キューとは

Service Bus の "キュー" はメッセージの単なる一時的な保存場所です。 コンポーネントを送信することで、キューにメッセージが追加されます。 送信先コンポーネントでは、キューの先頭にあるメッセージがピックアップされます。 通常の状況では、メッセージはそれぞれ 1 人の受信者のみが受信します。

Diagram that shows a sample message queue with one sender sending the messages to the queue and one receiver retrieving them one by one from the queue.

キューでは、需要が高い状況から送信先コンポーネントを隔離するために、送信元と送信先のコンポーネントを分離します。

ピーク時間帯では、送信先コンポーネントで処理できるよりも速くメッセージが着信する場合があります。 送信元コンポーネントは送信先に直接接続されないため、送信元が影響を受けることはなく、キューが増大します。 送信先コンポーネントでは、メッセージの処理が可能になると、キューからそのメッセージが削除されます。 需要が減少すると、送信先コンポーネントが追いつくことができ、キューが短くなります。

キューは、システムにリソースを追加することなく、高い需要に対応します。 しかし、迅速に処理する必要があるメッセージについては、送信先コンポーネントに追加のインスタンスを作成することで、それらに負荷を共有させることができます。 各メッセージは 1 つのインスタンスのみで処理されます。 これは、実際に必要なコンポーネントのみにリソースを追加することで、アプリケーション全体をスケーリングする効果的な方法です。

トピックとは

Service Bus の "トピック" はキューに似ていますが、複数のサブスクリプションを持つことができます。 つまり、複数の送信先コンポーネントが特定のトピックにサブスクライブできるため、各メッセージは複数の受信者に配信されます。 サブスクリプションでは、トピック内のメッセージをフィルター処理して関連するメッセージのみを受信することもできます。 サブスクリプションはキューと同じ分離された通信を提供し、込み合った状況にも同じ方法で対応します。 各メッセージを複数の送信先コンポーネントに配信する場合はトピックを使用します。

Note

トピックは Basic 価格レベルではサポートされていません。

Diagram that shows one sender sending messages to multiple receivers through a topic that contains three subscriptions. These subscriptions are used by three receivers to retrieve the relevant messages.

Service Bus キューとストレージ キュー

Service Bus と Azure Storage の 2 つの Azure サービスには、メッセージ キューが含まれます。 一般的なガイドとして、Service Bus キューに比べると、ストレージ キューの方が使用するのは簡単ですが、機能は劣り、柔軟性に欠けます。

Service Bus キューの主な利点は次のとおりです。

  • Azure Storage キュー メッセージの 64 KB に対して、メッセージあたり 256 KB (Standard レベル) または 100 MB (Premium レベル) と、より大きいサイズのメッセージをサポートします。
  • At-Most-Once と At-Least-Once の両方の配信がサポートされます。 メッセージが失われるという極めて低い可能性と、メッセージが 2 回処理されるという極めて低い可能性のいずれかを選択できます。
  • "先入れ先出し (FIFO)" の順序が保証されます。 メッセージは、追加された順序と同じ順序で処理されます。 FIFO はキューの通常の操作ですが、組織がシーケンス付きメッセージやスケジュールされたメッセージを設定した場合、またはシステム クラッシュのような中断の間は、既定の FIFO パターンが変更されます。 詳細については、Azure Storage キューと Azure Service Bus キューの比較に関する記事を参照してください。
  • 複数のメッセージを 1 つのトランザクションにグループ化できます。 トランザクション内の 1 つのメッセージの配信が失敗すると、トランザクション内のすべてのメッセージが配信されません。
  • ロール ベース セキュリティをサポートします。
  • 送信先コンポーネントが継続的にキューをポーリングする必要がありません。

ストレージ キューの利点は次のとおりです。

  • 無制限のキュー サイズがサポートされます (これに対して、Service Bus キューでは 80 GB に制限されています)
  • すべてのメッセージのログが維持されます

通信テクノロジを選択する方法

Azure が提供するさまざまな概念と実装について見てきました。 次に、各通信についてどのようなプロセスで決定する必要があるかを検討します。

考慮事項

メッセージの送受信方法を選択するときは、次のことを考慮します。

  • 通信はイベントですか? そうである場合は、Event Grid または Event Hubs の使用を検討してください。

  • 単一のメッセージを複数の送信先に配信する必要がありますか? 必要がある場合は、Service Bus トピックを使用します。 そうでない場合は、Service Bus キューを使用します。

キュー: Service Bus かストレージか

キューが必要であると判断した場合は、さらに選択を絞り込む必要があります。

次の場合は、Service Bus キューを選択します。

  • At-Most-Once の配信保証が必要である。
  • FIFO の保証が必要です (既定の FIFO 順序より他の設定が優先されない場合)。
  • メッセージをトランザクションにグループ化する必要がある。
  • キューをポーリングせずにメッセージを受信する必要がある。
  • キューへのロールベースのアクセスを提供する必要がある。
  • 64 KB より大きく 256 KB (Standard レベルの場合) または 100 MB (Premium レベルの場合) より小さいメッセージを処理する必要がある。
  • キューのサイズが 80 GB を超えることはない場合。
  • バッチ メッセージを発行および使用できる必要がある。

次の場合は、"ストレージ" キューを選択します。

  • 特定の追加要件のない、単純なキューが必要である。
  • キューを通ったすべてのメッセージの監査証跡が必要である。
  • キューのサイズが 80 GB を超えると予想される。
  • キュー内のメッセージ処理の進行状況を追跡する必要がある。

分散アプリケーションのコンポーネントは直接通信できますが、多くの場合、Azure Event Hubs や Azure Event Grid など、中間通信プラットフォームを使用してその通信の信頼性を高めることができます。

Event Hubs と Event Grid はイベント向けに設計されており、イベントは受信者のみに通知され、そのイベントに関連付けられた生データは含まれません。 Azure Event Hubs は高フローの分析タイプ イベント向けに設計されています。

Azure Service Bus とストレージ キューはメッセージ用であり、アプリケーション ワークフローの中核部分をバインドするために使用できます。

要件がシンプルな場合、1 つの送信先のみに各メッセージを送信する場合、または可能な限り早くコードを記述する場合は、ストレージ キューが最適なオプションである可能性があります。 それ以外の場合、Service Bus キューによって、より多くのオプションや柔軟性が提供されます。

複数のサブスクライバーにメッセージを送信する場合は、Service Bus トピックを使用します。