Pub/Subメッセージングの徹底解説：仕組み、利用方法、国内外の事例

2025 5/04

2025年5月4日 2025年5月4日

はじめに

近年、クラウドコンピューティングの普及とマイクロサービスアーキテクチャの採用が進む中で、アプリケーションの規模と複雑性は増大の一途を辿っています。このような状況下において、システム内の異なるコンポーネント間での効率的かつ柔軟な通信を実現する非同期通信モデルであるPublish/Subscribe（Pub/Sub）メッセージングの重要性が高まっています。Pub/Subメッセージングは、メッセージの送信者（パブリッシャー）と受信者（サブスクライバー）を直接的に結びつけることなく、両者を分離することで、疎結合なシステム構築を容易にします ¹。この特性により、システムの拡張性、耐障害性、および開発の独立性を向上させることが可能となります。

本稿では、Pub/Subメッセージングの基本的な概念から、その仕組み、具体的な利用方法、国内外の活用事例、そしてメリットとデメリットについて詳細に解説します。読者がPub/Subメッセージングを深く理解し、自身のシステム設計や開発に役立てることを目的とします。

Pub/Subとは

基本的な概念と定義

Pub/Subメッセージングは、メッセージの送信側であるパブリッシャーと受信側であるサブスクライバーを分離するメッセージングサービスです ⁴。このモデルでは、パブリッシャーは特定の受信者を意識することなくメッセージを送信し、サブスクライバーは関心のあるトピックを購読することで、必要な情報を受け取ります ²。AWS（Amazon Web Services）は、Pub/Subメッセージングを、開発者が高度に機能的でアーキテクチャ的に複雑なクラウドアプリケーションを容易に構築できる非同期通信モデルと定義しています ¹。通常、レイテンシは100ミリ秒程度とされています ⁷。

Pub/Subシステムにおける主要な構成要素には、メッセージを生成・送信するパブリッシャー（プロデューサー）、メッセージを受信するサブスクライバー（コンシューマー）、メッセージが送信される名前付きチャネルであるトピック、サブスクライバーが関心を示す特定のトピックへの登録であるサブスクリプション、そしてシステム内を流れるデータであるメッセージが含まれます ⁴。メッセージブローカーは、パブリッシャーとサブスクライバーの間でメッセージをルーティングする仲介役として機能します ⁸。IBMも、Pub/Subをサブスクライバーがパブリッシャーからメッセージの形で情報を受け取るためのメカニズムであり、パブリッシャーとサブスクライバー間のやり取りはキュー・マネージャーによって制御されると説明しています ⁶。また、MQTT（Message Queuing Telemetry Transport）の文脈では、Pub/Subパターンは、メッセージを送信するクライアントと受信するクライアントを、直接接続したり互いの存在を知らなくても通信できるように分離するメッセージングパターンとされています ¹⁰。

非同期通信モデルとしての特徴

Pub/Subメッセージングの大きな特徴は、その非同期性です。パブリッシャーは、イベントがいつ、どのように処理されるかを気にすることなく、Pub/Subサービスにイベントを送信します ⁷。サブスクライバーは、特定のトピックに関心があることを登録し、そのトピックに関連するメッセージを受信します ²。このパブリッシャーとサブスクライバー間のやり取りは一対多の関係であり、パブリッシャーは誰が情報を使用しているかを知る必要がなく、サブスクライバーもメッセージの送信元を知る必要はありません ²。これは、送信側が受信側からの直接的な応答を待つ同期的なリモートプロシージャコール（RPC）とは対照的です ⁷。

メッセージキューとの違い

Pub/Subは、Apache KafkaやPulsarのような水平スケーラビリティを持つメッセージングシステムと、Apache ActiveMQやRabbitMQのようなメッセージングミドルウェアの機能を組み合わせたものです ⁷。従来のメッセージキューイングとは異なり、Pub/Subでは、同じメッセージが、あるトピックに関心を持つ複数のサブスクライバーに配信されます（ファンアウト） ⁸。一方、メッセージキューは通常、キュー内のメッセージを一つのコンシューマーにのみ配信します。Pub/Subとメッセージキューはどちらも非同期通信を扱いますが、Pub/Subはイベントのブロードキャストに重点を置いており、メッセージキューは多くの場合、作業の分散やメッセージの確実な処理のために使用されます。しかし、現代のPub/Subシステムでは、従来のメッセージキューに見られる機能も取り込まれる傾向があります。

Pub/Subの仕組み

主要な構成要素

