Pub/Sub とは

Pub/Sub を使用すると、サービスが数百ミリ秒のレイテンシで非同期に通信できます。

Pub/Sub は、ストリーミング分析やデータ統合パイプラインでデータの取り込みと配信に使用されます。サービス統合向けのメッセージング指向のミドルウェアや、タスクを並列化するキューとしても効果があります。

Pub/Sub を使用すると、イベント プロデューサーのシステムとコンシューマーのシステム(パブリッシャーとサブスクライバー)を作成できます。パブリッシャーは、同期リモート プロシージャ コール(RPC)ではなく、イベントをブロードキャストして、サブスクライバーと非同期に通信します。

パブリッシャーは、イベントの処理方法やタイミングに関係なく、イベントを Pub/Sub サービスに送信します。次に、Pub/Sub は、それらに応答する必要があるすべてのサービスにイベントを配信します。サブスクライバーがデータを受信するまで、パブリッシャーが RPC を介して待機する必要があるシステムと比較すると、非同期の統合により、システム全体の柔軟性と堅牢性が向上します。

Pub/Sub の使用を開始するには、Cloud Console を使用したクイックスタートをご覧ください。より包括的な概要については、Pub/Sub メッセージング システムの構築をご覧ください。

一般的なユースケース

  • ユーザー インタラクションとサーバー イベントの取り込み: エンドユーザー アプリからのユーザー インタラクション イベントや、システムからのサーバー イベントを利用するには、それらを Pub/Sub に転送してから、Dataflow などのストリーム処理ツールを使用して、BigQuery、Bigtable、Cloud Storage などのデータベースにそれらを配信できます。Pub/Sub では、同時に多数のクライアントからイベントを収集できます。
  • リアルタイム イベントの分散: 未加工または処理済みのイベントを、チームや組織の複数のアプリケーションで使用してリアルタイム処理を行えます。これは、「エンタープライズ イベントバス」とイベント ドリブンのアプリケーション設計パターンをサポートします。Pub/Sub を使用し、イベントを Pub/Sub にエクスポートする多くの Google システムと統合できます。
  • データベース間でのデータの複製: Pub/Sub は一般的に、データベースから変更イベントを配布するために使用されます。これらのイベントを使用して、BigQuery やその他のデータ ストレージ システムにおけるデータベースの状態と状態の履歴のビューを確立できます。
  • 並列処理とワークフロー。テキスト ファイルの圧縮、メール通知の送信、AI モデルの評価、画像の再フォーマットなど、多数のタスクを多数のワーカーに効率的に分散するには、Pub/Sub メッセージを使用して Cloud Functions を接続します。
  • エンタープライズ イベントバス: エンタープライズ規模のリアルタイム データ共有バスを作成して、組織全体でビジネス イベント、データベース更新、分析イベントを配布できます。
  • IoT デバイスからのデータ ストリーミング。たとえば、クラウドにホストされているバックエンド サーバーに人感センサーからデータをストリーミングできます。
  • 分散キャッシュの更新。たとえば、アプリケーションで無効化イベントをパブリッシュし、変更されたオブジェクトの ID を更新できます。
  • 負荷分散により信頼性を確保。たとえば、サービスのインスタンスを複数のゾーンの Compute Engine にデプロイし、共通のトピックにサブスクライブできます。いずれかのゾーンでサービスが失敗した場合、他のサービスがその負荷を自動的に処理できます。

Pub/Sub または Pub/Sub Lite

Pub/Sub は次の 2 つのサービスで構成されます。

  • Pub/Sub サービス: ほとんどのユーザーとアプリケーションではこれがデフォルトの選択です。最も信頼性が高く、最大の統合のセットを提供するとともに、自動容量管理も提供されます。

  • Pub/Sub Lite サービス: 低コストで構築された、別であるものの同様のメッセージング サービス。ゾーン ストレージが用意されているため、ストレージとスループット容量の事前プロビジョニングと管理が必要になります。

Pub/Sub Lite は、費用を削減するために、追加の運用作業が必要で、可用性が低くなっても問題ないアプリケーションにのみ使用してください。

詳細については、Pub/Sub または Pub/Sub Lite の選択をご覧ください。Pub/Sub Lite を試すには、Pub/Sub Lite スタートガイドをご覧ください。

Pub/Sub と他のメッセージング テクノロジーの比較

Pub/Sub は、Apache KafkaPulsar の水平スケーラビリティと、Apache ActiveMQ や RabbitMQ などの従来のメッセージング ミドルウェアに見られる、デッドレター キューやフィルタリングなどの機能と両立できます。

Pub/Sub がメッセージ ミドルウェアから採用するもう 1 つの機能は、(パーティション ベースではなく)メッセージごとの並列処理です。Pub/Sub は、個々のメッセージをサブスクライバー クライアントに「リース」し、特定のメッセージが正常に処理されたかどうかを追跡します。

