このページは Cloud Translation API によって翻訳されました。

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

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

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

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

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

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 を介した外部管理鍵にアクセスできなくなった場合に発生することがあります。パブリッシュを再開するには、鍵へのアクセスを復元します。

単一メッセージ変換（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 トレースを調べて、パブリッシュレイテンシのデバッグに役立てます。

標準トピックのトラブルシューティング コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

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

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

公開タイムアウト時間が不十分

クライアント ライブラリに関する問題

C++

C#

Go

Java

Node.js

PHP

Python

Ruby