Pub/Sub サービスの概要

Pub/Sub は、パブリッシュ / サブスクライブ（Pub/Sub）サービスです。Pub/Sub サービスとは、メッセージの送信者とメッセージの受信者を切り離す方式のメッセージ サービスのことを指します。Pub/Sub サービスにはいくつかの重要なコンセプトがあります。次の図で説明します。

Pub/Sub サービスのさまざまなコンポーネントと、それらが相互にどのように接続されているかを示す図。
図 1 2 つのパブリッシャー クライアントが、2 つの異なるメッセージを共通の Pub/Sub トピックに送信します。

Pub/Sub サービスのコンポーネントは次のとおりです。

  • パブリッシャー（プロデューサー）: 特定のトピックに関するメッセージを作成してメッセージ サービスに送信（パブリッシュ）します。

  • メッセージ: サービスを通って移動するデータ。

  • トピック: メッセージのフィードを示す名前付きエンティティ。

  • スキーマ: Pub/Sub メッセージのデータ形式を管理する名前付きエンティティ。

  • サブスクリプション: 特定のトピックに関するメッセージの受信に関心があることを示す名前付きエンティティ。

  • サブスクライバー（コンシューマー）: 特定のサブスクリプションに関するメッセージを受信します。

次の手順では、Pub/Sub サービスのワークフローについて説明します。

  1. パブリッシャー 1 とパブリッシャー 2 の 2 つのパブリッシャー アプリケーションが、単一の Pub/Sub トピックにメッセージを送信します。パブリッシャー 1 がメッセージ A を送信し、パブリッシャー 2 がメッセージ B を送信します。

  2. トピック自体は、2 つのサブスクリプションにアタッチされます。これらは、サブスクリプション 1 と サブスクリプション 2 です。

  3. このトピックはスキーマにもアタッチされます。

  4. 各サブスクリプションは、トピックから A および B のメッセージのコピーを受け取ります。

  5. サブスクリプション 1 は、2 つのサブスクライバー アプリケーション（サブスクライバー 1 と サブスクライバー 2）に接続されています。2 つのサブスクライバー アプリケーションは、トピックからメッセージのサブセットを受信します。この例では、サブスクライバー 1 がメッセージ B を受信し、サブスクライバー 2 がメッセージ A を受信します。トピック

  6. サブスクリプション 2 は、サブスクライバー 3 という単一のサブスクライバー アプリケーションにのみ接続されています。したがって、サブスクライバー 3 はトピックからすべてのメッセージを受信します。

メールの概要

1 つのパブリッシャー クライアントがトピックに接続されているとします。トピックには、単一のサブスクリプションがアタッチされています。単一のサブスクライバーがサブスクリプションに接続されます。

Pub/Sub 内でのメッセージの流れを示す図。
図 2 メッセージは、Pub/Sub を介してパブリッシャー クライアントからサブスクライバー クライアントに送信されます。

次の手順では、Pub/Sub でのメッセージがどのように流れるかついて説明します。

  1. パブリッシャー アプリケーションが Pub/Sub トピックにメッセージを送信します。

  2. メッセージがストレージに書き込まれます。

  3. Pub/Sub は、メッセージをストレージに書き込むとともに、メッセージをトピックにアタッチされているすべてのサブスクリプションに配信します。

    この例では、それが 1 つのサブスクリプションです。

  4. サブスクリプションにより、アタッチされているサブスクライバー アプリケーションにメッセージが送信されます。

  5. サブスクライバーは、メッセージを処理したことを示す確認応答を Pub/Sub に返信します。

    各サブスクリプションの少なくとも 1 つのサブスクライバーがメッセージ受信の確認応答を返信すると、Pub/Sub は、ストレージからメッセージを削除します。

Pub/Sub のメッセージのステータス

サブスクライバーに対してメッセージが未処理である一方で、Pub/Sub は同じサブスクリプションの他のサブスクライバーにはメッセージを配信しようとはしません。サブスクライバーには、未処理のメッセージに確認応答するために、ackDeadlineという構成可能な限定時間があります。この期限をすぎると、メッセージは未処理とはみなされなくなり、再び配信できるようになります。

