メッセージの順序付けは Pub/Sub の機能であり、パブリッシャー クライアントによってパブリッシュされた順序でサブスクライバー クライアントでメッセージを受信できます。
たとえば、リージョン内のパブリッシャー クライアントがメッセージ 1、2、3 を順番にパブリッシュするとします。メッセージの順序付けを使用すると、サブスクライバー クライアントはパブリッシュされたメッセージを同じ順序で受信します。順序どおりに配信するには、パブリッシャー クライアントが同じリージョンにメッセージをパブリッシュする必要があります。
メッセージの順序付けは、データベース変更の取得、ユーザー セッション トラッキング、ストリーミング アプリケーションなど、イベントの順序を保持することが重要なシナリオで便利な機能です。
このページでは、メッセージの順序付けのコンセプトと、メッセージを順番に受信するようにサブスクライバー クライアントを設定する方法について説明します。メッセージの順序付け用にパブリッシャー クライアントを構成するには、順序付けキーを使用してメッセージをパブリッシュするをご覧ください。
メッセージの順序付けの概要
Pub/Sub での順序付けは、次の要素によって決定されます。
順序付けキー: Pub/Sub メッセージ メタデータで使用される文字列であり、メッセージの順序付けが必要なエンティティを表します。順序付けキーの長さは 1 KB までです。リージョンで順序付きメッセージのセットを受け取るには、同じ順序付けキーを使用して、同じリージョンにすべてのメッセージをパブリッシュする必要があります。順序付けキーの例としては、お客様 ID やデータベース内の行のプライマリ キーがあります。
各順序付けキーのパブリッシュ スループットは 1 MBps に制限されています。トピックのすべての順序付けキーのスループットは、パブリッシュ リージョンで使用可能な割り当てに制限されます。この上限は、GBps 単位で増やすことができます。
順序付けキーはパーティションよりもはるかに高い基数を持つことが想定されるため、順序付けキーはパーティション ベースのメッセージング システムのパーティションと同等ではありません。
メッセージの順序付けを有効にする: これはサブスクリプションの設定です。サブスクリプションでメッセージの順序付けが有効になっている場合、サブスクライバー クライアントは、同じリージョンで同じ順序付けキーを使用してパブリッシュされたメッセージを、サービスで受信した順序で受信します。サブスクリプションでこの設定を有効にする必要があります。
同じトピック T にアタッチされた 2 つのサブスクリプション A と B があるとします。サブスクリプション A はメッセージの順序付けが有効に構成されていますが、サブスクリプション B はメッセージの順序付けが有効に構成されていません。このアーキテクチャでは、サブスクリプション A と B の両方がトピック T から同じ一連のメッセージを受信します。同じリージョンで順序付けキーを使用してメッセージをパブリッシュすると、サブスクリプション A はパブリッシュされた順序でメッセージを受信します。一方、サブスクリプション B は、予定される順序を指定せずにメッセージを受信します。
一般に、ソリューションでパブリッシャー クライアントが順序付きメッセージと順序なしメッセージの両方を送信する必要がある場合は、順序付きメッセージ用と順序なしメッセージ用の別々のトピックを作成します。
順序付きメッセージを使用する際の考慮事項
次のリストに、Pub/Sub での順序付きメッセージの動作に関する重要な情報を表示します。
キー内の順序付け: 同じ順序付けキーでパブリッシュされたメッセージは、順番に受信されることが予定されます。順序付けキー A で、メッセージ 1、2、3 をパブリッシュするとします。順序付けが有効になっている場合、1 は 2 より前に配信され、2 は 3 より前に配信される予定です。
キー間の順序付け: 異なる順序付けキーでパブリッシュされたメッセージは、順序どおりに受信されるとは限りません。順序付けキー A と B があるとします。順序付けキー A の場合、メッセージ 1 と 2 は順番にパブリッシュされます。順序付けキー B の場合、メッセージ 3 と 4 は順番にパブリッシュされます。ただし、メッセージ 1 はメッセージ 4 の前に届く場合もあれば、後で届く場合もあります。
メッセージの再配信: Pub/Sub は各メッセージを少なくとも 1 回配信するため、Pub/Sub サービスでメッセージが再配信される可能性があります。メッセージの再配信は、そのキーの以降のすべてのメッセージ(確認応答済みメッセージを含む)の再配信をトリガーします。サブスクライバー クライアントが特定の順序付けキーのメッセージ 1、2、3 を受信するとします。メッセージ 2 が再配信された場合(確認応答期限が切れたか、ベスト エフォートの確認応答が Pub/Sub に保持されなかったため)、メッセージ 3 も再配信されます。サブスクリプションでメッセージの順序指定とデッドレター トピックの両方が有効になっている場合、Pub/Sub はベスト エフォート方式でデッドレター トピックにメッセージを転送するため、正確でないこともあります。
確認応答の遅延とデッドレター トピック: 特定の順序付けキーの確認応答されていないメッセージは、特にサーバー再起動時やトラフィックの変化時に、他の順序付けキーのメッセージの配信が遅れる可能性があります。このようなイベント間で順序を維持するには、すべてのメッセージに対してタイムリーに確認応答を行う必要があります。適切なタイミングで確認応答できない場合は、デッドレター トピックを使用して、メッセージの無期限の保持を回避することを検討してください。デッドレター トピックにメッセージが書き込まれるとき、順序が保持されないことがあることに注意してください。
メッセージ アフィニティ(streamingPull クライアント): 通常、同じキーのメッセージは同じ streamingPull サブスクライバー クライアントに配信されます。アフィニティは、特定のサブスクライバー クライアントへの順序付けキーのメッセージが未処理の場合に想定されます。未処理のメッセージがない場合、ロード バランシングまたはクライアントの切断のためにアフィニティがシフトすることがあります。
アフィニティが変更される可能性のある場合でもスムーズに処理できるように、特定の順序付けキーの任意のクライアントでメッセージを処理できるように streamingPull アプリケーションを設計することが重要です。
Dataflow との統合: Pub/Sub で Dataflow を構成する場合は、サブスクリプションのメッセージの順序付けを有効にしないでください。Dataflow には、ウィンドウ オペレーションの一部として、すべてのメッセージの時系列順序付けを確保する独自のメッセージ全体の順序付けメカニズムがあります。この順序付け方法は、Pub/Sub の順序付けキーベースのアプローチとは異なります。Dataflow で順序付けキーを使用すると、パイプラインのパフォーマンスが低下する可能性があります。
自動スケーリング: Pub/Sub の順序付き配信は、数十億の順序付けキーにスケーリングされます。順序付けキーの数が多いほど、より多くのサブスクライバーへの並列配信が可能になります。これは、順序付けが同じ順序付けキーを持つすべてのメッセージに適用されるためです。
順序付き配信にはいくつかのトレードオフがあります。順序なし配信と比較して、順序付き配信では、パブリッシュの可用性がわずかに低下し、エンドツーエンドのメッセージ配信レイテンシが増加する可能性があります。順序付け配信の場合、フェイルオーバーでは、メッセージが正しい順序で書き込まれ、読み取られるように調整する必要があります。
メッセージの順序付けの使用方法の詳細については、次のベスト プラクティスのトピックをご覧ください。
メッセージの順序付けに関するサブスクライバー クライアントの動作
サブスクライバー クライアントは、特定のリージョンでパブリッシュされた順序でメッセージを受信します。Pub/Sub では、pull サブスクリプションと push サブスクリプションに接続されたサブスクライバー クライアントなど、メッセージを受信するさまざまな方法がサポートされます。クライアント ライブラリは streamingPull を使用します(PHP を除く)。
これらのサブスクリプション タイプの詳細については、サブスクリプション タイプを選択するをご覧ください。
以下の各セクションでは、各タイプのサブスクライバー クライアントでメッセージを受信する順序の仕組みについて説明します。
StreamingPull サブスクライバー クライアント
streamingPull でクライアント ライブラリを使用する場合は、サブスクライバー クライアントがメッセージを受信するたびに実行されるユーザー コールバックを指定する必要があります。クライアント ライブラリでは、任意の順序付けキーに対して、コールバックが正しい順序でメッセージが完了するまで実行されます。メッセージがそのコールバック内で応答確認されると、メッセージのすべての計算が順番に行われます。ただし、ユーザー コールバックがメッセージに対して他の非同期動作をスケジュールする場合、サブスクライバー クライアントは非同期動作が順番に行われるようにする必要があります。1 つの方法は、順番に処理されるローカル動作キューにメッセージを追加することです。
pull サブスクライバー クライアント
pull サブスクリプションに接続しているサブスクライバー クライアントの場合、Pub/Sub メッセージの順序付けは次をサポートします。
PullResponse の順序付けキーのメッセージはすべて、リスト内で適切な順序になっています。
順序付けキーに対して一度に未処理にできるメッセージのバッチは 1 つのみです。
一度に未処理にできるメッセージのバッチは 1 つだけという要件は、順序付けられた配信を維持するために必要ですが、これは、Pub/Subサービスがサブスクライバーの pull リクエストのために送信する応答の成功または遅延を保証できないためです。
push サブスクライバー クライアント
push の制限は pull の制限よりも厳格です。push サブスクリプションの場合、Pub/Sub は順序付けキーごとに一度に 1 つの未処理のメッセージをサポートします。各メッセージは、個別のリクエストとしてプッシュ エンドポイントに送信されます。したがって、リクエストを並列で送信すると、同じ順序付けキーの複数のバッチのメッセージを配信してサブスクライバーを同時に pull する場合と同じ問題が発生します。同じ順序付けキーでメッセージが頻繁にパブリッシュされるトピックや、レイテンシが非常に重要なトピックでは、プッシュ サブスクリプションは適切ではない場合があります。
サブスクライバー クライアントをエクスポートする
エクスポート サブスクリプションでは、順序付きのメッセージがサポートされます。BigQuery サブスクリプションの場合、同じ順序指定キーを持つメッセージは BigQuery テーブルに順番に書き込まれます。Cloud Storage サブスクリプションの場合、同じ順序指定キーを持つメッセージがすべて同じファイルに書き込まれるとは限りません。同じファイル内の場合、順序指定キーのメッセージが順序どおりに処理されます。複数のファイルに分散している場合、順序指定キーの後続のメッセージは、以前のメッセージがあるファイルの名前のタイムスタンプよりも前のタイムスタンプを持つファイルに表示される可能性があります。
メッセージの順序付けを有効にする
メッセージを順に受信するには、メッセージを受信するサブスクリプションのメッセージ順序指定プロパティを設定します。メッセージを順に受信すると、レイテンシが増加する可能性があります。 サブスクリプションを作成した後にメッセージの順序付けプロパティを変更することはできません。
Google Cloud コンソール、Google Cloud CLI、または Pub/Sub API を使用してサブスクリプションを作成するときに、メッセージの順序指定プロパティを設定できます。
Console
メッセージの順序指定プロパティがあるサブスクリプションを作成する手順は次のとおりです。
- Google Cloud コンソールで、[サブスクリプション] ページに移動します。
[サブスクリプションを作成] をクリックします。
[サブスクリプション ID] を入力します。
メッセージを受信するトピックを選択します。
[メッセージの順序指定] セクションで、[順序指定キーを使用してメッセージの順序を指定する] を選択します。
[作成] をクリックします。
gcloud
メッセージの順序指定プロパティがあるサブスクリプションを作成するには、gcloud pubsub subscriptions
create
コマンドと --enable-message-ordering
フラグを使用します。
gcloud pubsub subscriptions create SUBSCRIPTION_ID \ --enable-message-ordering
SUBSCRIPTION_ID をサブスクリプションの ID に置き換えます。
リクエストが成功すると、コマンドラインに確認メッセージが表示されます。
Created subscription [SUBSCRIPTION_ID].
REST
メッセージの順序指定プロパティがあるサブスクリプションを作成するには、次のような PUT
リクエストを送信します。
PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID Authorization: Bearer $(gcloud auth application-default print-access-token)
以下を置き換えます。
- PROJECT_ID: トピックがあるプロジェクトのプロジェクト ID
- SUBSCRIPTION_ID: サブスクリプション ID
リクエスト本文には、次のように指定します。
{ "topic": TOPIC_ID, "enableMessageOrdering": true, }
TOPIC_ID は、サブスクリプションに接続するトピックの ID に置き換えます。
リクエストが成功した場合のレスポンスは、JSON 形式のサブスクリプションになります。
{ "name": projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID, "topic": projects/PROJECT_ID/topics/TOPIC_ID, "enableMessageOrdering": true, }
C++
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の C++ の設定手順を実施してください。詳細については、Pub/Sub C++ API リファレンス ドキュメントをご覧ください。
C#
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の C# の設定手順を実施してください。詳細については、Pub/Sub C# API リファレンス ドキュメントをご覧ください。
Go
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の Go の設定手順を実施してください。詳細については、Pub/Sub Go API リファレンス ドキュメントをご覧ください。
Java
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の Java の設定手順を実施してください。詳細については、Pub/Sub Java API リファレンス ドキュメントをご覧ください。
Node.js
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の Node.js の設定手順を実施してください。詳細については、Pub/Sub Node.js API リファレンス ドキュメントをご覧ください。
Node.js
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の Node.js の設定手順を実施してください。詳細については、Pub/Sub Node.js API リファレンス ドキュメントをご覧ください。
Python
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の Python の設定手順を実施してください。詳細については、Pub/Sub Python API リファレンス ドキュメントをご覧ください。
Ruby
このサンプルを試す前に、クイックスタート: クライアント ライブラリの使用の Ruby の設定手順を実施してください。詳細については、Pub/Sub Ruby API リファレンス ドキュメントをご覧ください。
次のステップ
順序指定に関するブログ記事を読む。
再試行不可能なエラーが発生した場合にメッセージをパブリッシュし続ける手順については、順序付けキーを使用してリクエストを再試行するをご覧ください。
サブスクリプションをモニタリングします。
順序付けキーを使用してメッセージをパブリッシュする方法を確認します。