このドキュメントでは、さまざまなタイプのサブスクリプションが Pub/Sub でどのように機能するかの概要を説明します。
サブスクリプションの概要
トピックにパブリッシュされたメッセージを受信するには、そのトピックへのサブスクリプションを作成する必要があります。 サブスクライバー クライアントで使用できるのは、サブスクリプションの作成後にトピックにパブリッシュしたメッセージだけです。ただし、トピックの保持を有効にすると、トピックに関連付けられたサブスクリプションが過去に seek ってメッセージをパブリッシュしたり、再生したりできます。サブスクライバー クライアントは、トピックにパブリッシュされたメッセージを受信して処理します。 トピックは複数のサブスクリプションを持つことができますが、特定のサブスクリプションは単一のトピックに属します。
サブスクリプションのワークフロー
メッセージがサブスクライバーに送信されたら、サブスクライバーはメッセージを確認応答する必要があります。
メッセージが配信のために送信され、サブスクライバーがまだ確認応答していない場合、メッセージは未処理と呼ばれます。
Pub/Sub は、確認応答されていないメッセージの配信を繰り返し試行します。ただし、Pub/Sub は同じサブスクリプション内の他のサブスクライバーに未処理のメッセージを配信しません。
サブスクライバーは、構成可能な限られた時間内（
ackDeadline）で未処理のメッセージに確認応答する必要があります。この期限を過ぎたメッセージは未処理とはみなされなくなり、Pub/Sub はメッセージの再配信を試みます。
サブスクリプションの種類
サブスクリプションを作成するときに、メッセージ配信のタイプを指定する必要があります。Pub/Sub には次の 3 種類のサブスクリプションに対応する 3 種類のメッセージ配信があります。各タイプのサブスクリプションについては、このドキュメントの後のセクションで詳しく説明します。
- pull サブスクリプション
- push サブスクリプション
- BigQuery のサブスクリプション
サブスクリプションの種類はいつでも更新できます。
pull サブスクリプション
pull サブスクリプションの場合、サブスクライバー クライアントは、Pub/Sub サーバーに対してメッセージ取得のリクエストを開始します。サブスクライバー クライアントはRESTPull API ）、RPCPullRequest API ）、RESTStreamingPullRequest APIまたはRPCStreamingPullRequest API 。ほとんどのサブスクライバー クライアントは、これらのリクエストを直接行うことはありません。代わりに、クライアントは Google Cloud が提供する高レベルのクライアント ライブラリに依存して、内部でストリーミング pull リクエストを実行し、非同期でメッセージを配信します。メッセージの pull 方法をより詳細に制御する必要があるサブスクライバー クライアントの場合、Pub/Sub は低レベルで自動的に生成される gRPC ライブラリを使用します。このライブラリは、pull またはストリーミングの pull リクエストを直接作成します。これらのリクエストは、同期または非同期です。
次の 2 つの画像は、サブスクライバー クライアントと pull サブスクリプションの間のワークフローを示しています。
pull ワークフローは次のようになります。図 1 を参照してください。
サブスクライバー クライアントは pull メソッドを明示的に呼び出し、メッセージの配信をリクエストします。このリクエストは、画像に示すように PullRequest です。
Pub/Sub サーバーは、ゼロ個以上のメッセージと確認応答 ID で応答します。メッセージが 0 のレスポンスまたはエラーが返されても、受信可能なメッセージがないとは限りません。このレスポンスは、画像に示されている PullResponse です。
サブスクライバー クライアントは明示的に確認済みのメソッドを呼び出します。クライアントは、返された確認 ID を使用して、メッセージが処理されていること、および再び配信する必要がないことを確認します。このリクエストは、画像で示されている AckRequest です。
単一のストリーミング pull リクエストでは、開いているクライアントが原因で、サブスクライバー クライアントが複数のレスポンスを返すことがあります。一方、pull リクエストごとに 1 つのレスポンスのみが返されます。
pull サブスクリプションの仕組みと設定例については、pull サブスクリプションをご覧ください。
push サブスクリプション
push サブスクリプションの場合、Pub/Sub サーバーは、サブスクライバー クライアントに対してメッセージ配信のリクエストを開始します。
次の図は、サブスクライバー クライアントと push サブスクリプションの間のワークフローを示しています。
図 3 を参照するワークフローの簡単な説明を次に示します。
Pub/Sub サーバーは、事前構成されたエンドポイントで、サブスクライバー クライアントに各メッセージを HTTPS リクエストとして送信します。このリクエストはイメージで PushRequest として表示されます。
エンドポイントは、HTTP 成功ステータス コードを返すことでメッセージに確認応答します。不成功のレスポンスは、Pub/Sub がメッセージを再送信する必要があることを示します。このレスポンスは、イメージで PushResponse として表示されます。
Pub/Sub は、成功のレスポンスを受信するレートに基づいて、push リクエストのレートを動的に調整します。
push サブスクリプションの仕組みと設定例については、push サブスクリプションをご覧ください。
BigQuery のサブスクリプション
BigQuery サブスクリプションは、受信時に既存の BigQuery テーブルにメッセージを書き込みます。個別のサブスクライバー クライアントを構成する必要はありません。
BigQuery のサブスクリプション タイプがない場合は、メッセージを読み取り、BigQuery テーブルに書き込むサブスクライバー（Dataflow など）と pull サブスクリプションまたは push サブスクリプションが必要です。メッセージを BigQuery テーブルに格納する前に追加の処理を必要としない場合、Dataflow ジョブの実行によるオーバーヘッドは不要です。代わりに BigQuery サブスクリプションを使用できます。ただし、データを BigQuery テーブルに保存する前にデータ変換が必要な Pub/Sub システムでは、Dataflow パイプラインの使用をおすすめします。Dataflow を使用して変換を使用して Pub/Sub から BigQuery にデータをストリーミングする方法については、Pub/Sub から BigQuery へのストリーミングをご覧ください。
次の図は、BigQuery サブスクリプションと BigQuery の間のワークフローを示しています。
図 4 を参照するワークフローの簡単な説明を次に示します。
- Pub/Sub は BigQuery Storage Write API を使用して BigQuery テーブルにデータを送信します。
- メッセージはバッチで BigQuery テーブルに送信されます。
- 書き込みオペレーションが正常に完了すると、API は OK レスポンスを返します。
- 書き込みオペレーションに失敗した場合、Pub/Sub メッセージ自体が否定応答されます。その後、メッセージが再送信されます。メッセージが十分に失敗し、サブスクリプションにデッドレター トピックが設定されている場合、メッセージはデッドレター トピックに移動します。
BigQuery サブスクリプションの仕組みについて詳しくは、BigQuery サブスクリプションをご覧ください。
サブスクリプション タイプを決定する
次の表は、アプリケーションに適した配信メカニズムの選択に関するガイドを示しています。
| pull | push | BigQuery | |
|---|---|---|---|
| ユースケース |
|
|
|
| Endpoints | 承認済みの認証情報を持つインターネット上のデバイスが Pub/Sub API を呼び出すことができます。 | 非自己署名証明書を持つ HTTPS サーバーは、パブリックウェブ上でアクセス可能です。 受信エンドポイントは、Pub/Sub サブスクリプションから切り離すことができるので、複数のサブスクリプションからのメッセージを単一のエンドポイントに送信できます。 | BigQuery テーブル。 |
| 負荷分散 | 複数のサブスクライバーが、同じ「共有」サブスクリプションへの pull 呼び出しを作成できます。各サブスクライバーはメッセージのサブセットを受け取ります。 | push エンドポイントにはロードバランサを指定できます。 | Pub/Sub サービスは負荷を自動的に分散します。 |
| 構成 | 構成は不要です。 | サブスクライバーと同じプロジェクトでは、App Engine アプリへの設定が不要です。
Google Cloud コンソールでは、push エンドポイントの確認は必要ありません。エンドポイントには DNS 名から到達可能で、SSL 証明書がインストールされている必要があります。 |
トピックのサブスクリプションには BigQuery テーブルが存在する必要があります。 |
| フロー制御 | サブスクライバー クライアントは配信レートを制御します。サブスクライバーは確認応答期限を動的に変更し、メッセージ処理期間を必要に応じて長くすることができます。 | Pub/Sub サーバーはフロー制御を自動的に実装します。クライアント側でメッセージ フローを処理する必要はありません。ただし、クライアントが HTTP エラーを戻すことで、現在のメッセージ ロードを処理できないことを示すことはできます。 | BigQuery へのメッセージの書き込みを最適化するために、Pub/Sub サーバーはフロー制御を自動的に実装します。 |
| 効率とスループット | バッチでの配信と確認応答に加えて非常に並列性の高い消費を可能にすることで、低い CPU と帯域幅で高いスループットを実現します。積極的なポーリングを使用してメッセージ配信時間を最小限に抑える場合には効率的でない場合があります。 | リクエストごとに 1 つのメッセージを配信し、未処理メッセージの最大数を制限します。 | スケーラビリティは Pub/Sub サーバーで動的に処理されます。 |
デフォルトのサブスクリプション プロパティ
デフォルトでは、Pub/Sub は at-least-once（最低 1 回）配信を提供します。すべてのサブスクリプション タイプに順序保証はありません。複数のメッセージが同じ順序指定キーを持ち、同じリージョンに存在している場合は、メッセージの順序指定を有効にできるメッセージの順序指定プロパティを設定すると、Pub/Sub サービスは、同じ順序指定キーを使用して、Pub/Sub サービスがメッセージを受信する順序でメッセージを送信します。
Pub/Sub は 1 回限りの配信もサポートしています。
通常、 Pub/Sub は各メッセージを公開された順序で 1 回配信します。ただし、メッセージが順不同で配信される場合や複数回配信される場合があります。Pub/Sub は、メッセージの確認応答リクエストが正常に返された後でもメッセージを再配信する場合があります。この再配信は、サーバー側の再起動やクライアント側の問題などによって発生する可能性があります。そのため、まれに任意のメッセージを再配信できることがあります。複数回の配信に対応するには、メッセージの処理時にサブスクライバーがべき等である必要があります。
サブスクリプションの有効期限
デフォルトでは、サブスクリプションが非アクティブになってから 31 日が経過すると、またはサブスクリプションの更新がない場合、サブスクリプションは期限切れになります。サブスクライバー アクティビティの例としては、オープン接続、アクティブな pull、正常に完了した push などがあります。Pub/Sub が、サブスクライバーのアクティビティまたはサブスクリプション プロパティの更新を検出すると、サブスクリプション削除クロックが再起動されます。サブスクリプション有効期限ポリシーを使用すると、非アクティブ期間を構成することや、アクティビティに関係なくサブスクリプションを永続化することがきます。サブスクリプションを手動で削除することもできます。
削除されたサブスクリプションと同じ名前のサブスクリプションを新しく作成することは可能ですが、その場合、新しいサブスクリプションは古いサブスクリプションとは無関係のものになります。削除されたサブスクリプションに多数の確認応答されていないメッセージがあっても、同じ名前で新しいサブスクリプションを作成すると、そのバックログは存在しません（配信待ちのメッセージは存在しません）。
サブスクリプションの操作の詳細については、サブスクリプションの作成と使用をご覧ください。
次のステップ
- pull サブスクリプションの詳細を見る。
- push サブスクリプションの詳細を見る。
- BigQuery サブスクリプションの詳細