Pub/Subサービスは、いくつかの主要な構成要素によって成り立っています。

パブリッシャー (Publisher): メッセージを作成し、指定されたトピックに対してメッセージングサービスに送信（パブリッシュ）するエンティティです ⁴。パブリッシャーは、メッセージの内容に基づいてトピックを分類します ⁸。
メッセージ (Message): サービスを通じて移動するデータです ⁴。メッセージには、テキスト、JSONオブジェクト、バイナリデータなど、さまざまなデータ型を含めることができ、タイムスタンプやトピック情報などのメタデータが含まれることもあります ⁸。
トピック (Topic): メッセージのフィードを表す名前付きエンティティです ⁴。パブリッシャーは、特定のトピックにメッセージを送信します ⁴。トピックは、送信者と受信者の間の中間チャネルとして機能し、関心のあるサブスクライバーのリストを保持します ²。
スキーマ (Schema): Pub/Subメッセージのデータ形式を規定する名前付きエンティティです ⁴。スキーマを使用することで、データの一貫性が保たれ、データの検証が容易になります。
サブスクリプション (Subscription): 特定のトピックに関するメッセージの受信に関心があることを表す名前付きエンティティです ⁴。サブスクライバーは、メッセージを受信したいトピックに対してサブスクリプションを作成します ⁴。一つのトピックに複数のサブスクリプションをアタッチすることができます ⁴。
サブスクライバー (Subscriber): 指定されたサブスクリプションに関するメッセージを受信するエンティティです ⁴。サブスクライバーは、関心のあるトピックに対して関心を表明することで、関連するメッセージを受信します ⁸。サブスクライバーは、異なる機能を実行したり、メッセージを並行して処理したりすることができます ²。
メッセージブローカー (Message Broker): Pub/Subシステムの中央コンポーネントであり、パブリッシャーとサブスクライバーの間で仲介役として機能します ⁸。ブローカーは、関心のあるすべてのサブスクライバーにメッセージをルーティングし、メッセージのキューイング、フィルタリング、ルーティングなどのタスクを処理します ⁸。

これらの構成要素が連携することで、疎結合かつ非同期な情報の交換が可能になります。パブリッシャーはデータ（メッセージ）を作成し、それを分類（トピック）してブローカーに送信します。サブスクライバーは関心（サブスクリプション）を表明し、ブローカーによってルーティングされたデータ（メッセージ）を受け取ります。スキーマはデータの整合性を保証します。

情報の流れ

Pub/Subにおける情報の流れは、以下の手順で進行します。

パブリッシャーアプリケーションが、指定されたPub/Subトピックにメッセージを送信します ⁴。通常、メッセージは暗号化され、パブリッシングフォワーダーに送信されます ¹³。
メッセージはストレージに書き込まれます ⁴。これにより、メッセージの永続性が確保されます。
メッセージがストレージに書き込まれると同時に、またはその直後に、Pub/Subはそのメッセージを、そのトピックにアタッチされているすべてのサブスクリプションに配信します ⁴。ブローカーがメッセージをルーティングします。
サブスクリプションは、そのメッセージをアタッチされているサブスクライバーアプリケーションに送信します ⁴。メッセージはコンシューマーに到達します。
サブスクライバーは、メッセージを正常に処理した後、Pub/Subに確認応答（Acknowledgement）を送信します ⁴。これにより、メッセージが正常に消費されたことが確認されます。
少なくとも1つのサブスクライバーが各サブスクリプションに対してメッセージを確認応答すると、Pub/Subはそのメッセージをストレージから削除します ⁴。これにより、ストレージが管理され、メッセージが無期限に保持されるのを防ぎます。

全体として、メッセージは以下のステップを経ます。パブリッシャーがメッセージを送信し、メッセージがストレージに書き込まれ、Pub/Subはメッセージを受信したことと、アタッチされたすべてのサブスクリプションへの配信を保証する確認応答をパブリッシャーに送信します。ストレージへの書き込みと同時に、Pub/Subはメッセージをサブスクライバーに配信し、サブスクライバーはメッセージを処理したことをPub/Subに確認応答します。すべてのサブスクリプションに対して少なくとも1つのサブスクライバーがメッセージを確認応答すると、Pub/Subはそのメッセージをストレージから削除します ¹³。この一連の流れは、メッセージの配信と管理における信頼性を保証します。

Pub/Subのアーキテクチャ

