Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

キューのルーティング、上限、再試行を構成する

Cloud Tasks では、キューレベルのルーティング、ディスパッチレート制限、再試行動作を定義して、タスクの実行を管理できます。これらの設定は、キューの作成時または既存のキューの更新時に構成できます。

gcloud tasks queues create と gcloud tasks queues update はどちらも同じフラグを使用してキューパラメータを設定しますが、gcloud tasks queues update は --clear-* フラグもサポートしており、パラメータをデフォルトにリセットできます。

キューレベルで認証を構成すると、タスクレベルの認証がオーバーライドされます。詳細については、認証トークンを使用した HTTP ターゲットタスクの使用をご覧ください。

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

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

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

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

制限事項

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

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

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

キューの作成時または更新時に、タスクレベルのルーティングをオーバーライドするようにキューを構成できます。キューレベルのルーティングを構成するには、キューの uriOverride パラメータを優先ルートに設定します。デフォルト（uriOverrideEnforceMode が ALWAYS に設定されている）では、キューレベルのルーティングがタスクレベルのルーティングをオーバーライドします。uriOverrideEnforceMode を IF_NOT_EXISTS に設定して、タスクが独自の URI コンポーネントを指定していない場合にのみキューレベルのルーティングが適用されるようにすることもできます。

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

次のコマンドを実行して、キューを一時停止します。
```
gcloud tasks queues pause QUEUE_ID \
    --location=LOCATION
```
次のように置き換えます。
- QUEUE_ID: キューの ID。
- LOCATION: キューの場所
キューレベルのルーティングを更新または削除します。
- キューレベルのルーティングを更新するには、uriOverride パラメータを更新されたルートに設定します（または --http-uri-override フラグを gcloud tasks queues update に渡します）。
- キューレベルのルーティングを削除するには:
  - Google Cloud CLI: --clear-http-uri-override フラグを指定して gcloud tasks queues update を実行します。
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --clear-http-uri-override
```
  - REST API: 空の JSON オブジェクト（{}）を含むキューの patch リクエストと、httpTarget.uriOverride に設定された updateMask クエリパラメータ（または、キューレベルの HTTP ターゲット設定をすべてクリアする場合は httpTarget）。
  - RPC API: queue.name を指定し、http_target.uri_override を設定せず、update_mask パラメータを http_target.uri_override に設定して（または http_target を設定して、キューレベルの HTTP ターゲット設定をすべてクリアして）、Queue の UpdateQueueRequest を送信します。
次の例では、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: キューをルーティングする新しいホスト。
1 分ほど待ちます。

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

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

gcloud tasks queues resume QUEUE_ID \
    --location=LOCATION

次のコマンドを実行して、キューが正常に構成されたことを確認します。
```
gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION
```
出力には、設定した httpTarget ルーティングオーバーライドが含まれます。

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

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

キューレベルのルーティングを設定し、タスクレベルのルーティングをオーバーライドします。
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --routing-override=service:SERVICE,version:VERSION
```
次のように置き換えます。
- QUEUE_ID: キュー ID（略称）。
- LOCATION: キューの場所。
- SERVICE: タスク処理を担当する App Engine ワーカーサービスです。
- VERSION: アプリのバージョン。
たとえば、キュー内のすべてのタスクを処理するためにワーカーサービスを設定すると、そのサービスとデフォルトバージョンにルーティングできます。
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --routing-override=service:SERVICE
```

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

gcloud tasks queues describe QUEUE_ID \
    --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

キューレベルのルーティングを削除するには、次のコマンドを実行します。
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --clear-routing-override
```
キューレベルのルーティングが削除されると、キュー内のタスクと、今後キューに追加されるタスクにタスクレベルのルーティングが適用されます。

レート制限の定義

レート制限は、アクティブなキューによってタスクをディスパッチできる最大定常レートを決定します。ディスパッチが最初のタスク試行か再試行かは関係ありません。

注: maxDispatchesPerSecond 設定は、アクティブなキューの定常状態の上限を定義します。キューが新しく作成された場合、一時停止後に再開された場合、ダウンストリームの HTTP 429 または 5xx エラーレスポンスから回復した場合、アクティブなディスパッチなしで数分間アイドル状態になった場合、コールド状態またはアイドル状態になります。この状態から、Cloud Tasks は、フル容量で直ちにバーストするのではなく、低いベースラインから maxDispatchesPerSecond に向かって、適用されるディスパッチレートを徐々に引き上げます。コールドランプアップ、アイドルランプアップ、システムスロットリングの詳細については、初期キューのランプアップとバックオフエラーと強制レートをご覧ください。

