メッセージやイベントを使用するかどうかを選択する
あなたは分散型の音楽共有アプリケーションのアーキテクチャを計画しているとします。 このアプリケーションの信頼性とスケーラビリティをできるだけ高くする必要があるため、Azure のテクノロジを使用して堅牢な通信インフラストラクチャを構築しようとしています。
適切な Azure テクノロジを選択するには、まずアプリケーションのコンポーネントが交わす個々の通信について理解しておく必要があります。 通信ごとに異なる Azure テクノロジを選択できます。
通信についてまず理解しなければならないのは、メッセージとイベントのどちらを送信するかということです。 この知識は、使用に適した Azure サービスを選択する際に役立ちます。
Azure での通信方法 (API)
メッセージとは
分散アプリケーションの用語で、メッセージには次の特性があります。
- メッセージには、1 つのコンポーネントによって生成され、別のコンポーネントで使用される生のデータが含まれています。
- メッセージには、データへの参照だけでなく、データ自体が含まれています。
- 送信側コンポーネントは、宛先コンポーネントによってメッセージのコンテンツが特定の方法で処理されることを想定しています。 全体的なシステムの整合性は、特定のジョブを実行する送信側と受信側の両方によって決まる場合があります。
たとえば、ユーザーがモバイルの音楽共有アプリを使用して新しい曲をアップロードするとします。 モバイル アプリは、Azure で実行されている Web API にその曲を送信する必要があります。 新しい曲が追加されたことを示すアラートだけでなく、曲のメディア ファイル自体を送信する必要があります。 そのモバイル アプリは、Web API がその新しい歌をデータベースに格納して、他のユーザーから使用できるようにすることを期待しています。 これはメッセージの例です。
イベントとは
イベントはメッセージよりも軽量で、ほとんどの場合はブロードキャスト通信に使用されます。 イベントを送信するコンポーネントはパブリッシャーと呼ばれ、受信側はサブスクライバーと呼ばれます。
イベントでは、受信側のコンポーネントによって関心がある通信が決定され、それらのイベントが "サブスクライブ" されます。 サブスクリプションの管理は、Azure Event Grid や Azure Event Hubs などの中継局が行います。 パブリッシャーによってイベントが送信されると、中継局によって関心を持っているサブスクライバーにイベントがルーティングされます。 このパターンは "パブリッシュ/サブスクライブ アーキテクチャ" と呼ばれ、イベントを処理する唯一の方法というわけではありませんが、最も一般的な方法です。
イベントには次の特性があります。
- イベントは、何かが発生したことを示す軽量の通知です。
- 送信されたイベントの受信者が複数のこともあれば、まったくいないこともあります。
- 多くの場合、イベントは "ファンアウト" を意図しています。つまり、パブリッシャーのそれぞれに対して多数のサブスクライバーが存在します。
- イベントのパブリッシャーは、受信側コンポーネントがどのようなアクションを実行するかについて何も想定していません。
- 一部のイベントは個別のユニットであり、他のイベントに関連しません。
- 一部のイベントは、一連の関連する順序付けられたイベントに属します。
たとえば、音楽ファイルのアップロードが完了し、新しい曲がデータベースに追加されたとします。 新しいファイルのことをユーザーに知らせるために、Web API は Web フロント エンドとモバイル アプリのユーザーに新しいファイルのことを通知する必要があります。 ユーザーは、その新しい曲を聴くかどうかを選択できます。したがって、最初の通知には、音楽ファイルが含まれず、その曲が存在することだけがユーザーに通知されます。 送信側では、イベントの受信側がこのイベント受信に応答して特に何かを実行することを想定していません。
このシナリオは、個別のイベントの例です。
メッセージまたはイベントを選択する方法
1 つのアプリケーションが、ある目的のためにイベントを使用し、別の目的のためにメッセージを使用するということはよくあります。 選択を行う前に、アプリケーションのアーキテクチャとそのすべてのユース ケースを分析して、そのコンポーネントが相互に通信する際のさまざまな目的をすべて識別する必要があります。
イベントは、ブロードキャストに使用される可能性の方が高く、多くの場合、エフェメラルです。 これは、現在まったくサブスクライブされていない場合は、その通信がどの受信側によっても処理されていない可能性があることを示しています。 メッセージが使用される可能性が高いのは、分散アプリケーションで通信の処理を保証する必要がある場合です。
各通信について、送信側コンポーネントは通信が宛先コンポーネントによって特定の方法で処理されることを想定しているか、ということを問いかけてみてください。
答えが "はい" の場合は、メッセージを使用します。 答えが "いいえ" の場合は、イベントを使用できる可能性があります。
コンポーネントに必要な通信方法を知っておくと、そのコンポーネントの通信方法を選択しやすくなります。 では、初めにメッセージについて見ていきましょう。