Pub/Subのアーキテクチャは、高信頼性と非同期メッセージングのスケーラビリティを実現するように設計されています。Google CloudのPub/Subサーバーは、世界中のすべてのGoogle Cloudリージョンで稼働しており、高速なグローバルデータアクセスを提供すると同時に、ユーザーがメッセージの保存場所を制御できるようにしています ¹³。

Pub/Subは、主にデータプレーン（パブリッシャーとサブスクライバー間のメッセージ移動を処理）とコントロールプレーン（パブリッシャーとサブスクライバーのサーバーへの割り当てを処理）の2つの主要部分に分かれています ¹³。データプレーンのサーバーはフォワーダーと呼ばれ、コントロールプレーンのサーバーはルーターと呼ばれます ¹³。この関心の分離は、スケーラビリティと管理性を高める上で重要です。

Pub/Subのアーキテクチャは、スケーラビリティ（さまざまな側面での負荷増加への対応）、可用性（障害の優雅な処理）、および低レイテンシ（メッセージの確認応答と配信時間の最小化）という3つの主要なパフォーマンス面に重点を置いています ¹³。水平スケーリング（サーバーインスタンスの追加による容量増加）を使用しています ¹³。分散アーキテクチャとコントロールプレーンとデータプレーンの分離、そしてスケーラビリティ、可用性、低レイテンシへの注力により、Pub/Subはグローバルなリーチを持つ要求の厳しいリアルタイムアプリケーションに適しています。

Pub/Subの利用方法

基本的な利用パターン

Pub/Subは、多様なアプリケーション要件に適応できる、いくつかの基本的な利用パターンをサポートしています。

ファンアウト (One-to-many): 単一のパブリッシャーがトピックにメッセージを送信し、複数のサブスクライバーがそれを受信します ⁴。これは、複数の関心のある関係者にイベントをブロードキャストするのに役立ちます。
ファンイン (Many-to-one): 複数のパブリッシャーが単一のトピックにメッセージを送信し、単一のサブスクライバーがそれらすべてを受信します ⁴。これは、さまざまなソースからのデータを集約するために使用できます。
多対多 (Many-to-many): 複数のパブリッシャーがトピックにメッセージを送信し、複数のサブスクライバーがそれらを受信します ⁴。このパターンは、多くのサービスがイベントを生成および消費する複雑な分散システムで一般的です。

Pub/Subがサポートする多様な通信パターン（ファンアウト、ファンイン、多対多）により、イベントのブロードキャストからデータの集約まで、さまざまなアプリケーション要件に適応できます。

メッセージ配信モデル

Pub/Subシステムは、メッセージをサブスクライバーに配信するために、主に2つのモデルを提供しています。

プッシュ配信 (Push Delivery): メッセージがトピックにパブリッシュされると、メッセージブローカーは関心のあるすべてのサブスクライバーに積極的にメッセージをプッシュします ⁸。これにより、リアルタイム配信が保証され、レイテンシが低減されます。サブスクライバーは、ブローカーがメッセージを送信するためのWebhookエンドポイントを提供する必要があります ⁷。
プル配信 (Pull Delivery): サブスクライバーは、メッセージを処理する準備ができたときに、メッセージブローカーから明示的にメッセージをプルします ⁸。これにより、サブスクライバーはメッセージの消費速度をより細かく制御できます。Google CloudのPub/Subは、プルモードで個々のメッセージをサブスクライバークライアントに「リース」します ⁷。

プッシュ配信とプル配信のどちらを選択するかは、リアルタイムアップデートの必要性、サブスクライバーが受信メッセージを処理する能力、およびエンドポイントの公開に関連するセキュリティ上の考慮事項などの要因によって異なります。プッシュ配信は即時通知に最適ですが、サブスクライバーはそれらを受信する準備ができている必要があります。プル配信は、サブスクライバーがいつ、いくつメッセージを消費するかをより細かく制御できるため、ワークロードの管理やサブスクライバーへの過負荷を防ぐのに役立ちます。

メッセージフィルタリング

一部のPub/Subシステムでは、サブスクライバーは特定の条件を満たすメッセージのみを受信するようにフィルタを指定できます ⁷。これにより、不要なメッセージ処理が減少し、効率が向上します。Google Cloud Pub/Subは、メッセージ属性に基づいたフィルタリングをサポートしています ¹⁶。メッセージフィルタリングにより、サブスクライバーは自分に関連する情報のみに集中できるため、システムのパフォーマンスが向上し、ノイズが低減されます。

メッセージの順序保証

