このページでは、Cloud Tasks の使用中に発生する可能性のある問題と制限について説明します。
実行順序
今後実行される予定のタスクを除き、タスクキューでは実行順序に関してプラットフォームには完全に依存しません。タスクが特定の順序で実行される保証はありません。たとえば、キューが完全に空にならない限り、古いタスクが実行される保証はありません。多くの場合、新しいタスクが古いタスクよりも先に実行されますが、このパターンは予告なしに変更される可能性があります。
重複実行
Cloud Tasks では「1 回だけの実行」が前提となります。 ただし、設計上、実行の保証か重複実行の回避のいずれかを選択しなければならない場合は、実行の保証を優先します。 重複実行を完全に避けることはできません。 デベロッパーは、重複実行で致命的な事態が生じないように対策を講じる必要があります。本番環境では、99.999% 以上のタスクが 1 回だけ実行されます。
リソースの制限
即時処理キューのバックログの最も一般的な原因は、ターゲット インスタンスのリソース不足です。毎秒 10 個のリクエストしか処理できないフロントエンド インスタンスで毎秒 100 個のタスクを処理しようとすると、バックログが発生します。この状態は主に 2 つの方法で確認できます。いずれの場合も、リクエストを処理するインスタンス数を増やすことで解決できます。
バックオフ エラーと適用レート
サーバーが過負荷状態になると、バックオフ エラー（App Engine ターゲットの場合は HTTP 503、外部ターゲットの場合は HTTP 429 または 5xx）を返すようになります。Cloud Tasks は、エラーがなくなるまで実行速度を下げることで、これらのエラーに対応します。このシステム スロットリングにより、ワーカーの過負荷を防ぐことができます。ユーザー指定の設定は変更されません。
システム スロットリングは、次のような状況で発生します。
Cloud Tasks は、すべてのエラーでバックオフします。通常は、
rate limitsで指定されたバックオフが使用されます。ただし、ワーカーが HTTP429 Too Many Requestsまたは503 Service Unavailableを返す場合や、エラー率が高い場合は、Cloud Tasks はより高いバックオフ率を使用します。Retry-AfterHTTP レスポンス ヘッダーで指定された再試行が考慮されます。トラフィックの急増を防ぎ、トラフィックの急増を緩和するために、キューが新しく作成されたときやアイドル状態のとき、および多数のタスクが突然ディスパッチ可能になった場合（タスク作成レートの急増、キューの一時停止の解除、多くのタスクが同時にスケジュールされたことによる）、ディスパッチが徐々に増加します。
レイテンシの急増と同時実行の最大数
サーバーが過負荷状態になると、レイテンシが長くなります。
この状況では、リクエストの処理時間が長くなります。キューでは同時に実行可能な最大数のタスクを処理するため、予期した速度でタスクが処理されなくなる可能性があります。キューの max_concurrent_dispatches に設定された値が低すぎるためにレート制限が適用されている場合は、該当するキューでこの設定値を大きくすると、状況が改善される場合があります。ただし、max_concurrent_dispatches の値を大きくしても、根底にあるリソース不足の問題は解決されません。
長時間実行タスクの増加に関する問題
Cloud Tasks キューは、以前にディスパッチされたタスクの数に基づいて出力を段階的に増やします。タスクハンドラがタスクを完了し、成功のレスポンスを返すまでにかなりの時間がかかる（数分程度）場合、キューの増加速度が遅れることがあります。
5,000 件を超えるタスクを表示している
タスクが 5,000 件を超える場合、一部のタスクはGoogle Cloud コンソールに表示されません。すべてのタスクを表示するには gcloud CLI を使用してください。
同じ名前のキューを再作成する
Google Cloud コンソールでキューを削除した場合、同じ名前のキューをもう一度作成するには 3 日間経過している必要があります。この待機期間により、削除時に実行中または実行待ちのタスクで予期しない動作が発生するのを防ぐことができます。また、削除または再作成サイクルの内部プロセス障害も回避できます。