プッシュサブスクリプション

このドキュメントでは、push サブスクリプションとそのワークフロー、関連するプロパティの概要について説明します。

push 配信では、Pub/Sub がサブスクライバーアプリケーションに対してリクエストを開始し、メッセージを配信します。メッセージは、HTTPS POST リクエストなどの一般公開されているサーバーまたは Webhook に配信されます。

push サブスクリプションでは、Pub/Sub 固有のクライアントライブラリと認証メカニズムに対する依存関係が最小限に抑えられます。また、Cloud Functions、Cloud Run、Google Kubernetes Engine など、サーバーレスで自動スケーリングのサービステクノロジーとも連携します。

準備

このドキュメントを読む前に、次の内容をよく理解しておいてください。

Pub/Sub の仕組みとさまざまな Pub/Sub の用語。
Pub/Sub がサポートするさまざまなサブスクリプションの種類と、push サブスクリプションを使用する理由。

push サブスクリプションワークフロー

push サブスクリプションの場合は、Pub/Sub サーバーがサブスクライバークライアントに対してメッセージ配信のリクエストを開始します。

次の図は、サブスクライバークライアントと push サブスクリプションの間のワークフローを示しています。

push サブスクリプションのメッセージフロー — **図 3.** push サブスクリプションのワークフロー

図 3 を参照するワークフローの簡単な説明は次のとおりです。

Pub/Sub サーバーは、事前構成されたエンドポイントで、サブスクライバークライアントに各メッセージを HTTPS リクエストとして送信します。このリクエストは、画像では PushRequest と表示されます。
エンドポイントは、HTTP 成功ステータスコードを返すことでメッセージに確認応答します。不成功のレスポンスは、Pub/Sub がメッセージを再送信する必要があることを示します。このレスポンスは、画像内で PushResponse として表示されます。
Pub/Sub は、成功のレスポンスを受信するレートに基づいて、push リクエストのレートを動的に調整します。

push サブスクリプションのプロパティ

push サブスクリプションに構成するプロパティによって、サブスクリプションにメッセージを書き込む方法が決まります。詳細については、サブスクリプションのプロパティをご覧ください。

push エンドポイントによるメッセージの受信方法

Pub/Sub が push エンドポイントにメッセージを配信するときに、メッセージをラップまたはラップ解除して送信することを選択できます。デフォルトでは、メッセージはラップして送信されます。

ラップ済み。Pub/Sub は、POST リクエストの JSON 本文でメッセージを送信します。
ラップ解除。Pub/Sub は、未加工のメッセージデータを HTTP 本文として直接送信します。

次の例は、message.data フィールドに文字列 Hello there を含む push エンドポイントへの JSON POST リクエストのラップされた本文を示しています。

POST リクエストの本文は JSON オブジェクトです。メッセージデータは message.data フィールドにあり、base64 でエンコードされています。

最小値を含むリクエストの例

  {
      "message": {
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
  }

最大値を含むリクエストの例

この例は現在の最大値を示しています。この値は時間とともに変化する可能性があります。また、属性マップにさまざまな値を含めることができます。

  {
      "deliveryAttempt": 5,
      "message": {
          "attributes": {
              "key": "value"
          },
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "orderingKey": "key",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
}

push サブスクリプションからメッセージを受信するには、Webhook を使用して、Pub/Sub によって push エンドポイントに送信される POST リクエストを処理します。App Engine でのこれらの POST リクエストの処理の詳細については、Pub/Sub メッセージの作成とレスポンスをご覧ください。

push リクエストの受信後、HTTP ステータスコードを返します。メッセージへ確認応答するには、次のいずれかのステータスコードを返します。

102
200
201
202
204

メッセージに対し否定応答を送信するには、他のステータスコードを返します。否定応答を送信するか、確認応答期限が切れた場合、Pub/Sub はメッセージを再送信します。push サブスクリプションから受信する個々のメッセージの確認応答期限は、変更できません。

push サブスクリプションの認証

push サブスクリプションが認証を使用する場合、Pub/Sub サービスは JWT に署名し、push リクエストの認可ヘッダーで JWT を送信します。

認証の設定の詳細については、push リクエストの認証をご覧ください。

メッセージ配信の停止と再開

Pub/Sub で push エンドポイントに対するリクエストの送信を一時的に停止するには、サブスクリプションを pull に変更します。変更が適用されるまで、数分かかることがあります。

push 配信を再開するには、URL を有効なエンドポイントにもう一度設定します。配信を完全に停止するには、サブスクリプションを削除します。

push バックオフ

push サブスクライバーが送信する否定確認応答が多すぎる場合、Pub/Sub は push バックオフを使用してメッセージ配信を開始する可能性があります。Pub/Sub が push バックオフを使用すると、事前に設定された期間、メッセージの配信を停止します。この期間は 100 ミリ秒から 60 秒の範囲で指定できます。この時間が経過すると、Pub/Sub はメッセージの配信を開始します。

push バックオフでは、指数バックオフアルゴリズムを使用して、メッセージの送信に使用する Pub/Sub の遅延を決定します。この期間は、サブスクライバーが送信する否定応答の数に基づいて計算されます。

たとえば、push サブスクライバーが 1 秒あたり 5 件のメッセージを受信して、1 秒あたり 1 件の否定確認応答を送信する場合は、Pub/Sub は約 500 ミリ秒ごとにメッセージを配信します。push サブスクライバーが毎秒 5 つの否定確認応答を送信する場合、Pub/Sub は 30～60 秒ごとにメッセージを配信します。

push バックオフについては、次の点を考慮してください。

push バックオフはオンまたはオフにできません。また、遅延の計算に使用される値は変更できません。
push バックオフは、次のアクションに対してトリガーされます。
- 否定確認応答を受け取った場合。
- メッセージの確認応答期限が切れた場合。
push バックオフは、サブスクリプション（グローバル）内のすべてのメッセージに適用されます。

配信レート

スロースタートアルゴリズムを使用して同時 push リクエストの数を調整します。push ウィンドウは、同時 push リクエストの最大数です。push ウィンドウは、配信が成功すると増加し、失敗すると減少します。システムは 1 桁の小さなウィンドウサイズから始まります。

サブスクライバーがメッセージの確認応答を行うと、ウィンドウは急激に増加します。サブスクライバーがメッセージの 99% 以上を確認応答し、push リクエストのレイテンシが平均 1 秒未満であるサブスクリプションの場合、push ウィンドウはパブリッシュスループットに対応できるように拡張する必要があります。

push リクエストのレイテンシには、次のものなどがあります。

Pub/Sub サーバーと push エンドポイントの間の往復ネットワークレイテンシ
サブスクライバーの処理時間

リージョンあたりの未処理のメッセージが 3,000 件を超えると、ウィンドウは比例して増加し、push エンドポイントがメッセージを過剰に受け取ることを回避できます。平均レイテンシが 1 秒を超えるか、サブスクライバーの確認応答がリクエストの 99% 未満の場合、ウィンドウは未処理のメッセージの下限 3,000 件に減少します。

push 配信のモニタリングに使用できる指標の詳細については、push サブスクリプションのモニタリングをご覧ください。

割り当てと上限

push サブスクリプションには割り当てとリソース上限があります。

次のステップ

トピックの push サブスクリプションを作成します。
gcloud CLI を使用してサブスクリプションを作成または変更する。
REST API を使用してサブスクリプションを作成または変更する。
REST API を使用してサブスクリプションを作成または変更する。

プッシュ サブスクリプション

準備

push サブスクリプション ワークフロー