トラブルシューティング

Cloud Pub/Sub の使用中に問題が発生した場合に役立つトラブルシューティング手順について説明します。

サブスクリプションを作成できない

以下の項目をすべてご確認ください。

  • name フィールドにサブスクリプション名を指定している。バージョン v1beta2 以降では、サブスクリプション名を projects/project-identifier/subscriptions/subscription-name という形式で指定する必要があります。
  • topic フィールドに、サブスクライブ先とする既存のトピックの名前を指定している。バージョン v1beta2 以降では、トピック名を projects/project-identifier/topics/topic-name という形式で指定する必要があります。
  • 受信 URL のプロトコルとして、pushEndpoint フィールドに https:// を小文字で指定している(http://HTTPS:// は不可)。

push サブスクライバーがメッセージを受信しない

次のことを確認してください。

  • 問題のあるサブスクリプションに関係するエラーがないかどうか、Stackdriver Monitoring を調べます。
  • App Engine では、App Engine エンドポイントの登録に記載されているように、エンドポイント URL のパスに /_ah/push-handlers/ 接頭辞を使用することをおすすめします。この設定により、エンドポイントが Cloud Pub/Sub API から push メッセージを受信できるようになります。
  • 他の環境で、ログインせずにインターネットからエンドポイント URL にアクセスできるか確認します。cURL などの診断ツールを使用して URL にアクセスすることで、URL が制限されていないことを確認します。
  • appspot.com 以外のドメインでは、ドメインを Google Cloud Platform Console に登録してください。詳細については、他のエンドポイントの登録をご覧ください。

403 (Forbidden) エラー

このエラーが発生した場合、以下を行ってください。

  • GCP Console で Cloud Pub/Sub API を有効にしていることを確認します。
  • 特に、プロジェクト間の通信のために Cloud Pub/Sub API を使用している場合、リクエストを実行しているプリンシパルが、関係する Cloud Pub/Sub API リソースに必要な権限を持っていることを確認します。
  • Cloud Dataflow を使用している場合、<projectId>@cloudservices.gserviceaccount.com と Compute Engine サービス アカウント <projectId>-compute@developer.gserviceaccount.com の両方が、該当する Cloud Pub/Sub API リソースに対して必要な権限を持っていることを確認します。詳細については、Google Cloud Dataflow セキュリティと権限をご覧ください。
  • App Engine を使用している場合、プロジェクトの権限ページで、App Engine サービス アカウントが編集者としてリストされているかどうか確認します。リストされていない場合、App Engine サービス アカウントを編集者として追加します。通常、App Engine サービス アカウントは <project-id>@appspot.gserviceaccount.com の形式です。

重複の処理と再試行の強制

確認期限が過ぎる前にメッセージを確認しないと、Cloud Pub/Sub はメッセージを再送信します。その結果、Cloud Pub/Sub は重複するメッセージを送信することがあります。Stackdriver で expired レスポンス コードを使用して確認応答オペレーションをモニタリングし、この状態を検出します。このデータを取得する方法の 1 つに、response_code でグループ化された確認応答メッセージ オペレーション指標を使用する方法があります。

Stackdriver で確認応答期限が切れたメッセージを検索する

メッセージの期限を延長すると、重複率を低下させることができます。

  • 期限の延長はクライアント ライブラリが自動的に行いますが、設定可能な延長期限の最大値にはデフォルトの制限があります。
  • クライアント ライブラリを独自に構築している場合は、確認応答期限の延長に modifyAckDeadline メソッドを使用します。

あるいは、Cloud Pub/Sub にメッセージの再試行を強制するには、modifyAckDeadline を 0 に設定します。

過剰な管理オペレーションの使用

管理オペレーションで割り当てを過剰に消費している場合、コードのリファクタリングが必要な可能性があります。ここでは、以下の疑似コードに基づいて説明します。この例では、リソースを実際に使用する前に管理オペレーション(GET)でサブスクリプションが存在することを確認しています。GETCREATE はどちらも管理オペレーションです。


    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
    }
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud Pub/Sub ドキュメント