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