このドキュメントでは、Pub/Sub トピックのサブスクライブとサブスクライバー クライアントでのメッセージの受信のプロセスにすでに精通していることを前提としています。
Pub/Sub を初めて使用する場合は、クイックスタート ガイドのいずれかを参照して、コンソール、Google Cloud CLI、またはクライアント ライブラリを使用して Pub/Sub を実行する方法を学んでください。
適切なサブスクリプションを選択する
Pub/Sub は、push サブスクリプションや pull サブスクリプションなどの標準サブスクリプションを提供します。Pub/Sub には、標準のサブスクリプションに加えて、エクスポート サブスクリプションも用意されており、Google Cloud リソースに直接メッセージを保存できます。Dataflow を中継点として使用する必要はありません。たとえば、BigQuery サブスクリプションは BigQuery テーブルにメッセージを保存します。
プッシュ サブスクリプションは、次のシナリオで推奨されます。
クライアント ライブラリを依存関係としてインポートするコードをサブスクライバー アプリケーションに含めることはできません。
サブスクライバー クライアントは送信リクエストを行うことができません。
サブスクライバー クライアントがサブスクリプションのリストを認識していない、異なるトピックとサブスクリプションのメッセージを処理するために同じインスタンスを使用する場合。
一般的なケースでは、高レベルのクライアント ライブラリを使用することをおすすめします。代わりに単項プルを使用している場合は、returnImmediately を true に設定しないでください。true に設定すると、pull のパフォーマンスに悪影響が及びます。returnImmediately フィールドは非推奨になりました。
すべてのサブスクリプション タイプを比較して、ビジネスニーズに最適なものを選択するには、Pub/Sub サブスクリプションの比較表をご覧ください。
エクスポート サブスクリプションのメリットについては、エクスポート サブスクリプションを使用する場合をご覧ください。
メッセージを処理してから確認応答を行う
デフォルトでは、Pub/Sub はメッセージが確認応答された後、サブスクリプションからメッセージを破棄します。確認応答を送信する前にメッセージを処理し、処理が失敗した場合、サービスはメッセージを再配信しません。ただし、確認応答済みメッセージの保持またはトピックの保持を構成し、シーク オペレーションを実行する場合は例外です。
レイテンシの高いサブスクライバーがいる場合は、フロー制御とリース管理にカスタム値を設定する必要がある場合があります。
一時的なトラフィックの急増に対するサブスクライバー フロー制御を構成する
サブスクライバー側のフロー制御を使用すると、トラフィックの急増によるサブスクライバーの過負荷を防ぐことができます。自動スケーリング メカニズムが負荷の増加に対応する時間を確保したり、負荷の処理をより長い期間に分散したりできます。前者の方法はレイテンシを短縮し、後者の方法はコストを削減します。
フロー制御を構成するには、maximum outstanding messages と total outstanding message bytes に適切な値を設定する必要があります。これらのフロー制御変数のデフォルト値と変数の名前は、クライアント ライブラリによって異なる場合があります。
最大未処理メッセージ数は、Pub/Sub が確認応答または否定応答を受信しなかったクライアントに配信されるメッセージの最大数を定義します。
未処理のメッセージの合計バイト数は、Pub/Sub が確認応答または否定応答を受信しなかったクライアントに配信されたメッセージの最大合計サイズを定義します。
これらのオプションのいずれかの上限を超えると、サブスクライバー クライアントは、それ以上メッセージをプルしません。この動作は、すでにプルされているメッセージに対して確認応答が行われるか、否定応答が行われるまで続きます。このようにして、スループットと、より多くのサブスクライバーを実行するための費用をトレードオフできます。
重複配信を処理する
デフォルトでは、Pub/Sub はサブスクライバーにメッセージの少なくとも 1 回の配信を提供します。つまり、確認応答されたメッセージでも複数回配信される可能性があります。以降のセクションでは、一般的な再配信シナリオに対処する方法について説明します。
多くのメッセージの一貫した再配信
多くのメッセージが常に再配信される場合は、サブスクライバーが過負荷になっているか、期限が切れる前にメッセージの確認応答を行っていない可能性があります。
プル サブスクリプションを使用している場合は、フロー制御の値にカスタム値を設定するか、リース管理を使用してリース延長期間を増やす必要がある場合があります。
push サブスクリプションを使用している場合は、確認応答期限の設定を増やす必要がある場合があります。正常なサブスクリプションを維持する方法に関するベスト プラクティスに沿って対応することもできます。
メッセージの再配信がときどき発生する
確認応答期限が切れる前にメッセージが再配信された場合や、メッセージが確認応答されてから数秒後に再配信された場合は、Pub/Sub は想定どおりに動作しています。再配信の急増は頻繁には発生しませんが、再配信が発生する場合は、複数のメッセージで同時に発生する可能性があります。システムは、このような重複がときどき発生しても許容できるように構築する必要があります。
少数のメッセージの再配信が繰り返される
少数のメッセージが複数回配信されている場合は、まずそれらのメッセージが確認されていることを確認します。そうでない場合は、サブスクライバーがメッセージを適切に処理していない理由を特定します。再配信を防止するために、デッドレター トピックを構成することをおすすめします。メッセージを確認している場合、Pub/Sub は想定どおりに動作している可能性があります。非常にまれですが、内部ネットワークやハードウェアの中断が発生した場合、少数のメッセージが複数回配信される可能性があります。このような場合、サービスは自己修復を試みますが、修復が有効になるまでに数分かかることがあります。
システムは再配信を許容する必要があります。メッセージをできるだけ早く処理して確認応答することで、この可能性を減らすことができます。
アプリケーションで重複を許容できない場合は、1 回限りの配信を有効にできます。この機能は pull サブスクリプションでのみ使用でき、パブリッシュからサブスクライブまでのレイテンシが長くなることに注意してください。この機能を有効にする前に、レイテンシの増加というトレードオフがユースケースで許容できるかどうかを評価してください。
登録時のメッセージの順序指定のベスト プラクティス
メッセージの順序指定を使用する場合は、以下の点を確認してください。
StreamingPull サブスクリプションまたは Pull サブスクリプションのいずれかを選択します。push サブスクリプションの場合、Pub/Sub は順序付けキーごとに一度に 1 つの未処理のメッセージをサポートします。このようなシナリオで並列 push リクエストを送信することは、同じ順序付けキーの複数のバッチのメッセージを送信してサブスクライバーを同時に pull するのと同様です。したがって、同じ順序付けキーで複数のメッセージが頻繁にパブリッシュされるトピックや、レイテンシが非常に重要なトピックでは、プッシュ サブスクリプションはおすすめしません。
サブスクリプションでメッセージの順序指定を有効にします。パブリッシャー側で、順序指定キーを使用して同じリージョンでメッセージを送信する場合は、それらのメッセージを順番に受信するようにサブスクライバーを構成できます。サブスクライバー側では、順序付けされたメッセージを受信するサブスクリプションに対してのみ、メッセージの順序付けプロパティを有効にします。プロパティのステータスに応じて、トピックに接続されている各サブスクリプションは、互いに影響を与えることなく、順序付き配信が必要かどうかを判断できます。
メッセージを順番に確認応答します。順序付けされた配信を使用する場合、順序指定キーごとに前のメッセージの確認応答が処理されるまで、後のメッセージの確認応答は処理されません。たとえば、同じ順序指定キーを持つメッセージ 1、2、3 があり、それらすべてを受信してメッセージ 3 のみを受信した場合、サービスではメッセージ 1 と 2 が確認応答されるまでメッセージ 3 が確認応答されたものとして認識されません。メッセージ 1 と 2 の確認応答が受信されない場合、メッセージ 1、2、3 はすべて再配信されます。
ベスト プラクティスの概要
次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。
| トピック | タスク |
|---|---|
| サブスクリプション タイプを選択する | ビジネスニーズに合ったサブスクリプション タイプを選択します。サブスクリプションでサポートされている場合は、高レベルのクライアント ライブラリも使用します。 |
| 確認応答済みメッセージを再生する | メッセージを処理してから確認応答します。または、確認応答済みのメッセージが失われないように、シーク オペレーション用に構成します。 |
| フロー制御 | 自動スケーリングが開始されるか、時間が経過するまでサブスクライバーが過負荷にならないように、サブスクライバーの設定でフロー制御を構成します。 |
| メッセージの順序指定 | 順序指定されたメッセージングを使用する場合は、StreamingPull または Pull を選択し、サブスクリプションでメッセージの順序指定を有効にして、メッセージを順番に確認応答します。 |