このガイドでは、Pub/Sub の信頼性機能の概要と全体像について説明します。このドキュメントで扱うトピックは次のとおりです。
- Pub/Sub を選ぶ理由
- フェイルオーバー
- パブリッシャーの微調整
- サブスクライバーの微調整
- 安全なデプロイのためのスナップショットとシークの使用
Pub/Sub を選ぶ理由
メッセージングのパラダイムとして、publish-subscribe はメッセージのプロデューサーとそれらのメッセージのコンシューマーを分離するように設計されています。プロデューサーは、データを使ってコンシューマーに直接リクエストを送信する代わりに、そのデータを Pub/Sub などの Pub/Sub サービスに公開します。このサービスは、サブスクライブしている関心のあるコンシューマーにこれらのメッセージを非同期で配信します。
その結果、このサービスは、データに関心のあるコンシューマーを見つける煩雑さをすべて吸収します。容量に基づいてコンシューマーがデータを受信するレートも管理します。分離することにより、データ プロデューサーは、コンシューマーの行動とは無関係に、低レイテンシで大規模にメッセージを書き込むことができます。
Pub/Sub は、スケーラビリティと信頼性の高いメッセージ配信を提供します。サービスはこの処理のほとんどを自動的に処理しますが、可用性とパフォーマンスに影響する可能性のあるパブリッシャーとサブスクライバーのさまざまな側面を制御できます。このガイドの残りの部分では、これらの側面について詳しく説明します。
フェイルオーバー
Pub/Sub はグローバル サービスである: トピックとトピックとサブスクリプションは本質的に特定のリージョンに結び付けられおらず、必要に応じて、リージョン間の Pub/Sub サービス内でメッセージが流れます。グローバル エンドポイント pubsub.googleapis.com を使用すると、パブリッシャーとサブスクライバーは、Pub/Sub が実行されるネットワークに最も近いリージョンに接続します。us-central1-pubsub.googleapis.com などのロケーション エンドポイントを使用する場合、パブリッシャーとサブスクライバーは指定されたリージョンの Pub/Sub に接続します。Google Cloud の外部でパブリッシャーやサブスクライバーを実行する場合、想定されるリージョン間でメッセージが一貫して流れるように、ロケーション エンドポイントを使用するのがベストです。このセクションの残りの部分では、トピックとサブスクリプションの作成方法について説明します。また、さまざまな種類のフェイルオーバーとデータの冗長性をサポートするために、パブリッシャーとサブスクライバーを配置する方法についても説明します。
デフォルトのフェイルオーバー セマンティクス
トピックとサブスクリプションが 1 つある場合について考えてみましょう。パブリッシャーは米国とオーストラリアのリージョンに配置され、サブスクライバーはヨーロッパとオーストラリアの Google Cloud リージョンに配置されます。すべてのサブスクライバーがメッセージを受信するのに十分な容量がある場合、メッセージのフローは次のようになります。
P はパブリッシャーを表し、S はサブスクライバーを表します。青い六角形は Pub/Sub サービスを表します。シリンダーは、メッセージが保存される場所を表します（メッセージは常にパブリッシュされたリージョン内の複数のゾーンに保持されます）。Pub/Sub では、サブスクライバーが利用可能な場合に、パブリッシュされたのと同じリージョン内でメッセージを送信することをおすすめします。それ以外の場合、容量のあるサブスクライバーのある最も近いネットワーク リージョンにメッセージを送信します。そのため、前の図に示すように、米国で公開されたメッセージはヨーロッパのサブスクライバーに配信され、オーストラリア内で公開されたメッセージはオーストラリアに残ります。
以降のセクションでは、さまざまな障害シナリオでの動作について説明します。
ヨーロッパのサブスクライバーが使用できない
ヨーロッパのサブスクライバーが停止するか、頻繁にクラッシュし、Pub/Sub への接続を維持できないことを前提としています。この場合、サービスはオーストラリアのサブスクライバーへのメッセージの配信を開始します。
ヨーロッパとオーストラリアのサブスクライバーが使用できない
すべてのサブスクライバーが使用できない場合、Pub/Sub は構成済みのメッセージ保持期間までメッセージを保存します。
サブスクライバーが再接続されると、停止が構成済みのメッセージ保持期間を超えない限り、メッセージは配信されます。サブスクリプション メッセージの保持はデフォルトで 7 日間に設定されています。最長 31 日間のトピックのメッセージ保持を構成することもできます。メッセージの保持期間は、予想される最大停止期間よりも短く、または許容できる期間よりも短く選択しないでください。
Pub/Sub がヨーロッパで使用できない
まれですが、Pub/Sub 自体が使用できない場合にも対処する場合があります。Pub/Sub が使用不能になると、パブリッシュまたはサブスクライブ リクエスト時の予期しないエラーや、サブスクライバーにパブリッシュされたメッセージを配信できない状態が長期間続くことを表します。たとえば、Pub/Sub がヨーロッパのリージョンでダウンした場合、シナリオはサブスクライバーがダウンした場合とほぼ同じになります。
この場合、グローバル エンドポイントを使用していても、ヨーロッパのサブスクライバーは別のリージョンにフェイルオーバーしません。 Pub/Sub は意図的に自動的にフェイルオーバーしません。サブスクライバー自身が Pub/Sub で予期しない問題を発生させ、使用不能になったとします。このような問題は、大規模な停止として処理されます。ただし、サービス停止の影響の範囲は、サブスクライバーが接続したリージョンに限定される場合があります。サービスが別のリージョンにフェイルオーバーすることを許可している場合、サブスクライバーもそこで使用不能になり、サービス全体でカスケード障害が発生する可能性があります。
オーストラリアのパブリッシャーが使用できない
あるリージョンのパブリッシャーが使用不能になっても、すでにパブリッシュされているメッセージは最も近いサブスクライバーに配信されます。
最終的に、すべてのメッセージがサブスクライバーによって消費され、確認応答されます。Pub/Sub は、メッセージを送信する際に、ネットワーク距離を最小限に抑えようとします。 したがって、ヨーロッパのサブスクライバーが米国でパブリッシュされたすべてのメッセージを処理するのに十分な容量がある場合、オーストラリアのサブスクライバーがメッセージの受信を停止できます。
Pub/Sub が米国で使用できない
Pub/Sub は、リージョン内の複数のゾーンに同期的にメッセージを書き込みます。したがって、メッセージの配信を防ぐには、ゾーンの停止では不十分です。リージョン全体を使用不可にする必要があります。パブリッシャーがメッセージを送信しているリージョンで Cloud Pub/Sub が使用できなくなると、サービスが完全に復元されるまでそのリージョンのメッセージは配信されない可能性があります。
メッセージは、停止期間中遅延しますが、最終的に配信されます（メッセージの保持期間が経過していないと想定）。 サブスクライバーと同様に、米国のパブリッシャーもサービス障害中に別のリージョンにフェイルオーバーしません。この動作により、パブリッシャーやサブスクライバーのエラーが原因でリージョン間でカスケード障害が発生する可能性を回避できます。
分離
デフォルトのフェイルオーバー セマンティクスは、データの分離と、パブリッシャー、サブスクライバー、Pub/Sub 自体が使用できないことによりメッセージ フローに影響します。ユースケースによっては、異なるレベルの分離が必要になることがあります。たとえば、すべてのメッセージのリージョン内配信が必要になることがあります。
分離が不要な場合は、デフォルトのフェイルオーバー セマンティクスで十分です。1 つのトピック、1 つのサブスクリプションを作成し、指定したすべてのリージョンにパブリッシャーとサブスクライバーを配置する必要があります。サブスクライバー使用できなくなるか、Pub/Sub が接続先のリージョンでダウンすると、別のリージョンのサブスクライバーに配信がフェイルオーバーされます。
データがリージョンから離れることがないことが保証されるリージョン分離の場合、各リージョンのメッセージを処理するトピックとサブスクリプションを作成します。各リージョンのパブリッシャーとサブスクライバーを見つけて、対応するリージョンのトピックとサブスクリプションをそれぞれパブリッシュしてサブスクライブします。また、データがリージョン内でのみ移動するように、リージョン エンドポイントを使用する必要があります。単一のリージョンでパブリッシャー、サブスクライバー、Pub/Sub に障害が発生した場合、そのリージョンでのメッセージ配信が停止します。他のリージョンのトピックとサブスクリプションに関するメッセージ配信は影響を受けません。
最後に、データが 1 つのゾーン内に留まることが保証されているゾーン分離は、Pub/Sub ではできません。個々のゾーンを独立させる必要がある場合は、Pub/Sub Lite を使用します。
お客様管理のフェイルオーバーと冗長性
Pub/Sub のデフォルトのフェイルオーバー セマンティクスでは、いずれかの時点でサービスが停止した場合、パブリッシャーからサブスクライバーにメッセージが流れるとは限りません。サービス停止は、クライアントや、パブリッシャーまたはサブスクライバーが稼働するサービス、ネットワーク、さらには Pub/Sub 自体においても、さまざまな場所で発生する可能性があります。 このような停止に対するサービスの復元性が必要な場合は、独自の冗長性を実装する必要があります。通常、これらの冗長性には、パブリッシャーとサブスクライバーのクライアントの複数のインスタンスを使用することがあり、それぞれが異なるロケーション エンドポイントを使用します。
ゾーンまたはリージョンという 2 つの異なる影響範囲に対して復元力を設定できます。 各設定オプションは以下のとおりです。
ゾーンの復元性
Pub/Sub には、ゾーン間のレプリケーションが組み込まれています。サービス自体に影響を与えるシングルゾーンの停止に対処するために、特別な手順を行う必要はありません。ただし、クライアントまたはネットワークの停止に対する復元力を高めるには、リージョン内の複数のゾーンに十分な容量のパブリッシャーとサブスクライバーを実行することをおすすめします。1 つのゾーンがダウンした場合、他のゾーンのクライアントがトラフィックを選択してメッセージを処理できます。バグが発生しても、手つかずの他のゾーンがメッセージの処理を継続できるように、これらのクライアントに対する変更を同時に公開しないことをおすすめします。
リージョンの復元性
リージョンの障害に対する復元力を確保するため、パブリッシャーとサブスクライバーに追加の冗長性を設定します。パブリッシャーとサブスクライバーを複数のリージョンで実行して、これらのクライアントやネットワークで停止の可能性に対処できます。
リージョン内の潜在的な Pub/Sub の障害に対する復元力を高めるには、そのような停止に対処するためのフェイルオーバー メカニズムが必要です。可能なアプローチは、エンドツーエンドのメッセージ配信のレイテンシとコストのトレードオフです。
コストが問題にならない場合のレイテンシを最小限に抑えるには、常に複数のリージョンで同時にパブリッシュとサブスクライブを行うことをおすすめします。まず、冗長性が必要なリージョンの数を選択します。 次に、厳密には必須ではありませんが、各リージョンのトピックとサブスクリプションを設定できます。
各パブリッシャーは、リージョンと同じ数のパブリッシャー クライアントを作成し（リージョンごとに 1 つずつ）、異なるロケーション エンドポイントを使用して、メッセージが別々のリージョンに送られるようにします。別々のトピックを使用する場合、各パブリッシャー クライアントは対応するリージョンごとのトピックにパブリッシュする必要があります。メッセージごとに、パブリッシャーは各クライアントにパブリッシュします。冗長なパブリッシュでは、いずれかのパブリッシュが失敗した場合、パブリッシュを再試行する必要はありません。
同様に、各サブスクライバーは、多数のサブスクライバー クライアント（リージョンごとに 1 つ）を作成し、ロケーション エンドポイントを使用して異なるリージョンに接続します。リージョンごとに異なるサブスクリプションを使用する場合、各サブスクライバー クライアントは対応するサブスクリプションを使用する必要があります。パブリッシャーとサブスクライバーに使用されるリージョンは、必ずしも同じである必要はありません。サブスクライバーは 3 つのサブスクリプションでメッセージを受信し、処理します。
この設定には、いくつかの主な機能と要件があります。
- シングルリージョンの停止は、すでにパブリッシュされたメッセージの処理や、停止中にパブリッシュされたメッセージの処理に影響しません。メッセージは複数のリージョンにパブリッシュされているため、1 つのリージョンがダウンしても他のリージョンで使用できます。停止中、影響を受けるリージョンではパブリッシュ呼び出しは失敗しますが、他のリージョンでは成功します。
- メッセージを処理するリージョンが使用可能な限り、メッセージ処理のレイテンシに影響はありません。
- メッセージ処理はべき等である必要があります。すべてのメッセージは複数回配信されるため、メッセージ処理は重複に対する復元性を備えている必要があります。リージョンが停止した場合、メッセージの最初の配信よりもかなり後に、これらの重複の一部が発生する可能性があります。これらに重複は、停止が発生していない別のリージョンで発生している可能性があります。
このような種類の冗長性を実行することにより、いかなる種類の停止に対しても高い復元力を実現できます。Pub/Sub を使用し、最高の可用性を必要とする内部 Google サービスの場合、この設定をおすすめします。ただし、この設定では、メッセージ配信の費用が使用するリージョン数の倍数となるというトレードオフがあります。また、リージョン間を移動する必要があるメッセージには、リージョン間のネットワーク使用量に対する追加コストがかかります。
冗長性のもう 1 つのアプローチは、リクエストが失敗した場合や、パブリッシャーからサブスクライバーにメッセージが想定どおりに流れない場合にのみフェイルオーバーすることです。このシナリオでは、ロケーション エンドポイントを通じてパブリッシャーとサブスクライバーを誘導するプライマリ リージョンがあります。前述したように、これらは同じリージョンである必要はありません。また、プライマリ リージョンが使用不可になった場合に使用されるフォールバック リージョンをパブリッシャーとサブスクライバーに備えます。
パブリッシャーは、リクエストが正常に送信された場合（ロケーション エンドポイントを介して）プライマリ リージョンにのみパブリッシュします。リージョンがダウンしていると判断された場合、パブリッシャーは代わりにフォールバック リージョンへのパブリッシュを開始します。リージョンがダウンしてフェイルオーバーすることは、次の 2 つの方法で判断できます。これは、手動プロセスで行うことができます。構成はパブリッシャーで動的に更新されます。パブリッシャーは、パブリッシュ リクエストのエラー率が十分に高い場合は、構成を自ら更新することもできます。
サブスクライバーは常に、ロケーション エンドポイントを介してプライマリ リージョンに接続する必要があります。サブスクライバーは、次のトリガーの 1 つ以上を使用してフォールバック リージョンを使用できます。
- 常にフォールバック リージョンにサブスクライブする。この場合、サブスクライバーはプライマリ リージョンとフォールバック リージョンの両方への接続を常に維持します。パブリッシャーとサブスクライバーの両方で、同じリージョンをプライマリとフォールバックに使用できます。この場合、パブリッシャーがフェイルオーバーした場合にのみ、サブスクライバーがバックアップ リージョンを介してメッセージを受信する必要があります。
- 構成を使用して、サブスクライバーをフォールバック リージョンに手動で検出して切り替えます。サービス停止が検出されると、フォールバック リージョンにフェイルオーバーし、停止状態が解除されたときにプライマリ リージョンに戻すことができます。
- サブスクライバー エラーでフェイルオーバーする。サブスクライバー リクエストでエラーが返された場合、これをフォールバック リージョンにフェイルオーバーする必要があることを示すものとして使用できます。Pub/Sub クライアント ライブラリは、一時的なエラーでストリーミング pull リクエストを内部的に再試行するため、予期しないエラーが長期間検出されない場合があります。また、通常のオペレーションであっても、ストリーミング pull エラー率は 100% と予想されます。
- サブスクライバーがメッセージを受信せずに、予期せず長時間経過した場合にフェイルオーバーする。メッセージの公開が一貫していれば、サブスクライバーは常にメッセージを受信できます。サブスクライブがメッセージを長期に渡ってしない場合、プライマリ リージョンの Pub/Sub にサブスクライブ側の問題がある可能性があります。これは、フォールバック リージョンにフェイルオーバーすることで解決されます。
4 つのオプションすべての中で、最初のオプションが最適です。サブスクライバーの接続にメッセージが流れない場合、サブスクライバーの接続に料金は発生しません。唯一の費用は、サブスクライバー クライアント ライブラリの追加インスタンスのフットプリントですが、これはごくわずかである場合があります。また、リージョン割り当てごとのオープン ストリーミング pull 接続数にも注意する必要があります。
この 2 番目のモデルの利点は、メッセージが 1 回だけパブリッシュされるため、Pub/Sub のコストに乗数が発生しないことです。ただしトレードオフとして、特定の種類の停止では、停止が解決されるまで、パブリッシュされたメッセージが使用できない場合があります。使用できないリージョンに保存されているメッセージは、接続場所に関係なく、サブスクライバーに配信できない場合があります。停止時にフォールバック リージョンにパブリッシュされたメッセージが使用可能になります。また、パブリッシャーやサブスクライバーのエラー率が上昇し、使用不能になる期間もあります。これは、停止を検出する方法と、フォールバック リージョンにフェイルオーバーする時間によって異なります。
いずれのオプションを選択する場合でも、Pub/Sub の機能とやりとりする方法を考慮してください。順序指定配信と 1 回限りの配信は、どちらもリージョン内で保証します。たとえば、フェイルオーバーの冗長性技術を使用する場合、メッセージ配信は、同じリージョンにパブリッシュされるメッセージに対してのみ保証されます。メッセージが最初にプライマリー リージョンにパブリッシュされていた場合でも、プライマリ リージョンにメッセージがパブリッシュされる前に、サブスクライバーは、フォールバック リージョンにパブリッシュされたメッセージを受信できます。
パブリッシャーの微調整
どのフェイルオーバー オプションを選択しても、パブリッシャー自身でいくつかの調整手順を行う必要があります。パブリッシャーの動作を調整することで、高負荷で最適なパフォーマンスを実現できます。メッセージのバッチ処理は、コストとレイテンシをトレードオフする方法ですが、信頼性にはそれほど重要でないため、ここでは説明しません。代わりに、再試行の設定やフロー制御設定など、信頼性の調整に役立つ他のパラメータをいくつか説明します。
パブリッシュは、ネットワーク使用不能などの一時的なものや、権限の変更などユーザーの操作が必要なものなど、さまざまな理由で失敗する可能性があります。Pub/Sub クライアント ライブラリは、再試行の設定で指定されたパラメータを使用して一時的なエラーを再試行します。これらの設定により、一時的な理由で失敗したパブリッシュ RPC の再試行時の指数バックオフの動作が制御されます。通常、デフォルト設定はほとんどのシナリオで問題なく機能しますが、これらの値を調整したい場合もあります。
調整する可能性が高い 2 つのプロパティは、初期 RPC タイムアウトと合計タイムアウトです。初期 RPC タイムアウトは、最初のパブリッシュ RPC が完了するまでの時間です。RPC が失敗した場合や RPC がタイムアウトした場合、リクエストの合計数または合計タイムアウトを超えるまで、より長いタイムアウトで再試行されます。
パブリッシャーがネットワークの制約を受ける場合や、Pub/Sub を実行する最も近い Google Cloud データセンターから離れている場合、初期タイムアウトを調整できます。ネットワークの制約は、パブリッシャーが実行されているマシンのスループットが制限される場合や、ネットワーク集約型の同じマシン上で実行されている他のサービスの結果である可能性があります。タイムアウトの設定が短すぎると、最初の RPC が繰り返し失敗し、パブリッシュに成功するまでの試行が多くなります（タイムアウトが長くなります）。再試行の繰り返しが必要であるため、パブリッシュのレイテンシが増加します。このような状況では、初期タイムアウトを長くするとパブリッシュが速くなる可能性があります。
ネットワーク接続の信頼性が低い場合は、合計タイムアウトと初期タイムアウトを増やすと解決できることがあります。合計タイムアウトを長くすると、パブリッシュ RPC が常に完了するための時間が長くなります。パブリッシュ RPC が、期限超過エラーで一貫して失敗する場合は、これらの値の調整を検討してください。
連続した期限超過エラーは、パブリッシャーのフロー制御を調整する必要があることを示している場合もあります。これらの設定により、Pub/Sub に送信するメッセージを増やす受信トラフィックの急増に対してパブリッシャーの復元力を高めることができます。送信リクエストが大幅に増加すると、パブリッシャーの CPU、メモリ、ネットワーク容量が過負荷状態になる可能性があります。パブリッシュが過負荷になると、タイムアウト前にパブリッシュのリクエストやレスポンスを処理できなくなります。これにより、パブリッシュ リクエストが増え、最終的には合計タイムアウトに達します。パブリッシャー フロー制御では、パブリッシュ リクエストからのレスポンスのない未処理のメッセージまたはバイト数が制限されます。この方法でリクエストの数を制限すると、リクエストの急増時でも管理しやすいレベルのリソース使用率が維持されます。 パブリッシャーの動作に応じて、パブリッシュが後続のリクエストをブロックできるようにすることで、後続のパブリッシュ RPC が容量を待機できるようになります。また、容量に達したときにフロー制御でエラーを返すことで、サービスの呼び出し元に push することもできます。パブリッシャー クライアント ライブラリが制限超過動作で応答する方法を構成します。
サブスクライバーの微調整
確実に動作させるには、サブスクライバーの調整が必要になることもあります。パブリッシャーと同様に、サブスクライバーのフロー制御設定を調整して、過負荷状態にならないようにできます。サブスクライバー クライアント ライブラリはストリーミング pull を使用し、クライアントがサーバーへの永続ストリームを開き、使用可能になったときにサーバーがメッセージを送信します。パブリッシュされたメッセージが大幅に増加すると、サブスクライバーは処理できる数より多くのメッセージを受信する可能性があります。フロー制御を設定すると、クライアントに同時に確認応答されていない未確認メッセージの数が制限されます。これにより、同時に処理されるメッセージの数が減少し、長期間にわたって処理を分散させます。負荷の分散により、サブスクライバーをメッセージ処理に影響を与えるリソースの制限内にとどまらせることができます。これによりメッセージを処理できなくなるカスケード効果が発生する可能性があります。
処理するデータ量の急増が最終的には減少することが想定される場合は、フロー制御だけで十分です。使用率の増加によってトラフィックが時間とともに増加する場合、フロー制御によってサブスクライバーを保護します。ただし、バックログが蓄積し続け、メッセージの保持期間が経過する前にメッセージを配信できなくなる可能性があります。このような場合は、確認応答されていないメッセージの数が増えても、それに応じてサブスクライバーを増やすように自動スケーリングを設定することもできます。この設定方法は、サブスクライバーに使用しているコンピューティング プラットフォームによって異なります。たとえば、Compute Engine のオートスケーラーでは、未配信メッセージの数などの指標に基づいてスケーリングできます。自動スケーリングとフロー制御の両方を使用すると、メッセージ スループットでの他の短期的な急増や多くのコンピューティング能力を必要とする長期的な増加に対しても、サブスクライバーの復元力を確保できます。
安全なデプロイのためにスナップショットとシークを使用する
通常、メッセージ損失は致命的な事態です。Pub/Sub では、パブリッシュされたすべてのメッセージについて、少なくとも 1 回の配信が行われます。ただし、これらのメッセージの正しい処理は、サブスクライバーの動作によって異なります。メッセージの確認応答が正常に完了すると、Pub/Sub はメッセージを再配信しません。したがって、デプロイする新しいサブスクライバー コードでバグが発生し、メッセージが正しく処理されなかった場合、サブスクライバーによってメッセージが失われる可能性があります。 Pub/Sub にはスナップショットとシーク機能があり、サブスクライバーのバグに直面しても、すべてのメッセージを正しく処理できます。
サブスクライバーのすべてのデプロイ パターンは、次のようになります。
新しいサブスクライバーが動作するかどうかを判断するまでの時間は、ユースケースによって異なります。ステップのフローを終了する唯一の方法は、サブスクライバーが動作しているとみなされるときに、スナップショットを削除できることです。
スナップショットとシークの使用は、非本番環境で最初に実行するソフトウェアと、本番環境への段階的なデプロイに関するベスト プラクティスに代わるものではありません。これらは、データ処理の信頼性を確保するための、保護強化策を提供するものです。トレードオフは、スナップショットまでシークすると、サブスクライバーが処理したメッセージが重複して配信される可能性があることです。ただし、Pub/Sub には少なくとも 1 回配信のセマンティクスがあるため、サブスクライバーはすでにメッセージの再配信に対して復元性を備えています。