Pub/Sub サービス内のメッセージには、次の 3 つの状態があります。

  • 確認済みメッセージ（確認済み）。サブスクライバー アプリケーションは、トピックからサブスクリプションに送信されたメッセージを処理した後、確認応答を Pub/Sub に返信します。トピックのすべてのサブスクリプションがメッセージ受信の確認応答を返信すると、メッセージはパブリッシュ メッセージ ソースとストレージから非同期的に削除されます。

  • 未確認のメッセージ（未確認）。Pub/Sub が確認応答期限までに確認応答を受け取らなかった場合、メッセージが複数回配信される可能性があります。たとえば、サブスクライバーが期限を経過した後に確認応答を送信する可能性や、一時的なネットワークの問題により確認応答が失われる可能性があります。確認応答されていないメッセージは、メッセージがパブリッシュされてからメッセージの保持期間が切れるまで、引き続き配信されます。この時点で、メッセージは期限切れになります。

  • 否定応答メッセージ（否定応答）。サブスクライバーによってメッセージが否定応答されると、Pub/Sub はメッセージを直ちに再配信します。 サブスクライバーは、無効なメッセージを否定応答する場合や、メッセージを処理できない場合に、これらのメッセージが失われないようにして、最終的に正常に処理されるようにします。modifyAckDeadlineを値 0 で使用して、メッセージを否定応答できます。

Pub/Sub のパブリッシュ / サブスクライブ パターンを選択する

Pub/Sub パブリッシャー クライアントとサブスクライバー クライアントが複数ある場合は、設定するパブリッシュ アーキテクチャとサブスクライブ アーキテクチャの種類も選択する必要があります。

さまざまなパブリッシュとサブスクライブのパターンを示す図。
図 3 パブリッシャーとサブスクライバーの関係は、多対 1（ファンイン）と多対多（負荷分散）と 1 対多（ファンアウト）です。

サポートされている Pub/Sub パブリッシュ / サブスクライブ パターンには、次のようなものがあります。

  • ファンイン（多対 1）この例では、複数のパブリッシャー アプリケーションが単一のトピックにメッセージをパブリッシュします。この単一のトピックは、単一のサブスクリプションにアタッチされます。次に、サブスクリプションはトピックからすべてのパブリッシュされたメッセージを取得する単一のサブスクライバー アプリケーションに接続されます。

  • 負荷分散（多対多）この例では、単一または複数のパブリッシャー アプリケーションが単一のトピックにメッセージをパブリッシュします。この単一のトピックは、単一のサブスクリプションにアタッチされ、次に、複数のサブスクライバー アプリケーションに接続されます。各サブスクライバー アプリケーションは、パブリッシュされたメッセージのサブセットを取得します。2 つのサブスクライバー アプリケーションが同じメッセージのサブセットを取得することはありません。このロード バランシング ケースでは、複数のサブスクライバーを使用して大規模にメッセージを処理します。より多くのメッセージをサポートする必要がある場合は、同じサブスクリプションからメッセージを受信するためにより多くのサブスクライバーを追加します。

  • ファンアウト（1 対多）この例では、単一または複数のパブリッシャー アプリケーションが単一のトピックにメッセージをパブリッシュします。この単一のトピックは、複数のサブスクリプションにアタッチされます。各サブスクリプションは、単一のサブスクライバー アプリケーションにアタッチされます。各サブスクライバー アプリケーションは、トピックから同じセットのパブリッシュされたメッセージを取得します。トピックに複数のサブスクリプションがある場合、すべてのメッセージは、各サブスクリプションに代わってメッセージを受信するサブスクライバーに送信する必要があります。同じメッセージ セットに対して異なるデータ オペレーションを実行する必要がある場合は、ファンアウトが良い選択肢です。また、各サブスクリプションに複数のサブスクライバーをアタッチし、サブスクライバーごとにメッセージの負荷分散されたサブセットを取得できます。

Pub/Sub の構成オプションを選択する

Pub/Sub 環境は、次のいずれかのオプションを使用して構成できます。

  • Google Cloud コンソール
  • Google Cloud CLI
  • Cloud クライアント ライブラリ（高レベル クライアント ライブラリ）
  • REST API と RPC API（低レベル クライアント ライブラリ）

Pub/Sub の構成オプションの選択は、ユースケースによって異なります。

Google Cloud コンソールが初めてで、Pub/Sub をテストする場合は、コンソールまたは gcloud CLI を使用します。

