このドキュメントでは、Pub/Sub StreamingPull サブスクリプションに関する一般的なトラブルシューティングのヒントを紹介します。StreamingPull サブスクリプションでは、StreamingPull API を使用します。
StreamingPull サブスクリプションの詳細については、pull サブスクライバー ガイドをご覧ください。
StreamingPull のエラー率が 100% になる
StreamingPull ストリームは、常に OK 以外のステータスで終了します。単一 RPC とは異なり、StreamingPull はこのステータスはストリームが壊れたことを示しています。リクエストは失敗していません。そのため、StreamingPull API のエラー率が 100% にもなることがありますが、この動作は設計によるものです。
不正な前提条件エラー、使用不可エラー、存在しないエラー
StreamingPull ストリームは常にエラーで終了するため、エラーの診断中にストリーム終了の指標を調べることは役に立ちません。代わりに、Streaming/streaming_pull_response_count などの StreamingPull レスポンス指標を重視します。
次のエラーを探します。
次の場合で発生する可能性のある前提条件失敗のエラー。
Pub/Sub が、無効化された Cloud KMS 鍵を使用してメッセージの復号を試みます。
サブスクリプション バックログに無効な Cloud KMS 鍵で暗号化されたメッセージがある場合、サブスクリプションが一時的に停止されます。
Pub/Sub でリクエストを処理できないときに発生する可能性のある使用不可のエラー。これは一時的な条件であり、クライアント ライブラリはリクエストを再試行します。
存在しないエラー。サブスクリプションが削除された、またはそもそも存在しない場合に発生する可能性があります。後者のケースでは、無効なサブスクリプション パスを指定した場合に発生します。
StreamingPull サブスクリプションにおける小さいメッセージの大きなバックログ
gRPC StreamingPull スタックは高スループットが得られるように最適化されているため、メッセージをバッファリングします。小さいメッセージの大きなバックログを処理しようとすると、メッセージが何度も配信されることがあります。こうしたメッセージはクライアント間で負荷分散されない場合があります。
Pub/Sub サービスとクライアント ライブラリ ユーザー スペースの間のバッファ容量は約 10 MB です。クライアント ライブラリの動作に対するこのバッファの影響を理解するために、次の例を見てみましょう。
サブスクリプションに 10,000 件の 1 KB メッセージのバックログがあります。
シングル スレッドのクライアント インスタンスによる順次処理には、各メッセージに 1 秒かかります。
そのサブスクリプションのためのサービスへの StreamingPull 接続を確立する最初のクライアントインスタンスのバッファは、10,000 件のメッセージで満たされます。
このバッファを処理するには、10,000 秒（約 3 時間）かかります。
その間、バッファ内にある一部のメッセージが確認応答期限を超え、同じクライアントに再送信され、結果として重複が生じます。
複数のクライアント インスタンスが実行されている場合、1 つのクライアントのバッファに滞留しているメッセージは、他のクライアント インスタンスでは使用できません。この状況は、StreamingPull のフロー制御を使用する場合は発生しません。このサービスでは 10 MB のメッセージ全体が一度に処理されることはないため、複数のサブスクライバー間でメッセージの負荷を効率的に分散できます。