問題と制限事項

Cloud Tasks を使用すると、特定のキュー実行動作とサービス制限を設計するときに、復元力のある非同期システムを構築できます。少なくとも 1 回の配信、システム スロットリング、ターゲット リソース容量を考慮することで、処理のボトルネックや予期しない遅延を防ぐことができます。

実行順序

今後実行される予定のタスクを除き、タスクキューでは実行順序に関してプラットフォームには完全に依存しません。タスクが特定の順序で実行される保証はありません。たとえば、キューが完全に空にならない限り、古いタスクが実行される保証はありません。多くの場合、新しいタスクが古いタスクよりも先に実行されますが、このパターンは予告なしに変更される可能性があります。

実行の遅延

Cloud Tasks の実行では、内部システムの再起動により、通常は数分程度のわずかな遅延が発生することがあります。タスクは遅延しますが、タスクが失われることはありません。これらはシステムレベルのイベントであり、回避策はありません。これらのイベントはログに記録されず、発生のタイムラインも設定されていません。

重複実行

Cloud Tasks では「1 回だけの実行」が前提となります。 ただし、設計上、実行の保証か重複実行の回避のいずれかを選択しなければならない場合は、実行の保証を優先します。 重複実行を完全に避けることはできません。 アプリが重複した実行を適切に処理し、予期しないエラーが発生しないようにしてください。本番環境では、99.999% 以上のタスクが 1 回だけ実行されます。

リソースの制限

即時処理キューのバックログの最も一般的な原因は、ターゲット インスタンスのリソース不足です。1 秒あたり 10 件のリクエストしか処理できないフロントエンド インスタンスで 1 秒あたり 100 件のタスクを実行しようとすると、バックログが発生します。これは通常、2 つの方法のいずれかで現れます。どちらの方法でも、リクエストを処理するインスタンスの数を増やすことで解決できます。

バックオフ エラーと適用レート

サーバーが過負荷状態になると、バックオフ エラーを返すようになります。App Engine ターゲットの場合は HTTP 503、外部ターゲットの場合は HTTP 429 または 5xx です。このエラーに対し、Cloud Tasks はエラーがなくなるまで実行速度を下げることで対処します。このシステム スロットリングにより、ワーカーの過負荷が防止されます。設定は変更されません。

システム スロットリングは、次のような状況で発生します。

  • Cloud Tasks は、すべてのエラーに対してバックオフを行います。通常、Cloud Tasks は retry_config で指定されたバックオフを使用します。ただし、ワーカーが HTTP 429 Too Many Requests、503 Service Unavailable、5xx のエラー レスポンスを返す場合、またはエラー率が高い場合、Cloud Tasks は低いディスパッチ レートを適用し、Retry-After HTTP レスポンス ヘッダーで指定された再試行遅延を考慮します。エラーが停止し、ターゲット ハンドラが HTTP 2xx レスポンスを返すと、キューは強制ディスパッチ レートを徐々に上げていきます。

  • トラフィックの急増を防ぎ、負荷の急増を緩和するため、Cloud Tasks は、キューが新しく作成されたとき、一時停止後に再開されたとき、アクティブなディスパッチがない状態で数分間アイドル状態になったときに、ディスパッチを徐々に増やします。このランプアップは、タスク作成の急増時や、多くのタスクが同時にスケジュールされている場合など、多数のタスクが突然ディスパッチ可能になった場合にも発生します。コールド状態またはアイドル状態から、Cloud Tasks は低いベースライン レートでディスパッチを開始し、定期的な評価間隔で適用されるディスパッチ レートを段階的に引き上げます。キューの需要が飽和状態のままで、ターゲット ハンドラが HTTP 2xx レスポンスを返す限り、レートは構成された max_dispatches_per_second レートに向かって段階的に増加します。コールド ランプアップ、アイドル ランプアップ、再開されたキューの管理の詳細については、初期キューのランプアップとターゲットの過負荷をご覧ください。

レイテンシの急増と同時実行の最大数

