이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Cloud Tasks 큐 구성

큐를 만들 때 또는 이후에 언제든지 Cloud Tasks 큐를 구성할 수 있습니다. 이 구성은 큐에 있는 모든 태스크에 적용됩니다.

큐 구성 시 다음 세 가지 기본 요소를 고려합니다.

라우팅
비율 제한
재시도 매개변수

큐 수준 라우팅 구성

큐 수준에서 라우팅을 구성하면 태스크 수준에서 설정된 라우팅이 재정의됩니다. Cloud Tasks를 대상 서비스 앞에 버퍼로 사용하거나 큐의 모든 태스크에 대한 라우팅을 변경해야 하는 경우에 유용합니다.

큐 수준 라우팅은 다음에 적용됩니다.

대기열에 있는 작업
큐 수준 라우팅이 설정된 후 큐에 추가된 작업

제한사항

큐 수준 라우팅은 Cloud Key Management Service(Cloud KMS) 고객 관리 암호화 키(CMEK)와 호환되지 않습니다. CMEK가 사용 설정된 경우 다음 작업을 할 수 없습니다.

큐 수준 라우팅이 있는 큐에서 작업 만들기
큐 수준 라우팅 적용

HTTP 태스크에 큐 수준 라우팅 구성

큐를 만들 때 또는 큐를 업데이트할 때 태스크 수준 라우팅을 재정의하도록 큐를 구성할 수 있습니다. 큐 수준 라우팅을 구성하려면 큐의 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: 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'로 끝나는 문자열이어야 합니다. 0으로 설정하면 작업 기간이 무제한입니다. MAX_RETRY_DURATION이 0로 설정된 경우에도 MAX_ATTEMPTS는 계속 적용됩니다.
참고: MAX_ATTEMPTS이 -1 이외의 값으로 설정되고 MAX_RETRY_DURATION이 0보다 큰 경우 MAX_ATTEMPTS 및 MAX_RETRY_DURATION이 모두 충족되면 Cloud Tasks는 재시도를 중지합니다. 태스크가 MAX_ATTEMPTS회 시도되고 MAX_RETRY_DURATION 시간이 지나면 더 이상 시도되지 않으며 태스크가 삭제됩니다. MAX_ATTEMPTS을 -1로 설정하고 MAX_RETRY_DURATION을 0로 설정하면 태스크가 무한정 재시도됩니다.
- 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초 등
매개변수에 관한 자세한 내용은 Queue 리소스의 RetryConfig 설정을 참고하세요.
다음 명령어를 실행하여 큐가 성공적으로 구성되었는지 확인합니다.
```
gcloud tasks queues describe QUEUE_ID --location=LOCATION
```
LOCATION을 큐의 위치로 바꿉니다.

출력에는 설정한 재시도 매개변수가 포함되어야 합니다.

다음 단계

HTTP Target 작업 만들기 알아보기
App Engine 작업 만들기 알아보기
RPC API 참조에서 큐 관리에 대해 자세히 알아보세요.
REST API 참조에서 큐 관리에 대해 자세히 알아보기