Pub/Sub サービスの概要

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

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

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

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

Pub/Sub のメッセージのライフサイクル

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

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 はメッセージの再配信を試みます。

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

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

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

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

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 呼び出しを行うときに重要です。

次のステップ