だいぶアドベントカレンダーの趣旨からは外れてしまいますが、今年も 1 人アドベントカレンダー実施することにしました。
25 日まで毎日更新頑張ります！
qiita.com

今日の項目内容

今回からサービスの接続のラーニングパスに移っていきます。
ご自分のサービスにゆるく接続するために Azure でメッセージングモデルを選ぶ

メッセージやイベントを使用するかどうかを選択する
キューを使用するメッセージベースの配信を選択する

学習内容まとめ

メッセージやイベントを使用するかどうかを選択する

分散アプリケーションの用語で、メッセージとイベントがある。
メッセージには以下の特性がある。

1 つのコンポーネントによって生成され、別のコンポーネントで使用される生のデータが含まれる
データへの参照だけでなく、データ自体が含まれる
送信側コンポーネントは、メッセージのコンテンツが宛先コンポーネントによって特定の方法で処理されることを想定している

イベントには、以下の特性がある。

何かが発生したことを示す軽量の通知
送信されたイベントの受信者が複数のこともあれば、まったくいないこともある
パブリッシャーのそれぞれに対して多数のサブスクライバーが存在する
受信側コンポーネントがどのようなアクションを実行するかについて想定していない
一部のイベントは個別ユニットであり、他のイベントに関連しない
一部のイベントは、一連の関連する順序つけられたイベントに属する

イベントは、ブロードキャストに使用されることが多く、ほぼ一時的。メッセージは分散アプリケーションで通信の処理を保証する必要がある場合に使用される可能性が高い。
送信側コンポーネントは通信が宛先コンポーネントによって特定の方法で処理されることを想定しているか、という点でどちらがふさわしいか選択できる。

キューを使用するメッセージベースの配信を選択する

「音楽共有アプリケーション用のアーキテクチャを計画している」という仮定に基づき、理解を深めていく。
今回の要件には、Azure では Azure Queue Storage と Azure Service Bus のソリューションが適している。
キューは、以下の点において、非常に有用である。

信頼性の向上
混み合い時、宛先コンポーネント側でメッセージを処理する準備が整うまでメッセージを単純に待機させることができる為、メッセージ交換の信頼性が向上する。

メッセージの配信保証 通常、キューシステムによりキュー内の各メッセージを宛先コンポーネントに配信する処理が行われるが、以下のようなアプローチでも実現が可能。
At-Least-Once 保証 : キューからメッセージを取得するコンポーネントの少なくとも 1 つへ、各メッセージが配信されることが保証される
At-Most-Once 保証 : 同じメッセージが 2 回配信されることはない、自動重複データ検出
FIFO : キューに入れられたのと同じ順番でキューから出されている保証があるかを検討する必要がある

トランザクションのサポート
e コマースアプリケーションなどを例に考えた場合、クレジットカードメッセージが配信されずに、すべての注文内容が支払いなしに処理されることを防ぐためにもメッセージをトランザクションにグループ化することによって回避できる。
データベースの場合と同様に、単一のユニットとして成功または失敗する。
なので、クレジットカード情報のメッセージ配信が失敗した場合は、注文詳細のメッセージ配信も失敗する。

本日の内容は以上です。