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