一部のアプリケーションでは、メッセージの順序を維持することが重要です ¹⁷。Pub/Subシステムは、多くの場合メッセージに関連付けられた順序キーに基づいて、順序付けられた配信を保証する機能を提供することがあります ¹⁷。メッセージの順序付けを有効にすると、パブリッシュの可用性が低下し、レイテンシが増加する可能性があります ¹⁸。分散Pub/Subシステムでメッセージの順序付けを実現するには、パフォーマンスと可用性との間でトレードオフが生じることがよくあります。一部のプラットフォームでは、キーまたは特定の構成に基づいて順序付けの保証を提供していますが、レイテンシやシステムの複雑さへの影響を考慮することが重要です。

メッセージの永続化と保持

Pub/Subシステムは通常、耐久性を確保し、データ損失を防ぐためにメッセージを永続化します ¹³。メッセージが保持される期間は、一部のシステムで構成できます ¹⁴。Google Pub/Subは、メッセージがパブリッシャーによって送信されてから限られた期間（例：7日間）のみを保存します ¹⁴。メッセージの永続性は信頼性にとって非常に重要であり、特にサブスクライバーが一時的にオフラインになったり、障害が発生したりする可能性のあるシナリオで重要です。メッセージを正常に処理されるまで保存することで、システムはサブスクライバーまたはネットワーク接続における一時的な問題によってデータが失われることを防ぎます。

Pub/Subの国内外の事例

国内事例

日本の企業においても、Pub/Subメッセージングは様々な分野で活用されています。

セブン-イレブン・ジャパン: Google Cloud Pub/Subを使用してPOSデータをリアルタイムに取り込み、Cloud SpannerとBigQueryで利用しています ¹⁹。これにより、IT戦略のためのリアルタイムなデータ活用を実現しています。
株式会社フリークアウト: オンライン広告のリアルタイム入札（RTB）プラットフォームの一部として、Google Cloud Pub/Subを利用しています ²⁰。Kubernetes EngineやBigQueryなどの他のGCPサービスと組み合わせて使用されています。
株式会社リクルートライフスタイル: 『じゃらんnet』や『ホットペッパービューティー』などのサービスにおけるリアルタイムログ分析基盤の一部として、Google Cloud Pub/SubをBigQueryやBigtableと連携して活用しています ²¹。

表1: 国内の利用事例

企業名	業界	利用目的	主な効果	使用しているPub/Subサービス
セブン-イレブン・ジャパン	小売業	POSデータのリアルタイム収集と活用	商品購入から数分でデータ集約、データ活用環境の構築	Google Cloud Pub/Sub
株式会社フリークアウト	広告配信	リアルタイム入札（RTB）プラットフォームの一部として利用	広告配信の高速化と効率化	Google Cloud Pub/Sub
株式会社リクルートライフスタイル	情報サービス	『じゃらんnet』や『ホットペッパービューティー』などのログのリアルタイム分析基盤の一部として利用	大量のログデータを低コストかつ高速に分析	Google Cloud Pub/Sub

これらの国内事例は、小売、広告技術、情報サービスといった需要の高い業界において、リアルタイムデータ処理のためにGoogle Cloud Pub/Subが活用されていることを示しています。その効果として、データの迅速な利用可能性、効率の向上、そして大量のデータを処理する能力が挙げられます。

海外事例

海外においても、Pub/Subメッセージングは広範な分野で利用されています。

PedidosYa (南米): Pub/SubとBigQueryを使用して、クエリあたりのコストを5分の1に削減しています ²²。また、リアルタイムのフライト追跡を含むクリエイティブなワールドカップキャンペーンにもPub/Subを活用しました ²⁵。
Delivery Hero (グローバル): 大規模な食品デリバリープラットフォームであり、毎日数百万件の注文を処理しています ²⁸。一部のスニペットではAWSのSNSやSQSの利用が言及されていますが ³⁰、動画の事例研究ではGoogle Cloudサービスの利用が示唆されており、Pub/Subがデータ処理やリアルタイムオペレーションのインフラストラクチャの一部である可能性があります ²²。Google Cloud上でデータメッシュアプローチを採用し、データをグローバルかつ普遍的にアクセス可能にすることを目指しています ²⁸。
Wunderkind (AI駆動型マーケティング): 小売業者やメディア顧客のスケーリングを支援するためにPub/Subを使用しています ²²。パーソナライズされたメッセージングのために、大量のデータをリアルタイムで処理しています ³¹。イベントバスとしてRedpandaを活用し、ピーク時には毎秒20万〜25万件のメッセージを処理し、1日に数十億件のメッセージを処理しています。また、Kafkaを介したリアルタイムデータ分析のためにDeephavenを使用しています ³¹。Split（Wunderkindに買収された）は、AblyのPub/Sub機能を使用して、数千万のクライアントアプリケーションにフィーチャーフラグイベントを配信しています ³²。