一方、水平スケーリングが可能な他のメッセージング システムでは、水平スケーリングにパーティションが使用されます。これにより、サブスクライバーは各パーティションでメッセージを順番に処理し、同時実行クライアントの数をパーティションの数に限定します。メッセージごとの処理により、サブスクライバー アプリケーションの並列処理が最大化され、パブリッシャー/サブスクライバーの独立性が確保されます。

サービス間通信と、サービスとクライアントとの通信

Pub/Sub は、エンドユーザーや IoT クライアントとの通信ではなく、サービス間通信を目的としています。他のパターンは、他のプロダクトでより適切にサポートされています。

  • クライアント サーバー: モバイルアプリとウェブアプリおよびサービスの間でメッセージを送信するには、Firebase Realtime DatabaseFirebase Cloud Messaging を含むプロダクトを使用してください。
  • IoT クライアント サービス: IoT アプリとサービスの間でメッセージを送信するには、Cloud IoT Core を使用してください。
  • 非同期サービス呼び出し: クラウドタスクを使用してください。

これらのサービスを組み合わせて、クライアント -> サービス -> データベースのパターンを構築できます。たとえば、WebSocket での Pub/Sub メッセージのストリーミングにあるチュートリアルをご覧ください。

統合

Pub/Sub には、フル機能のメッセージング システムを作成するためのその他の Google Cloud プロダクトとの統合が多数あります。

  • ストリーム処理とデータ統合: Dataflow でサポートされており、処理と BigQuery や Cloud Storage 上のデータレイクへのデータ統合を可能にする Dataflow テンプレートSQL を含んでいます。Pub/Sub から Cloud Storage、BigQuery、その他のプロダクトにデータを移動するための Dataflow テンプレートは、Cloud Console の Pub/Sub と Dataflow UI で利用できます。特に Dataproc で管理される場合、Apache Spark との統合も可能です。Spark と Dataproc で実行されている統合パイプラインと処理パイプラインを視覚的に合成するには、Datafusion を使用します。
  • モニタリング、アラート、ロギング: Monitoring プロダクトと Logging プロダクトでサポートされています。
  • 認証と IAM: Pub/Sub は、他の Google Cloud プロダクトで使用される標準の OAuth 認証に依存し、個々の IAM をサポートし、個々のリソースのアクセス制御を有効にします。
  • API: Pub/Sub は、標準の gRPC と REST サービスの API テクノロジーとともに、複数の言語のクライアント ライブラリを使用します。
  • トリガー、通知、Webhook: Pub/Sub は、HTTP POST リクエストとして Webhook にメッセージを push 配信します。これにより、Cloud Functions などのサーバーレス プロダクトを使用してワークフローの自動化を簡単に実装できます。
  • オーケストレーション: Pub/Sub は、複数ステップのサーバーレス ワークフロー ワークフローに宣言型の方法で統合できます。ビッグデータと分析オーケストレーションは多くの場合、Pub/Sub トリガーをサポートする Cloud Composer で行われます。

基本コンセプト

  • トピック: パブリッシャーがメッセージを送信する名前付きのリソース。
  • サブスクリプション: 特定の単一のトピックからサブスクライブするアプリケーションに配信されるメッセージのストリームを表す、名前付きのリソース。サブスクリプションとメッセージ配信体系の詳細については、サブスクライバー ガイドをご覧ください。
  • メッセージ: パブリッシャーがトピックに送信し、最終的にはサブスクライバーに配信されるデータ。データと属性を組み合わせることもできます。
  • メッセージ属性: パブリッシャーがメッセージに対して定義できる Key-Value ペア。たとえば、キー iana.org/language_tag、値 en をメッセージに付加すれば、英語圏のサブスクライバー向けメッセージとして識別できるようになります。
  • パブリッシャー: メッセージを作成してトピックに送信するアプリケーション。
  • サブスクライバー: トピックへのサブスクリプションを持つアプリケーション。メッセージを受信します。
  • 確認応答(または「ack」): メッセージを正常に受信した後、サブスクライバーが Pub/Sub に送信した信号。確認応答されたメッセージは、サブスクリプションのメッセージ キューから削除されます。
  • push と pull: 2 つのメッセージ配信方法。サブスクライバーは、Pub/Sub がメッセージをサブスクライバーが選択したエンドポイントに push するか、サブスクライバーがメッセージをサービスから pull することで、メッセージを受け取ります。

パブリッシャーとサブスクライバーの関係は、次の図のように 1 対多(ファンアウト)、多対 1(ファンイン)、多対多になります。

パブリッシャーとサブスクライバーの関係

次の図は、メッセージがパブリッシャーからサブスクライバーに渡される方法を示しています。push 配信では、ack は push リクエストへのレスポンスで暗黙的に指定されますが、pull 配信では個別の RPC が必要になります。

メッセージ ライフサイクル

次のステップ