pull サブスクリプション

このドキュメントでは、pull サブスクリプションの概要、ワークフロー、関連するプロパティについて説明します。

pull サブスクリプションでは、サブスクライバー クライアントが Pub/Sub サーバーからメッセージをリクエストします。

pull モードでは、Pull または StreamingPull のいずれかのサービス API を使用できます。選択した API を実行するには、Google が提供する高レベル クライアント ライブラリか、低レベルの自動生成クライアント ライブラリを選択します。非同期メッセージ処理と同期メッセージ処理のどちらかを選択することもできます。

準備

このドキュメントを読む前に、次の内容をよく理解しておいてください。

pull サブスクリプションのワークフロー

pull サブスクリプションの場合、サブスクライバー クライアントが Pub/Sub サーバーに対してリクエストを開始し、メッセージを取得します。サブスクライバー クライアントは、次のいずれかの API を使用します。

ほとんどのサブスクライバー クライアントは、これらのリクエストを直接行いません。代わりに、クライアントは Google Cloudが提供する高レベル クライアント ライブラリを使用します。このライブラリは、内部でストリーミング pull リクエストを実行し、メッセージを非同期で配信します。メッセージのプル方法を細かく制御する必要があるサブスクライバー クライアントの場合、Pub/Sub は低レベルの自動生成された gRPC ライブラリを使用します。このライブラリは、プルリクエストまたはストリーミング プルリクエストを直接作成します。これらのリクエストは同期または非同期にできます。

次の 2 つの画像は、サブスクライバー クライアントと pull サブスクリプション間のワークフローを示しています。

pull サブスクリプションのメッセージのフロー
図 1. pull サブスクリプションのワークフロー



streamingPull サブスクリプションのメッセージのフロー
図 2. ストリーミング プル サブスクリプションのワークフロー

pull ワークフロー

pull ワークフローは次のとおりです（図 1 を参照）。

  1. サブスクライバー クライアントは、配信用のメッセージをリクエストする pull メソッドを明示的に呼び出します。このリクエストは、画像に示す PullRequest です。

  2. Pub/Sub サーバーは、0 個以上のメッセージと確認応答 ID で応答します。メッセージがないレスポンスまたはエラーがあるレスポンスは、受信可能なメッセージが存在しないことを示すとは限りません。このレスポンスは、図に示すように PullResponse です。

  3. サブスクライバー クライアントは、acknowledge メソッドを明示的に呼び出します。クライアントは、返された確認応答 ID を使用して、メッセージが処理済みであり、再度配信する必要がないことを確認します。

単一のストリーミング pull リクエストの場合、サブスクライバー クライアントは、開いている接続が原因で複数のレスポンスを返すことがあります。これに対し、pull リクエストごとに 1 つのレスポンスのみが返されます。

pull サブスクリプションのプロパティ

pull サブスクリプション用に構成するプロパティによって、サブスクリプションにメッセージを書き込む方法が決まります。詳細については、サブスクリプション プロパティをご覧ください。

Pub/Sub サービス API

Pub/Sub の pull サブスクリプションでは、次の 2 つの API のいずれかを使用してメッセージを取得できます。

  • pull
  • StreamingPull

これらの API を使用してメッセージを受信する場合は、単項の Acknowledge RPC と ModifyAckDeadline RPC を使用します。2 つの Pub/Sub API については、以降のセクションで説明します。

StreamingPull API

Pub/Sub クライアント ライブラリでは、スループットを最大にしてレイテンシを最小にするために、StreamingPull を使用します（使用可能な場合）。StreamingPull API を直接使用することがなくても、Pull API との違いを理解することは重要です。

StreamingPull API は、複数のメッセージを受信するために、次の永続的な双方向接続に依存します。ワークフローは次のとおりです。

  1. クライアントが接続を確立するためにサーバーへのリクエストを送信します。接続の割り当てを超えると、サーバーはリソース不足エラーを返します。クライアント ライブラリは、割り当て超過エラーを自動的に再試行します。

  2. エラーがない場合や、接続の割り当てが再び使用可能になった場合、サーバーは接続されたクライアントに継続的にメッセージを送信します。

  3. スループットの割り当てを超過した場合、サーバーはメッセージの送信を停止します。ただし、接続は切断されません。十分なスループットの割り当てが再び利用可能になると、ストリームが再開されます。

  4. クライアントまたはサーバーが最終的に接続を閉じます。

StreamingPull API はオープン接続を維持します。Pub/Sub サーバーは、長時間実行される固定接続を回避するために、一定期間後に接続を閉じます。クライアント ライブラリは、StreamingPull 接続を自動的に再開します。

メッセージが利用可能になると、その接続に送信されます。StreamingPull API は、メッセージのレイテンシを最小限に抑え、スループットを最大化します。

