このドキュメントでは、標準の 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 を示しています。使用しているクライアント ライブラリのバージョンに影響する既知の問題が見つかった場合は、クライアント ライブラリの最新バージョンにアップグレードしてください。これにより、修正やパフォーマンスの向上など、関連する更新がすべて適用されます。
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
スキーマに関する問題
パブリッシュが INVALID_ARGUMENT を返し始めた場合、誰かがトピックを更新して関連するスキーマを変更したか、スキーマを削除したか、またはトピックに関連付けられたスキーマ リビジョンを削除した可能性があります。この場合は、トピックのスキーマ設定を更新してスキーマとパブリッシュされているメッセージに一致するリビジョンのセットにするか、メッセージの形式を調整して現在のスキーマと一致するようにします。
メッセージの暗号化に関する問題
パブリッシュされたメッセージを顧客管理の暗号鍵を使用して暗号化するように Pub/Sub トピックを構成している場合、パブリッシュが失敗して FAILED_PRECONDITION エラーが発生することがあります。このエラーは、Cloud KMS 鍵が無効になっている場合や、Cloud EKM を介した外部管理鍵にアクセスできなくなった場合に発生することがあります。パブリッシュを再開するには、鍵へのアクセスを復元します。