Pub/Sub 指標をパイプラインの自動スケーリングのシグナルとして使用する場合は、次の推奨事項をご覧ください。
複数のシグナルを使用してパイプラインを自動スケーリングする
Pub/Sub 指標のみを使用してパイプラインの自動スケーリングを行わないでください。これにより、自動スケーリングの決定に単一障害点が生じる可能性があります。代わりに、シグナルの組み合わせを使用して自動スケーリングをトリガーします。追加のシグナルの例としては、クライアントの CPU 使用率などがあります。このシグナルは、クライアント タスクが作業を処理しているかどうか、スケールアップによってクライアント タスクがより多くの作業を処理できるかどうかを示します。パイプラインで使用できる他の Cloud プロダクトからのシグナルの例を次に示します。
Compute Engine は、CPU 使用率や Monitoring 指標などのシグナルに基づく自動スケーリングをサポートしています。Compute Engine は、信頼性を高めるために複数の指標と複数のシグナルもサポートしています。
Monitoring 指標によるスケーリングの詳細については、Monitoring 指標に基づくスケーリングをご覧ください。CPU 使用率に基づくスケーリングの詳細については、CPU 使用率に基づくスケーリングをご覧ください。
Google Kubernetes Engine 水平 Pod 自動スケーリング（HPA）は、CPU とメモリの使用量などのリソース使用量、カスタムの Kubernetes 指標、Pub/Sub の Monitoring 指標などの外部指標に基づく自動スケーリングをサポートします。また、複数のシグナルもサポートしています。
詳細については、水平 Pod 自動スケーリングをご覧ください。
グローバル バージョンではなく、指標のリージョン バージョンを使用する
Pub/Sub では、通常自動スケーリングで使用される各指標の 2 つのバージョンが提供されます。by_region 接尾辞が付いたバージョンを使用してください。
自動スケーリングを単一リージョンの停止に対して復元力のあるものにする場合は、これらの指標のグローバル バージョンを使用しないでください。これらの指標のグローバル バージョンでは、メッセージが存在することがわかっているすべてのリージョンでバックログを計算する必要があります。つまり、単一リージョンで利用できない場合、データギャップが発生します。一方、by_region バージョンの指標は、リージョンごとにバックログを計算して報告します。単一のリージョンでバックログを計算できない場合でも、指標は他のリージョンの値を報告します。
加入者の自動スケーリングに加入者側のスループット指標を使用しない
subscription/ack_message_count などのサブスクライバー側のスループット指標を使用してサブスクライバー クライアントを自動スケーリングしないでください。代わりに、前述の subscription/num_unacked_messages や subscription/oldest_unacked_message_age など、処理待ちのメッセージのバックログを直接反映する指標の使用を検討してください。
自動スケーリングにサブスクライバー側のスループット指標を使用する場合の問題
これらの指標は Pub/Sub とサブスクライバー間のトラフィック量を表すため、使用すると問題が発生する可能性があります。このような指標に基づいてスケーリングすると、配信済みまたは確認済みのメッセージの減少がクライアントのスケールダウンにつながる自己参照ループが発生する可能性があります。たとえば、トラフィックが一時的に減少した場合や、チャンネル登録者のいずれかに問題がある場合に発生することがあります。
クライアントがゼロまたはゼロに近い値にスケールダウンすると、進行中のサブスクライブ トラフィックがすべて停止し、新しいメッセージが届いてもサブスクライバーがメッセージを処理できなくなる可能性があります。これにより、取り込みの遅延が大幅に発生し、サブスクライバー クライアントが回復不能な状態になる可能性があります。
指標のギャップが発生した場合の対処
指標が存在しないからといって、処理するメッセージがないとは考えないでください。たとえば、指標の欠落に対応して処理タスクをゼロにスケールダウンすると、バックログにすでに存在するメッセージや、この間に公開されたメッセージが消費されない可能性があります。これにより、エンドツーエンドのレイテンシが増加します。レイテンシを最小限に抑えるには、最小タスク数をゼロより大きい値に設定して、最新の Pub/Sub 指標が空のキューを示している場合でも、パブリッシュされたメッセージを処理できるように常に準備します。
Compute Engine オートスケーラーと Google Kubernetes Engine HPA はどちらも、指標が利用できない場合に現在のレプリカ数を維持するように設計されています。これにより、指標が利用できない場合にセーフティ ネットが提供されます。
また、Pub/Sub フロー制御メカニズムを実装して、指標の欠落が原因でタスクが意図せずにスケールダウンされた場合に、タスクが過負荷になるのを防ぐこともできます。