このドキュメントでは、標準 Pub/Sub トピックにメッセージをパブリッシュする際の一般的なトラブルシューティングのヒントを紹介します。
詳細については、メッセージをトピックへパブリッシュする方法とさまざまな機能をご覧ください。
パブリッシュの高レイテンシ
パブリッシュのレイテンシとは、パブリッシャー クライアントが発行したパブリッシュ リクエストの完了にかかる時間です。パブリッシュのレイテンシは、エンドツーエンドの配信レイテンシとは異なります。エンドツーエンドの配信レイテンシとは、Pub/Sub にパブリッシュされたメッセージがサブスクライバー クライアントに配信されるのにかかる時間です。他のレイテンシ タイプの値が小さい場合でも、パブリッシュ レイテンシまたはエンドツーエンドのレイテンシが高くなることがあります。Pub/Sub パブリッシャー クライアント、クライアントと Pub/Sub バックエンド間の転送、Pub/Sub バックエンドでは、パブリッシュのレイテンシが高くなる可能性があります。Pub/Sub バックエンドで発生するパブリッシュのレイテンシは、topic/send_request_latencies 指標を使用して検査できます。バックエンドのパブリッシュのレイテンシが高い場合、次の要因が関連している可能性があります。
Pub/Sub は、低レイテンシ、高スループットの配信向けに設計されています。トピックのスループットが低い場合、トピックに関連付けられたリソースの初期化に時間がかかることがあります。
メッセージ ストレージ ポリシーを使用している場合、トピックとサブスクリプションへのリクエストの全体的なレイテンシに影響する可能性があります。この構成の使用に関するパフォーマンスと可用性への影響を確認してください。
パブリッシャー クライアントのパブリッシュのレイテンシが指標に反映されているレイテンシよりも大幅に高い場合は、クライアント側の以下のいずれかの要因を示している可能性があります。
毎回のパブリッシュで新しいパブリッシャーを作成しないようにします。アプリケーションごと、トピックごとに 1 つのパブリッシャー クライアントを使用してすべてのメッセージをパブリッシュすることをおすすめします。新しいパブリッシャー オブジェクトをスピンアップし、新しいスレッドを追加すると、レイテンシのコストがかかります。Cloud Functions を使用してメッセージをパブリッシュする場合、呼び出しがパブリッシュのレイテンシに影響することもあります。
デフォルトの再試行設定がユースケースに十分でないことがわかった場合は、対応する調整を行います。ただし、新しい値が高すぎないようにしてください。リクエストの再試行の構成方法をご覧ください。
パブリッシュのレイテンシが高いと、次のセクションで説明する DEADLINE_EXCEEDED エラーが発生するおそれがあることに注意してください。
パブリッシュ操作が DEADLINE_EXCEEDED で失敗する
パブリッシュ リクエスト中の DEADLINE_EXCEEDED エラーは、割り当てられた時間内にリクエストが正常に完了しなかったことを示します。この原因として、リクエストが Pub/Sub サービスに到達しない、パフォーマンスの問題がリクエストに影響しているなど、さまざまな要因が考えられます。
パブリッシュ リクエストが Pub/Sub サービスに到達したことを確認するには、response_code でグループ化された topic/send_request_count 指標を使用してトピックをモニタリングします。この指標は、Pub/Sub トピックに到達する前にリクエストが失敗するのかどうかを判断するのに役立ちます。指標が空の場合、メッセージが Pub/Sub サービスに到達する妨げとなっている外部要因があります。また、断続的な問題の可能性を除外するには、エラー率を確認します。エラー率が非常に低い場合は、断続的な問題である可能性があります。
リクエストが Pub/Sub に到達している場合、DEADLINE_EXCEEDED エラーによりパブリッシュ オペレーションが失敗する原因はいくつかあります。
クライアント側のボトルネック
パブリッシュの失敗は、クライアント側のボトルネック（メモリ不足、CPU 圧縮、スレッドの状態不良、パブリッシャー クライアントをホストする VM のネットワークの輻輳など）が原因で発生している可能性があります。Publish 呼び出しが DEADLINE_EXCEEDED を返す場合は、非同期 Publish 呼び出しのキューへの追加速度がサービスへの送信より速いために、リクエストのレイテンシが徐々に長くなっている可能性があります。また、システム内でのボトルネック発生の可能性を特定するために、次のいずれかが役立つかどうかを確認します。
メッセージのパブリッシュが、クライアントがメッセージを送信するよりも速いかどうかを確認します。通常、非同期
Publish呼び出しによってFutureオブジェクトが返されます。送信を待機しているメッセージの数を追跡するには、Publish呼び出しごとに送信されるメッセージの数を保存し、このうちFutureオブジェクトのコールバックに含まれているものだけを削除します。パブリッシャーが実行されているマシンと Google Cloud 間で十分なアップロードの帯域幅があることを確認します。開発用 Wi-Fi ネットワークの帯域幅は通常 1 ～ 10 MB/秒、一般的なメッセージは 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 MB/秒〜700 MB/秒を達成できます。
不十分なパブリッシュ タイムアウト期間
パブリッシュ呼び出しのタイムアウト率を下げるには、パブリッシャー クライアントの再試行設定に十分なタイムアウトが定義されていることを確認してください。再試行の設定では、最初の期限を 10 秒、合計タイムアウトを 600 秒に設定します。未送信のメッセージの大規模なバックログが蓄積されていない場合でも、リクエスト レイテンシの一時的な急増により、パブリッシュ呼び出しがタイムアウトになる可能性があります。ただし、問題を起こす原因がときどき発生するタイムアウトではなく永続的なボトルネックである場合は、再試行回数を増やすとエラーが増える可能性があります。
クライアント ライブラリに関する問題
既知の問題があるクライアント ライブラリのバージョンが実行されている可能性があります。次のリストは、すべてのクライアント ライブラリの Issue Tracker を示しています。使用しているクライアント ライブラリのバージョンに影響する既知の問題が見つかった場合は、クライアント ライブラリの最新バージョンにアップグレードします。これにより、修正やパフォーマンスの向上など、関連するすべての更新を確実に受け取ることができます。
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
スキーマに関する問題
パブリッシュが INVALID_ARGUMENT を返し始めた場合、誰かがトピックを更新して関連するスキーマを変更したか、スキーマを削除したか、またはトピックに関連付けられたスキーマ リビジョンを削除した可能性があります。この場合は、トピックのスキーマ設定を更新してスキーマとパブリッシュされているメッセージに一致するリビジョンのセットにするか、メッセージの形式を調整して現在のスキーマと一致するようにします。
メッセージ暗号化に関する問題
顧客管理の暗号鍵を使用してパブリッシュされたメッセージを暗号化するように Pub/Sub トピックを構成している場合、パブリッシュが FAILED_PRECONDITION エラーで失敗する可能性があります。このエラーは、Cloud KMS 鍵が無効になっているか、Cloud EKM で外部管理された鍵にアクセスできない場合に発生することがあります。パブリッシュを再開するには、鍵へのアクセスを復元します。