表2: 海外の利用事例

企業名	業界	利用目的	主な効果	使用しているPub/Subサービス
PedidosYa	食品デリバリー	注文処理、データ分析基盤	クエリあたりのコスト削減、プラットフォームの可用性を保証、運用保守作業の軽減、ユーザーエクスペリエンスの向上	Google Cloud Pub/Sub
Delivery Hero	食品デリバリー	注文処理、データ統合	大量の注文と請求書処理のスケーラビリティを確保	AWS SNS/SQS, Google Cloud Pub/Sub (言及あり)
Wunderkind	マーケティング	大量のマーケティングデータのリアルタイム処理、パーソナライズされたメッセージング、機能フラグの配信	小売業者とメディア顧客のスケーリングを支援、リアルタイムデータ分析	Ably, Redpanda (Kafka)

これらの海外事例は、食品デリバリーやマーケティングといった顧客向けのアプリケーションにおいて、Pub/Subが非常に大量のデータをリアルタイムで処理するために使用されていることを示しています。スケーラビリティ、コスト効率、そしてタイムリーなデータ処理によるユーザーエクスペリエンスの向上が重視されています。

国内外の事例比較

国内外の事例を比較すると、どちらのケースでもクラウドベースのPub/Subサービス、特にGoogle Cloud Pub/SubとAWS SNS/SQSが広く利用されていることがわかります。主な利用目的は、分析のためのリアルタイムデータ処理、アプリケーション統合、および様々なオンラインサービスにおけるユーザーエクスペリエンスの向上です。海外の事例、特にDelivery HeroやWunderkindでは、1日に数百万、あるいは数十億ものメッセージを処理するなど、運用規模が非常に大きいことが特徴的です。リアルタイムデータ処理のためのPub/Subの採用は、様々な業界におけるグローバルなトレンドであり、国内外の企業がそのスケーラビリティと効率性を活用してアプリケーションを構築しています。

Pub/Subのメリットとデメリット

メリット

Pub/Subメッセージングには、以下のような多くのメリットがあります。

疎結合性 (Decoupling): パブリッシャーはサブスクライバーに関する情報を一切知る必要がありません ³³。パブリッシャーはサブスクライバーのリストを管理する必要がなく ²、サブスクライバーもメッセージの送信元を知る必要がありません ²。これにより、通信と統合が簡素化されます ³。
スケーラビリティ (Scalability): パブリッシャーとサブスクライバーは互いに影響を与えることなく追加または削除できるため、システムはより簡単にスケールできます ⁸。メッセージブローカーは、複数のノード間で負荷を分散できます ⁸。クラウドプロバイダーは、大量のトラフィックに対応するためにインフラストラクチャを管理します ³⁴。
信頼性と可用性 (Reliability and Availability): Apache Kafkaのクラスターモデルは、設計に信頼性と可用性を組み込んでいます ¹⁷。クラウドベースのシステムは、クロスゾーンレプリケーションなどの機能を通じて高可用性を提供します ¹²。
柔軟性 (Flexibility): パブリッシュ-サブスクライブ（Pub/Sub）パターンは、より柔軟に対応できます ²。パブリッシャーとサブスクライバーは、独立して追加または変更できます ²。
リアルタイム性 (Real-time): メッセージがトピックにパブリッシュされると、Pub/Subメッセージングは非同期イベント通知を即座にプッシュします ²。リアルタイムPub/Subサービスは、頻繁なポーリングなしでメッセージの送受信を容易にします ¹²。
開発の迅速化 (Faster Application Development): メッセージングAPIを使用すると、開発者はイベントの発行と受信の方法を簡単に理解してテストできます ¹⁷。
ポーリングの排除 (Eliminates Polling): メッセージトピックを使用すると、プッシュベースの即時配信が可能になり、メッセージコンシューマーは新しい情報や更新を定期的にチェック（またはポーリング）する必要がなくなります ³。

デメリット

一方で、Pub/Subメッセージングには以下のようなデメリットも存在します。

