メッセージの再生と破棄

Cloud Pub/Sub サブスクライバーのデータ API(pull など)は、メッセージ データへの制限付きアクセスを提供します。通常、特定のサブスクリプションのサブスクライバーから確認済みのメッセージにアクセスすることはできません。さらに、サブスクライバーのクライアントは、一部しか必要でなくてもサブスクリプションに含まれるメッセージをすべて処理しなければなりません。

今回の Seek の要点はサブスクライバーの機能を拡張し、確認応答状態のメッセージをまとめて操作できるようになったことです。たとえば、確認済みのメッセージを再生したり、メッセージをまとめて破棄したりできます。さらに、シーク機能の一部として導入されたスナップショットという機能とシークを組み合わせて使えば、あるサブスクリプションの状態を別のサブスクリプションにコピーすることもできます。なお、確認済みのメッセージを回復するには、通常、ソース サブスクリプションを事前に構成する必要があり、そのために追加のストレージ料金が発生します。

以下、これらの機能を説明します。ただし、活用例についてはクイックスタートをご覧ください。

仕組み

特定のタイムスタンプまでシークする

ある特定の時刻までシークすると、結果的に、その時刻よりも前に Cloud Pub/Sub が受信したあらゆるメッセージが「確認済み」とマークされ、それよりも後に受信したあらゆるメッセージが「未確認」とマークされます。未来のある時刻までシークするとメッセージが破棄されます。確認済みのメッセージを再生または再処理するには、より前の時刻までシークします。メッセージ公開時間は Cloud Pub/Sub サーバーで生成されます(API リファレンスの publishTime を参照)。なお、このやり方は正確でありません。Cloud Pub/Sub サーバーの間のクロックがずれている可能性があること、また Cloud Pub/Sub がソースシステムでのイベント発生時刻ではなく、公開リクエストの到着時刻で処理を行うしかないからです。

より前の時刻までシークする場合は、確認済みのメッセージが保持されるようにサブスクリプションを最初に構成してください。

  • 確認済みのメッセージは、サブスクリプションの retain_acked_messages プロパティが true(デフォルトは false)に設定されている場合のみ、公開後、最長で message_retention_duration(デフォルトでは 7 日間)サブスクリプションに保持されます。確認済みのメッセージは、サブスクリプションの retain_acked_messagestrue に設定された後に確認されたもののみが保持されます。
  • 未確認メッセージは、公開後、最長で message_retention_duration(デフォルトでは 7 日間)サブスクリプションに保持されます。
  • サブスクリプションの retain_acked_messages プロパティと message_retention_duration プロパティは、両方とも、サブスクリプションの作成時に指定したり、既存のサブスクリプションのものを更新したりできます。

特定のスナップショットまでシークする

スナップショット機能を使用すると、サブスクリプションのメッセージ確認状態を取得できます。スナップショットが作成されると、(そのスナップショットの作成時に)ソース サブスクリプション内で未確認だったすべてのメッセージと、それ以降に当該トピックに公開されたすべてのメッセージが保持されます。これらの未確認のメッセージを再生するには、スナップショットを使用して当該トピックのいずれかのサブスクリプションまでシークします。

特定の時刻までシークする場合と異なり、特定のスナップショットまでシークするのにサブスクリプションを特別に構成する必要はありません。必要なのは、より前の時刻にスナップショットを作成することだけです。たとえば、新しいサブスクライバー コードをデプロイするとき、予期しない確認応答や誤った確認応答から回復するためにスナップショットを作成するようなケースが考えられます。

スナップショットは、次の場合に期限切れとなり削除されます(どちらかの条件が最初に成立したとき)。

  • スナップショットの有効期間(7 日間)が切れた。
  • スナップショット内の最も古い未確認メッセージが message retention duration を超えた。

たとえば、サブスクリプションのスナップショットにバックログがあり、その最も古い未確認メッセージが 1 日前のメッセージだとします。この場合、スナップショットは 7 日ではなく 6 日後に期限切れになります。これはスナップショットで少なくとも 1 回の配信を確実に保証するための必須の設定です。

結果整合性

メッセージ配信の保証に関してシーク オペレーションには完全な一貫性があります。つまり、シーク条件に基づいて未確認と判定されるメッセージは、シーク操作の成功後に最終的に少なくとも 1 回は配信されることが保証されます。しかし、これは配信されるメッセージが直ちにシーク オペレーションと一致することを意味しません。シーク タイムスタンプよりも前に公開されたメッセージ(またはスナップショット内の確認済みのメッセージ)はシーク操作後もまだ配信される可能性があります。ある意味で、メッセージ配信はシーク オペレーションと最終的に一致するシステムとして動作します。オペレーションが完全に有効になるまで 1 分ほどかかることがあります。

使用例

  • サブスクライバー コードを安全に更新する。 次のような懸念があります。新しいサブスクライバー コードをデプロイするとき、新しい実行可能ファイルがメッセージを誤って確認してメッセージを失うかもしれません。この場合、デプロイ プロセスにスナップショットを組み込むことで、新しいサブスクライバー コードのバグから回復できます。
  • 予期しないサブスクライバーの問題から回復する。 サブスクライバーの問題が特定のデプロイ イベントに関係していないと、関連するスナップショットが存在しない可能性があります。この場合、サブスクリプションの確認済みのメッセージを保持する設定が有効化してあれば、過去の時間までシークすることでエラーから回復できます。
  • 処理時間とコストを節約する。 関連性のないメッセージの大きなバックログに対して一括で確認応答を行います。
  • サブスクライバー コードを既知のデータでテストする。 サブスクライバー コードをテストしてパフォーマンスや一貫性の向上を図るときは、毎回同じデータを使用すると便利です。スナップショットは、セマンティクスの面でこれを強力に支えます。また、そのデータを新しく作成されたサブスクリプションも含め、所定のトピックの任意のサブスクリプションに適用できるからです。

次のステップ

Cloud Pub/Sub を Cloud Dataflow で使用できます。しかし、稼働中の Cloud Pub/Sub Seek パイプラインから Cloud Pub/Sub Seek に直接アクセスすることはおすすめしません。推奨ワークフローは、「Using Cloud Pub/Sub with Cloud Dataflow」(Cloud Pub/Sub を Cloud Dataflow で使用する)をご覧ください。

このページは役立ちましたか?評価をお願いいたします。

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

Cloud Pub/Sub ドキュメント