StreamingPull RPC メソッドの詳細については、StreamingPullRequest と StreamingPullResponse をご覧ください。

Pull API

この API は、リクエストとレスポンス モデルに基づく従来の単項 RPC です。1 つの pull レスポンスは 1 つの pull リクエストに対応します。ワークフローは次のとおりです。

  1. クライアントはサーバーにメッセージのリクエストを送信します。 スループットの割り当てを超過すると、サーバーはリソース不足エラーを返します。

  2. エラーがない場合や、スループットの割り当てが再び使用可能になった場合、サーバーは 0 個以上のメッセージと確認応答 ID を返します。

単項 Pull API を使用する場合、メッセージがないレスポンスまたはエラーがあるレスポンスは、受信可能なメッセージが存在しないことを示すとは限りません。

Pull API を使用しても、メッセージの低レイテンシと高スループットは保証されません。Pull API で高スループットと低レイテンシを実現するには、未処理のリクエストが同時に複数存在する必要があります。古いリクエストがレスポンスを受け取ると、新しいリクエストが作成されます このようなソリューションの設計は、エラーが発生しやすく、保守が困難です。このようなユースケースでは、StreamingPull API を使用することをおすすめします。

次のものを厳密に制御する必要がある場合にのみ、StreamingPull API の代わりに Pull API を使用します。

  • サブスクライバー クライアントが処理できるメッセージの数
  • クライアントのメモリとリソース

サブスクライバーが Pub/Sub とより pull 指向で動作する別のサービスの間のプロキシである場合にも、この API を使用できます。

Pull REST メソッドの詳細については、メソッド: projects.subscriptions.pull をご覧ください。

Pull RPC メソッドの詳細については、PullRequest と PullResponse をご覧ください。

メッセージ処理モードの種類

サブスクライバー クライアントに対して、次のいずれかの pull モードを選択します。

非同期 pull モード

非同期 pull モードでは、メッセージの受信とサブスクライバー クライアントでのメッセージ処理が切り離されます。このモードは、ほとんどのサブスクライバー クライアントでデフォルトです。非同期 pull モードでは、StreamingPull API または単一 Pull API を使用できます。非同期 pull では、高レベルのクライアント ライブラリまたは低レベルの自動生成クライアント ライブラリも使用できます。

クライアント ライブラリについては、このドキュメントで後ほど詳しく説明します。

同期 pull モード

同期 pull モードでは、メッセージの受信と処理が順番に行われ、互いに分離されていません。そのため、非同期処理では StreamingPull と単項 pull API と同様に、同期処理よりもレイテンシが短く、スループットが大きくなります。

同期プルモードは、低レイテンシと高スループットが他の要件ほど重要ではないアプリケーションでのみ使用します。たとえば、アプリケーションが同期プログラミング モデルのみを使用するように制限される場合があります。また、リソースの制約があるアプリケーションでは、メモリ、ネットワーク、CPU をより正確に制御する必要がある場合があります。このような場合は、単一 Pull API を備えた同期モードを使用します。

Pub/Sub クライアント ライブラリ

Pub/Sub では、高レベルと低レベルの自動生成クライアント ライブラリが提供されます。

高レベルの Pub/Sub クライアント ライブラリ

高レベル クライアント ライブラリには、リース管理を使用して確認応答の期限を制御するオプションが用意されています。これらのオプションは、コンソールや CLI を使用してサブスクリプション レベルで確認応答期限を構成するよりも細かく設定できます。高レベル クライアント ライブラリには、順序指定配信、1 回限りの配信、フロー制御などの機能のサポートも実装されています。

非同期 pull と StreamingPull API を、高レベルのクライアント ライブラリで使用することをおすすめします。Google Cloud でサポートされているすべての言語が、高レベル クライアント ライブラリの Pull API もサポートしているわけではありません。

高レベル クライアント ライブラリを使用するには、Pub/Sub クライアント ライブラリをご覧ください。

低レベルの自動生成 Pub/Sub クライアント ライブラリ

Pull API を直接使用する必要がある場合は、低レベルのクライアント ライブラリを使用できます。低レベルの自動生成クライアント ライブラリでは、同期処理または非同期処理を使用できます。低レベルの自動生成クライアント ライブラリを使用する場合は、順序指定配信、1 回限りの配信、フロー制御、リース管理などの機能を手動でコーディングする必要があります。

サポートされているすべての言語で、低レベルの自動生成クライアント ライブラリを使用する場合は、同期処理モデルを使用できます。Pull API を直接使用することが賢明な場合は、低レベルの自動生成クライアント ライブラリと同期 pull を使用できます。たとえば、このモデルに依存する既存のアプリケーション ロジックがある可能性があります。

低レベルの自動生成クライアント ライブラリを直接使用するには、 Pub/Sub API の概要をご覧ください。

次のステップ