メッセージの順序保証 (Message Ordering Challenges): Pub/Subシステムでは、メッセージの順序が保証されない場合があります ¹⁸。特に複数のパブリッシャーが存在する場合、順序を維持することは困難です ⁴⁰。
メッセージの配信保証 (Delivery Guarantees): データが確実に届いたかどうかを判断できないため、メッセージが欠落する可能性があります ¹³。Exactly-once配信を実現することは難しい場合があります ⁴¹。
監視とトラブルシューティング (Monitoring and Troubleshooting): 誰が受信しているかを知ることができません ⁴⁰。メッセージの流れを追跡することは困難な場合があります ⁴⁰。APIタイムアウトエラーが発生する可能性があります ³⁸。
設定の複雑さ (Configuration Complexity): 大規模なPub/Subシステムでは、パフォーマンスの最適化が課題となる場合があります ³⁴。自己ホスト型のオプションはカスタマイズ性を提供しますが、より多くの管理が必要です ¹²。

どのような状況でPub/Subが有効なのか

Pub/Subメッセージングは、特に以下のような状況で有効な選択肢となります。

イベント駆動型アーキテクチャ (Event-Driven Architecture): アプリケーションの異なるコンポーネントが、他のコンポーネントによって行われたアクションに疎結合な方法で反応する必要がある場合 ¹²。
マイクロサービス間の通信 (Microservices Communication): アプリケーションの異なるコンポーネントが、疎結合な方法で通信し、スケーラビリティと柔軟性を高めることができる分散システムおよびマイクロサービスアーキテクチャを構築する場合 ⁷。
リアルタイムデータ処理 (Real-time Data Processing): ソーシャルメディアプラットフォーム、インスタントメッセージングアプリ、共同作業環境など、リアルタイムのメッセージングおよびチャットアプリケーションを作成する場合 ⁷。
IoT (Internet of Things): IoTデバイスをクラウドに接続し、中央のブローカーと通信してデータを送受信できるようにする場合 ³。
ログ集約と分析 (Log Aggregation and Analysis): Pub/Subパターンを使用すると、ログを複数の購読された宛先に同時に送信できます ¹²。
キャッシュの更新 (Cache Invalidation): バックエンドデータソースのデータが更新されたときに、Pub/Subトピックにメッセージがパブリッシュされ、これにより、キャッシュのすべてのインスタンスが更新される場合 ⁷。

まとめ

Pub/Subメッセージングは、現代のスケーラブルなクラウドアプリケーションにとって不可欠なメッセージングパターンです。サービスの疎結合化と非同期通信の促進能力により、イベント駆動型アーキテクチャの構築とリアルタイムデータストリームの処理に不可欠となっています。様々な業界での採用が増加していることは、その重要性が今後も続くことを示唆しています。

読者の皆様は、高いスケーラビリティ、耐障害性、およびリアルタイムデータ処理を必要とする分散システムを設計する際に、Pub/Subの利用を検討すべきです。ただし、メッセージの順序保証と配信保証に関連するトレードオフを慎重に評価し、選択した実装が特定のアプリケーションニーズを満たすことを確認してください。

引用文献

