このドキュメントは、Pub/Sub トピックをサブスクライブし、サブスクライバー クライアントでメッセージを受信するプロセスに精通していることを前提としています。
Pub/Sub を初めて使用する場合は、クイックスタート ガイドのいずれかを参照して、コンソール、gCloud CLI、またはクライアント ライブラリを使用して Pub/Sub を実行する方法を学んでください。
適切なサブスクリプションを選択する
Pub/Sub は、push サブスクリプションや pull サブスクリプションなどの標準サブスクリプションを提供します。Pub/Sub には、標準のサブスクリプションに加えて、エクスポート サブスクリプションも用意されており、Google Cloud リソースに直接メッセージを保存できます。Dataflow を中継点として使用する必要はありません。たとえば、BigQuery サブスクリプションは BigQuery テーブルにメッセージを保存します。
push サブスクリプションは、次のシナリオで推奨されます。
クライアント ライブラリを依存関係としてインポートするコードをサブスクライバー アプリケーションに含めることはできません。
サブスクライバー クライアントは送信リクエストを送信できません。
サブスクライバー クライアントがサブスクリプションのリストを知らない場合に、同じインスタンスを使用してさまざまなトピックとサブスクリプションからのメッセージを処理する。
一般的なケースでは、高レベル クライアント ライブラリを使用することをおすすめします。単項 pull を使用している場合は、returnImmediately を true に設定しないでください。true に設定すると、pull のパフォーマンスに悪影響を及ぼします。
returnImmediately フィールドは非推奨になりました。
すべてのサブスクリプション タイプを比較し、ビジネスニーズに最適なサブスクリプションを選択するには、Pub/Sub サブスクリプションの比較表をご覧ください。
エクスポート サブスクリプションのメリットについては、エクスポート サブスクリプションを使用するタイミングをご覧ください。
メッセージの確認応答の前にメッセージを処理する
デフォルトでは、メッセージの確認応答後、Pub/Sub はサブスクリプションからメッセージを破棄します。確認応答を送信する前にメッセージを処理せず、処理が失敗した場合、サービスはメッセージを再配信しません。例外は、確認済みメッセージの保持またはトピックの保持を構成し、シーク オペレーションを実行している場合です。
レイテンシの高いサブスクライバーがある場合は、フロー制御とリース管理のカスタム値の設定が必要になる場合があります。
一時的なトラフィック急増に対するサブスクライバー フロー制御を構成する
サブスクライバー側のフロー制御により、トラフィックの急増によってサブスクライバーが過負荷になるのを防ぐことができます。自動スケーリング メカニズムが負荷の増加に応答する時間を確保したり、負荷の処理を長期にわたって分散したりすることができます。前者の方法ではレイテンシが節約され、後者では費用を節約できます。
フロー制御を構成するには、maximum outstanding messages と total outstanding message bytes に適切な値を設定する必要があります。これらのフロー制御変数のデフォルト値と変数名は、クライアント ライブラリによって異なる場合があります。
未処理の最大メッセージは、Pub/Sub が確認応答または否定確認応答を受信していないクライアントに配信されるメッセージの最大数を定義します。
未処理のメッセージの合計バイト数は、Pub/Sub が確認応答または否定確認応答を受け取っていないクライアントに配信されるメッセージの最大サイズを定義します。
これらのオプションのいずれかの上限を超えると、サブスクライバー クライアントはそれ以上メッセージを pull しません。この動作は、すでに pull されているメッセージに対して確認応答が行われるか、否定応答が行われるまで続きます。このようにして、より多くのサブスクライバーの実行にかかるコストとスループットをトレードオフできます。
登録時のメッセージの順序指定のベスト プラクティス
メッセージの順序指定を使用する場合は、次の点を確認してください。
StreamingPull または Pull サブスクリプションを選択します。 push サブスクリプションの場合、Pub/Sub は、順序指定キーごとに一度に 1 つの未処理のメッセージのみをサポートします。このようなシナリオで同時 push リクエストを送信する方法は、同じ順序指定キーに対して複数のメッセージをバッチで送信し、サブスクライバーを同時に pull する場合に似ています。したがって、複数のメッセージが同じ順序指定キーで頻繁にパブリッシュされる場合や、レイテンシが非常に重要になるトピックでは、push サブスクリプションは推奨されません。
サブスクリプションでメッセージの順序指定を有効にします。パブリッシャー側では、順序指定キーと同じリージョン内でメッセージを送信する場合、これらのメッセージを順番に受信するようにサブスクライバーを構成できます。サブスクライバー側では、順序付けされたメッセージを受信するサブスクリプションに対してのみメッセージの順序指定プロパティを有効にします。プロパティのステータスに応じて、トピックに添付された各サブスクリプションは、相互に影響を与えることなく、順序付けされた配信が必要であるかどうかを判断できます。
メッセージを順番に確認する。順序付けされた配信を使用する場合、後のメッセージの確認応答は、順序指定キーごとに以前のメッセージの確認応答が処理されるまで処理されません。たとえば、同じ順序指定キーを持つメッセージ 1、2、3 があり、それらすべてを受信してメッセージ 3 のみを受信した場合、サービスではメッセージ 1 と 2 が確認応答されるまでメッセージ 3 が確認応答されたものとして認識されません。メッセージ 1 と 2 の確認応答が受信されなかった場合、メッセージ 1、2、3 はすべて再配信されます。
ベスト プラクティスの概要
次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。
| トピック | タスク |
|---|---|
| サブスクリプション タイプを選択する | ビジネスニーズに適したサブスクリプション タイプを選択します。サブスクリプションでサポートされている場合は、高レベルのクライアント ライブラリも使用します。 |
| 確認応答済みのメッセージを再生する | メッセージを確認応答する前に処理します。または、確認応答済みのメッセージが失われないように、シーク オペレーション用に構成します。 |
| フロー制御 | 自動スケーリングがフローを開始するまで、または時間が経過するまでサブスクライバーが過負荷にならないように、サブスクライバーの設定でフロー制御を構成します。 |
| メッセージの順序指定 | 順序付けされたメッセージを使用する場合は、StreamingPull または pull を選択し、サブスクリプションでメッセージの順序指定を有効にし、メッセージを順番に確認します。 |