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 또는 RPC API를 사용하여 큐 수준 라우팅을 삭제하려면 다음 안내를 따르세요.
  - REST API: 페이로드가 비어 있고 updateMask 매개변수가 httpTarget으로 설정된 큐에 patch 요청을 전송합니다.
  - RPC API: 페이로드가 비어 있고 update_mask 매개변수가 http_target으로 설정된 큐에 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: 프로젝트의 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 파일을 업로드하여 큐 처리 속도를 정의할 수 있습니다. 두 가지 방법 모두 동일한 기본 메커니즘을 사용하는 큐를 생성합니다.

두 경우 모두 큐는 토큰 버킷 알고리즘을 사용하여 태스크 실행 속도를 제어합니다. 각 명명된 큐에는 토큰을 보유하는 버킷이 있습니다.

애플리케이션이 태스크를 실행할 때마다 토큰이 버킷에서 삭제됩니다. 큐는 버킷에 토큰이 소진될 때까지 태스크를 계속 처리합니다. 시스템은 큐에 지정한 max_dispatches_per_second 속도에 따라 버킷에 새 토큰을 계속 채웁니다. 큐에 처리할 태스크가 포함되어 있고 큐의 버킷에 토큰이 포함되어 있으면 시스템은 설정한 max_concurrent_dispatches 값까지 토큰 수만큼의 태스크를 동시에 처리합니다.

고르지 않은 로드로 인해 버킷의 토큰 수가 크게 증가할 수 있으며, 이로 인해 대량의 요청이 들어오면 처리량이 늘어날 수 있습니다. 이 경우 큐에 max_dispatches_per_second 속도를 초과하는 실제 디스패치 속도가 발생하여 시스템 리소스를 소비하고 사용자 제공 요청과 경쟁할 수 있습니다. 다운스트림 서비스의 상대적으로 느린 SLA를 기반으로 큐를 사용하여 디스패치 속도를 관리하는 경우 HTTP 429 (너무 많은 요청) 또는 HTTP 503(서비스를 사용할 수 없음)과 같은 오류가 발생할 수 있습니다.

Cloud Tasks API 메서드를 사용하는 경우 큐 디스패치 속도를 정의하는 두 가지 필드가 있습니다.
- max_dispatches_per_second
- max_concurrent_dispatches
세 번째 필드인 max_burst_size는 max_dispatches_per_second에 설정한 값을 기반으로 시스템에서 계산합니다. 자세한 내용은 RateLimits 메시지를 참조하세요.
queue.yaml 메서드를 사용하면 다음 세 가지 요소를 모두 설정할 수 있습니다.
- 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: 실패한 태스크를 재시도할 수 있는 최대 시간으로, 태스크가 처음 시도되었을 때부터 측정됩니다. 값은 5s와 같이 's'로 끝나는 문자열이어야 합니다. 무제한 기간을 지정하려면 이 값을 0s로 설정합니다. MAX_RETRY_DURATION에 도달하거나 0s로 설정된 경우에도 MAX_ATTEMPTS가 계속 적용됩니다.
참고: 무제한 시도 (MAX_ATTEMPTS가 -1)와 무제한 기간 (MAX_RETRY_DURATION이 0s)을 지정하면 최대 태스크 보관 한도에 도달할 때까지 태스크가 재시도됩니다. 그렇지 않으면 Cloud Tasks는 두 조건이 모두 충족되거나 태스크가 성공한 후에만 재시도를 중지합니다. 태스크가 MAX_ATTEMPTS번 시도되고 MAX_RETRY_DURATION 시간이 경과하면 더 이상 시도하지 않고 태스크가 삭제됩니다.
- MIN_INTERVAL: 재시도 사이에 대기해야 하는 최소 시간입니다. 값은 5s와 같이 's'로 끝나는 문자열이어야 합니다.
- MAX_INTERVAL: 재시도 사이에 대기해야 하는 최대 시간입니다. 값은 5s와 같이 's'로 끝나는 문자열이어야 합니다.
- MAX_DOUBLINGS: 실패한 태스크 다시 시도 사이의 간격이 두 배가 되는 최대 횟수입니다. 이 횟수 이후에는 증분 값이 상수가 됩니다. 태스크의 재시도 간격은 MIN_INTERVAL에서 시작하여 MAX_DOUBLINGS번 두 배로 늘어난 후 선형으로 증가하고 마지막으로 MAX_ATTEMPTS번까지 MAX_INTERVAL 간격으로 재시도됩니다.
  
  예를 들어 MIN_INTERVAL이 10s이고 MAX_INTERVAL이 300s이며 MAX_DOUBLINGS이 3이면 재시도 간격이 3번 두 배로 늘어나고 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 참조에서 큐 관리에 대해 자세히 알아봅니다.