Cloud Tasks キューを構成する

Cloud Tasks キューの構成は、キューの作成時だけでなく、キューの作成後にも行うことができます。この構成は、そのキュー内のすべてのタスクに適用されます。

キューの構成には、次の基本的な 3 つの設定項目があります。

キューレベルのルーティングを構成する

キューレベルでルーティングを構成すると、タスクレベルで設定されたルーティングがオーバーライドされます。これは、Cloud Tasks をターゲット サービスの前のバッファとして使用する場合や、キュー内のすべてのタスクのルーティングを変更する必要がある場合に便利です。

キューレベルのルーティングは、次のものに適用されます。

  • キュー内のタスク
  • キューレベルのルーティングが設定された後にキューに追加されたタスク

制限事項

キューレベルのルーティングは、Cloud Key Management Service(Cloud KMS)の顧客管理の暗号鍵(CMEK)と互換性がありません。CMEK が有効になっている場合、次の操作はできません。

  • キューレベルのルーティングがあるキューにタスクを作成する
  • キューレベルのルーティングを適用する

HTTP タスクのキューレベル ルーティングを構成する

キューレベルのルーティングは、キューの作成時または更新時に、タスクレベルのルーティングをオーバーライドするように構成できます。キューレベルのルーティングを構成するには、キューの uriOverride パラメータを優先するルートに設定します。

既存のキューに更新としてキューレベルのルーティングを適用する場合、変更を適用する前にキューを一時停止し、変更を適用してから 1 分間待ってキューを再開します。

  1. 次のコマンドを実行して、キューを一時停止します。

      gcloud tasks queues pause QUEUE_ID
      

    QUEUE_ID は、プロジェクトの ID に置き換えます。

  2. キューレベルのルーティングを更新または削除します。

    • キューレベルのルーティングを更新するには、uriOverride パラメータを更新されたルートに設定します。

    • REST API または RPC API を使用してキューレベルのルーティングを削除するには:

      • REST API: 空のペイロードを含むキューの patch リクエストと httpTarget に設定された updateMask パラメータ。

      • RPC API: 空のペイロードを含むキューの updateQueueRequest リクエストと http_target に設定された update_mask パラメータ。

    次の例では、REST API を使用して、タスクの転送先となるホストを更新します。

    curl -X PATCH -d @- -i \
      -H "Authorization: Bearer ACCESS_TOKEN" \
      -H "Content-Type: application/json" \
      "https://cloudtasks.googleapis.com/v2/projects/PROJECT_ID/locations/LOCATION/queues/QUEUE_ID?updateMask=httpTarget.uriOverride" << EOF
    {
      "httpTarget": {"uriOverride":{"host":"NEW_HOST"}}
    }
    EOF
    

    次のように置き換えます。

    • ACCESS_TOKEN:自分のアクセス トークン。これは、ターミナルで次のコマンドを実行することで取得できます。

      gcloud auth application-default login
      gcloud auth application-default print-access-token
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。これは、ターミナルで次のコマンドを実行することで取得できます。

      gcloud config get-value project

    • LOCATION: キューの場所

    • NEW_HOST: キューをルーティングする新しいホスト。

  3. 1 分ほど待ちます。

    新しい設定が有効になるまで 1 分ほどかかることがあります。キューの再開を待機すると、古い構成でタスクがディスパッチされるのを防ぐことができます。

  4. 次のコマンドを実行して、キューを再開します。

    gcloud tasks queues resume QUEUE_ID

App Engine タスクのキューレベルのルーティングを構成する

