サブスクライバーの概要

このドキュメントでは、Google Cloud Pub/Sub でのサブスクリプションの動作の概要を説明します。pull 配信サブスクリプションと push 配信サブスクリプションの詳細については、pull サブスクライバー ガイドpush サブスクライバー ガイドをご覧ください。

トピックに公開されたメッセージを受信するには、そのトピックへのサブスクリプションを作成する必要があります。サブスクライバー アプリケーションで使用できるのは、サブスクリプションの作成後にトピックに公開したメッセージだけです。サブスクリプションにより、トピックとサブスクライバー アプリケーションが関連付けられます。このアプリケーションがそのトピックに公開されたメッセージを受信して処理します。トピックは複数のサブスクリプションを持つことができますが、特定のサブスクリプションは単一のトピックに属します。

サブスクリプションの作成と更新の詳細については、トピックとサブスクリプションの管理をご覧ください。

at-least-once 配信

Google Cloud Pub/Sub は、すべてのサブスクリプションについて、公開されたメッセージを 1 回以上配信します。ただし、この at-least-once 配信には例外もあります。サブスクリプションでは、メッセージに最大保持期間を設定できます。その期間内に配信できなかったメッセージは削除され、アクセス不能になります。通常、この状況はサブスクライバーがメッセージのフローについていけない場合に発生します。特定のサブスクリプションが作成される前に公開されたメッセージは、通常は配信されません。このため、サブスクリプションのないトピックに公開されたメッセージは取得できません。

メッセージがサブスクライバーに送信されたら、サブスクライバーはメッセージを確認応答またはドロップする必要があります。メッセージは、配信のために送信された後、サブスクライバーが確認応答するまでは未処理と見なされます。Google Cloud Pub/Sub は、確認応答されていないか未処理でないメッセージの配信を繰り返し試行します。サブスクライバーには、メッセージの確認応答に対して設定可能な制限時間(ackDeadline)があります。期限が経過すると、未処理のメッセージは未確認応答状態になります。

通常、Pub/Sub は各メッセージを公開された順序で 1 回配信します。ただし、メッセージが順不同で配信される場合や複数回配信される場合があります。通常、複数回の配信に対応するには、メッセージの処理時にサブスクライバーがべき等である必要があります。Google Cloud Pub/Sub メッセージ ストリームを 1 回だけ処理するには、Cloud Dataflow PubsubIO を使用します。PubsubIO は、カスタム メッセージ ID または Google Cloud Pub/Sub が割り当てた ID でメッセージの重複を排除します。Cloud Dataflow で順次処理を行うには、サービスの標準的な並べ替え API を使用します。あるいは、登録するトピックのパブリッシャーがメッセージにシーケンス トークンを追加することもできます。詳細については、メッセージの順次処理をご覧ください。

push 配信と pull 配信

サブスクリプションでは、メッセージ配信に push メカニズムまたは pull メカニズムを使用できます。メカニズムは、いつでも変更または設定できます。push 配信では、Pub/Sub がサブスクライバー アプリケーションに対してメッセージ配信のリクエストを開始します。pull 配信では、サブスクライバー アプリケーションが Pub/Sub サーバーに対してメッセージ取得のリクエストを開始します。

push サブスクリプションの場合、Pub/Sub サーバーは、事前設定されたエンドポイントで、サブスクライバー アプリケーションに各メッセージを HTTPs リクエストとして送信します。エンドポイントは、HTTP 成功ステータス コードを返すことでメッセージに確認応答します。不成功のレスポンスは、メッセージを再送信する必要があることを示します。Pub/Sub は、成功のレスポンスを受信するレートに基づいて、push リクエストのレートを動的に調整します。

pull サブスクリプションでは、登録側のアプリケーションがメッセージの配信をリクエストする pull メソッドを明示的に呼び出します。Pub/Sub サーバーはメッセージ(キューが空の場合はエラー)と確認応答 ID でレスポンスします。次に、サブスクライバーは戻された確認応答 ID を使用して acknowledge メソッドを明示的に呼び出し、受信の確認応答を行います。