高レベルのクライアント ライブラリは、運用のオーバーヘッドと処理コストを最小限に抑えながら、高スループットと低レイテンシが必要な場合におすすめします。デフォルトでは、高レベル クライアント ライブラリは StreamingPull API を使用します。高レベル クライアント ライブラリには、認証、スループット、レイテンシの最適化、メッセージのフォーマットなどの機能のために基盤となる API 呼び出しを処理するビルド済み関数とクラスが含まれています。

低レベル クライアント ライブラリは自動生成される gRPC ライブラリで、サービス API を直接使用すると機能し始めます。

クライアント ライブラリを使用する際のベスト プラクティスを以下にいくつか紹介します。

  • 適切なクライアント ライブラリの言語を選択します。Pub/Sub クライアント ライブラリのパフォーマンスは言語によって異なります。たとえば、Java クライアント ライブラリは Python クライアント ライブラリよりも垂直方向のスケールアップに効果的で、より多くのスループットを処理できます。Java、C++、Go は、パブリッシュ / サブスクライブ ロードの処理に必要なコンピューティング リソースの点で、より効率的な言語です。

  • 最新バージョンのクライアント ライブラリを使用するPub/Sub クライアント ライブラリは、新機能とバグ修正によって常に更新されています。ご使用の言語に最新バージョンのクライアント ライブラリを使用していることを確認してください。

  • パブリッシャー クライアントを再利用する。メッセージをパブリッシュする場合は、パブリッシュ リクエストごとに新しいパブリッシャー クライアントを作成する代わりに、同じパブリッシャー クライアントを再利用するとより効率的です。これは、新しいパブリッシャー クライアントの作成後に最初の公開リクエストを行うと、承認済みの接続を確立するために時間がかかるためです。明示的なパブリッシャー クライアントがない Node などの言語では、パブリッシュ メソッドを呼び出すオブジェクトを再利用します。たとえば、Node では、トピック オブジェクトを保存して再利用します。

Pub/Sub を設定する方法

Pub/Sub を構成する上位レベルの手順は次のとおりです。

  1. Pub/Sub を設定できる Google Cloud プロジェクトを作成または選択します。

  2. Pub/Sub API を有効にします。

  3. Pub/Sub の実行に必要なロールと権限を取得します。

  4. トピックを作成します。

  5. メッセージの構造が重要である場合は、メッセージのスキーマを定義します。

  6. スキーマをトピックにアタッチします。

  7. トピックにメッセージをパブリッシュできるパブリッシャー クライアントを構成します。

  8. 必要に応じて、フロー制御、バッチ メッセージング、同時実行制御などの高度なパブリッシュ オプションを構成します。

  9. メッセージを受信する方法に応じて、サブスクリプション タイプを選択します。

  10. 選択済みトピックのサブスクリプションを作成します。

  11. サブスクリプションからメッセージを受信できるサブスクライバー クライアントを構成します。

  12. 必要に応じて、1 回限りの配信、リース管理、順序指定配信、フロー制御などの高度なメッセージ配信オプションを構成します。

  13. パブリッシャー クライアントからトピックへのメッセージのパブリッシュを開始します。

  14. 同時に、これらのメッセージを受信して処理するようにサブスクライバー クライアントを設定します。

トピック、サブスクリプション、スキーマ、スナップショットの名前に関するガイドライン

Pub/Sub リソース名は、トピック、サブスクリプション、スキーマ、スナップショットなどの Pub/Sub リソースを一意に識別します。リソース名は次の形式にする必要があります。

projects/project-identifier/collection/ID

  • project-identifier: Google Cloud コンソールから取得可能なプロジェクト ID またはプロジェクト番号を指定する必要があります。たとえば、my-cool-project はプロジェクト ID です。123456789123 はプロジェクト番号です。

  • collection: topics、subscriptions、schemas、snapshots のいずれかにする必要があります。

  • ID: 次のガイドラインに従う必要があります。

    • 文字列 goog で始めないこと。
    • 文字から始まる
    • 3～255 文字の長さであること。
    • 次の文字だけが含まれている: 文字 [A-Za-z]、数字 [0-9]、ダッシュ -、アンダースコア _、ピリオド .、チルダ ~、プラス記号 +、パーセント記号 %

    URL エンコードのないリソース名で、上記リストの特殊文字を使用できます。ただし、URL で使用する場合、その他すべての特殊文字が適切にエンコードまたはデコードされることを確認する必要があります。たとえば、mi-tópico は無効な ID です。しかし、mi-t%C3%B3pico は有効です。この形式は、REST 呼び出しを行う場合に重要です。

次のステップ