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