App Engine タスクのキューレベルのルーティングを構成するには、キューの appEngineRoutingOverride パラメータを、優先する App Engine サービスとバージョンに設定します。

  1. キューレベルのルーティングを設定し、タスクレベルのルーティングをオーバーライドします。

    gcloud tasks queues update QUEUE_ID \
        --routing-override=service:SERVICE,version:VERSION

    次のように置き換えます。

    • QUEUE_ID: キュー ID(略称)。
    • SERVICE: タスク処理を担当する App Engine ワーカー サービス。
    • VERSION: アプリのバージョン。

    たとえば、キュー内のすべてのタスクを処理するようにワーカー サービスを設定すると、そのサービスとデフォルト バージョンにルーティングできます。

    gcloud tasks queues update QUEUE_ID \
        --routing-override=service:SERVICE
  2. 次のコマンドを実行して、キューが正常に構成されたことを確認します。

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    LOCATION は、キューのロケーションに置き換えます。

    出力例を以下に示します。

    appEngineRoutingOverride:
      host: SERVICE.PROJECT_ID.appspot.com
      service: SERVICE
    name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
    rateLimits:
      maxBurstSize: 100
      maxConcurrentDispatches: 1000
      maxDispatchesPerSecond: 500.0
    retryConfig:
      maxAttempts: 100
      maxBackoff: 3600s
      maxDoublings: 16
      minBackoff: 0.100s
    state: RUNNING
  3. キューレベルのルーティングを削除するには、次のコマンドを実行します。

    gcloud tasks queues update QUEUE_ID \
        --clear-routing-override

    キューレベルのルーティングが削除されると、タスクレベルのルーティングがキュー内のタスクと、今後キューに追加されるタスクに適用されます。

レート制限の定義

レート上限は、ディスパッチが最初のタスク試行か再試行かに関係なく、キューでタスクをディスパッチできる最大レートを決定します。

  1. 次のコマンドを実行して、キューによってディスパッチされる同時タスクの最大レートと最大数を設定します。

    gcloud tasks queues update QUEUE_ID \
        --max-dispatches-per-second=DISPATCH_RATE \
        --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES

    次のように置き換えます。

    • QUEUE_ID: キュー ID(略称)。
    • DISPATCH_RATE: ディスパッチ率。これは、バケット内のトークンが更新される割合です。タスクが比較的安定している状況では、これはタスクがディスパッチされる割合に相当します。
    • MAX_CONCURRENT_DISPATCHES: キュー内で一度に実行できるタスクの最大数。

    たとえば、パラメータを設定せずにキューを作成した場合は、次のコマンドを実行して同時タスクの最大数を更新できます。

    gcloud tasks queues update QUEUE_ID \
        --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES
  2. 次のコマンドを実行して、キューが正常に構成されたことを確認します。

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    LOCATION は、キューのロケーションに置き換えます。

    出力例を以下に示します。

    name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
    rateLimits:
      maxBurstSize: 100
      maxConcurrentDispatches: MAX_CONCURRENT_DISPATCHES
      maxDispatchesPerSecond: 500.0
    retryConfig:
      maxAttempts: 100
      maxBackoff: 3600s
      maxDoublings: 16
      minBackoff: 0.100s
    state: RUNNING

キューの処理速度を定義する方法

キュー処理速度は、Cloud Tasks API を使用するか、queue.yaml ファイルをアップロードして定義できます。どちらの方法でも、同じ基盤メカニズムを使用するキューが作成されます。

どちらの場合も、トークン バケット アルゴリズムを使用して、タスクの実行レートが制御されます。名前付きの各キューには、トークンを保持するバケットがあります。

アプリケーションで 1 つのタスクが実行されるたびに、バケットからトークンが 1 つ削除されます。キューのバケットのトークンがなくなるまでタスクの処理を続けます。キューに指定した max_dispatches_per_second レートに基づいて、システムからバケットに新しいトークンが続けて補充されます。処理対象のタスクがキューにあって、そのキューのバケットにトークンがある場合、システムはトークンと同じ数のタスクを、設定した max_concurrent_dispatches 値まで、同時に処理します。