次のコマンドを実行して、キューによってディスパッチされる同時タスクの最大レートと最大数を設定します。
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --max-dispatches-per-second=DISPATCH_RATE \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES
```
次のように置き換えます。
- QUEUE_ID: キュー ID（略称）。
- LOCATION: キューの場所。
- DISPATCH_RATE: ディスパッチレート。これは、バケット内のトークンが更新されるレートです。タスクが比較的安定している状況では、これはタスクがディスパッチされる割合に相当します。
- MAX_CONCURRENT_DISPATCHES: キュー内で同時に実行できるタスクの最大数。
たとえば、パラメータを設定せずにキューを作成した場合は、次のコマンドを実行して同時タスクの最大数を更新できます。
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES
```

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

gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION

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

name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: MAX_CONCURRENT_DISPATCHES
  maxDispatchesPerSecond: DISPATCH_RATE
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（Too Many Requests）や HTTP 503（Service Unavailable）などのエラーが発生する可能性があります。ただし、キューが新しく作成された場合、最近再開された場合、数分間アイドル状態だった場合は、コールド状態またはアイドル状態になり、すぐにバーストするのではなく、max_dispatches_per_second に向けて徐々に増加します。コールドキューまたはアイドルキューのランプアップの詳細については、初期キューのランプアップをご覧ください。

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_requests（max_concurrent_dispatches と同等）
- rate（max_dispatches_per_second と同等）
- bucket_size（max_burst_size と同等）

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

再試行パラメータの設定

タスクが正常に完了しない場合、Cloud Tasks は設定されたパラメータに従って指数バックオフを使用してタスクを再試行します。タスクが正常に実行されると、キューから削除されます。いずれの場合も、タスクの最大保持期間の上限も適用されます。

必要に応じて、タスクのキューレベルの再試行構成をオーバーライドするタスクレベルの再試行構成を指定できます。詳細については、タスクの再試行パラメータを設定するをご覧ください。

次のコマンドを実行して、キュー内で失敗したタスクを再試行する最大回数を指定したり、再試行の制限時間を設定したり、試行間隔を制御したりできます。
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --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（略称）。
- LOCATION: キューの場所。
- MAX_ATTEMPTS: タスクの最大試行回数（最初の試行を含む）。再試行を無制限に許可するには、-1 に設定します。MAX_ATTEMPTS に達した場合、または -1 に設定されている場合でも、MAX_RETRY_DURATION は適用されます。
- MAX_RETRY_DURATION: 失敗したタスクを再試行する最大時間で、タスクが最初に試行された時点から測定されます。値は「s」で終わる文字列でなければなりません（5s など）。無制限の期間を指定するには、0s に設定します。MAX_RETRY_DURATION に達した場合や 0s に設定されている場合でも、MAX_ATTEMPTS は引き続き適用されます。
注: 無制限の試行回数（MAX_ATTEMPTS が -1）と無制限の期間（MAX_RETRY_DURATION が 0s）を指定すると、タスクの最大保持期間の上限に達するまで、タスクが再試行されます。それ以外の場合、Cloud Tasks は、両方の条件が満たされるか、タスクが成功した後にのみ再試行を停止します。タスクが MAX_ATTEMPTS 回試行され、MAX_RETRY_DURATION 時間が経過すると、それ以上の試行は行われず、タスクは削除されます。
- MIN_INTERVAL: 再試行の間に待機する最小時間です。値は「s」で終わる文字列でなければなりません（5s など）。
- MAX_INTERVAL: 再試行の間に待機する最大時間です。値は「s」で終わる文字列でなければなりません（5s など）。
- MAX_DOUBLINGS: 失敗したタスクの再試行間隔が一定になるまでの、間隔が倍増する最大回数。タスクの再試行間隔は MIN_INTERVAL から始まり、MAX_DOUBLINGS 回 2 倍ずつ間隔を長くします。その後は直線的に間隔が広げられます。最終的には、MAX_INTERVAL の間隔で最大 MAX_ATTEMPTS 回再試行します。
  
  たとえば、MIN_INTERVAL が 10s、MAX_INTERVAL が 300s、MAX_DOUBLINGS が 3 の場合、再試行間隔は 3 回 2 倍になり、2^3 * 10 秒ずつ直線的に増加します。その後、タスクが MAX_ATTEMPTS 回試行されるまで、MAX_INTERVAL の間隔で再試行されます（10 秒、20 秒、40 秒、80 秒、160 秒、240 秒、300 秒、300 秒など）。

パラメータの詳細については、RetryConfig リソースリファレンスをご覧ください。

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

gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION

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

retryConfig:
  maxAttempts: MAX_ATTEMPTS
  maxBackoff: MAX_INTERVAL
  maxDoublings: MAX_DOUBLINGS
  maxRetryDuration: MAX_RETRY_DURATION
  minBackoff: MIN_INTERVAL

次のステップ

HTTP ターゲットタスクの作成方法を学習する。
App Engine タスクの作成方法を学習する。
RPC API リファレンスでキュー管理の詳細を学習する。
REST API リファレンスでキュー管理の詳細を確認する。

キューのルーティング、上限、再試行を構成する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

制限事項

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

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

レート制限の定義

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

再試行パラメータの設定

次のステップ

キューのルーティング、上限、再試行を構成する

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