標準トピックのトラブルシューティング

このドキュメントでは、標準の Pub/Sub トピックにメッセージをパブリッシュする際の一般的なトラブルシューティングのヒントを示します。

詳細については、メッセージをトピックへパブリッシュする方法とさまざまな機能をご覧ください。

パブリッシュの高レイテンシ

パブリッシュのレイテンシとは、パブリッシャー クライアントが発行したパブリッシュ リクエストの完了にかかる時間です。パブリッシュのレイテンシは、エンドツーエンドの配信レイテンシとは異なります。エンドツーエンドの配信レイテンシとは、Pub/Sub にパブリッシュされたメッセージがサブスクライバー クライアントに配信されるのにかかる時間です。他のレイテンシ タイプの値が小さい場合でも、パブリッシュ レイテンシまたはエンドツーエンドのレイテンシが高くなることがあります。Pub/Sub パブリッシャー クライアント、クライアントと Pub/Sub バックエンド間の転送、Pub/Sub バックエンドでは、パブリッシュのレイテンシが高くなる可能性があります。topic/send_request_latencies 指標を使用して、Pub/Sub バックエンドで発生したパブリッシュ レイテンシを調べることができます。バックエンドのパブリッシュ レイテンシが高い場合は、次の要因が考えられます。

  • Pub/Sub は、低レイテンシ、高スループットの配信向けに設計されています。トピックのスループットが低い場合、トピックに関連付けられたリソースの初期化に時間がかかることがあります。

  • メッセージ ストレージ ポリシーを使用している場合、トピックとサブスクリプションに対するリクエストの全体的なレイテンシに影響する可能性があります。この構成を使用した場合のパフォーマンスと可用性への影響を確認します。

パブリッシャー クライアントのパブリッシュのレイテンシが指標に反映されているレイテンシよりも大幅に高い場合は、クライアントサイドの以下のいずれかの要因を示している可能性があります。

  • 毎回のパブリッシュで新しいパブリッシャーを作成しないようにします。アプリケーションごと、トピックごとに 1 つのパブリッシャー クライアントを使用してすべてのメッセージをパブリッシュすることをおすすめします。新しいパブリッシャー オブジェクトをスピンアップし、新しいスレッドを追加すると、レイテンシのコストがかかります。Cloud Run functions を使用してメッセージをパブリッシュしている場合、呼び出しもパブリッシュ レイテンシに影響する可能性があることに注意してください。

  • デフォルトの再試行設定がユースケースに十分でないことがわかった場合は、対応する調整を行います。ただし、新しい値が高すぎないことを確認してください。リクエストの再試行の構成方法をご覧ください。

パブリッシュのレイテンシが高いと、次のセクションで説明する DEADLINE_EXCEEDED エラーが発生するおそれがあることに注意してください。

パブリッシュ操作が DEADLINE_EXCEEDED で失敗する

パブリッシュ リクエスト中の DEADLINE_EXCEEDED エラーは、割り当てられた時間内にリクエストが完了しなかったことを示します。この原因として、リクエストが Pub/Sub サービスに到達しない、パフォーマンスの問題がリクエストに影響しているなど、さまざまな要因が考えられます。

パブリッシュ リクエストが Pub/Sub サービスに到達していることを確認するには、response_code でグループ化された topic/send_request_count 指標を使用してトピックをモニタリングします。この指標は、Pub/Sub トピックに到達する前にリクエストが失敗するかどうかを判断するのに役立ちます。指標が空の場合、メッセージが Pub/Sub サービスに到達する妨げとなっている外部要因があります。また、断続的な問題の可能性を排除するには、前述の topic/send_request_count 指標グラフまたはGoogle Cloud コンソールの [API とサービス] ページを使用して、エラー率を確認します。エラー率が非常に低い場合は、断続的な問題である可能性があります。

リクエストが Pub/Sub に到達している場合、DEADLINE_EXCEEDED エラーによりパブリッシュ オペレーションが失敗する原因はいくつかあります。

クライアント側のボトルネック

パブリッシュの失敗は、クライアント側のボトルネック（メモリ不足、CPU 圧縮、スレッドの状態不良、パブリッシャー クライアントをホストする VM のネットワークの輻輳など）が原因で発生している可能性があります。Publish 呼び出しが DEADLINE_EXCEEDED を返す場合は、非同期 Publish 呼び出しのキューへの追加速度がサービスへの送信より速いために、リクエストのレイテンシが徐々に長くなっている可能性があります。また、システム内でのボトルネック発生の可能性を特定するために、次のいずれかが役立つかどうかを確認します。

  • メッセージのパブリッシュが、クライアントがメッセージを送信するよりも速いかどうかを確認します。通常、非同期 Publish 呼び出しによって Future オブジェクトが返されます。送信を待機しているメッセージの数を追跡するには、Publish 呼び出しごとに送信されるメッセージの数を保存し、このうち Future オブジェクトのコールバックに含まれているものだけを削除します。

  • パブリッシャーが実行されているマシンと Google Cloudの間で十分なアップロードの帯域幅があることを確認します。開発用 Wi-Fi ネットワークの帯域幅は通常 1 ～ 10 MBps、一般的なメッセージは 1 秒あたり 1,000 ～ 10,000 件です。レート制限なしでメッセージをループしてパブリッシュすると、短期間に高帯域幅の急増が生じる可能性があります。これを回避するには、 Google Cloud 内のマシンでパブリッシャーを実行するか、利用可能な帯域幅に合わせてメッセージをパブリッシュするレートを下げます。

  • 起動時のネットワークの輻輳やファイアウォールなどの理由による、ホストと Google Cloud間のレイテンシが非常に大きいかどうかを確認します。ネットワーク スループットの計算には、さまざまなシナリオでの帯域幅とレイテンシを調べるためのヒントがあります。

  • 最終的に、1 台のマシンでパブリッシュできるデータ量には限界があります。複数のマシンで、水平スケーリングやパブリッシャー クライアントの複数インスタンスの実行を試みる必要がある場合もあります。Cloud Pub/Sub クライアントをテストしてストリーミングのパフォーマンスを最大化するでは、1 つの Google Cloud VM で CPU の数を増やして、Pub/Sub をスケーリングする方法を示しています。たとえば、16 コアの Compute Engine インスタンスで 1 KB のメッセージに対して 500 MBps〜700 MBps を達成できます。

