このドキュメントでは、Pub/Sub の pull サブスクリプションに関する一般的なトラブルシューティングのヒントを示します。pull サブスクリプションの詳細については、pull サブスクライバー ガイドをご覧ください。
Pub/Sub サブスクリプションを効果的にモニタリングするには、まず配信レイテンシの健全性スコア（subscription/delivery_latency_health_score）を確認して、予期しない問題やレイテンシが増加します。
確認応答されていない最も古いメッセージの経過時間が増加し続ける
oldest_unacked_message_age は、Pub/Sub サブスクリプションの健全性をモニタリングする重要な指標です。これは、サブスクリプションのバックログ内でサブスクライバーによってまだ確認応答（確認）されていない最も古いメッセージの経過時間を秒単位で測定します。この指標は、潜在的な処理の遅延やボトルネックに関する貴重な分析情報を提供します。
メッセージ バックログのモニタリングにより、タイムリーで効率的なメッセージ処理が保証されます。確認応答されていない最も古いメッセージの経過時間を追跡することで、消費者の対応が遅れている状況を事前に特定できます。これにより、パフォーマンスの低下に関連する潜在的な問題に対処するために、早期の介入が可能になります。
調査できる一般的な問題には、次のようなものがあります。
クライアントの構成に関する問題
oldest_unacked_message_age 指標と num_undelivered_messages 指標の両方が同時に増加する場合は、サブスクライバーがメッセージの量についていけていない可能性があります。この状況では、サブスクライバー コンポーネントに調査を集中します。
クライアントの健全性: サブスクライバー クライアントをホストするマシン（CPU、メモリ、ネットワーク帯域幅など）のリソース使用率を分析します。処理効率を阻害する可能性がある圧力点を探します。
クライアント コード: 最近のコード変更やエラーログの確認を行います。サブスクライバー コードのバグや非効率性は、メッセージ処理速度に大きな影響を与える可能性があります。特定のメールに問題がある場合があります。たとえば、データベース内の同じ行に複数のメッセージで同時にアクセスする必要がある場合があります。この動作により、競合や高レイテンシが発生する可能性があります。
割り当て制限: ご利用のホスティング サービスの Pub/Sub 割り当てや制限を超えていないことを確認します。サブスクライバーが Google Cloud でホストされている場合は、Compute Engine または GKE のリソース割り当てを確認して、潜在的なボトルネックを回避します。
サブスクライバーがメッセージに否定応答をした
サブスクライバーがメッセージに否定応答（否定応答）すると、メッセージを正常に処理できなかったことを Pub/Sub に通知します。その後、Pub/Sub は同じメッセージの再配信を試みます。メッセージが否定応答を繰り返すと、重複が発生し、メッセージ配信に大幅な遅延が発生する可能性があります。
メッセージを nack しても、次の pull で別のメッセージがフェッチされるとは限りません。Pub/Sub の再配信ポリシーでは、未確認のメッセージが新しいメッセージの前に引き続き再配信される可能性があります。そのため、特定のメッセージをフィルタリングまたはスキップする方法として、nack を使用しないでください。代わりに、再試行ポリシー（可能であれば指数バックオフ）を設定します。再配信までに少し時間がかかる可能性があるが、後で処理できるメールを個別に差し戻すことができます。して、ソース別にトラフィック データを分類します。
特定のメッセージを意図的にスキップする必要がある場合は、処理しない場合でも確認応答することをおすすめします。これにより、サブスクリプションから削除され、不要な再配信を回避してリソースの使用量が削減されます。意図的かどうかにかかわらず、メッセージを未確認のままにしておくと、バックログの問題や重複配信が発生します。
配信のレイテンシが高い場合
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 リクエストがあった場合でも、すぐに pull リクエストに応答するように Pub/Sub サービスに指示します。その結果、バックログがある場合でも、pull リクエストでメッセージが返されない場合があります。
重複の処理
Pub/Sub でのメッセージの重複は、サブスクライバーが確認応答期限内にメッセージを確認できない場合に発生します。これにより、メッセージが再配信され、重複したインプレッションが発生します。subscription/expired_ack_deadlines_count 指標を使用すると、サブスクライバーがどれくらいの割合で確認応答期限を逃しているかを測定できます。確認応答期限の有効期限のモニタリング方法について学習する。
メッセージの期限を延長すると、重複率を低下させることができます。
- 期限の延長はクライアント ライブラリによって自動的に処理されますが、構成可能な延長期限の最大値にはデフォルトの上限があります。
- 独自のクライアント ライブラリを構築する場合は、
modifyAckDeadlineメソッドを使用して、確認応答期限を延長します。
メッセージが処理や確認応答よりも速くサブスクライバーに pull されると、一部のメッセージが期限切れになり、期限の延長が必要になる場合があります。しかし、サブスクライバーが多いと、期限の延長が最終的に失敗します。最悪のシナリオでは、サブスクライバーが重複でオーバーフローし、バックログが悪化する可能性があります。有効期限が過ぎている重複は、新しい重複を生成します。
サブスクライバーが過負荷状態にならないようにするには、サブスクライバーが一度に pull するメッセージの数を減らします。これにより、サブスクライバーが期限内に処理するメッセージが減少します。期限切れとなるメッセージが少なくなり、再配信されるメッセージも少なくなります。
サブスクライバーが一度に pull するメッセージ数を減らすには、サブスクライバーのフロー制御構成で未処理のメッセージの最大数を減らす必要があります。画一的な値は存在しないため、スループットとサブスクライバー容量に基づいて未処理のメッセージの上限を調整する必要があります。アプリケーションごとにメッセージの処理方法が異なり、メッセージの確認応答にかかる時間も異なります。
再試行の強制
Pub/Sub にメッセージの再試行を強制するには、nack リクエストを送信します。高レベルのクライアント ライブラリを使用していない場合は、ackDeadlineSeconds を 0 に設定して modifyAckDeadline リクエストを送信します。
順序指定キー
Pub/Sub が順序指定キーを含むメッセージを再配信する場合は、以前に確認応答済みのものであっても、同じ順序指定キーを持つ後続のメッセージもすべて再配信されます。これは、シーケンスの順序を保持するために行われます。ただし、シーケンス内の前のメッセージの確認応答が成功した後にのみ、依存メッセージが送信されることは厳密には保証されません。
サブスクライバーがメッセージを否定応答する
サブスクライバーがメッセージを nack するをご覧ください。
StreamingPull サブスクリプションのトラブルシューティング
StreamingPull ストリームは、常に OK 以外のステータスで終了します。単項 RPC のエラー ステータスとは異なり、StreamingPull のこのステータスは、ストリームが切断されたことを示すものです。リクエストは失敗していません。そのため、StreamingPull API のエラー率が 100% にもなることがありますが、この動作は設計によるものです。
StreamingPull ストリームは常にエラーで終了するため、エラーの診断中にストリーム終了の指標を調べることは役に立ちません。代わりに、response_code または response_class でグループ化された StreamingPull レスポンス指標 subscription/streaming_pull_response_count を重視します。
次のエラーを探します。
サブスクリプション バックログに無効な Cloud KMS 鍵で暗号化されたメッセージがある場合、前提条件失敗エラーが発生することがあります。pull を再開するには、鍵へのアクセスを復元します。
Pub/Sub でリクエストを処理できないときに発生する可能性のある使用不可のエラー。これは一時的な状態である可能性が高いため、クライアント ライブラリはリクエストを再試行します。クライアント ライブラリを使用している場合、ユーザー側でのアクションは必要ありません。
存在しないエラーは、サブスクリプションが削除された場合、またはサブスクリプションが最初から存在しなかった場合に発生する可能性があります。後者のケースでは、無効なサブスクリプション パスを指定した場合に発生します。