次の表は、アプリケーションに適した配信メカニズムの選択に関するガイドを示しています。

pull push
  • メッセージが多い場合(1 秒間に 1 個超)。
  • メッセージ処理の効率とスループットが重要な場合。
  • 非自己署名 SSL 証明書を持つパブリック HTTPs エンドポイントの設定が現実的でない場合。
  • Google Cloud の依存関係(認証情報やクライアント ライブラリ)が設定できない環境。
  • 同じ webhook で処理する必要がある複数のトピック。
  • App Engine Standard サブスクライバー。

次の表は、pull 配信と push 配信を比較しています。

  pull push
エンドポイント 承認済みの認証情報を持つインターネット上のデバイスが Google Cloud Pub/Sub API を呼び出すことができます。 非自己署名証明書を持つ HTTPS サーバーは、パブリックウェブ上でアクセス可能です。受信エンドポイントは、Pub/Sub サブスクリプションから切り離すことができるので、複数のサブスクリプションからのメッセージを単一のエンドポイントに送信できます。
負荷分散 複数のサブスクライバーが、同じ「共有」サブスクリプションへの pull 呼び出しを作成できます。サブスクライバーごとにメッセージのサブセットを受信します。 push エンドポイントにはロードバランサを指定できます。
設定 設定は不要です。 サブスクライバーと同じプロジェクトでは、App Engine アプリへの設定が不要です。
他のすべてのエンドポイントには、Google Cloud Platform Console で push エンドポイントの設定(および確認)が必要です。エンドポイントには DNS 名から到達可能で、SSL 証明書がインストールされている必要があります。
フロー制御 サブスクライバー クライアントは配信レートを制御します。サブスクライバーは確認応答期限を動的に変更し、メッセージ処理期間を必要に応じて長くすることができます。 Pub/Sub サーバーはフロー制御を自動的に実装します。クライアント側でメッセージ フローを処理する必要はありません(クライアントが HTTP エラーを戻すことで、現在のメッセージ ロードを処理できないことを示すことはできます)。
効率とスループット バッチでの配信と確認応答に加えて非常に並列性の高い消費を可能にすることで、低い CPU と帯域幅で高いスループットを実現します。積極的なポーリングを使用してメッセージ配信時間を最小限に抑える場合には効率的でない場合があります。 リクエストごとに 1 つのメッセージを配信し、未処理メッセージの最大数を制限します。

サブスクリプションの設定

サブスクリプションは、単一のトピックに対して作成されます。次のような、作成時に設定するか後で更新できる複数のプロパティがあります。

  • 配信方法: デフォルトでは、Pub/Sub サブスクリプションは pull 方式を使用します。空でない有効な HTTPs push エンドポイント URL を指定することで、push 配信に切り替えることができます。空の URL を指定して、pull 配信に戻すことができます。
  • 確認応答期限: コードが期限前にメッセージに確認応答しなかった場合は、メッセージが再送信されます。デフォルト値は 10 秒です。指定できる最大カスタム期限は 600 秒(10 分)です。
  • 最大メッセージ保持期間: Google Cloud Pub/Sub がメッセージを保持し、配信を試行する最大期間。デフォルトおよび最大値は 7 日間です。最小値は 10 分です。

サブスクリプションのライフサイクル

31 日間にわたってアクティビティ(push 成功または pull リクエスト)がなかったサブスクリプションは自動的に削除されることがあります。サブスクリプションを手動で削除することもできます。削除されたサブスクリプションと同じ名前で新しいサブスクリプションを作成できますが、同じ名前であっても、新しいサブスクリプションと古いサブスクリプションの間に関係はありません。したがって、削除されたサブスクリプションに確認応答されていないメッセージが大量にある場合でも、新しいサブスクリプションは作成時にバックログを持ちません(配信を待っているメッセージはありません)。

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

フィードバックを送信...