Pub/Sub の使用中に問題が発生した場合に役立つトラブルシューティング手順について説明します。
トピックを作成できない
必要な
権限を付与されていることを確認します。
Pub/Sub トピックを作成するには、プロジェクトに対する
Pub/Sub 編集者(roles/pubsub.editor)Identity and Access Management
ロールが必要です。このロールを付与されていない場合は、管理者にお問い合わせください。
トピックに関するトラブルシューティングの詳細については、次のページをご覧ください。
サブスクリプションを作成できない
以下を行ったことを確認します。
必要な 権限を付与されていることを確認します。 Pub/Sub サブスクリプションを作成するには、 プロジェクトに対する Pub/Sub 編集者 (roles/pubsub.editor)IAM ロールが必要です。 このロールを付与されていない場合は、管理者にお問い合わせください。
サブスクリプションの名前を指定している。
サブスクリプションをアタッチする既存のトピックの名前を指定している。
push サブスクリプションを作成する場合、受信 URL のプロトコルとして、
pushEndpointフィールドにhttps://を小文字で指定している(http://やHTTPS://は不可)。
サブスクリプションに関するトラブルシューティングの詳細については、次のページをご覧ください。
pull、push、BigQuery、または Cloud Storage のトラブルシューティング
権限に関する問題のトラブルシューティング
Pub/Sub 権限は、Pub/Sub リソースに対してアクションを実行できるユーザーとサービス アカウントを制御します。権限が正しく構成されていないと、権限拒否エラーが発生し、メッセージ フローが中断される可能性があります。 監査ログには、すべての権限変更の詳細な記録が残るため、これらの問題の原因を特定できます。
監査ログを使用して Pub/Sub の権限に関する問題をトラブルシューティングするには:
[ログ エクスプローラ] を表示するために必要な権限を取得します。
詳細については、始める前にをご覧ください。
コンソール Google Cloud で、[**ログ エクスプローラ**] ページに移動します。
既存の Google Cloud プロジェクト、フォルダ、または組織を選択します。
関連するログを検索するために使用できるフィルタの一覧を次に示します。
resource.type="pubsub_topic" OR resource.type="pubsub_subscription":トピックまたはサブスクリプションの構成の変更、アクセス制御に関連する問題のトラブルシューティングを行う場合は、このクエリを起点として使用します。他のフィルタと組み合わせて、検索を絞り込むことができます。protoPayload.methodName="google.iam.v1.SetIamPolicy": 問題の原因が権限の誤りまたは欠落であると思われる場合は、このクエリを使用します。IAM ポリシーを変更したユーザーと、その変更内容を追跡できます。これは、ユーザーがトピックに公開できない、またはサブスクリプションに登録できない、アプリケーションが Pub/Sub リソースへのアクセスを拒否された、アクセス制御が予期せず変更されたなどの問題のトラブルシューティングに役立ちます。protoPayload.status.code=7: 権限に明示的に関連するエラーが発生した場合は、このクエリを使用します。これにより、失敗しているアクションと、そのアクションを試行しているユーザーを特定できます。このクエリを前のクエリと組み合わせて、権限拒否の原因となっている可能性のある特定のリソースと IAM ポリシーの変更を特定できます。
ログを分析して、イベントのタイムスタンプ、変更を行ったプリンシパル、行われた変更の種類などの要素を特定します。
監査ログから収集した情報に基づいて、修正措置を講じることができます。
Terraform の権限に関する問題のトラブルシューティング
Terraform で Pub/Sub を使用する場合は、Terraform
コードで必要なロールを明示的に付与します。たとえば、公開の場合、アプリケーションのサービス アカウントには
roles/pubsub.publisher ロールが必要です。このロールが Terraform
コードで明示的に定義されていない場合、今後の terraform apply
で削除される可能性があります。これは、関連のないアップデート中に発生することが多く、信頼性の高いアプリケーションが突然 PERMISSION_DENIED
エラーで失敗する原因となります。
コードでロールを明示的に定義すると、このような意図しない回帰を防ぐことができます。
サブスクリプションが削除された
Pub/Sub サブスクリプションは、主に次の 2 つの方法で削除できます。
十分な権限を持つユーザーまたはサービス アカウントが、サブスクリプションを意図的に削除する。
サブスクリプションは、操作が行われない状態が一定期間(デフォルトでは 31 日間)続くと自動的に削除されます。サブスクリプションの有効期限ポリシーの詳細については、有効期間をご覧ください。
削除されたサブスクリプションのトラブルシューティングを行うには、次の手順を行います。
コンソール Google Cloud で、Pub/Sub の [サブスクリプション] ページに移動し、サブスクリプションがリストに表示されなくなったことを確認します。 サブスクリプションを一覧表示する方法の詳細については、 サブスクリプションを一覧表示するをご覧ください。
監査ログを確認します。[ログ エクスプローラ] に移動します。 フィルタ
protoPayload.methodName="google.pubsub.v1.Subscriber.DeleteSubscription"を使用して、削除されたサブスクリプションを検索します。ログを調べて、誰かがサブスクリプションを削除したのか、操作が行われない状態が続いたために削除されたのかを確認します。InternalExpireInactiveSubscriptionは、操作が行われない状態が続いたためにサブスクリプションが削除されたことを示します。 トラブルシューティングに監査ログを使用する方法の詳細については、 監査ログを使用して Pub/Sub の問題をトラブルシューティングするをご覧ください。
403 (Forbidden) エラー
通常、403 エラーは、アクションを実行するための適切な権限がないことを意味します。たとえば、トピックに公開しようとしたり、サブスクリプションから pull しようとしたりすると、403 User not authorized エラーが発生することがあります。
このエラーが発生した場合、以下を行ってください。
- Google Cloud コンソールで Pub/Sub API が有効になっていることを確認します。
プロジェクト間の通信に Pub/Sub API を使用する場合は、リクエストを行うプリンシパルが、関連する Pub/Sub API リソースに必要な 権限を持っていることを確認します。
Dataflow を使用している場合は、
{PROJECT_NUMBER}@cloudservices.gserviceaccount.comと Compute Engine サービス アカウントの{PROJECT_NUMBER}-compute@developer.gserviceaccount.comの両方が、関連する Pub/Sub API リソースに対して必要な権限を持っていることを確認します。詳細については、Dataflow のセキュリティと権限をご覧ください。App Engine を使用している場合、プロジェクトの権限ページで、App Engine サービス アカウントが Pub/Sub 編集者としてリストされているかどうか確認します。リストされていない場合、App Engine サービス アカウントを Pub/Sub 編集者として追加します。通常、 App Engine サービス アカウントは 次の形式になります:
<project-id>@appspot.gserviceaccount.com監査ログを使用して、権限に関する問題をトラブルシューティングできます。
その他の一般的なエラーコード
Pub/Sub API に関連するその他の一般的なエラーコード とその説明の一覧については、エラーコードをご覧ください。
接続タイムアウト、レイテンシ、ネットワーク エラー
Pub/Sub クライアント アプリケーションが サービスに接続 Google Cloud しようとすると、断続的または永続的な障害が発生することがあります。これらの問題は、次のように現れることがあります。
- メッセージの公開時に大幅な遅延が発生し、アプリケーションのバックログが発生する可能性がある。
- gRPC
DEADLINE_EXCEEDED、code = DeadlineExceeded、java.net.SocketTimeoutExceptionなどのタイムアウト エラー。 pubsub.googleapis.comやoauth2.googleapis.comなどのサービスにアクセスしようとしたときに発生するUNAVAILABLE: io exceptionやConnection refusedなどのネットワーク I/O エラー。
これらの接続の問題は、Pub/Sub 構成やアプリケーション コードを変更しなくても発生する可能性があります。これは、オンプレミスまたは VPC ファイアウォールが Google API にハードコードされた IP アドレスの許可リストを使用している場合に頻繁に発生します。Pub/Sub や認証サービスなどの依存関係を含む Google サービスでは、IP アドレスの動的範囲を使用します。ファイアウォールが新しい IP アドレスに対応していない場合、新しい IP アドレスへのトラフィックがブロックされ、接続と認証が失敗する可能性があります。
安定した接続を確保するには、Google サービスに静的 IP ベースのファイアウォール ルールを使用しないでください。代替方法は次のとおりです。
- ハードコードされたアドレスではなく、Google が公開しているデフォルト ドメインの IP 範囲を使用してトラフィックを許可するようにファイアウォールを構成します。これらの範囲を取得してファイアウォール ルールの更新を自動化する方法については、デフォルト ドメインの IP アドレスをご覧ください。
- プライベート Google アクセスを有効にします。これにより、VPC ネットワーク内のインスタンスは、公共のインターネットを経由せずに Google API とサービスにアクセスできるようになり、ファイアウォールの管理が簡素化されます。
JWT が無効です: トークンは有効期間が短いトークンである必要があります
アプリケーションが Invalid JWT: Token must be a short-lived token (60
minutes) and in a reasonable timeframe のようなエラーを
Pub/Sub API とやり取りするときに受信する場合は、通常、
認証情報のタイミングに問題があることを示しています。
このエラーは、API リクエストの認証に使用される JSON Web Token(JWT)の検証中に発生します。一般的な原因は、Pub/Sub ライブラリを実行しているクライアント マシンと Google の認証サーバーとの間に大きな時間差(時刻のずれ)があることです。JWT の有効期間は限られているため、クロックの不一致により、有効期限切れまたはまだ有効でないとみなされる可能性があります。
この問題を解決するには、クライアント マシンのクロックを同期します。
マシンの日付、時刻、タイムゾーンが正しいことを確認します。
ネットワーク タイム プロトコル(NTP)サービスを使用してシステム時刻を同期し、サービスが実行されていて正しく構成されていることを確認します。
過剰な管理オペレーションの使用
管理オペレーションで
割り当てを過剰に消費している場合、
コードのリファクタリングが必要な可能性があります。ここでは、以下の疑似コードに基づいて説明します。この例では、リソースの消費を試行する前に、管理オペレーション(GET)を使用して、サブスクリプションが存在することを確認しています。GET と CREATE はどちらも管理者オペレーションです。
if !GetSubscription my-sub {
CreateSubscription my-sub
}
Consume from subscription my-sub
サブスクリプションからメッセージを利用すると、より効率的になります(ただし、サブスクリプションの名前がある程度確実にわかる場合に限ります)。 この楽観的なアプローチでは、エラーが発生した場合にのみサブスクリプションが取得または作成されます。次の例を考えてみましょう。
try {
Consume from subscription my-sub
} catch NotFoundError {
CreateSubscription my-sub
Consume from subscription my-sub
}
次のコードサンプルを使用して、選択した言語でこのパターンを実装できます。
Go
次のサンプルでは、Go Pub/Sub クライアント ライブラリのメジャー バージョン(v2)を使用しています。引き続き v1 ライブラリを使用している場合は、 v2 への移行ガイドをご覧ください。 v1 コードサンプルのリストについては、 非推奨のコードサンプルをご覧ください。
このサンプルを試す前に、 クイックスタート: クライアント ライブラリの使用の Go の設定手順を実施してください。 詳細については、Pub/Sub Go API のリファレンス ドキュメントをご覧ください。
Java
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の Java の設定手順を実施してください。詳細については、Pub/Sub Java API リファレンス ドキュメントをご覧ください。
Node.js
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の Node.js の設定手順を実施してください。詳細については、Pub/Sub Node.js API リファレンス ドキュメントをご覧ください。
Node.ts
このサンプルを試す前に、 クイックスタート: クライアント ライブラリの使用の Node.js の設定手順を実施してください。 詳細については、Pub/Sub Node.js API リファレンス ドキュメントをご覧ください。
Python
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の Python の設定手順を実施してください。詳細については、Pub/Sub Python API リファレンス ドキュメントをご覧ください。
C++
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の C++ の設定手順を実施してください。詳細については、Pub/Sub C++ API リファレンス ドキュメントをご覧ください。