Pub/Sub トピックにパブリッシュするためのベスト プラクティス

パブリッシュでは、パブリッシャー クライアントが Pub/Sub トピックにメッセージを送信します。Pub/Sub にメッセージをパブリッシュする際のベスト プラクティスを以下に示します。

このドキュメントでは、Pub/Sub トピックへのメッセージのパブリッシュ プロセスにすでに精通していることを前提としています。

Pub/Sub を初めて使用する場合は、クイックスタート ガイドのいずれかを参照して、コンソール、gCloud CLI、またはクライアント ライブラリを使用して Pub/Sub を実行する方法を学んでください。

パブリッシュを開始する前に、サブスクリプションを接続するか、トピックの保持を有効にする

サブスクライバーが関連付けられていないトピックへのパブリッシュを開始した場合、メッセージは保持されません。これらのメッセージは、後で接続されたサブスクリプションに配信できません。そのため、メッセージのパブリッシュを開始する前に、次のいずれかを行います。

バッチ メッセージを構成する

Pub/Sub では、バッチ メッセージとは、複数のメッセージを 1 つのバッチにまとめ、1 回のパブリッシュ リクエストでパブリッシュするプロセスを指します。クライアント ライブラリを使用してメッセージをパブリッシュする場合、バッチ処理はデフォルトで有効になっています。メッセージのバッチ処理（またはグループ化）により、パブリッシャーの効率が改善して、より高いスループットでメッセージを送信できます。バッチ処理によりデータのパブリッシュ コストを削減できます。ただし、バッチ処理では、パブリッシャーはバッチがいっぱいになるのを待ってからバッチをパブリッシュするため、個々のメッセージにもレイテンシが発生します。

Pub/Sub のレイテンシには次の 2 種類があります。

  • エンドツーエンドのレイテンシは、メッセージがパブリッシャーによってパブリッシュされ、処理のために対応するサブスクライバーに配信されるまでにかかる時間です。

  • パブリッシュのレイテンシは、メッセージをパブリッシュするまでにかかる時間です。

バッチ処理を使用する場合、両方のタイプのレイテンシを増やすと、効率とスループットが向上する一方で、トレードオフが発生します。

クライアント ライブラリ内のメッセージは、メッセージ リクエストのサイズ、メッセージの数、時間に基づいてバッチ処理できます。バッチ設定を構成する際に、ユースケースに合わせて費用、スループット、レイテンシの適切なバランスを見つけることができます。

バッチ メッセージング変数のデフォルト値と変数の名前は、クライアント ライブラリによって異なる場合があります。 クライアント ライブラリでは、1 つまたは 3 つすべての値を指定できます。バッチ メッセージ変数のいずれかの値が満たされると、クライアント ライブラリは次のメッセージのバッチをパブリッシュします。

パブリッシャー クライアントのバッチ メッセージを構成するには、パブリッシュ リクエストのバッチ メッセージをご覧ください。

一時的なメッセージの急増に対するフロー制御を構成する

パブリッシャー クライアントが多数のメッセージを処理する必要がある場合、Deadline exceeded エラーでメッセージのパブリッシュができなくなるまで、パブリッシュ リクエストがメモリに蓄積される可能性があります。

メッセージのパブリッシュの一時的な急増に対処するために、パブリッシャーの設定でフロー制御を使用できます。パブリッシャー側のフロー制御により、パブリッシャー クライアント リソースが過剰な未処理のリクエストによって圧迫されるのを防ぎます。パブリッシャー クライアントがメモリや CPU、スレッドに制約を受けると、Deadline exceeded エラーが大量に発生します。

クライアント ライブラリでフロー制御を構成するには、最大未処理メッセージ数と最大未処理メッセージ バイト数の各変数に適切な値を設定します。この 2 つの値で、メッセージのスループットとシステム容量のバランスをとります。

クライアント ライブラリがパブリッシャーのフロー制御をサポートしているかどうかを確認し、それを構成する場合は、フロー制御をご覧ください。

ネットワークの帯域幅とレイテンシについて

パブリッシャーのスループットは、ネットワーク帯域幅と送信されるリクエストの数によって制限されます。帯域幅が十分でもネットワーク レイテンシが大きい場合は、多数の小さなリクエストでシステムを圧迫することは避けてください。パブリッシャー側のフロー制御は、クライアント側のネットワークの問題を解決するのに役立ちます。

パブリッシャーのスループットは CPU とメモリにも依存します。利用可能なマシンコアが多いほど、パブリッシュのスループットを向上させるためにスレッド数を増やすことができます。ストリーミングのパフォーマンスを最大化する方法の詳細については、Cloud Pub/Sub クライアントのテストによるストリーミングのパフォーマンスの最大化をご覧ください。

失敗したパブリッシュの再試行リクエスト変数を調整する

パブリッシャー クライアントによってメッセージがパブリッシュされる際に、パブリッシュ エラーが表示されることがあります。このようなエラーは、通常、クライアント側のボトルネック（サービス CPU の不足、スレッドの状態不良、ネットワークの輻輳など）が原因です。publisher retry policy により、メッセージ配信に失敗した場合の動作が決まります。再試行ポリシーでは、Pub/Sub がメッセージの配信を試行する回数と、各試行間の間隔を定義します。

