このドキュメントでは、Pub/Sub の pull サブスクリプションの一般的なトラブルシューティングのヒントを示します。pull サブスクリプションの詳細については、pull サブスクライバー ガイドをご覧ください。
Pub/Sub サブスクリプションを効果的にモニタリングするには、まず配信レイテンシの健全性スコア（subscription/delivery_latency_health_score）を確認して、予期しないレイテンシやレイテンシの増加に貢献している要因を確認することをおすすめします。
確認応答されていない最も古いメッセージの経過時間が増加し続ける
oldest_unacked_message_age は、Pub/Sub サブスクリプションの正常性をモニタリングするための重要な指標です。サブスクライバーによって確認応答（ACK）されていない、サブスクリプションのバックログ内の最も古いメッセージの経過時間（秒単位）を測定します。この指標は、潜在的な処理の遅延やボトルネックに関する貴重な分析情報を提供します。
メッセージのバックログをモニタリングすることで、タイムリーで効率的なメッセージ処理が実現します。確認応答されていない最も古いメッセージの経過時間をトラッキングすることで、コンシューマが遅れている状況を事前に特定できます。こうすることで、パフォーマンスの低下に関連する潜在的な問題に対処するために、早期の介入が可能になります。
調査できる一般的なバックログの問題には、次のようなものがあります。
クライアントの構成に関する問題
oldest_unacked_message_age と num_undelivered_messages の両方の指標が同時に増加する場合は、サブスクライバーがメッセージの量についていけていないことを示している可能性があります。この場合、定期購入コンポーネントに焦点を当てて調査します。
クライアントの健全性: サブスクライバー クライアントをホストするマシンのリソース使用率（CPU、メモリ、ネットワーク帯域幅など）を分析します。処理効率を阻害する可能性のある問題点を確認します。
クライアント コード: 最近のコード変更を確認し、エラーログを調べます。サブスクライバー コードのバグや非効率性は、メッセージ処理速度に大きな影響を与える可能性があります。なお、特定のメッセージで問題が発生する可能性があります。たとえば、複数のメッセージがデータベース内の同じ行に同時にアクセスすることが必要な場合があります。この動作により、競合や高レイテンシが発生する可能性があります。
割り当ての制限: ホスティング サービスによって課される Pub/Sub の割り当てまたは制限を超えていないことを確認します。サブスクライバーが Google Cloud でホストされている場合は、潜在的なボトルネックを回避するために Compute Engine または GKE のリソース割り当てを確認します。
サブスクライバーがメッセージを否定応答した
サブスクライバーがメッセージを否定応答（nack）すると、メッセージが正常に処理されなかったことを Pub/Sub に通知します。その後、Pub/Sub は同じメッセージの再配信を試みます。メッセージの nack が繰り返されると、重複が発生し、メッセージの配信が大幅に遅れる可能性があります。
メッセージをナックしても、次の pull で別のメッセージが取得されるとは限りません。Pub/Sub の再配信ポリシーでは、新しいメッセージよりも前に確認応答されたメッセージが再配信される可能性があります。そのため、特定のメッセージをフィルタまたはスキップする方法として nack に依存しないでください。代わりに、再試行ポリシー（できれば指数バックオフ）を設定して、後で処理できる可能性が高いが再配信までに少し時間のかかる個々のメッセージをバックオフします。
特定のメッセージを意図的にスキップする必要がある場合は、処理しない場合でも、そのメッセージを ack することをおすすめします。これにより、それらのアイテムはサブスクリプションから削除され、不要な再配信が回避され、リソースの消費が削減されます。意図的かどうかにかかわらず、メッセージを未確認のままにすると、バックログの問題と重複配信が発生します。
配信レイテンシが高い
Pub/Sub の配信レイテンシは、パブリッシャーからのメッセージがサブスクライバーに届くまでの時間です。配信レイテンシが長くなる原因として、次のことが考えられます。
チャンネル登録者が少ない
StreamingPull を使用するクライアントの場合、常に低レイテンシを実現するには、サブスクリプションに対する StreamingPull のオープン接続を複数維持します。有効なサブスクライバー接続がないと、Pub/Sub はメッセージを迅速に配信できません。単一のストリームが単一障害点になり、遅延のリスクが高まります。subscription/open_streaming_pulls 指標は、アクティブなストリーミング接続の数を表示します。これにより、受信メッセージを処理するのに十分なストリームが常に確保されます。
単項 pull を使用するクライアントの場合、常に低レイテンシを実現するには、サブスクリプションに対する未処理の pull リクエストを複数保持します。頻度の低いリクエストでは、バックログにメッセージが蓄積され、レイテンシが増加する可能性があります。このアプローチにより、接続性のギャップを最小限に抑え、配信のレイテンシを改善できます。
高レベル クライアント ライブラリは、運用上のオーバーヘッドと処理コストを最小限に抑えながら、高スループットと低レイテンシを必要とする場合に推奨されます。高レベル クライアント ライブラリのデフォルトでは、StreamingPull API を使用します。これは、レイテンシを最小限に抑えるのに役に立つ傾向があるためです。高レベル クライアント ライブラリには、認証、スループット、レイテンシの最適化、メッセージのフォーマットなどの機能のために基盤となる API 呼び出しを処理するビルド済み関数とクラスが含まれています。
クライアントの構成に関する問題
クライアント構成の問題をご覧ください。
バックログが多い
Pub/Sub サブスクリプションの未確認メッセージのメッセージ バックログは、メッセージがサブスクライバーによってすぐに処理されないため、エンドツーエンドのレイテンシが本質的に増加します。
順序指定キーと 1 回限りの配信
順序指定キーと 1 回限りの配信は重要な機能ですが、正しく配信するには Pub/Sub 内で追加の調整が必要です。この調整により、可用性が低下し、レイテンシが増加する可能性があります。定常状態では差異は最小限ですが、必要な調整手順を行うと、一時的にレイテンシが増加したり、エラー率が増加したりする可能性があります。順序指定が有効になっている場合、同じ順序指定キーを持つ以前のメッセージが ACK されるまでは、順序指定キーを持つメッセージは配信できません。
アプリケーションにおいて、メッセージの順序指定と 1 回限りの配信が絶対的に不可欠かどうかを検討してください。低レイテンシが最優先の場合は、これらの機能の使用を最小限に抑えることで、メッセージ処理の遅延を減らすことができます。
メッセージ サイズの増加
メッセージ サイズが急増すると、Pub/Sub とクライアントとの間の転送時間が長くなり、クライアント側でのメッセージの処理時間が長くなる可能性があります。
配信レイテンシの増加が確認された場合は、topic_id でグループ化された topic/message_sizes 指標を使用してメッセージサイズを確認できます。メッセージ サイズの急増と、確認されたパフォーマンスの問題を関連付ける。
メッセージが見つからない
メッセージがサブスクライバーに正常に配信されていないと思われる場合は、次のいずれかの理由が原因である可能性があります。
複数のコンシューマを使用する Pub/Sub サブスクリプションでのメッセージの分散
Pub/Sub では、メッセージがコンシューマ間で均等に分散されないことがあります。この動作は、Pub/Sub が効率性を高めるためにアクティブなコンシューマにメッセージを分散するため発生します。場合によっては、1 人のコンシューマが、想定よりも少ないメッセージや、他のコンシューマとは異なるメッセージのサブセットを受信することもあります。
メッセージはすでにクライアントに届いている可能性があり、未確認のメッセージのバックログがあるからといって、必ずしも次の pull リクエストでそれらのメッセージを受け取れるとは限らないことに注意してください。コンシューマは、Google Cloud コンソールまたは Google Cloud CLI で pull を使用しているか、カスタム サブスクライバーをローカルで実行してメッセージを確認している場合があります。
単項 pull クライアントの場合、一部の pull リクエストでメッセージが返されない場合があります。サブスクライバーが足りないセクションで説明したように、一部のリクエストでは、構成された最大メッセージ数より少ないメッセージが返される場合や、メッセージが返されない場合があるため、未処理の pull リクエストを複数保持することをおすすめします。
このような動作が疑われる場合は、サブスクリプションに複数のコンシューマが同時に接続されているかどうかを調査し、確認します。
サブスクリプションのフィルタ
サブスクリプションにフィルタが添付されているかどうかを確認します。その場合は、フィルタに一致するメッセージのみを受信します。Pub/Sub サービスは、フィルタに一致しないメッセージの確認応答を自動的に行います。フィルタがバックログ指標に与える影響を検討してください。
オプション returnImmediately を使用する
クライアントが単項 pull を使用している場合は、returnImmediately フィールドが true に設定されているかどうかを確認します。これは非推奨のフィールドで、メッセージが返されなくても pull リクエストにすぐに応答するように Pub/Sub サービスに指示します。これにより、バックログがある場合でも、pull リクエストでメッセージ 0 が返されることがあります。
重複に対処する
Pub/Sub でのメッセージの重複は、サブスクライバーが確認応答期限内にメッセージを確認応答できない場合によく発生します。これにより、メッセージが再配信され、重複しているように見えることがあります。subscription/expired_ack_deadlines_count 指標を使用して、サブスクライバーが確認応答期限に間に合わないレートを測定できます。詳しくは、確認期限の有効期限のモニタリングをご覧ください。
メッセージの期限を延長すると、重複率を低下させることができます。
- 期限の延長はクライアント ライブラリによって自動的に処理されますが、構成できる延長期限の最大値にはデフォルトの上限があります。
- 独自のクライアント ライブラリを構築する場合は、
modifyAckDeadlineメソッドを使用して、確認応答期限を延長します。
メッセージの処理や確認応答ができない速さでサブスクライバーに pull されると、一部のメッセージが期限切れになり、期限の延長が必要になることがあります。しかし、サブスクライバーに過剰な負荷がかかると、繰り返しの期限の延長は最終的に失敗します。最悪のシナリオでは、サブスクライバーが重複でオーバーフローし、バックログが悪化する可能性があります。重複の期限が切れると、新しい重複が生成されます。
サブスクライバーの過剰な負荷を避けるために、サブスクライバーが一度に pull するメッセージの数を減らします。これにより、サブスクライバーが期限内に処理するメッセージの数を減らすことができます。期限切れとなるメールが少なくなり、再配信されるメールも少なくなります。
サブスクライバーが一度に pull するメッセージの数を減らすには、サブスクライバーのフロー制御構成で設定されている未処理のメッセージの最大数を減らす必要があります。画一的な値は存在しないため、スループットとサブスクライバーの容量に基づいて未処理のメッセージの上限を調整する必要があります。各アプリケーションがメッセージを処理する方法が異なり、メッセージの ACK にかかる時間も異なることを考慮してください。
再試行を強制する
Pub/Sub にメッセージの再試行を強制するには、nack リクエストを送信します。高レベルのクライアント ライブラリを使用していない場合は、ackDeadlineSeconds を 0 に設定して modifyAckDeadline リクエストを送信します。
順序指定キー
Pub/Sub が順序指定キーを持つメッセージを再配信する場合は、以前に確認応答があったとしても、同じ順序キーを持つすべてのメッセージを再配信します。これは、シーケンスの順序を保持するためです。ただし、シーケンス内の前のメッセージの確認応答に成功した後にのみ、依存するメッセージが送信されるという厳密な保証はありません。
サブスクライバーがメッセージを否定応答している
サブスクライバーがメッセージを否定応答しているをご覧ください。
StreamingPull サブスクリプションのトラブルシューティング
リクエストのレイテンシ指標とエンドツーエンドの配信レイテンシの関係
StreamingPull の場合、指標 serviceruntime.googleapis.com/api/request_latencies は、ストリームが開いている時間を表します。この指標は、エンドツーエンドの配信レイテンシの特定には役立ちません。
リクエスト レイテンシ指標を使用する代わりに、配信レイテンシの健全性スコアを使用して、エンドツーエンドの配信レイテンシの増加に寄与している要因を確認します。
StreamingPull 接続が OK 以外のステータスで閉じる
StreamingPull ストリームは、常に OK 以外のステータスで終了します。単項 RPC のエラー ステータスとは異なり、StreamingPull のこのステータスは、ストリームが切断されたことを示しています。リクエストは失敗していません。そのため、StreamingPull API のエラー率が 100% にもなることがありますが、この動作は設計によるものです。
StreamingPull ストリームは常にエラーで終了するため、エラーの診断中にストリーム終了の指標を調べることは役に立ちません。代わりに、response_code または response_class でグループ化された StreamingPull レスポンス指標 subscription/streaming_pull_response_count に注目してください。
次のエラーを探します。
サブスクリプション バックログに無効な Cloud KMS 鍵で暗号化されたメッセージがある場合、前提条件の失敗エラーが発生することがあります。pull を再開するには、鍵へのアクセスを復元します。
Pub/Sub でリクエストを処理できないときに発生する可能性のある使用不可のエラー。これは一時的な状態である可能性が高く、クライアント ライブラリはリクエストを再試行します。クライアント ライブラリを使用している場合、お客様側での操作は必要ありません。
存在しないエラーは、サブスクリプションが削除された場合、またはサブスクリプションが最初から存在しなかった場合に発生する可能性があります。後者のケースでは、無効なサブスクリプション パスを指定した場合に発生します。