公開タイムアウトの時間が不適切

パブリッシュ呼び出しのタイムアウト率を下げるには、パブリッシャー クライアントの再試行設定で十分な長さのタイムアウトが定義されていることを確認します。再試行設定で、最初の期限を 10 秒、合計タイムアウトを 600 秒に設定します。未送信のメッセージの大規模なバックログが蓄積されていない場合でも、リクエスト レイテンシの一時的な急増により、パブリッシュ呼び出しがタイムアウトになる可能性があります。ただし、問題の原因がときどき発生するタイムアウトではなく永続的なボトルネックである場合は、再試行回数を増やすとエラーが増える可能性があります。

クライアント ライブラリの問題

既知の問題があるクライアント ライブラリのバージョンが実行されている可能性があります。次のリストは、すべてのクライアント ライブラリの Issue Tracker を示しています。使用しているクライアント ライブラリのバージョンに影響する既知の問題が見つかった場合は、クライアント ライブラリの最新バージョンにアップグレードしてください。これにより、修正やパフォーマンスの改善など、関連性のある更新をすべて取得できます。

スキーマに関する問題

パブリッシュが INVALID_ARGUMENT を返し始めた場合、誰かがトピックを更新して関連するスキーマを変更したか、スキーマを削除したか、またはトピックに関連付けられたスキーマ リビジョンを削除した可能性があります。この場合は、トピックのスキーマ設定を更新してスキーマとパブリッシュされているメッセージに一致するリビジョンのセットにするか、メッセージの形式を調整して現在のスキーマと一致するようにします。

メッセージの暗号化に関する問題

顧客管理の暗号鍵を使用してパブリッシュされたメッセージを暗号化するように Pub/Sub トピックを構成している場合、パブリッシュが FAILED_PRECONDITION エラーで失敗することがあります。このエラーは、Cloud KMS 鍵が無効になっている場合や、Cloud EKM を介して外部管理の鍵にアクセスできなくなった場合に発生することがあります。公開を再開するには、鍵へのアクセスを復元します。

メッセージ ストレージ ポリシーに関する問題

サブスクリプションがパブリッシュされたメッセージを受信しない場合、トピックにメッセージ ストレージ ポリシーが有効になっている可能性があります。その場合、公開指標に FAILED_PRECONDITION エラーが表示されることがあります。

通常、これらのエラーには次のようなメッセージが含まれます。

Cannot publish messages that contain ordering keys
to topic projects/...  due a message storage policy on the topic that would
require the messages to be forwarded to another region. Please either change
the topic's message storage policy or publish to an allowed region using
the appropriate regional Cloud Pub/Sub endpoint.

または

The topic's message storage policy requires enforcement
in transit, but the Publish request was received by a Pub/Sub server in
a non-allowed region. Please either publish via a regional Pub/Sub endpoint
corresponding to an allowed region, or update the topic's message storage policy.

この問題を解決するには、以下のいずれかを行います。

  • トピックのメッセージ ストレージ ポリシーを更新して、リージョンを許可します。
  • 適切なリージョン Pub/Sub エンドポイントを使用して、許可されたリージョンにパブリッシュするようにパブリッシャー クライアントを構成します。

単一メッセージ変換（SMT）に関する問題

Pub/Sub トピックで SMT を構成している場合、メッセージに変換を適用できないと、パブリッシュが INVALID_ARGUMENT エラーで失敗することがあります。パブリッシュ バッチ内のいずれかのメッセージの変換が失敗すると、バッチ全体のパブリッシュが失敗します。返されたエラーは、失敗の理由を示します。次に例を示します。

INVALID_ARGUMENT: Pub/Sub failed to apply a message transformation to one or
more messages in the publish request. Error: Failed to execute JavaScript UDF:
`my_function`. Return value is not an object.

SMT をモニタリングする

トピックに対する SMT のパフォーマンスと影響を把握するには、次のモニタリング指標を使用します。

topic/message_transform_latencies 指標は、SMT がメッセージに適用されるまでの時間を測定します。この指標は SMT レイテンシのみを測定し、メッセージ配信時間の他の部分は含まれません。

この指標には、次の 2 つの主要なラベルがあります。

  • status: 変換が成功したか、問題が発生したかを報告します。

  • filtered: SMT によってメッセージがフィルタされたかどうかを示します。SMT がトピックのメッセージをフィルタリングすると、Pub/Sub はメッセージを削除し、メッセージはサブスクライバーに送信されません。この filtered ラベルは、SMT がフィルタリングを実行する場合にのみ true になります。Pub/Sub の組み込みのフィルタリング機能を使用してフィルタされたメッセージは、この特定の指標には反映されません。

topic/byte_cost 指標は、SMT によってフィルタされたメッセージや、SMT が失敗したメッセージを特定するために使用されます。次の特定の値を探します。

  • SMT がメッセージをフィルタリングすると、operation_type は smt_publish_filter_drop になります。

  • SMT がメッセージの変換に失敗すると、OK ではない response_code が表示されます。

次のステップ

OpenTelemetry トレースを調べて、パブリッシュ レイテンシのデバッグに役立ててください。