たとえば、Pub/Sub 用の Java クライアント ライブラリでは、パブリッシャー クライアントに次の値が含まれています。

  • initialRetryDelay。パブリッシャーがパブリッシュ オペレーションを再試行するまで待機する初期遅延時間。デフォルト値は 100 milliseconds です。

  • retryDelayMultiplier。再試行間の遅延を計算するために使用される乗算係数。デフォルト値は 4 です。つまり、再試行間の遅延は 2 回目の再試行では最大 100 milliseconds * 4 = 400 milliseconds、3 回目の再試行では最大 400 milliseconds * 4 = 1600 milliseconds になります。

  • maxRetryDelay。パブリッシャーがパブリッシュ オペレーションを再試行するまでの最大遅延時間。デフォルト値は 60 seconds です。

  • initialRpcTimeout。パブリッシャーが RPC 呼び出しの完了を待機する初期タイムアウト。デフォルト値は 5 seconds です。

  • rpcTimeoutMultiplier。RPC タイムアウトを計算するために使用される乗算係数。デフォルト値は 4.0 です。つまり、RPC 呼び出しのタイムアウトは 2 回目の再試行で最大 5 seconds * 4 = 20 seconds、3 回目の再試行で最大 10 seconds * 4 = 40 seconds になります。

  • maxRpcTimeout。パブリッシャーが RPC 呼び出しの完了を待機する最大タイムアウト。デフォルト値は 600 seconds です。

  • totalTimeout。公開オペレーションの合計タイムアウト。これには、RPC 呼び出しが完了するまでの待機時間と、再試行するまでの待機時間が含まれます。デフォルト値は 600 seconds です。

デフォルトの再試行設定ではユースケースに対して十分でないと判断した場合にのみ、指定された値を調整します。たとえば、多数のメッセージをパブリッシュする場合でも、initialRetryDelay と maxRetryDelay の値を増やす必要はありません。ただし、このような状況では、フロー制御とバッチ処理を調整できます。不安定なインターネット接続や帯域幅に制限がある接続でパブリッシュする場合は、initialRpcTimeout、maxRpcTimeout、rpcTimeoutMultiplier の各変数の値を試してみることができます。推奨される値については、パブリッシュ操作が DEADLINE_EXCEEDED で失敗するをご覧ください。

メッセージ ストレージ ポリシーを使用してデータの局所性を確保する

Pub/Sub のトピックのメッセージ ストレージ ポリシーによって、パブリッシュ リクエストの発行元に関係なく、トピックにパブリッシュされるメッセージが、指定した Google Cloud のリージョン セットの外部に保持されないようにします。

メッセージ ストレージ ポリシーを使用して、Pub/Sub がメッセージ データをディスクに保存することを許可する Google Cloud リージョンのリストを指定します。このリストにないリージョンにメッセージがパブリッシュされると、リクエストは最も近い許可されたリージョンに転送されて処理されます。このポリシーは、トピックまたはプロジェクト、プロジェクト フォルダ、組織全体の組織のポリシーとして構成できます。組織のポリシーが構成されている場合、個々のトピック ポリシーは、組織のポリシーに違反しない方法でのみ変更できます。

たとえば、ヨーロッパで事業を行う企業は、メッセージ ストレージ ポリシーを使用して、現地の法律を遵守するためにすべてのデータが EU リージョンに保管されるようにできます。

詳細については、メッセージ ストレージ ポリシーを構成するをご覧ください。

パブリッシュ時のメッセージの順序指定のベスト プラクティス

メッセージの順序指定を使用する場合は、以下の点を確認してください。

  • ロケーション エンドポイントを使用する。メッセージの順序は、パブリッシュ側とリージョン内で保持されます。つまり、複数のリージョンにメッセージをパブリッシュする場合、同じリージョン内のメッセージのみが整合性のある順序で配信されます。メッセージがすべて同じリージョンにパブリッシュされていても、サブスクライバーが複数のリージョンに分散している場合は、サブスクライバーはすべてのメッセージを順番に受信します。同じリージョンにメッセージをパブリッシュするには、ロケーション エンドポイントを使用します。

  • パブリッシュ再開機能を構成する。クライアント ライブラリがリクエストを再試行し、メッセージに順序指定キーがある場合、クライアント ライブラリは再試行の設定にかかわらずリクエストを繰り返し再試行します。再試行不可能なエラーが発生すると、クライアント ライブラリはメッセージをパブリッシュせず、同じ順序指定キーが含まれる他のメッセージのパブリッシュを停止します。パブリッシュに失敗した順序指定キーでパブリッシュを継続する準備ができたら、resumePublish メソッドを呼び出します。

ベスト プラクティスの概要

次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。

トピック タスク
メッセージ保持を構成する メッセージ保持をパブリッシュまたは有効にする前に、サブスクリプションを接続します。
パブリッシュ リクエスト内のメッセージのバッチ処理 メッセージをバッチ処理またはグループ化し、パブリッシャーの効率を上げてより高いスループットでメッセージを送信します。
フロー制御 一時的なトラフィックの急増を処理するには、パブリッシャーの設定でフロー制御を構成します。
Pub/Sub クライアントのテストによるストリーミングのパフォーマンスの最大化 使用可能なマシンのコアとネットワーク帯域幅を増やして、パブリッシャーのスループットを上げます。
リクエストを再試行する デフォルトの再試行設定ではユースケースに対して十分でないと判断した場合にのみ、パブリッシャーの再試行ポリシーで指定された値を調整します。
メッセージ ストレージ ポリシーを構成する メッセージ ストレージ ポリシーを使用して、特定のロケーションにのみメッセージ データをディスクに保存します。
パブリッシュで順序指定キーを使用する場合にロケーション エンドポイントを使用する 順序指定メッセージを使用する場合は、ロケーション エンドポイントでパブリッシュの失敗に対処するパブリッシュ再開機能を構成します。

次のステップ