このページでは、すべての Pub/Sub サブスクリプション タイプに共通するプロパティについて説明します。これらのプロパティは、サブスクリプションを作成または更新するときに設定できます。
メッセージ保持期間
メッセージの保持期間オプションにより、Pub/Sub がパブリッシュ後にメッセージを保持する期間が指定されます。メッセージの保持期間が経過すると、メッセージの確認応答状態にかかわらず、Pub/Sub によりメッセージが破棄される可能性があります。メッセージ保持期間の間の確認済みメッセージの保持については、メッセージの再生と破棄をご覧ください。
[メッセージ保持期間] オプションの値は次のとおりです。
- デフォルト値: 7 日
- 最小値: 10 分。
- 最大値: 31 日
未確認メッセージの原因は、アイドル状態のサブスクリプション、バックアップのニーズ、処理速度が遅いことである可能性があります。24 時間以内にメッセージを処理できれば追加料金は発生しません。このようなシナリオを次のように管理することで、新しい料金の発生を回避できます。
アイドル状態のサブスクリプション。アイドル状態のサブスクリプションを削除して、サブスクリプション メッセージの保持料金が発生しないようにします。
バックアップ ストレージ。バックアップ ストレージとしてサブスクリプションの保持を使用している場合は、トピック メッセージの保持や確認済みメッセージの保持など、別のストレージ オプションに切り替えることができます。トピックのメッセージ保持では、メッセージをトピックレベルで 1 回のみ保存し、必要に応じてすべてのサブスクリプションで使用できるよう、利用可能に保たれます。
処理の遅延。1 日以内にメッセージを処理できるように、サブスクライバーを追加します（可能な場合）。
確認済みメッセージを保持する
メッセージ保持期間を指定した場合、確認済みメッセージを保持するかどうかも指定できます。
確認済みメッセージを保持するオプションを使用すると、指定したメッセージ保持期間の間、確認済みメッセージを保持できます。このオプションを使用すると、メッセージのストレージ料金が加算されます。詳細については、ストレージ費用をご覧ください。
有効期限
[有効期限] オプションを使用すると、サブスクリプションの有効期限を延長できます。
サブスクライバーのアクティビティがないサブスクリプションや、サブスクリプションのプロパティが変更されていないサブスクリプションは期限切れになります。Pub/Sub がサブスクライバーのアクティビティを検出した場合、またはサブスクリプション プロパティを更新した場合、サブスクリプション削除クロックが再起動されます。サブスクライバー アクティビティの例としては、オープン接続、アクティブな pull、push の成功などがあります。
有効期限を指定する場合、値は メッセージ保持期間オプションで指定されたメッセージ保持期間以上にする必要があります。
[有効期限] オプションの値は次のとおりです。
- デフォルト値: 31 日
- 最小値: 1 日
サブスクリプションの有効期限が切れないようにするには、有効期限を never expire に設定します。
確認応答の期限
確認期限オプションを使用すると、未確認メッセージが再度送信される最初の期限を指定できます。ModifyAckDeadline リクエストを続けて送ることで、メッセージごとに確認期限を延長できます。
[Acknowledgment deadline] オプションの値は次のとおりです。
- デフォルト値: 10 秒
- 最小値: 10 秒
- 最大値 = 600 秒
場合によっては、Pub/Sub クライアント ライブラリによって配信レートを制御し、確認応答期限を動的に変更できます。
この場合、設定した確認応答の期限より前にメッセージが再配信されることがあります。この動作をオーバーライドするには、minDurationPerAckExtension と maxDurationPerAckExtension を使用します。これらの値の使用方法の詳細については、クライアント ライブラリでの 1 回限りの配信のサポートをご覧ください。
単一メッセージ変換（SMT）
SMT を使用すると、メッセージ属性とデータに対する軽量な変更を Pub/Sub 内で直接行うことができます。この機能を使用すると、メッセージがサブスクライバー クライアントに配信される前に、データのクリーンアップ、フィルタリング、形式変換を行うことができます。
詳細については、SMT の概要と SMT を使用してサブスクリプションを作成するをご覧ください。
サブスクリプション フィルタ
このサブスクリプション フィルタオプションを使用して、フィルタリング式で文字列を指定します。 。サブスクリプションにフィルタがある場合、サブスクリプションはフィルタに一致するメッセージのみを配信します。Pub/Sub サービスは、フィルタに一致しないメッセージの確認応答を自動的に行います。
メッセージは属性でフィルタできますが、メッセージ内のデータでフィルタすることはできません。
指定がない場合、サブスクリプションはメッセージをフィルタせず、サブスクライバーはすべてのメッセージを受け取ります。
フィルタは、適用後に変更または削除することはできません。
フィルタを含むサブスクリプションからメッセージを受信した場合、Pub/Sub が自動的に確認応答するメッセージに対して下り料金は発生しません。これらのメッセージに対しては、メッセージ配信料金とシーク関連のストレージ料金が発生します。
詳細については、サブスクリプションからのメッセージをフィルタするをご覧ください。
メッセージの順序指定
デフォルトでは、Pub/Sub はメッセージを公開された順に配信しないことがあります。サブスクリプションでメッセージの順序指定が有効になっている場合、同じリージョンで同じ順序指定キーを使用して送信されたすべてのメッセージは、パブリッシュされた順序で受信されます。
メッセージを順番に受信するには、パブリッシャーが順序指定キーを設定する必要があります。順序指定キーのないメッセージは、順序どおりに受信されないことがあります。
順序付けされた配信を使用する場合、前のメッセージの確認応答が処理されるまで、後のメッセージの確認応答は処理されません。詳細については、メッセージの順序指定をご覧ください。
デッドレター トピック
設定した配信試行回数に達した後にメッセージを配信できない場合、またはサブスクライバーがメッセージを確認応答できない場合、Pub/Sub は構成されたデッドレター トピックにメッセージを再公開できます。
デッドレター トピックを設定する場合は、配信の最大試行回数も指定できます。デフォルト値は 5 回の配信試行です。最大試行回数は、5 ～ 100 の任意の数値を設定できます。
デッドレター トピックがサブスクリプションとは異なるプロジェクトにある場合は、デッドレター トピックとともにプロジェクト ID も指定する必要があります。
詳細については、デッドレター トピックをご覧ください。
再試行ポリシー
確認応答期限が切れた場合、またはサブスクライバーが否定応答をした場合、Pub/Sub はメッセージを再度送信できます。この再配信の試みは、サブスクリプションの再試行ポリシーと呼ばれます。
デフォルトでは、サブスクリプションの再試行ポリシーは「すぐに再試行」を使用するように設定されています。このオプションを使用すると、確認応答の期限が切れるか、サブスクライバーが否定確認応答で応答したときに、Pub/Sub がメッセージを再送信します。
値を [指数バックオフ遅延後の再試行] に設定することもできます。 この場合、バックオフの最大値と最小値を指定する必要があります。
最大バックオフ値と最小バックオフ値を設定する際のガイドラインは次のとおりです。
バックオフ期間の最大値を設定する場合、デフォルトのバックオフ期間の最小値は 10 秒です。
バックオフ期間の最小値を設定する場合、デフォルトのバックオフ期間の最大値は 600 秒です。
指定できるバックオフ期間の最長値は 600 秒です。
ポリシーとバッチメッセージの再試行
メッセージがバッチにまとまっている場合、次のいずれかが発生すると、Pub/Sub は指数バックオフを開始します。
サブスクライバーにより、バッチ内のすべてのメッセージに対して否定応答が送信される。
確認応答期限が切れた。
ポリシーを再試行してサブスクリプションを push する
push サブスクリプションからメッセージを受信すると、指数バックオフ期間ではなく push バックオフ期間の経過後に、Pub/Sub がメッセージを再配信する場合があります。push バックオフの期間が指数バックオフの期間よりも長い場合、Pub/Sub は push バックオフ期間の経過後に確認応答していないメッセージを再配信します。