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(Dataflow テンプレートSQL を含む)によってサポートされており、BigQuery や Cloud Storage 上のデータレイクへの処理とデータの統合を可能にします。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 が必要になります。

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

次のステップ