今回も、Professional Cloud Data Engineer認定取得するために、私が勉強した内容をアウトプットしていきます。
今回は、Pub/Subのリソースロケーション制限、Pub/SubのSeek機能、Pub/Subのメッセージ保持ポリシーについて説明します！
ぜひ、最後までご覧いただけると嬉しいです！
Pub/Subのリソースロケーション制限
クラウドサービスを利用する際、特に金融、公共、ヘルスケアなどの分野では、「データが物理的にどこに保存されるか」というデータレジデンシーの要件が極めて重要になります。規制や法律により、特定の国や地域内にデータを留め置くことが求められるためです。
私が参画したプロジェクトでも、データは日本国内に留めてほしいという要件を頂いたことがあります。
Google CloudのPub/Subでは、この要件に応えるための強力な機能を提供しており、メッセージデータが保存される地理的な場所を厳密に制御できます。
リソースロケーション制限とは？
通常、グローバルなPub/Subエンドポイントに公開されたメッセージは、パフォーマンスを最適化するために最も効率的なGoogle Cloudリージョンに保存される可能性があります。しかし、これではデータが意図せず国外に出てしまうリスクが残ります。
データレジデンシーを確実に満たすためには、以下の2つの側面を制御する必要があります。
- リソースの作成場所：トピックなどのPub/Subリソースを、許可されたリージョン（例: 日本国内）でのみ作成できるようにする。
- データの保存場所：作成されたトピック内で、メッセージデータそのものが許可されたリージョン外に保存されないようにする。
Pub/Subでは、これらを組織のポリシーによって一元的に強制することが可能です。
仕組みと設定方法：2つのポリシーを組み合わせる
厳格なデータレジデンシーは、「リソースの場所」と「メッセージの保存場所」をそれぞれ制御する2つのポリシー制約を組み合わせることで実現します。
1. リソースの作成場所を制限する (gcp.resourceLocations)
まず、Pub/Subのトピックという「リソース」自体が、意図しないリージョンで作成されるのを防ぎます。
- 制約：
constraints/gcp.resourceLocations - 目的：Pub/Subトピックを含む、Google Cloudリソースを作成できるリージョンを限定する。
- 設定例：許可する場所に「
in:asia-northeast1-locations」と設定すると、リソース作成が東京リージョンに限定されます。
このポリシーを適用すると、許可されていないリージョンでトピックを作成しようとしてもリクエストは失敗し、コンプライアンス違反を未然に防ぎます。また、この組織ポリシーは、Pub/Sub以外のリソースに対しても適用されるんで、日本リージョン以外でリソースを作成すると失敗します。
2. メッセージデータの保存場所を強制する (pubsub.enforceInTransitRegions)
次に、作成されたトピック内の「メッセージデータ」がどこに保存されるかを制御します。これはPub/Subのメッセージストレージポリシーという機能によって管理されます。
- 制約：constraints/pubsub.enforceInTransitRegions
- 目的：トピック作成時に設定されるメッセージストレージポリシーを特定のリージョンに強制する。
- 設定例：適用を「オン」と設定すると、上記リージョンでのみメッセージが転送される。
これにより、メッセージデータが必ず指定したリージョン（この場合は東京）内に留まることを保証します。
なぜこの組み合わせが重要なのか？
この2段階のアプローチにより、以下のようなメリットが生まれます。
- コンプライアンス遵守：GDPRや各国のデータ保護法など、地域固有の厳しい規制要件を確実に満たすことができます。GDPR（General Data Protection Regulation）は、EU域内の個人データの収集・利用・保護に関するルールを定めた包括的なデータ保護規則です。
- データガバナンスの強化：組織全体のデータ管理ポリシーを一元的に、かつ強制的に適用し、ヒューマンエラーの余地をなくします。
- セキュリティの向上：データの物理的な所在地を完全に把握・管理することで、セキュリティリスクを大幅に低減します。
Pub/Subのロケーション制御機能を正しく活用することで、企業はリアルタイムメッセージングの利便性を享受しつつ、厳しいデータレジデンシー要件にも確実に対応することが可能になります。
Pub/Subのリソースロケーション制限のまとめ
Pub/Subのリソースロケーション制限は、金融や公共、医療など厳しいデータレジデンシー要件を持つ分野で特に有効です。
組織ポリシーを用いて、メッセージが保存・処理されるリージョンを明示的に制御できます。
これにより、意図しない場所へのデータ保存を防ぎ、法規制やコンプライアンスを確実に遵守できます。
さらに、データガバナンスの強化やセキュリティリスクの低減にも貢献します。
企業はリアルタイム性と規制対応を両立し、安全かつ効率的にPub/Subを活用できます。
Pub/SubのSeek機能
サブスクライバーのコードにバグがあったり、デプロイに失敗したりして、すでに「確認応答（ack）」したメッセージをもう一度処理したいと思ったことはありませんか？
通常、一度確認応答されたメッセージはサブスクリプションのバックログから除外されるため、再取得はできません。
この課題を解決するのが Pub/Sub の Seek（シーク）機能 です。Seek を使うと、サブスクリプションのカーソルを過去の時点に戻し、メッセージを再配信させることができます。
Seek（シーク）とは？
Seek は、サブスクリプションの ack ポインタ を、指定した過去の時刻やスナップショットの位置に戻す操作です。これにより、すでに確認応答されたメッセージも含め、その時点以降のメッセージを再度受信できるようになります。ack ポインタは、Pub/Sub のサブスクリプションで、サブスクライバーが最後にメッセージを確認応答（ack）した位置を示すマーカーです。
注意：Seek を実行すると、サブスクリプションの「どこまでメッセージを処理済みか」を表す位置が変更されます。未処理メッセージが「消去」されるのではなく、配信の開始位置が変わると理解すると正確です。
メッセージを再配信（リプレイ）する方法
Seek を使ったリプレイには、主に次の 2 つの方法があります。
方法1：タイムスタンプを指定して巻き戻す
＜仕組み＞
「2025年8月18日 15:00」のように日時を指定すると、Pub/Sub はその時刻以降に配信可能なすべてのメッセージをバックログから再配信します。
＜前提条件＞
トピックに「メッセージ保持（Message retention）」を有効にし、保持期間内である必要があります。
＜ユースケース＞
「昨日のデプロイ以降、処理結果がおかしい」といった場合に、デプロイ前の正常な時点に戻してデータを再処理する。
方法2：スナップショットを指定して巻き戻す
＜スナップショット＞
サブスクリプションのある時点の未ackメッセージ位置を記録した「セーブポイント」。
＜仕組み＞
事前に作成したスナップショットを指定して Seek を実行すると、その作成時点の ack 状態にサブスクリプションが復元されます。
＜ユースケース＞
リスクの高いデプロイやデータ移行の前にスナップショットを作成し、問題が発生したらその直前の状態に戻す。
Pub/SubのSeek機能のまとめ
Pub/SubのSeek機能は、過去に確認応答済みのメッセージを再処理できる便利な仕組みです。
サブスクリプションを特定の時刻やスナップショットに巻き戻し、メッセージを再配信させることができます。
ただし、Seekを実行すると未処理のメッセージが消去されるため、注意が必要です。
タイムスタンプ指定では任意の時刻に戻せ、スナップショット指定では保存時点と同じ状態に復元できます。
この機能を活用すれば、デプロイ失敗やバグ発生時でも安全にメッセージ処理をやり直せます。
Pub/Subのメッセージ保持ポリシー
Google Cloud の Pub/Sub は、スケーラブルで信頼性の高い非同期メッセージングサービスとして、幅広いアプリケーションで利用されています。
その中で重要な機能のひとつが メッセージ保持ポリシー です。これにより、パブリッシュ済みのメッセージを一定期間保存し、必要に応じて再処理できます。
Pub/Sub のアーキテクチャでは、1つのトピックを複数のサブスクリプションで管理でき、各サブスクライバーが独自の要件に沿ってメッセージを取得・保持できます。
保持には「トピック保持」と「サブスクリプション保持」の 2 種類があります。
1. トピック保持機能：メッセージ履歴を一元管理
トピック保持を有効にすると、トピックにパブリッシュされたメッセージは、サブスクリプションの有無にかかわらず最大 31 日間保持されます。
＜メリット＞
- コストと管理の簡素化：複数のサブスクリプションが同じ履歴を利用する場合でも、メッセージはトピックに一度だけ保持されます。
- 新規サブスクリプションでの再生：新しく作成したサブスクリプションから、保持中の過去メッセージを取得可能です。
- 安全なコード更新：処理に問題が起きた場合でも、トピックに残っているメッセージを再処理できます。
＜ユースケース＞
- 新規サービスを既存トピックに追加し、過去 2 週間分のイベントデータを最初から読み込んで分析する。
- 本番環境で不具合が発覚した際、影響範囲を調査するために履歴データを再処理する。
＜注意＞
トピック保持を有効にすると、メッセージ保持料金が発生します。
データストリーム全体のライフサイクルを中央でコントロールしたい場合に適した機能です。
2. サブスクリプション保持機能：サブスクライバーごとの独立した管理
各サブスクリプションに対しても、独自にメッセージ保持を設定できます。
＜特徴＞
- 保持期間の柔軟性：10 分〜 31 日の範囲で保持期間を指定可能（デフォルトは 7 日間）。
- 確認済みメッセージの保持：「確認済みメッセージを保持」オプションを有効にすると、ack 済みのメッセージも保持期間内で再取得できます。
＜ユースケース＞
- データ解析チームが「確認済みメッセージを保持」をオンにして、過去の処理結果を何度も検証できるようにする。
マルチテナント構成で、同じトピックを使いながら、各テナントが自分専用のサブスクリプションを持ち、保持期間を独自に設定する。
Pub/Subのメッセージ保持ポリシーのまとめ
Pub/Subのメッセージ保持ポリシーは、過去のメッセージを保存・再処理するための機能で、メッセージを一元管理する「トピック保持」と、サブスクリプションごとに柔軟に設定できる「サブスクリプション保持」の2種類があります。トピック保持は、データストリーム全体を中央で管理したい場合に適しており、新しく作成したサブスクリプションでも過去のデータを利用できる点が特徴です。一方、サブスクリプション保持は、確認済みメッセージも含めて利用者やチームごとに独立した保持期間を設定できるため、より柔軟な運用を実現します。これらを組み合わせ、1つのトピックに複数のサブスクリプションを接続することで、部門や用途に応じた最適なデータ保持戦略を設計し、効率的なデータ活用が可能になります。
まとめ
今回は、下記３点について説明しました。
- Pub/Subのリソースロケーション制限
- Pub/SubのSeek機能
- Pub/Subのメッセージ保持ポリシー
Pub/Subは、リアルタイムメッセージングの利便性に加え、規制対応やデータ再処理を支える多彩な機能を提供します。
リソースロケーション制限により、データの保存先を厳密に管理し、コンプライアンスを確実に遵守できます。
シーク機能を活用すれば、過去のメッセージを巻き戻して再処理でき、障害発生時の復旧にも役立ちます。
さらに、メッセージ保持ポリシーによって履歴を効率的に管理し、用途に応じた柔軟な運用が可能です。
これらを組み合わせることで、企業は安全性・信頼性・効率性を兼ね備えたデータ基盤を構築できます。
これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！
それでは、次回のブログで！