負荷が不均等になると、バケット内のトークンの数が大幅に増加し、リクエストの急増に伴い、処理が急増する場合があります。この場合、キューの実際のディスパッチ レートが max_dispatches_per_second レートを超え、システム リソースが消費され、ユーザー リクエストの処理とリソースの競合が発生する可能性があります。ダウンストリーム サービスの比較的遅い SLA に基づいてディスパッチ レートを管理するキューを使用している場合、HTTP 429(リクエストが多すぎます)や HTTP 503(サービスを利用できません)などのエラーが発生します。

  • Cloud Tasks API メソッドを使用する場合、キューのディスパッチ レートを定義する 2 つのフィールドがあります。

    • max_dispatches_per_second
    • max_concurrent_dispatches

    3 つ目のフィールド max_burst_size は、max_dispatches_per_second に設定した値に基づいてシステムによって計算されます。詳細については、RateLimits メッセージをご覧ください。

  • queue.yaml メソッドを使用する場合は、3 つの要素すべてを設定できます。

    • max_concurrent_requestsmax_concurrent_dispatches と同等)
    • ratemax_dispatches_per_second と同等)
    • bucket_sizemax_burst_size と同等)

ほとんどの場合、Cloud Tasks API メソッドを使用してシステムに max_burst_size を設定させると、リクエストのバーストをとても効率的に管理できます。ただし、特に必要なレートが比較的低い場合には、queue.yaml メソッドを使用して手動で bucket_size を小さい値に設定するか、Cloud Tasks API を使用して max_concurrent_dispatches を小さい値に設定すると、より細かく制御できます。

再試行パラメータの設定

タスクが正常に完了しない場合、Cloud Tasks は設定されたパラメータに従って、指数バックオフによりタスクを再試行します。

  1. 次のコマンドを実行して、キュー内で失敗したタスクを再試行する最大回数を指定し、再試行の制限時間を設定し、試行間隔を制御します。

    gcloud tasks queues update QUEUE_ID \
        --max-attempts=MAX_ATTEMPTS \
        --max-retry-duration=MAX_RETRY_DURATION \
        --min-backoff=MIN_INTERVAL \
        --max-backoff=MAX_INTERVAL \
        --max-doublings=MAX_DOUBLINGS

    次のように置き換えます。

    • QUEUE_ID: キュー ID(略称)。
    • MAX_ATTEMPTS: 最初の試行を含むタスクの最大試行回数。このフラグを -1 に設定すると、再試行が無制限に許可されます。MAX_ATTEMPTS-1 に設定されている場合でも、MAX_RETRY_DURATION は適用されます。
    • MAX_RETRY_DURATION: 失敗したタスクを再試行する最大時間で、タスクが最初に試行された時点から測定されます。値は「s」で終わる文字列でなければなりません(5s など)。0 に設定すると、タスクの有効期間は無制限になります。MAX_RETRY_DURATION0 に設定されている場合でも、MAX_ATTEMPTS は適用されます。
    • MIN_INTERVAL: 再試行の間に待機する最小時間。値は「s」で終わる文字列でなければなりません(5s など)。
    • MAX_INTERVAL: 再試行の間に待機する最大時間です。値は「s」で終わる文字列でなければなりません(5s など)。
    • MAX_DOUBLINGS: 失敗したタスクの再試行間隔が一定になるまでの、間隔が倍増する最大回数。タスクの再試行間隔は、最初は MIN_INTERVAL で、MAX_DOUBLINGS 回 2 倍になり、その後は直線的に増加します。最終的な再試行間隔は MAX_INTERVAL で、MAX_ATTEMPTS 回まで再試行が発生します。

      たとえば、MIN_INTERVAL10sMAX_INTERVAL300sMAX_DOUBLINGS3 の場合、再試行間隔は 3 回 2 倍になり、2^3 * 10 秒ずつ直線的に増加し、タスクが MAX_ATTEMPTS 回試行されるまで MAX_INTERVAL の間隔で再試行されます(10 秒、20 秒、40 秒、80 秒、160 秒、240 秒、300 秒、300 秒など)。

    パラメータの詳細については、Queue リソースの RetryConfig 設定をご覧ください。

  2. 次のコマンドを実行して、キューが正常に構成されたことを確認します。

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    LOCATION は、キューのロケーションに置き換えます。

    出力には、設定した再試行パラメータが含まれているはずです。

次のステップ