パブリッシュ・サブスクライブパターン

ソフトウェア アーキテクチャにおいて、パブリッシュ - サブスクライブは、パブリッシャーがメッセージをサブスクライバーが受信するクラスに分類するメッセージング パターンです。これは、パブリッシャーがメッセージをサブスクライバーに直接送信する一般的なメッセージング パターン モデルとは対照的です。

同様に、サブスクライバーは 1 つ以上のクラスに関心を示し、どのパブリッシャーが存在するか (存在する場合) を認識せずに、関心のあるメッセージのみを受信します。

パブリッシュ/サブスクライブはメッセージ キューパラダイムの兄弟であり、通常は、より大きなメッセージ指向ミドルウェアシステムの一部です。ほとんどのメッセージング システムは、 APIでパブリッシュ/サブスクライブ モデルとメッセージ キュー モデルの両方をサポートしています(例: Java Message Service (JMS))。

このパターンは、ネットワークのスケーラビリティとネットワークトポロジーの動的な向上を実現しますが、その結果、パブリッシャーとパブリッシュされたデータの構造を変更する柔軟性は低下します。Gregor Hohpe によると、同期メッセージングパターン ( RPCなど) やポイントツーポイントメッセージングパターンと比較して、パブリッシュ-サブスクライブはアーキテクチャコンポーネント間の分離レベルが最も高いものの、他の方法 (フォーマットやセマンティック結合など) でコンポーネントが結合してしまうこともあり、時間の経過とともに複雑化します。^[1]

パブリッシュ/サブスクライブ モデルでは、サブスクライバーは通常、パブリッシュされたメッセージ全体のサブセットのみを受信します。受信および処理するメッセージを選択するプロセスは、フィルタリングと呼ばれます。フィルタリングには、トピック ベースとコンテンツ ベースの 2 つの一般的な形式があります。

トピック ベースのシステムでは、メッセージは「トピック」または名前付き論理チャネルに公開されます。トピック ベースのシステムのサブスクライバーは、サブスクライブしているトピックに公開されたすべてのメッセージを受信します。サブスクライバーがサブスクライブできるトピックを定義するのはパブリッシャーの役割です。

コンテンツ ベースのシステムでは、メッセージの属性またはコンテンツがサブスクライバーによって定義された制約に一致する場合にのみ、メッセージがサブスクライバーに配信されます。サブスクライバーはメッセージを分類する責任があります。

一部のシステムでは、これら 2 つのハイブリッドがサポートされています。つまり、パブリッシャーはトピックにメッセージを投稿し、サブスクライバーは 1 つ以上のトピックにコンテンツ ベースのサブスクリプションを登録します。

多くのパブリッシュ・サブスクライブシステムでは、パブリッシャーは中間メッセージブローカーまたはイベントバスにメッセージを投稿し、サブスクライバーはそのブローカーにサブスクリプションを登録して、ブローカーがフィルタリングを実行できるようにします。ブローカーは通常、ストアアンドフォワード機能を実行して、パブリッシャーからサブスクライバーにメッセージをルーティングします。さらに、ブローカーはルーティング前にキュー内のメッセージを優先順位付けする場合があります。^{[引用が必要]}

サブスクライバーは、ビルド時、初期化時、または実行時に特定のメッセージを登録できます。GUI システムでは、サブスクライバーはユーザー コマンド (ボタンのクリックなど) を処理するようにコーディングできます。これはビルド時の登録に相当します。一部のフレームワークおよびソフトウェア製品では、サブスクライバーの登録にXML構成ファイルを使用します。これらの構成ファイルは初期化時に読み取られます。最も洗練された代替方法は、実行時にサブスクライバーを追加または削除できるようにすることです。この後者のアプローチは、たとえば、データベース トリガー、メーリング リスト、およびRSSで使用されます。^[要出典]