aws.amazon.com, 4月 5, 2025にアクセス、 https://aws.amazon.com/what-is/pub-sub-messaging/#:~:text=Publish%2Dsubscribe%20messaging%2C%20or%20pub,complex%20applications%20in%20the%20cloud.
What is Pub/Sub Messaging? – AWS, 4月 5, 2025にアクセス、 https://aws.amazon.com/what-is/pub-sub-messaging/
Pub/Sub メッセージングとは何ですか? – AWS, 4月 5, 2025にアクセス、 https://aws.amazon.com/jp/what-is/pub-sub-messaging/
Overview of the Pub/Sub service | Pub/Sub Documentation | Google …, 4月 5, 2025にアクセス、 https://cloud.google.com/pubsub/docs/pubsub-basics
Pub/Sub サービスの概要 – Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/pubsub/docs/pubsub-basics?hl=ja
パブリッシュ/サブスクライブの概要 – IBM, 4月 5, 2025にアクセス、 https://www.ibm.com/docs/ja/integration-bus/10.0?topic=applications-publishsubscribe-overview
What is Pub/Sub? – Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/pubsub/docs/overview
What is pub sub messaging? How does it work? – CometChat, 4月 5, 2025にアクセス、 https://www.cometchat.com/blog/pub-sub-messaging
Publish-subscribe pattern – AWS Prescriptive Guidance, 4月 5, 2025にアクセス、 https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/publish-subscribe.html
MQTT パブリッシュ/サブスクライブパターンの概要 – Qiita, 4月 5, 2025にアクセス、 https://qiita.com/emqx_japan/items/0998f79c1fc03b53adca
www.ibm.com, 4月 5, 2025にアクセス、 https://www.ibm.com/docs/ja/ibm-mq/9.2?topic=messaging-publishsubscribe-components#:~:text=%E3%83%91%E3%83%96%E3%83%AA%E3%83%83%E3%82%B7%E3%83%A5%2F%E3%82%B5%E3%83%96%E3%82%B9%E3%82%AF%E3%83%A9%E3%82%A4%E3%83%96%E3%81%AF%E3%80%81%E3%82%B5%E3%83%96,%E3%83%9E%E3%83%8D%E3%83%BC%E3%82%B8%E3%83%A3%E3%83%BC%E3%81%AB%E3%82%88%E3%81%A3%E3%81%A6%E5%88%B6%E5%BE%A1%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82
Pub/Sub (Publish/Subscribe) – Redis, 4月 5, 2025にアクセス、 https://redis.io/glossary/pub-sub/
Architectural overview of Pub/Sub – Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/pubsub/architecture
Guide To Google PubSub: Examples & Comparison – Macrometa, 4月 5, 2025にアクセス、 https://www.macrometa.com/event-stream-processing/google-pubsub
Amazon SNS FIFO のご紹介 – 先入れ先出しでの Pub/Sub メッセージング – AWS, 4月 5, 2025にアクセス、 https://aws.amazon.com/jp/blogs/news/introducing-amazon-sns-fifo-first-in-first-out-pub-sub-messaging/
Pub/Sub for Application & Data Integration | Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/pubsub
Publish-Subscribe – Intro to Pub-Sub Messaging | Confluent, 4月 5, 2025にアクセス、 https://www.confluent.io/learn/publish-subscribe/
Order messages | Pub/Sub Documentation – Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/pubsub/docs/ordering
株式会社セブン‐イレブン・ジャパンの導入事例 | Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/customers/sej/?hl=ja
株式会社フリークアウトの導入事例：フルマネージドな Kubernetes …, 4月 5, 2025にアクセス、 https://cloud.google.com/blog/ja/topics/customers/freakout-kubernetes-engine
株式会社リクルート … – Google Cloud Platform Japan 公式ブログ, 4月 5, 2025にアクセス、 https://cloudplatform-jp.googleblog.com/2016/02/google-cloud-bigtable-google-10-1.html
メディア: 記事、動画、ポッドキャスト | Pub/Sub Documentation …, 4月 5, 2025にアクセス、 https://cloud.google.com/pubsub/docs/media?hl=ja
媒体：文章、视频、播客| Pub/Sub Documentation – Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/pubsub/docs/media?hl=zh-cn
PedidosYa Case Study | Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/customers/pedidosya
[Case Study] Pedidosya’s Worldcup Campaign – Content Shifu | Digital Marketing & MarTech Resources for Your Business in Southeast Asia, 4月 5, 2025にアクセス、 https://contentshifu.com/en/blog/pedidosya-case-study/
PedidosYa – World Cup Delivery (case study) – YouTube, 4月 5, 2025にアクセス、 https://www.youtube.com/watch?v=WoGh0-RlrI8&pp=0gcJCfcAhR29_xXO
PedidosYa: World Cup Delivery (case study) • Ads of the World™ | Part of The Clio Network, 4月 5, 2025にアクセス、 https://www.adsoftheworld.com/campaigns/world-cup-delivery-case-study
Delivery Hero Case Study | Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/customers/delivery-hero
Delivery Hero Case Study – AWS – Amazon.com, 4月 5, 2025にアクセス、 https://aws.amazon.com/solutions/case-studies/delivery-hero-case-study/
Delivery Hero on AWS: Case Studies, Videos, Innovator Stories, 4月 5, 2025にアクセス、 https://aws.amazon.com/solutions/case-studies/innovators/delivery-hero/
Wunderkind case study – Deephaven, 4月 5, 2025にアクセス、 https://deephaven.io/landing-page/wunderkind-case-study/
Pub/Sub use cases: When to use the Pub/Sub pattern – Ably, 4月 5, 2025にアクセス、 https://ably.com/blog/pub-sub-pattern-examples
GCPのメッセージングサービス『Pub/Sub』をやさしく、完全に理解する – Zenn, 4月 5, 2025にアクセス、 https://zenn.dev/moepyxxx/articles/67dd2f59538b20
Pub/Subモデルとは？初心者にもわかる仕組みと実践的な活用法, 4月 5, 2025にアクセス、 https://www.resumy.ai/tech-posts/94ea8448-1617-4039-93eb-69a5c3f9bb14
Google のメッセージングサービス Cloud Pub/Sub とは？特徴やユースケース、料金体系まで徹底解説！ – トップゲート, 4月 5, 2025にアクセス、 https://www.topgate.co.jp/blog/google-service/22226
【図解付き】Cloud Pub/Subに概要や使い方についてわかりやすく解説 – KIYONO Engineer Blog, 4月 5, 2025にアクセス、 https://laboratory.kiyono-co.jp/69/gcp/
セールスフォース Pub/Sub API: リアルタイムデータ統合の新時代 …, 4月 5, 2025にアクセス、 https://note.com/furucrm/n/n47d8e2003a1e
Understanding GCP Pub/Sub: Key Challenges in Production Environments – Medium, 4月 5, 2025にアクセス、 https://medium.com/@hitesh.agarwal_96383/understanding-gcp-pub-sub-key-challenges-in-production-environments-c7b2c21e04f6
Google Pub/Sub: Common Subscriber Problems and Fixes – RisingWave, 4月 5, 2025にアクセス、 https://risingwave.com/blog/google-pub-sub-common-subscriber-problems-and-fixes/
技術レポート「OPC UAのPub/Sub通信」｜ソフテックだより｜株式 …, 4月 5, 2025にアクセス、 https://www.softech.co.jp/mm_250205_tr.htm
Realtime reliability: How to ensure exactly-once delivery in pub/sub systems – Ably, 4月 5, 2025にアクセス、 https://ably.com/topic/pub-sub-exactly-once
Exactly-once delivery | Pub/Sub Documentation – Google Cloud, 4月 5, 2025にアクセス、 https://cloud.google.com/pubsub/docs/exactly-once-delivery
Delivery guarantees with pub/sub: What they are and why you need them – Ably, 4月 5, 2025にアクセス、 https://ably.com/topic/pubsub-delivery-guarantees
Delivery guarantee for local messages in distributed pub sub – Akka Cluster, 4月 5, 2025にアクセス、 https://discuss.lightbend.com/t/delivery-guarantee-for-local-messages-in-distributed-pub-sub/10640
【徹底解説】Amazon EventBridgeとは？ | SunnyCloud, 4月 5, 2025にアクセス、 https://www.sunnycloud.jp/column/20210802-01-2/
イベントドリブンアーキテクチャのスタイル – Azure Architecture Center | Microsoft Learn, 4月 5, 2025にアクセス、 https://learn.microsoft.com/ja-jp/azure/architecture/guide/architecture-styles/event-driven
[レポート] SNSとSQSとLambdaによるスケーラブルでサーバーレスなイベント駆動アーキテクチャ #reinvent #svs303 | DevelopersIO, 4月 5, 2025にアクセス、 https://dev.classmethod.jp/articles/reinvent2020-svs303-scalable-serverless-event-driven-architectures-with-sns-sqs-lambda/
オライリー「大規模データ管理」を読んでみた-第5章イベントとレスポンスの管理：ストリーミングアーキテクチャ #OREILLY – Qiita, 4月 5, 2025にアクセス、 https://qiita.com/zumax/items/6439b9af6cc2b2597c58
[イベント駆動型アーキテクチャ] Salesforce の提供するイベント機能｜しょっさん – note, 4月 5, 2025にアクセス、 https://note.com/sho7650/n/n6ecc7e88f68c
Most Common RabbitMQ Use Cases – ScaleGrid, 4月 5, 2025にアクセス、 https://scalegrid.io/blog/rabbitmq-use-cases/
Case studies – Apache Pulsar, 4月 5, 2025にアクセス、 https://pulsar.apache.org/case-studies/
Pub/Sub highlights of 2024 | Google Cloud Blog, 4月 5, 2025にアクセス、 https://cloud.google.com/blog/products/data-analytics/pubsub-highlights-of-2024
PubSub+ Event Broker: Software | Solace, 4月 5, 2025にアクセス、 https://solace.com/jp/products/event-broker/software/
DBMotoユーザ事例：ASL Modena | データベースアクセス, 4月 5, 2025にアクセス、 https://www.climb.co.jp/blog_dbmoto/archives/34
Google Cloud Ready – BigQuery パートナー, 4月 5, 2025にアクセス、 https://cloud.google.com/bigquery/docs/bigquery-ready-partners?hl=ja
NTT技術ジャーナル, 4月 5, 2025にアクセス、 https://journal.ntt.co.jp/wp-content/uploads/2020/11/JN202011all.pdf