Pub/Sub とは

Pub/Sub は、パブリッシャー / サブスクライバーの略で、これを使用するとサービスが 100 ミリ秒程度のレイテンシで非同期に通信できます。

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 テンプレートSQL などの Dataflow でサポートされており、CloudStorage 上の BigQuery やデータレイクへの処理とデータ統合が可能です。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 は、Webhook への HTTP POST リクエストとしてメッセージの 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 配信では、push リクエストへのレスポンスで ack が暗黙的に行われますが、pull 配信では、別の RPC が必要になります。

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

次のステップ