データ配信サービス( DDS) ミドルウェアは、中間にブローカーを使用しません。代わりに、pub/sub システム内の各パブリッシャーとサブスクライバーは、IP マルチキャストを介して互いのメタデータを共有します。パブリッシャーとサブスクライバーはこの情報をローカルにキャッシュし、共有認識内での互いの検出に基づいてメッセージをルーティングします。実際には、ブローカーレス アーキテクチャでは、パブリッシャーからサブスクライバーへの効率的な分散ルーティングを可能にするオーバーレイ ネットワークを構築するために、パブリッシュ/サブスクライブ システムが必要です。効率的な分散ルーティングには、ナビゲート可能なスモール ワールド トポロジが必要であることがJon Kleinbergによって示されました。このようなスモール ワールド トポロジは通常、分散型または連合型のパブリッシュ/サブスクライブ システムによって実装されます。^[2]ローカリティ認識パブリッシュ/サブスクライブ システム^[3]は、サブスクリプションを短距離で低コストのリンクを介してルーティングするスモール ワールド トポロジを構築し、サブスクリプションの配信時間を短縮します。

最も初期に公開されたパブリッシュ/サブシステムの 1 つは、Isis ツールキットの「ニュース」サブシステムであり、1987 年のAssociation for Computing Machinery (ACM) Symposium on Operating Systems Principles カンファレンス (SOSP '87) の論文「分散システムにおける仮想同期の活用. 123–138」で説明されました。^[4]

パブリッシャーはサブスクライバーと疎結合されており、その存在を知る必要さえありません。このトピックに焦点をあてることで、パブリッシャーとサブスクライバーはシステム トポロジーを認識しなくてもかまいません。それぞれが、他方から独立して通常どおり動作し続けることができます。従来の密結合クライアント サーバー パラダイムでは、サーバー プロセスが実行されていない間はクライアントはサーバーにメッセージを投稿できず、クライアントが実行されていない限りサーバーはメッセージを受信できません。多くの pub/sub システムでは、パブリッシャーとサブスクライバーの場所だけでなく、時間的にも分離されています。ミドルウェア アナリストがこのような pub/sub システムで使用する一般的な戦略は、パブリッシャーを停止してサブスクライバーがバックログを処理できるようにすることです (帯域幅スロットリングの形式)。

Pub/sub は、並列操作、メッセージ キャッシュ、ツリーベースまたはネットワークベースのルーティングなどを通じて、従来のクライアント サーバーよりも優れたスケーラビリティを実現します。ただし、特定の種類の密結合された大容量のエンタープライズ環境では、システムが拡張されて、何千ものサーバーが pub/sub インフラストラクチャを共有するデータ センターになると、現在のベンダー システムではこの利点が失われることがよくあります。このような状況で高負荷がかかった場合の pub/sub 製品のスケーラビリティは、研究課題となっています。

一方、エンタープライズ環境以外では、pub/sub パラダイムは、単一のデータセンターをはるかに超えるボリュームへのスケーラビリティが実証されており、RSSやAtomなどの Web シンジケーション プロトコルを通じてインターネット全体に分散されたメッセージングを提供します。これらのシンジケーション プロトコルは、低性能の Web サーバーでも (潜在的に) 数百万の個別のサブスクライバー ノードにメッセージをシンジケートできる機能と引き換えに、より高いレイテンシと配信保証の欠如を受け入れます。

• パブリッシュ/サブスクライバ システム内の冗長サブスクライバは、最小限の複雑さでメッセージの配信を保証するのに役立ちます。たとえば、工場では、機器が問題や障害をサブスクライバにパ​​ブリッシュし、サブスクライバがそれらの問題を表示して記録できるパブリッシュ/サブスクライバ システムを利用することができます。ロガーが故障 (クラッシュ) した場合、機器の問題パブリッシャーは必ずしもロガーの障害の通知を受け取るわけではなく、エラー メッセージはパブリッシュ/サブスクライバ システム上のどの機器でも表示または記録されません。クライアント/サーバー システムでは、エラー ロガーが故障すると、システムはエラー ロガー (サーバー) の障害の通知を受け取ります。ただし、クライアント/サーバー システムは、冗長ログ サーバーをオンラインにするか、フォールバック ログ サーバーを動的に生成して、その障害に対処する必要があります。これにより、クライアントとサーバーの設計だけでなく、クライアント/サーバー アーキテクチャ全体が複雑になります。パブリッシュ/サブスクライバ システムでは、既存のロガーとまったく同じ冗長ログ サブスクライバをシステムに追加して、システム上の他の機器に影響を与えることなく、ログの信頼性を高めることができます。機器の問題メッセージのロギングの基本機能を実装した後、確実なエラー メッセージのロギング機能を段階的に追加することもできます。

pub/sub システムの最も深刻な問題は、その主な利点であるパブリッシャーとサブスクライバーの分離によって生じる副作用です。

パブリッシュ/サブスクライブ システムは、確実な配信など、特定のアプリケーションに必要な強力なシステム プロパティを提供できるように慎重に設計する必要があります。

• パブリッシュ/サブスクライブ システムのブローカーは、指定された時間メッセージを配信するように設計されている場合がありますが、すべてのサブスクライバーからメッセージが正常に受信されたかどうかに関係なく、配信の試行を停止します。このように設計されたパブリッシュ/サブスクライブ システムでは、このような確実な配信を必要とする可能性のあるアプリケーションへのメッセージの配信を保証できません。このような確実な配信を実現するには、パブリッシャーとサブスクライバーのペアの設計をより緊密に結合して、パブリッシュ/サブスクライブ アーキテクチャの外部で強制する必要があります (たとえば、サブスクライバーに受信メッセージをパブリッシュするように要求するなど)。
• パブリッシャー/サブスクライブ システム内のパブリッシャーは、サブスクライバーが実際にはリッスンしていないにもかかわらず、リッスンしていると想定する場合があります。

パブリッシャー/サブスクライバー ノードの数が少なく、メッセージ量が少ない小規模ネットワークでは、pub/sub パターンは適切に拡張されます。ただし、ノードとメッセージの数が増えると、不安定になる可能性が高まり、pub/sub ネットワークの最大スケーラビリティが制限されます。大規模なスループットの不安定性の例には、次のものがあります。

• 負荷の急増 - 加入者のリクエストがネットワーク スループットを飽和させ、その後にメッセージ量が少ない期間が続く (ネットワーク帯域幅が十分に活用されていない)
• 速度低下 - システムを使用するアプリケーションが増えると（別々のpub/subチャネルで通信している場合でも）、個々のサブスクライバーへのメッセージ量の流れが遅くなります。

ブローカー (サーバー) を使用する pub/sub システムの場合、ブローカーがサブスクライバーにメッセージを送信する引数はインバンドであり、セキュリティ上の問題が発生する可能性があります。ブローカーは、間違ったクライアントに通知を送信するように騙され、クライアントに対するサービス拒否要求を増幅する可能性があります。ブローカー自体は、作成されたサブスクリプションを追跡するためにリソースを割り当てるため、過負荷になる可能性があります。

ブローカーに依存しないシステムでも、サブスクライバーは受信を許可されていないデータを受信できる可能性があります。許可されていないパブリッシャーは、pub/sub システムに誤ったメッセージや有害なメッセージを送り込む可能性があります。これは、メッセージを ブロードキャストまたはマルチキャストするシステムに特に当てはまります。暗号化(例: Transport Layer Security (SSL/TLS)) は、許可されていないアクセスを防ぐことができますが、許可されたパブリッシャーによって有害なメッセージが送り込まれるのを防ぐことはできません。クライアント/サーバー システムなど、pub/sub 以外のアーキテクチャも、悪意のある動作をする許可されたメッセージ送信者に対して脆弱です。

• Atom、もう一つの非常にスケーラブルなウェブシンジケーションプロトコル
• データ配信サービス(DDS)
• イベント駆動型プログラミング
• 高レベルアーキテクチャ
• インターネット グループ管理プロトコル(IGMP)
• メッセージブローカー
• メッセージキュー
• オブザーバーパターン
• 生産者と消費者の問題
• プッシュテクノロジー^[2]
• RSS、非常にスケーラブルなウェブ配信プロトコル
• ユーズネット
• WebSub、pub/subの実装