メッセージをグローバル Pub/Sub エンドポイントにパブリッシュすると、Pub/Sub は最も近い Google Cloud リージョンにメッセージを自動的に保存します。メッセージの保存と処理を行うリージョンを制御する場合は、トピックにメッセージ ストレージ ポリシーを構成できます。
メッセージ ストレージ ポリシーの概要
新しいトピックの作成時や、コンソール、Google Cloud CLI、または REST API を使用したトピックの更新時に、メッセージ ストレージ ポリシーを設定できます。
メッセージ ストレージ ポリシーはメッセージ コンテンツにのみ適用されます。このポリシーは、トピック名、ラベル、Identity and Access Management（IAM）設定などの他のデータには適用されません。
クライアントから Pub/Sub にメッセージがパブリッシュされると、Pub/Sub でメッセージが保存されます。メッセージ ストレージ ポリシーにより、パブリッシュ リクエストまたはサブスクライブ リクエストの発行元に関係なく、Pub/Sub で指定した Google Cloud リージョンのセットでのみメッセージが保存され、処理されます。ポリシーでパブリッシュ オペレーションに複数のリージョンが許可されている場合、Pub/Sub では、パブリッシュされたメッセージが Google Cloud ネットワークに入る場所に最も近い、許可されたリージョンにメッセージが保存されます。
メッセージ ストレージ ポリシーの指定時に、enforceInTransit を True に設定できます。このフラグにより以下が制御されます。
メッセージ ストレージ ポリシーで許可されていないリージョンで受信したパブリッシュ リクエスト、pull リクエスト、streamingPull リクエストは、
FAILED_PRECONDITIONエラーにより拒否されます。push サブスクリプションの配信は、許可された Cloud リージョン内でのみ処理されます。この制限により、push サブスクリプションのメッセージ配信が完全に一時停止される場合があります。push サブスクリプションが、メッセージの保存場所、許可されたリージョン、エクスポート リソースの場所などの要因の組み合わせによって過度に制約されるため、push サブスクリプションがそのような状態になると、状態が Stackdriver に表示されます。
新しいトピックのメッセージ ストレージ ポリシー
トピックの作成時にメッセージ ストレージ ポリシーを指定しない場合、メッセージ ストレージ ポリシーは有効なリソース ロケーション制限組織ポリシーに基づいて自動的に決定されます。 組織ポリシーが有効でない場合、メッセージ ストレージ ポリシーはすべてのリージョンを許可します。
同様に、指定されたメッセージ ストレージ ポリシーがない場合、
enforceInTransitフラグは Pub/Sub メッセージの転送中リージョンの適用に関する有効な組織のポリシーに基づいて決定されます。この組織のポリシーの詳細については、組織のポリシーの制約をご覧ください。トピックの作成時にメッセージ ストレージ ポリシーを指定すると、有効なリソース ロケーション制限組織ポリシーで許可されているリージョンのみをメッセージ ストレージ ポリシーに含めることが可能です。有効な組織ポリシーがない場合、メッセージ ストレージ ポリシーには任意のリージョンを含めることが可能です。
既存のトピックのメッセージ ストレージ ポリシー
組織ポリシーが更新された場合、その変更が既存のトピックに自動的に反映されることはありません。そのため、既存のトピックのメッセージ ストレージ ポリシーが最新の組織ポリシーと同期しなくなる可能性があります。詳細については、組織のポリシーとトピックのポリシーの差異を管理するをご覧ください。
トピックのメッセージ ストレージ ポリシーが更新された場合、すでにパブリッシュされたメッセージにその変更が反映されることはありません。古いポリシーに基づいてすでに保存されているメッセージが、新しいポリシーに一致するように移動されることはありません。変更は、更新後にパブリッシュされるメッセージにのみ適用されます。
例外
ポリシーには、許可された Google Cloud リージョン名のリストが指定されます。そのため、次の項目はサポートされません。
- 除外リスト
- ゾーンまたはマルチリージョン ロケーション
順序指定キーがあるメッセージをパブリッシュし、メッセージ ストレージ ポリシーによって最も近いリージョンが除外されると、Pub/Sub サービスによってエラーが返されます。
メッセージ ストレージ ポリシーの構成
トピックのメッセージ ストレージ ポリシーを構成する方法には、次の 2 つの方法があります。
- 組織のポリシーを使用してメッセージ ストレージ ポリシーを設定します。
- トピックを作成するときにメッセージ ストレージ ポリシーを構成します。
組織のポリシーを使用してメッセージ ストレージ ポリシーを設定する
Console
複数のトピックに適用されるメッセージ ストレージ ポリシーを構成するには、リソース ロケーション制限組織ポリシーを設定します。
Identity and Access Management コンソールの [組織のポリシー] ページに移動します。
組織のポリシーを設定するリソース階層ノード（組織、フォルダ、プロジェクト）を選択します。
フィルタに「リソースのロケーションの制限」と入力します。
[Google Cloud - リソース ロケーション制限] をクリックします。
[編集] をクリックします。
必要に応じてリージョンを追加または削除します。
作成した新しいトピックには、これらの設定が継承されます。変更は既存のトピックに自動的に反映されません。既存のトピックを更新するには、更新オペレーションを実行する必要があります。
組織のポリシーの詳細については、Google Cloud リソースを管理するをご覧ください。
トピックの作成時にメッセージ ストレージ ポリシーを構成する
Console
Google Cloud コンソールを使用する場合、トピックの作成時にメッセージ ストレージ ポリシーを構成することはできません。代わりに、新しいトピックはすべて、リソース ロケーション制限組織ポリシーを自動的に継承します。
ただし、トピックを作成した後、更新オペレーションを使用してコンソールでメッセージ ストレージ ポリシーを変更できます。
gcloud CLI
特定のメッセージ ストレージ ポリシーを使用してトピックを作成するには、--message-storage-policy-allowed-regions フラグを指定して gcloud pubsub topics create コマンドを使用します。
gcloud pubsub topics create TOPIC_ID \ --message-storage-policy-allowed-regions=REGION1,REGION2
以下を置き換えます。
TOPIC_ID: 新しいトピックの ID または名前。REGION1, REGION2: サポートされている Google Cloud リージョンのカンマ区切りリスト。
REST
メッセージ ストレージ ポリシーを含むトピックを更新するには、projects.topics.create メソッドを使用します。
リクエストは、Authorization ヘッダー内のアクセス トークンにより認証を受ける必要があります。現在のアプリケーションのデフォルト認証情報のアクセス トークンを取得する場合は、gcloud auth application-default print-access-token を使用します。
POST https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
Authorization: Bearer $(gcloud auth application-default print-access-token)
Content-Type: application/json --data @response-body.json
リクエスト本文に次のフィールドを指定します。
{
"name": "projects/PROJECT_ID/topics/TOPIC_ID",
"messageStoragePolicy": {
"allowedPersistenceRegions": ["REGION"],
"enforceInTransit": true
}
}
ここで
PROJECT_ID はプロジェクト ID です。
TOPIC_ID はトピック ID です。
REGION は、指定したリージョンです。
レスポンスの例:
{
"name": "projects/PROJECT_ID/topics/TOPIC_ID",
"messageStoragePolicy": {
"allowedPersistenceRegions": [
"REGION"
],
"enforceInTransit": true
}
}
メッセージ ストレージ ポリシーの構成の詳細については、次の API リファレンスをご覧ください。
メッセージ ストレージ ポリシーを更新する
Console
Google Cloud コンソールで、[トピックの詳細] ページを開きます。
更新するトピックを選択します。
複数のトピックを選択できます。
[情報パネル] で、[ストレージ ポリシー] タブを選択します。
このパネルはデフォルトで閉じられている場合があります。閉じている場合は、[情報パネルを表示] をクリックします。
必要に応じて、必要な数のリージョンを選択または選択解除します。
[更新] をクリックします。
gcloud CLI
組織のリソース ロケーション制限ポリシーで定義されたメッセージ ストレージ ポリシーをトピックに push するには、次の gcloud pubsub topics update コマンドを実行します。
gcloud pubsub topics update TOPIC_ID \ --recompute-message-storage-policy
特定のリージョンを含むトピックのメッセージ ストレージ ポリシーを更新するには、--message-storage-policy-allowed-regions フラグを指定して gcloud pubsub topics update コマンドを実行します。
gcloud pubsub topics update TOPIC_ID \ --message-storage-policy-allowed-regions=REGION1,REGION2
以下を置き換えます。
TOPIC_ID: 更新するトピックの ID。REGION1, REGION2: サポートされている Google Cloud リージョンのカンマ区切りリスト。
REST
メッセージ ストレージ ポリシーを含むトピックを更新するには、projects.topics.patch メソッドを使用します。
リクエストは、Authorization ヘッダー内のアクセス トークンにより認証を受ける必要があります。現在のアプリケーションのデフォルト認証情報のアクセス トークンを取得する場合は、gcloud auth application-default print-access-token を使用します。
PATCH https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
Authorization: Bearer $(gcloud auth application-default print-access-token)
Content-Type: application/json --data @response-body.json
リクエスト本文に次のフィールドを指定します。
{
"name": "projects/PROJECT_ID/topics/TOPIC_ID",
"messageStoragePolicy": {
"allowedPersistenceRegions": ["REGION"], // Replace with your required region
"enforceInTransit": true
}
}
ここで
PROJECT_ID はプロジェクト ID です。
TOPIC_ID はトピック ID です。
REGION は、指定したリージョンです。
レスポンスの例:
{
"name": "projects/PROJECT_ID/topics/TOPIC_ID",
"messageStoragePolicy": {
"allowedPersistenceRegions": [
"REGION"
],
"enforceInTransit": true
}
}
メッセージ ストレージ ポリシーの更新の詳細については、次の API リファレンスをご覧ください。
組織ポリシーとトピックのポリシーとの差異を管理する
組織ポリシーとトピックのポリシーとの差異を表示する
Console
Google Cloud コンソールには、組織ポリシーと個々のトピックのメッセージ ストレージ ポリシーとの差異が表示されます。
組織のポリシーと同期されていないトピックがあるかどうかを確認するには:
[トピックの詳細] ページに移動します。
トピックを選択します。
[情報パネル] で、[ストレージ ポリシー] タブを選択します。
このパネルはデフォルトで閉じられている場合があります。閉じている場合は、[情報パネルを表示] をクリックします。
ストレージ ポリシーがパネルに表示され、組織ポリシーとトピックのポリシーの差異が表示されます。
gcloud CLI
トピックに割り当てられている現在のポリシーを確認するには、次のコマンドを実行します。
gcloud pubsub topics describe TOPIC_ID
以下を置き換えます。
TOPIC_ID: 調査するトピックの ID。
組織ポリシーとトピックのポリシーとの差異を解決する
Console
Google Cloud コンソールで、[トピックの詳細] ページを開きます。
トピックを選択します。
[情報パネル] で、[ストレージ ポリシー] タブを選択します。
このパネルはデフォルトで閉じられている場合があります。閉じている場合は、[情報パネルを表示] をクリックします。
ストレージ ポリシーが不一致と一緒にパネルに表示されます。
不一致がある場合は、情報パネルに、トピックのストレージ ポリシーを組織のポリシーと同期するための次の 3 つのオプションが表示されます。
トピックで、許可されていないロケーションにストレージが許可されている。
ポリシーで許可されているロケーションへの保存のみを許可するよう更新します。
トピックで、一部の許可されているロケーションにストレージが許可されていない。
ポリシーで許可されているすべてのロケーションへの保存を許可するよう更新します。
許可されていないロケーションと許可されたロケーションの両方でトピックが最新でない。
ポリシーで許可されているロケーションへの保存を許可するよう更新します。
問題を解決するために適切な選択肢を選択します。
[トピックを更新] をクリックします。
[組織の保存ポリシーとの同期] ダイアログが開きます。
[トピックを更新] をクリックします。
モニタリングとトラブルシューティング
メッセージ データがどこに保存されているかを把握できるように、Pub/Sub には、各 Google Cloud リージョンで分類された指標が用意されています。
これらの指標を利用すると、以下が可能になる
- 世界中のデータの分布を把握する。
- そのデータに基づいて、パブリッシャーとサブスクライバーのデプロイするロケーションを最適化する。
メッセージ ストレージの指標
確認応答されていない保存メッセージ数:
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 インスタンスにバインドされます。パブリッシャーが単一のリージョンにある場合、単にメッセージ ストレージ ポリシーにリージョンを追加するだけでは、可用性は向上しません。Google Cloud の外部からパブリッシュする場合は、Pub/Sub サービスが利用可能な付近の Google Cloud リージョンにリクエストを転送するために、ルーティングの追加のレイヤが関与します。
us-central1 リージョンのみを許可するメッセージ ストレージ ポリシーを検討してください。
us-east1で実行されるパブリッシャー クライアントがPublishリクエストを発行します。- リクエストは
us-east1の Pub/Sub サーバーにルーティングされます。 - データは
us-east1に保存されず、リクエストはメッセージ ストレージ ポリシーで許可されている最も近いリージョン（us-central1）にルーティングされます。 - Pub/Sub はパブリッシュされたメッセージを
us-central1に保存し、そのロケーションからサブスクライバーにメッセージを転送します。
このメカニズムは、リクエストのレイテンシとシステム全体の可用性に影響します。リクエストはより多くのネットワーク リンクを通過するため、完了するまでにより多くの時間がかかり、失敗する可能性が相対的に高くなります。また、このことは、サブスクライバーによるメッセージの認識が多少遅れる可能性があることも意味します。これは、メッセージがディスパッチされる前に、最も近い許可されたリージョンに移動する必要があるためです。ポリシーでは単一のリージョンが許可されている一方で、パブリッシャー アプリケーションは複数のリージョンで実行される場合、分散アプリケーションは許可された単一のリージョンでのみ使用可能になります。
次のステップ
- グローバル エンドポイントまたはロケーション エンドポイントの使用方法については、Pub/Sub API の概要をご覧ください。