サーバーが過負荷状態になると、レイテンシが長くなります。 この状況では、リクエストの処理時間が長くなります。キューでは同時に実行可能な最大数のタスクを処理するため、予期した速度でタスクが処理されなくなる可能性があります。キューの max_concurrent_dispatches に設定された値が低すぎるためにレート制限が適用されている場合は、該当するキューでこの設定値を大きくすると、状況が改善される場合があります。ただし、max_concurrent_dispatches の値を大きくしても、根底にあるリソース不足の問題は解決されません。

長時間実行タスクの増加に関する問題

Cloud Tasks キューは、以前にディスパッチされたタスクの成功数に基づいて出力を増やします。タスクハンドラがタスクを完了し、成功のレスポンスを返すまでにかなりの時間がかかる（数分程度）場合、キューの増加速度が遅れることがあります。

5,000 件を超えるタスクを表示する

タスクが 5,000 件を超える場合、一部のタスクはGoogle Cloud コンソールに表示されません。すべてのタスクを表示するには gcloud CLI を使用してください。

報告されたキューの深さの最大指標

Cloud Tasks によって報告される最大キュー深度指標の上限は 1,000,000 タスクです。これは、基盤となるタスクワーカーのパフォーマンスを向上させることを目的としており、キューに送信または処理できるタスクの数には影響しません。キューの深さの上限を超えてキューに送信されたタスクは、意図したとおりに実行を継続します。

1,000,000 タスクを超える現在のキューの深さを取得するには、queues.tasks.list メソッドを使用します。このメソッドは、ページネーション付きのすべてのタスクを返します。これにより、データを集計してカウント オペレーションを実行できます。ただし、キューの深さによっては、このメソッドで割り当て制限が発生する可能性があります。

同じ名前のキューを再作成する

キューを削除すると、スケジュールされたタスクや実行または再試行を待機しているタスクなど、キュー内のすべてのタスクが完全に削除され、元に戻すことはできません。削除したキューやタスクは、ユーザーも Cloud カスタマーケアも復元できません。

キューを削除した後に同じ名前で再び作成する場合は、その前に 3 日間待つ必要があります。この待機期間により、削除時に実行中のタスクの予期しない動作が防止され、削除と再作成のサイクル中の内部プロセス障害が回避されます。待機期間は、 Google Cloud コンソール、gcloud CLI、REST API、RPC API、Terraform などのインターフェースで削除されたキューに適用されます。

この最大 3 日間の廃棄期間中は、キューを再作成せずにキュー作成リクエストが成功したように見えることがあり、削除されたキュー名を含む queue.yaml ファイルのアップロードが失敗することがあります。同じ名前のキューが再作成されたことを確認するには、gcloud tasks queues describe コマンドまたは projects.locations.queues.get メソッドを使用してキューを取得します。成功（200 OK）レスポンスは、キューが再作成されたことを確認します。

キューを失うことなく、または 3 日間の待機期間をトリガーすることなく、タスクをクリアするか、キューを変更するには、キューを削除して再作成するのではなく、キューからすべてのタスクを削除するか、キューをインプレースで更新するか、キューを一時停止します。Terraform でキューを管理する場合は、lifecycle ブロックで prevent_destroy = true を設定して、キューが誤って削除されないようにします。

セキュアな境界を使用する場合にサポートされないターゲット

VPC Service Controls を使用して安全な境界を設定している場合、Cloud Tasks の実行からの HTTP リクエストは、サポートされていないターゲットに対してブロックされ、TARGET_TYPE_NOT_PERMITTED_FOR_VPC エラーコードで失敗します。詳細については、VPC Service Controls を使用してサービス境界を設定するをご覧ください。

リソース ロケーションの制約

Cloud Tasks はリソース ロケーションの制限をサポートしていますが、次のリージョンには制限が適用されます。

  • us-central1
  • us-central2（プライベート Google Cloud リージョン）

組織のポリシーでいずれかのリージョンを指定する場合は、両方のリージョンで Cloud Tasks リソースを作成しない場合でも、us-central1 と us-central2 の両方を含める必要があります。プライベート リージョンを使用していない組織でも、組織のポリシーにリージョン us-central2 を含めることができます。