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