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

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

Cloud Tasks では、キューレベルのルーティング、ディスパッチレート制限、および再試行動作を定義して、タスクの実行を管理できます。これらの設定は、キューの作成時または既存のキューの更新時に構成できます。 gcloud tasks queues create または gcloud tasks queues update で使用される構成フラグは同じです。

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

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

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

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

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

制限事項

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

キューレベルのルーティングが設定されているキューにタスクを作成する
キューレベルのルーティングを適用する

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

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

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

キューを一時停止します次のコマンドを実行して
```
  gcloud tasks queues pause QUEUE_ID
  
```
QUEUE_ID は、キューの ID に置き換えます。
キューレベルのルーティングを更新または削除します。
- キューレベルのルーティングを更新するには、 uriOverride パラメータを更新したルートに設定します。
- REST API または RPC API を使用してキューレベルのルーティングを削除するには:
  - REST API: 空のペイロードを含むキューの patch リクエストと httpTarget に設定された updateMask パラメータ。
  - RPC API: 空のペイロードを含むキューの updateQueueRequest リクエストとupdate_maskに設定された http_targetパラメータ。
次の例では、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
```

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

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

キューレベルのルーティングを設定し、タスクレベルのルーティングをオーバーライドします。
```
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
```

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

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

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

レート制限の定義

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

次のコマンドを実行して、キューによってディスパッチされる同時タスクの最大レートと最大数を設定します。
```
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
```

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

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_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 \
    --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 など）。無制限の期間を指定するには、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: 失敗したタスクの再試行の間隔が 2 倍になる最大回数。この回数を超えると、増加は一定になります。タスクの再試行間隔は MIN_INTERVAL から始まり、MAX_DOUBLINGS 回 2 倍になり、その後線形に増加し、最終的に MAX_ATTEMPTS 回まで MAX_INTERVAL の間隔で再試行されます。
  
  たとえば、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 Queueリソースの設定をご覧ください。

次のコマンドを実行して、キューが正常に構成されたことを確認します。
```
gcloud tasks queues describe QUEUE_ID --location=LOCATION
```
LOCATION は、キューのロケーションに置き換えます。

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

次のステップ

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