Azure Service Bus について
Azure Survice Bus の概要
Azure にはキューメカニズムとして２種類あるらしい。
- Service Bus キュー
- Storage キュー
こいつら二人はアプリケーション間の通信をええ感じにしてくれるらしい。
アプリケーション間の通信形式は以下だったらどれでも良いとのこと。
- JSON
- XML
- Apache
- Avro
- プレーンテキスト。
Azure では、Service Bus キューと Storage キューという 2 種類のキュー メカニズムがサポートされています。
Service Bus キューは、より大きな Azure メッセージング インフラストラクチャの一部です。このインフラストラクチャでは、キュー処理やパブリッシュ/サブスクライブなどの高度な統合パターンがサポートされています。 これらは、複数の通信プロトコル、データ コントラクト、信頼ドメイン、ネットワーク環境などにまたがるアプリケーションやアプリケーション コンポーネントの統合を目的としています。
Microsoft Azure Service Bus は、完全なマネージド エンタープライズ統合メッセージ ブローカーです。 Service Bus は、アプリケーションとサービスを分離できます。 データは、メッセージを使用してさまざまなアプリとサービス間で転送されます。 メッセージは、メタデータで装飾されたコンテナーであり、データを格納します。 データは、次のような一般的な形式でエンコードされた構造化データなど、どのような種類の情報でもかまいません: JSON、XML、Apache Avro、プレーンテキスト。
機能詳細
標準レベルとプレミアム レベルが提供されている
| Premium | Standard |
|---|---|
| 高スループット | 変わりやすいスループット |
| 予測可能なパフォーマンス | 変わりやすい待機時間 |
| 固定価格 | 従量課金制の変わりやすい料金 |
| ワークロードをスケールアップおよびスケールダウンする機能 | 該当なし |
| 最大 100 MB のメッセージ サイズ | 最大 256 KB のメッセージ サイズ |
高度な機能も搭載
| 機能 | 説明 |
|---|---|
| メッセージ セッション | Service Bus の先入れ先出し (FIFO) 処理を作成するには、セッションを使用します。 メッセージ セッションでは、関連メッセージのバインドなしシーケンスの排他的な順序指定処理が可能です。 |
| 自動転送 | 自動フォワード機能は、キューまたはサブスクリプションを、同じ名前空間内の別のキューまたはトピックにチェーンします。 |
| 配信不能キュー | Service Bus は配信不能キュー (DLQ) をサポートしています。 DLQ は、受信者に配信できないメッセージを保持します。 Service Bus を使用すると、DLQ のメッセージを削除し、検査することができます。 |
| 配信不能キュー | メッセージをキューまたはトピックに送信して、処理を遅延させることができます。 特定の時点にシステムで処理できるようにジョブをスケジュールすることができます。 |
| メッセージ遅延 | キューまたはサブスクリプション クライアントは、メッセージの取得を遅延させることができます。 メッセージは、キューまたはサブスクリプションに留まりますが、確保されます。 |
| バッチ処理 | クライアント側のバッチ処理により、キューまたはトピックのクライアントはメッセージの送信を一定期間遅らせることができます。 |
| トランザクション | トランザクションにより、複数の操作が 1 つの実行スコープにグループ化されます。 Service Bus は、単一トランザクションのスコープ内の単一メッセージング エンティティに対するグループ化操作をサポートしています。 メッセージ エンティティは、キュー、トピック、またはサブスクリプションとすることができます。 |
| フィルター処理とアクション | サブスクライバーは、トピックから受信するメッセージを定義できます。 これらのメッセージは、1 つ以上の名前付きのサブスクリプション ルールの形式で指定されます。 |
| アイドル状態時の自動削除 | アイドル状態時の自動削除機能を使用すると、アイドル間隔を指定できます。この間隔が経過すると、キューは自動的に削除されます。 最小時間は、5 分です。 |
| 重複検出 | エラーが発生すると、クライアントは送信操作の結果について不明な状態になる可能性があります。 重複検出を使用すると、送信者は同じメッセージを再送信したり、キューまたはトピックで重複するコピーを破棄したりすることができます。 |
| セキュリティ プロトコル | Service Bus は、Shared Access Signatures (SAS)、ロールベースのアクセス制御 (RBAC)、および Azure リソースのマネージド ID などのセキュリティ プロトコルをサポートしています。 |
| geo ディザスター リカバリー | Azure リージョンまたはデータセンターでダウンタイムが発生すると、geo ディザスター リカバリーにより、異なるリージョンまたはデータ センターでデータ処理を継続できます。 |
| セキュリティ | Service Bus は、標準の AMQP 1.0 および HTTP/REST プロトコルをサポートしています。 |
キューのメッセージ配信方法
キューでは、コンシューマーが競合している場合のメッセージ配信に先入れ先出し法 (FIFO) を使用します。 つまり、受信者は、通常はキューに追加された順序でメッセージを受信して処理します。
トピックとサブスクリプション
キューでは、1 つのコンシューマーが 1 つのメッセージを処理できます。 キューとは対照的に、トピックとサブスクリプションは、"発行とサブスクライブ" のパターンで一対多の形式の通信を実現します。
ルールとアクション
フィルターアクションなるものがある。
フィルターの種類は 2 種類。
- SQLFilter
SQL フィルター：このフィルターは、SQL に似た構文を使用して、メッセージのプロパティを指定してフィルタリングすることができます。例えば、"color = 'red'" のように、メッセージのカラープロパティが 'red' である場合にメッセージをフィルタリングすることができます。
- Correlation Filter
Correlation フィルター：このフィルターは、メッセージの Correlation ID プロパティを使用してメッセージをフィルタリングすることができます。Correlation ID は、関連する複数のメッセージをグループ化するために使用されます。
どこで使うの？
具体例は以下。
- メッセージング。 販売または購入の注文、仕訳帳、在庫移動などのビジネス データを転送します。
- アプリケーションの切り離し。 アプリケーションとサービスの信頼性とスケーラビリティを向上します。 クライアントとサービスが同時にオンラインになっている必要はありません。
- トピックとサブスクリプション。 公開元とサブスクライバーの間で 1:n の関係が可能になります。
- メッセージ セッション。 メッセージの順序付けやメッセージの遅延が必要なワークフローを実装します。
Storage キューとの使い分け方は？
Service Bus キューの使用を検討する
- 次の場合に Service Bus キューの使用を検討してください。
- ソリューションで、キューをポーリングせずにメッセージを受信できる必要がある場合。 Service Bus では、Service Bus がサポートする TCP ベースのプロトコルを使用し、長いポーリングの受信操作を使用することによってこれを実現できます。
- キューによるメッセージの配信が先入れ先出し (FIFO) の順序で行われることが保証される必要がある場合。
- ソリューションで、自動重複検出をサポートする必要がある場合。
アプリケーションでメッセージを実行時間の長い並列ストリームとして処理する必要がある場合 (メッセージは、それ自体の [セッション ID] プロパティを使用してストリームに関連付けられます)。 このモデルでは、処理を行うアプリケーションの各ノードは、メッセージではなくストリームに対して競合します。 処理を行うノードにストリームが渡されると、そのノードはトランザクションを使用してアプリケーション ストリームの状態を確認できます。 - 複数のメッセージをキューに送信したりキューから受信したりする際にトランザクション動作と原子性が必要な場合。
- アプリケーションで処理するメッセージのサイズが 64 KB を超えることはあっても 256 KB の制限に到達することはないと考えられる場合。
Storage キューの使用を検討する
- 次の場合に Storage キューの使用を検討してください。
- アプリケーションは 80 ギガバイトを超えるメッセージをキューに格納する必要がある場合。
- アプリケーションでキュー内のメッセージ処理の進行状況を追跡したい場合。 これは、メッセージを処理しているワーカーがクラッシュした場合に役に立ちます。 別のワーカーでその情報を使用して、前のワーカーが中断した時点から処理を再開できます。
- キューに対して実行されたすべてのトランザクションのサーバー側のログが必要な場合。
PeekLock
受信クライアントが、受信したメッセージの明示的な解決を求めることを、ブローカーに指示します。 受信クライアントが処理できるよう、メッセージに排他的なロックがかけられ、他の競合受信クライアントからは認識できなくなります。 ロックの有効期間は、当初キューまたはサブスクリプション レベルで定義され、ロックを所有しているクライアントによる RenewLock 操作によって延長できます。
受信操作の解決 / Settling receive operations MQ や JMS を知っている人になじみが深い挙動で、メッセージの取り扱いはクライアントに委ねられているため、明示的に完了を発行しなければメッセージはブローカーに滞留する（最大試行回数を超えると、Dead Letter Queue に入る）。
Discussion