Pub/Sub と Pub/Sub Lite とは

このページでは、Pub/Sub、ビジネスに Pub/Sub が必要な理由、類似のテクノロジーと比較した Pub/Sub のメリットについて説明します。また、Pub/Sub の基本コンセプト（トピック、パブリッシャー、サブスクライバーという用語を含む）について説明します。

Pub/Sub は、メッセージを生成するサービスを、それらのメッセージを処理するサービスと切り離す、非同期のスケーラブルなメッセージング サービスです。

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

Pub/Sub は、データを取り込んで配布するためのストリーミング分析とデータ統合パイプラインに使用されます。これは、サービスの統合を目的としたメッセージング指向のミドルウェア、または、タスクを同時に読み込むキューとしても使用されます。

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

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

Pub/Sub を使用する前に、Google Cloud コンソールを使用したクイックスタートをご覧ください。より包括的な情報については、Pub/Sub メッセージング システムの構築をご覧ください。

一般的なユースケース

  • ユーザー操作の取り込みとサーバー イベント。エンドユーザー アプリからのユーザー インタラクション イベントや、システムからのサーバー イベントを利用するには、それらを Pub/Sub に転送できます。その後、Dataflow などのストリーム処理ツールを使用してイベントをデータベースに送信できます。 このようなデータベースの例として、BigQuery、Bigtable、Cloud Storage などがあります。Pub/Sub では、同時に多数のクライアントからイベントを収集できます。

  • リアルタイムのイベント配信。イベントは、未加工か処理された状態かを問わず、チームや組織の複数のアプリケーションでリアルタイム処理のために使用できます。Pub/Sub では、「エンタープライズ イベントバス」とイベント ドリブンなアプリケーション設計パターンがサポートされます。Pub/Sub を使用すると、イベントを Pub/Sub にエクスポートする多くの Google システムと連携できます。

  • データベース間でデータを複製する。Pub/Sub は一般的に、データベースから変更イベントを分散するために使用されます。これらのイベントを使用して、BigQuery やその他のデータ ストレージ システムでデータベースの状態と状態の履歴に関するビューを作成できます。

  • 並列処理とワークフロー。Pub/Sub メッセージを使用して Cloud Run functions に接続することで、多数のタスクを複数のワーカーに効率的に分散できます。このようなタスクの例としては、テキスト ファイルの圧縮、メール通知の送信、AI モデルの評価、画像の再フォーマットなどがあります。

  • エンタープライズ イベントバス。組織全体にビジネス イベント、データベース更新、分析イベントを配布する、エンタープライズ規模のリアルタイム データ共有バスを作成できます。

  • アプリケーション、サービス、IoT デバイスからのデータ ストリーミング。たとえば、SaaS アプリケーションはイベントのリアルタイム フィードを公開できます。または、人感センサーは Dataflow パイプラインを介して他の Google Cloud プロダクトで使用するために Pub/Sub にデータをストリーミングできます。

  • 分散キャッシュの更新。たとえば、アプリケーションで無効なイベントをパブリッシュし、変更されたオブジェクトの ID を更新できます。

  • 負荷分散により信頼性を確保。たとえば、サービスのインスタンスを複数のゾーンの Compute Engine にデプロイし、共通のトピックにサブスクライブできます。いずれかのゾーンでサービスが失敗した場合、他のサービスがその負荷を自動的に処理できます。

Pub/Sub サービスのタイプ

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

  • Pub/Sub サービス。ほとんどのユーザーとアプリケーションでは、このメッセージ サービスがデフォルトの選択です。最高レベルの信頼性、最大限の統合機能、自動の容量管理を提供します。Pub/Sub は、少なくとも 2 つのゾーンに対するすべてのデータの同期レプリケーションと、3 つ目の追加ゾーンに対するベスト エフォートのレプリケーションを保証します。

  • Pub/Sub Lite サービス。同じようなメッセージ サービスですが、別のサービスで、低コスト向けです。Pub/Sub と比較すると、信頼性は低くなります。ゾーンまたはリージョンのトピック ストレージを提供します。ゾーン Lite トピックは 1 つのゾーンでのみ保存されます。リージョン Lite トピックでは、データは非同期で 2 つ目のゾーンに複製されます。また、Pub/Sub Lite では、ストレージとスループット容量の事前プロビジョニングと管理が必要になります。費用を削減するために、追加の運用作業と、信頼性の低下が許容されるアプリケーションにのみ、Pub/Sub Lite を使用することを検討してください。

Pub/Sub と Pub/Sub Lite の違いの詳細については、Pub/Sub または Pub/Sub Lite の選択をご覧ください。

Pub/Sub と他のメッセージング技術の比較

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

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

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

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

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

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

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

統合

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

  • ストリーム処理とデータ統合。Dataflow でサポートされている Dataflow テンプレートや SQL により、Cloud Storage 上の BigQuery やデータレイクへの処理とデータ統合が可能です。Pub/Sub から Cloud Storage、BigQuery およびその他のプロダクトにデータを移行するための Dataflow テンプレートは、Google Cloud コンソールの Pub/Sub と Dataflow UI で利用できます。特に Dataproc で管理されている場合、Apache Spark との統合も可能です。Spark と Dataproc で実行される統合パイプラインと処理パイプラインの視覚的な構成は、Data Fusion を使用して実現できます。
  • モニタリング、アラート、ロギング。Monitoring と Logging の各プロダクトでサポートされています。
  • 認証と IAM。Pub/Sub は、他の Google Cloud プロダクトで使用される標準の OAuth 認証に依存し、個々の IAM をサポートし、個々のリソースのアクセス制御を有効にします。
  • APIs。Pub/Sub は、標準の gRPC と REST サービスの API テクノロジーとともに、複数の言語のクライアント ライブラリを使用します。
  • トリガー、通知、Webhook。Pub/Sub は、Webhook への HTTP POST リクエストとしてメッセージの push ベースの配信を行います。Cloud Functions などのサーバーレス プロダクトを使用して、ワークフローの自動化を簡単に実装できます。
  • オーケストレーション。Pub/Sub は、複数ステップのサーバーレス ワークフローに宣言型の方法で統合できます。ビッグデータと分析オーケストレーションは多くの場合、Pub/Sub トリガーをサポートする Cloud Composer で行われます。Pub/Sub を Application Integration（プレビュー）と統合することもできます。これは Integration-Platform-as-a-Service（iPaaS）ソリューションです。Application Integration では、統合をトリガーまたは開始するための Pub/Sub トリガーが提供されます。
  • Integration Connectors（プレビュー）。これらのコネクタを使用すると、さまざまなデータソースに接続できます。コネクタにより、Google Cloud サービスとサードパーティのビジネス アプリケーションの両方が透過的で標準的なインターフェースを介して統合に公開されます。Pub/Sub の場合は、統合で使用する Pub/Sub 接続を作成できます。

基本コンセプト

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

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

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

次の図は、メッセージがパブリッシャーからサブスクライバーに渡される仕組みを示しています。push 配信では、push リクエストへのレスポンスで確認応答が暗黙的に行われますが、pull 配信では別の RPC が必要です。

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

次のステップ