よくある質問

一般的な質問

Pub/Sub は Firebase Cloud Messaging(FCM)やサポートが終了した Google Cloud Messaging(GCM)に関連したものですか?

部分的にはそうです。いずれのシステムもメッセージの配信に使用されますが、FCM はエンドユーザー デバイス間でのメッセージの送受信に、Pub/Sub はサーバー間での通信に使用されます。FCM では非常に多数の配信エンドポイントにスケーリングするように設計されていますが、スループット(1 チャネル 1 秒あたりのメッセージ数)が低下します。Pub/Sub には、スループットに対する制限はなく、より汎用的な API を使用します。

これは PubSubHubbub に関連したものですか?

いいえ。Google 社員は PubSubHubbub の考案に深く関わっていましたが、PubSubHubbub の RSS とコンテンツを広くシンジケートする強みは、Pub/Sub が目指すユースケースではありません。名前以外の共通点はほとんどありません。

Pub/Sub を使用して、異なる App Engine モジュール間で通信できますか?

はい。Pub/Sub を使用して、1 つの App Engine アプリケーション内の異なるモジュール間、さらには同じプロジェクト内の異なるアプリケーション間でも、特別な ACL 構成を行わずにメッセージを送受信できます。低いレイテンシでパブリッシュするには、パブリッシャー クライアントをグローバル変数として初期化することによってキャッシュに保存します。

Pub/Sub を App Engine 以外のプラットフォームで使用できますか?

はい。Pub/Sub は、Google Compute Engine でホストされているアプリケーション、さらには Google 以外のプラットフォームでホストされているアプリケーションとも使用できます。必要なのは、Google Cloud Console プロジェクトを開始することのみです。低いレイテンシでパブリッシュするには、パブリッシャー クライアントをグローバルにすることによってキャッシュすることを検討してください。

App Engine と Compute Engine アプリケーションを接続するにはどうすればよいですか?

Compute Engine から App Engine への低レイテンシ メッセージングには、push 配信を使用します。App Engine から多数の Compute Engine サブスクライバーにデータを送信する場合は、pull 配信を使用します。

Pub/Sub 指標をモニタリングするにはどうすればよいですか?

こちらの記事をご覧ください。

Pub/Sub には KMS が統合されていますか?

はい。Pub/Sub トピックは、Cloud KMS の鍵を使用してメッセージの内容を保護するように構成できます。詳細については、顧客管理の暗号鍵の使用をご覧ください。

技術的な質問

メッセージは順序どおりに配信されますか?

Pub/Sub では、順序どおりの配信、つまり FIFO(先入れ先出し)配信は保証されません。メッセージは可能な限りすばやく配信され、より古いメッセージが先に配信されるように優先されますが、それが保証されているわけではありません。厳密な順序指定は Pub/Sub の可用性とスケーラビリティに反するものです。このトピックに関する詳細は、メッセージの順序指定をご覧ください。

使用率が制限を十分に下回っているときに割り当てエラーが出るのはなぜですか?

割り当てと制限で説明されているように、割り当ては認証されたクライアントに関連付けられたプロジェクトに対して適用されます。十分な割り当てを持つプロジェクトに関連付けられたサービス アカウントまたは API_KEY を使用していることを確認してください。特に、gcloud コマンドラインは共有プロジェクトを使用し、割り当ては非常に制限されています。

重複メッセージが多すぎるのはなぜですか?

Pub/Sub では at-least-once 配信が保証されているため、場合によっては重複が発生します。ただし、重複率が高い場合は、構成された ack_deadline_seconds 内にクライアントがメッセージの確認応答を行っていないために、Pub/Sub がメッセージ配信を再試行している可能性があります。これは、モニタリング指標 pubsub.googleapis.com/subscription/pull_ack_message_operation_count(pull サブスクリプションの場合)と pubsub.googleapis.com/subscription/push_request_count(push サブスクリプションの場合)で発生する可能性があります。/response_code で値の大きな expired または webhook_timeout 値を探してください。Pub/Sub によってメッセージが内部的にバッチ処理され、部分的に確認応答されたバッチが全体的に再配信されるため、この問題は特に小さなメッセージが数多く存在する場合に発生します。

または、それらの特定のメッセージを処理するコードパスが失敗し、Acknowledge 呼び出しが行われないか、push エンドポイントが応答しない、あるいはエラーで応答するため、サブスクライバーが一部のメッセージの確認応答を行わない場合もあります。

重複するメッセージを検出するにはどうすればよいですか?

各メッセージには Pub/Sub によって一意の「message_id」が割り当てられるため、これを使用してサブスクライバーが受信した重複メッセージを検出できます。ただし、同じデータに対する複数のパブリッシュ リクエストによって重複する結果となったメッセージを検出することはできません。こうしたメッセージを検出するには、パブリッシャーによって一意のメッセージ識別子が指定されている必要があります。詳しくは、Pub/Sub I/O をご覧ください。