メッセージをグローバル Pub/Sub エンドポイントにパブリッシュすると、Pub/Sub は最も近い Google Cloud リージョンにメッセージを自動的に保存します。その後、Pub/Sub は、メッセージがどこに保存されているかに関係なく、世界中のサブスクライバーにメッセージを配信します。
場合によっては、メッセージがどこに保存されるかをより詳細に管理することが必要になります。Pub/Sub のトピックのメッセージ ストレージ ポリシーによって、パブリッシュ リクエストの発行元に関係なく、トピックにパブリッシュされるすべてのデータが特定のリージョンまたはリージョン セットに保持されるようにできます。複数のリージョンがポリシーで許可されている場合、Pub/Sub は最も近い許可されたリージョンを選択します。
順序指定キーがあるメッセージをパブリッシュし、メッセージ ストレージ ポリシーによって最も近いリージョンが除外されると、Pub/Sub サービスによってエラーが返されます。
トピックのメッセージ ストレージ ポリシーは、次の方法で構成できます。
すべてのトピックを組織全体のスコープ内で構成するには、リソース ロケーション制限組織ポリシーを使用できます。組織全体のポリシーは [IAM と管理] コンソールの [組織のポリシー] セクションで管理されます。
きめ細かく管理するためには、トピックのメッセージ ストレージ ポリシーを、トピックの作成時点で構成するか、
UpdateTopicオペレーションを使用して構成します。
新しいトピックのメッセージ ストレージ ポリシー
トピックの作成時にメッセージ ストレージ ポリシーを指定しない場合、メッセージ ストレージ ポリシーは有効なリソース ロケーション制限組織ポリシーに基づいて自動的に決定されます。組織ポリシーが有効でない場合、メッセージ ストレージ ポリシーはすべてのリージョンを許可します。
トピックの作成時にメッセージ ストレージ ポリシーを指定すると、有効なリソース ロケーション制限組織ポリシーで許可されているリージョンのみをメッセージ ストレージ ポリシーに含めることが可能です。有効な組織ポリシーがない場合、メッセージ ストレージ ポリシーには任意のリージョンを含めることが可能です。
既存のトピックとメッセージに関するメッセージ ストレージ ポリシーの更新
組織ポリシーが更新された場合、その変更が既存のトピックに自動的に反映されることはありません。そのため、既存のトピックのメッセージ ストレージ ポリシーが最新の組織ポリシーと同期しなくなる可能性があります。これらの差異が発生した場合の解決方法については、以下をご覧ください。
トピックのメッセージ ストレージ ポリシーが更新された場合、すでにパブリッシュされたメッセージにその変更が自動的に反映されることはありません。古いポリシーに基づいてすでに保存されているメッセージが、新しいポリシーに一致するように移動されることはありません。変更は、更新後にパブリッシュされるメッセージにのみ適用されます。
メッセージ ストレージ ポリシーの構成
メッセージ ストレージ ポリシーを構成するには、組織ポリシーと同期するか、トピックに対して明示的に指定します。ポリシーは次の方法で構成できます。
- [トピックの詳細] ビュー
gcloudコマンドライン ツール- サービス API（クライアント ライブラリを使用）
gcloud ツールを使用したトピックのメッセージ ストレージ ポリシーの更新または設定
現在の組織ポリシーで、トピックの既存のポリシーを更新します。
gcloud pubsub topics update TOPIC --recompute-message-storage-policy
許可された Google Cloud リージョンのリストとして、トピックに明示的なメッセージ ストレージ ポリシーを設定します。
gcloud pubsub topics update TOPIC --message-storage-policy-allowed-regions=us-central1,us-east1
このオペレーションによって、その後、トピックにパブリッシュされたメッセージが、確実に us-central1 または us-east1 に保存されます。
組織ポリシーとトピックのポリシーとの差異の表示と解決
Cloud Console には、組織ポリシーと個々のトピックのメッセージ ストレージ ポリシーとの差異が表示されます。また、Cloud Console では、トピックのメッセージ ストレージ ポリシーを組織ポリシーと同期することもできます。トピックレベルのメッセージ ストレージ ポリシーは Cloud Console では指定できません。
組織ポリシーとの同期がとれていないトピックを確認するには、コンソールにアクセスし、右側の情報パネルの [ストレージ ポリシー] タブを開きます。
また、コマンドラインを使用して現在のポリシーを確認することもできます。
gcloud pubsub topics describe TOPIC
複数のトピックの更新
1 つ以上のトピックを更新するには:
- コンソールの [ストレージ ポリシー] タブに移動します。
- 1 つ以上のトピックを選択します。
- [更新] をクリックします。
例外
ポリシーには、許可された Google Cloud リージョン名のリストが指定されます。そのため、次の項目はサポートされません。
- 除外リスト
- ゾーンまたはマルチリージョン ロケーション
モニタリングとトラブルシューティング
メッセージ データがどこに保存されるかを把握できるように、Google Cloud リージョンで分類された Pub/Sub の指標を用意しています。
確認応答されていない保存メッセージ数:
subscription/num_unacked_messages_by_region
保存されたデータの量:
subscription/unacked_bytes_by_region
最も古いメッセージの経過時間:
subscription/oldest_unacked_message_age_by_region
トピックとスナップショットには、類似の指標を使用できます。さらに、再生のために任意で保持される確認応答済みメッセージに、対応する指標を使用できます。次に例を示します。
subscription/num_retained_acked_messages_by_region
これらの指標を使用して、次のことを行えます。
- 世界中のデータの分布を把握する。
- そのデータに基づいて、パブリッシャーとサブスクライバーのデプロイするロケーションを最適化する。
パフォーマンスと可用性への影響
メッセージ ストレージ ポリシーは全体的な SLA には影響しませんが、パブリッシャーまたはサブスクライバーが Google Cloud の外部またはポリシーで許可されていないリージョンで実行される場合、可用性と制御のトレードオフが発生します。メッセージ ストレージ ポリシーで許可されているリージョン セット内でパブリッシャー クライアントを実行しているユーザーには、サービスのレイテンシや可用性の変更は表示されません。
これらのトレードオフを理解するために、パブリッシュ リクエストのルーティング方法を検討すると有益です。通常、Pub/Sub では、リクエストのソースのできるだけ近くにメッセージを保存しようとします。Google Cloud 内で発行されるリクエストは、原則として同じリージョン内の Pub/Sub インスタンスにバインドされます。パブリッシャーが単一のリージョンにある場合、単にメッセージ ストレージ ポリシーにリージョンを追加しても、可用性は向上しません。GCP の外部からパブリッシュする場合は、Pub/Sub サービスが利用可能な付近の GCP リージョンにリクエストを転送するために、ルーティングの追加のレイヤが関与します。
us-central1 リージョンのみを許可するメッセージ ストレージ ポリシーを検討してください。
us-east1で実行されるパブリッシャー クライアントがPublishリクエストを発行します。- リクエストは
us-east1の Pub/Sub サーバーにルーティングされます。 - データは
us-east1に保存されず、リクエストはメッセージ ストレージ ポリシーで許可されている最も近いリージョン（us-central1）にルーティングされます。 - Pub/Sub はパブリッシュされたメッセージを
us-central1に保存し、そのロケーションからサブスクライバーにメッセージを転送します。
このメカニズムは、リクエストのレイテンシとシステム全体の可用性に影響します。リクエストはより多くのネットワーク リンクを通過するため、完了するまでにより多くの時間がかかり、失敗する可能性が相対的に高くなります。また、このことは、サブスクライバーによるメッセージの認識が多少遅れる可能性があることも意味します。これは、メッセージがディスパッチされる前に、最も近い許可されたリージョンに移動する必要があるためです。ポリシーでは単一のリージョンが許可されている一方で、パブリッシャー アプリケーションは複数のリージョンで実行される場合、分散アプリケーションは許可された単一のリージョンでのみ使用可能になります。