push 큐를 Cloud Tasks로 마이그레이션(Python)

이 페이지에서는 태스크 큐에서 Cloud Tasks로 push 큐 코드를 마이그레이션하는 방법을 설명합니다. 이제 Cloud Tasks가 App Engine push 큐 작업에 더 좋은 방법입니다.

Cloud Tasks를 사용하면 Task Queues RPC API로 액세스하는 것과 동일한 서비스에 액세스할 수 있습니다. 즉, 기존 push 큐와 push 태스크를 다시 만들 필요가 없습니다. 하지만 Cloud Tasks API를 사용하려면 push 큐 또는 push 태스크를 만들거나 상호작용하는 코드를 마이그레이션해야 합니다.

Cloud Tasks REST 및 RPC API, Cloud Tasks 클라이언트 라이브러리, Google Cloud CLI, Google Cloud 콘솔을 사용하여 push 큐 및 push 태스크를 만들고 상호작용할 수 있습니다. 이 페이지에서는 gcloud CLI와 Cloud Tasks 클라이언트 라이브러리를 사용하는 예시를 제공합니다.

Cloud Tasks에서 모든 큐는 push 큐로 작동합니다. 이 가이드의 나머지 부분과 Cloud Tasks 문서에서 큐라는 용어는 push 큐와 같습니다. 마찬가지로 태스크라는 용어는 push 태스크와 같습니다.

Cloud Tasks에서 사용할 수 없는 기능

다음 기능은 Cloud Tasks에서 사용할 수 없습니다.

Datastore 트랜잭션의 태스크를 큐에 추가
작업자 서비스 대신 지연된 태스크 라이브러리 사용
멀티 테넌트 애플리케이션에서 태스크 처리
로컬 개발 서버에서 시뮬레이션
비동기식으로 작업 추가

가격 책정 및 할당량

push 큐를 Cloud Tasks로 마이그레이션하면 앱의 가격 책정 및 할당량에 영향을 줄 수 있습니다.

가격 책정

Cloud Tasks에는 자체 가격이 적용됩니다. 태스크 큐와 마찬가지로 태스크를 사용하여 App Engine 앱에 요청을 전송하면 앱에 비용이 발생할 수 있습니다.

할당량

Cloud Tasks 할당량은 태스크 큐의 할당량과 다릅니다. 태스크 큐와 마찬가지로 Cloud Tasks에서 App Engine 앱에 요청을 전송하면 App Engine 요청 할당량에 영향을 줄 수 있습니다.

마이그레이션하기 전에

아직 하지 않은 경우 Google Cloud와 호환되는 Python 버전을 사용하도록 Python 개발 환경을 설정하고 격리된 Python 환경을 만드는 테스트 도구를 설치하세요.

다음 섹션에서는 push 큐를 Cloud Tasks로 마이그레이션하기 전의 설정 단계를 설명합니다.

pull 큐 마이그레이션

시작하기 전에 pull 큐를 마이그레이션한 다음 이 가이드의 안내에 따라 push 큐를 마이그레이션합니다. push 큐를 마이그레이션한 후 pull 큐를 마이그레이션하는 것은 권장되지 않습니다. queue.yaml 파일의 필수 사용으로 Cloud Tasks에서 예기치 않은 동작이 발생할 수 있기 때문입니다.

큐 구성 보호

Cloud Tasks로 마이그레이션하는 프로세스를 시작한 후 queue.yaml 파일을 수정하면 예기치 않은 동작이 발생할 수 있으므로 권장하지 않습니다. queue.yaml 파일이 큐 구성을 수정하지 못하도록 다음 안내를 따르세요.

이후 배포에서 queue.yaml 파일을 생략하도록 gcloud CLI를 구성합니다.

queue.yaml 파일을 .gcloudignore 파일에 추가합니다. .gcloudignore 파일이 이미 있는지 확인하려면 앱의 최상위 디렉터리에서 터미널에 다음 명령어를 실행하면 됩니다. 이 명령어는 파일이 존재할 경우 파일 이름을 출력합니다.
```
ls -a | grep .gcloudignore
```
.gcloudignore 파일에 대한 자세한 내용은 .gcloudignore 참조를 읽어보세요.
queue.yaml 파일에 대한 권한을 제한합니다.

큐 구성 보호 가이드에 설명된 권장사항을 따르세요.
Cloud Tasks 및 queue.yaml 파일에 대해 알아봅니다(선택사항).

Cloud Tasks API를 사용하여 큐 구성을 관리할 때 queue.yaml 파일을 배포하면 Cloud Tasks에서 설정한 구성을 재정의하여 예기치 않은 동작이 발생할 수 있습니다. 자세한 내용은 큐 관리와 queue.yaml 사용 비교를 읽어보세요.

Cloud Tasks API 사용 설정

Cloud Tasks API를 사용 설정하려면 API 라이브러리의 Cloud Tasks API에서 사용 설정을 클릭합니다. 사용 설정 버튼 대신 관리 버튼이 표시되면 이전에 프로젝트에 Cloud Tasks API를 사용 설정했으므로 다시 설정할 필요가 없습니다.

Cloud Tasks API에 앱 인증

Cloud Tasks API에 앱을 인증해야 합니다. 이 섹션에서는 두 가지 사용 사례에 대한 인증을 설명합니다.

앱을 로컬로 개발하거나 테스트하려면 서비스 계정을 사용하는 것이 좋습니다. 서비스 계정을 설정하고 앱에 연결하는 방법은 수동으로 서비스 계정 사용자 인증 정보 획득 및 제공을 읽어보세요.

App Engine에 앱을 배포하기 위해 새 인증을 제공할 필요는 없습니다. 애플리케이션 기본 사용자 인증 정보(ADC)는 App Engine 앱의 인증 세부정보를 추론합니다.

gcloud CLI 다운로드

이전에 설치하지 않았으면 gcloud CLI를 다운로드하고 설치하여 Cloud Tasks API에서 gcloud CLI를 사용합니다. gcloud CLI가 이미 설치되어 있으면 터미널에서 다음 명령어를 실행합니다.

gcloud components update

Cloud 클라이언트 라이브러리 가져오기

App Engine 앱에서 Cloud Tasks 클라이언트 라이브러리를 사용하려면 다음 단계를 따르세요.

app.yaml 파일을 업데이트합니다. 사용 중인 Python 버전에 해당하는 안내를 따르세요.
Python 2
Python 2 앱의 경우 최신 버전의 grpcio, setuptools 라이브러리를 추가하세요.

다음은 app.yaml 파일의 예시입니다.
```
runtime: python27
threadsafe: yes
api_version: 1

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest
```
Python 3
Python 3 앱의 경우 지원되는 Python 3 버전을 사용하여 app.yaml 파일에서 runtime 요소를 지정합니다. 예를 들면 다음과 같습니다.
```
runtime: python310 # or another support version
```
Python 3 런타임은 라이브러리를 자동으로 설치하므로 이전 Python 2 런타임의 기본 제공 라이브러리를 지정할 필요가 없습니다. 마이그레이션 시 Python 3 앱이 다른 기존 번들 서비스를 사용하는 경우 계속 필요한 기본 제공 라이브러리를 지정할 수 있습니다. 또는 app.yaml 파일에서 불필요한 줄을 삭제할 수도 있습니다.
requirements.txt 파일을 업데이트합니다. 사용 중인 Python 버전에 해당하는 안내를 따르세요.
Python 2
Cloud Tasks용 Cloud 클라이언트 라이브러리를 requirements.txt 파일의 종속 항목 목록에 추가합니다.
```
google-cloud-tasks
```
그런 다음 pip install -t lib -r requirements.txt를 실행하여 앱에 사용 가능한 라이브러리 목록을 업데이트합니다.
Python 3
Cloud Tasks용 Cloud 클라이언트 라이브러리를 requirements.txt 파일의 종속 항목 목록에 추가합니다.
```
google-cloud-tasks
```
App Engine은 Python 3 런타임에서 앱 배포 중에 이러한 종속 항목을 자동으로 설치하므로, lib 폴더가 있는 경우 이를 삭제하세요.
Python 2 앱의 경우 앱에서 기본 제공 또는 복사된 라이브러리를 사용한다면 app.yaml 파일과 같은 폴더에 있는 appengine_config.py 파일에 해당 경로를 지정해야 합니다.
```
import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)
```
appengine_config.py 파일은 lib 폴더가 있는 위치를 현재의 작업 디렉터리라고 간주합니다. 일부 경우(예: 단위 테스트)에는 현재 작업 디렉터리가 다를 수 있습니다. 오류를 방지하기 위해 다음을 사용하여 lib 폴더로 전체 경로를 명시적으로 전달할 수 있습니다.
```
import os
path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
```
Task Queues API에서 push 큐를 사용하는 모든 파일에서 Cloud Tasks 클라이언트 라이브러리를 가져옵니다.
```
from google.cloud import tasks
```
push 큐를 생성하거나 push 큐와 상호작용하는 모든 코드를 Cloud Tasks에 성공적으로 마이그레이션하면 Task Queues API를 가져오는 구문(예: from google.appengine.api import taskqueue)을 삭제합니다.

큐 만들기 및 관리

이 섹션에서는 Cloud Tasks API를 사용하여 큐를 만들고 관리하는 방법을 설명합니다.

Cloud Tasks에서는 큐 만들기 또는 관리를 위해 queue.yaml 파일을 사용하지 않습니다. 대신 Cloud Tasks API를 사용합니다. queue.yaml 파일과 Cloud Tasks API를 모두 사용하는 것은 권장되지 않지만, 앱에 따라 태스크 큐에서 Cloud Tasks로 마이그레이션할 때 이렇게 하는 것이 불가피할 수 있습니다. 권장사항은 큐 관리와 queue.yaml 사용 비교를 읽어보세요.

큐 만들기

앱에서 프로그래매틱 방식으로 큐를 만들거나 명령줄에서 추가 큐를 만들려면 이 섹션을 읽어보세요.

Cloud Tasks에서 큐 이름은 projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID 형식입니다. 큐 이름의 LOCATION_ID 부분은 Google Cloud 리전에 해당합니다. 큐 이름의 QUEUE_ID 부분은 태스크 큐의 name 필드와 같습니다. 큐를 생성하는 동안 사용자가 정하는 프로젝트, 리전, QUEUE_ID에 따라 큐 이름이 생성됩니다.

일반적으로 큐 위치(예: 리전)는 앱 리전과 동일해야 합니다. 이 규칙의 두 가지 예외는 europe-west 리전을 사용하는 앱과 us-central 리전을 사용하는 앱에 적용됩니다. Cloud Tasks에서 이러한 리전을 각각 europe-west1과 us-central1이라고 합니다.

큐를 만드는 동안 큐 구성을 선택적으로 지정할 수 있지만 큐를 만든 후 큐를 업데이트하여 큐 구성을 지정할 수도 있습니다.

기존 큐를 다시 만들 필요가 없습니다. 대신 이 가이드의 관련 부분을 참조하여 기존 큐와 상호작용하는 코드를 마이그레이션하세요.

큐 이름 재사용

큐를 삭제한 후 동일한 프로젝트 및 위치(예: 리전)에 동일한 큐 ID를 만들려면 7일이 지나야 합니다.

다음 예시에서는 Cloud Tasks를 사용하여 두 개의 큐를 만듭니다. 첫 번째 큐에는 큐 ID queue-blue가 있으며 모든 태스크를 5/s 속도로 v2 버전의 task-module 서비스에 전송하도록 구성됩니다. 두 번째 큐의 큐 ID는 queue-red이며 1/s 속도로 태스크를 디스패치합니다. 둘 다 us-central1 위치의 프로젝트 ID가 my-project-id인 프로젝트에서 생성됩니다. 태스크 큐의 큐 삭제와 동일한 Cloud Tasks입니다.

gcloud

gcloud CLI는 gcloud CLI 구성에서 프로젝트와 위치를 추론합니다.

gcloud tasks queues create queue-blue \
--max-dispatches-per-second=5 \
--routing-override=service:task-module,version:v2

gcloud tasks queues create queue-red \
--max-dispatches-per-second=1

클라이언트 라이브러리

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue_blue_name = 'queue-blue'
# queue_red_name = 'queue-red'

parent = f"projects/{project}/locations/{location}"

queue_blue = {
    "name": client.queue_path(project, location, queue_blue_name),
    "rate_limits": {"max_dispatches_per_second": 5},
    "app_engine_routing_override": {"version": "v2", "service": "task-module"},
}

queue_red = {
    "name": client.queue_path(project, location, queue_red_name),
    "rate_limits": {"max_dispatches_per_second": 1},
}

queues = [queue_blue, queue_red]
for queue in queues:
    response = client.create_queue(parent=parent, queue=queue)
    print(response)

자세한 내용은 Cloud Tasks 참조인 Cloud Tasks 큐 만들기를 확인하세요.

큐 처리 속도 설정

다음 표에는 태스크 큐와 Cloud Tasks가 다른 필드가 나와 있습니다.

태스크 큐 필드	Cloud Tasks 필드	설명
`rate`	`max_dispatches_per_second`	큐에서 태스크가 디스패치되는 최대 속도
`max_concurrent_requests`	`max_concurrent_dispatches`	큐에서 디스패치할 수 있는 최대 동시 태스크 수
`bucket_size`	`max_burst_size`	Cloud Tasks는 `max_dispatches_per_second` 값을 기준으로 큐의 태스크가 처리되는 속도를 제한하는 가져오기 전용 속성 `max_burst_size`를 계산합니다. 이 필드는 큐에 빠른 속도를 허용하여 태스크가 큐에 추가된 직후부터 처리가 시작되지만 짧은 기간 동안 많은 태스크가 큐에 추가되면 리소스 사용량을 제한할 수 있습니다. `queue.yaml` 파일을 사용하여 만들거나 업데이트한 App Engine 큐의 경우 `max_burst_size`는 처음에 `bucket_size`와 동일합니다. 하지만 Cloud Tasks 인터페이스를 사용하여 큐가 나중에 `update` 명령어로 전달되면 `max_burst_size`는 `max_dispatches_per_second`의 업데이트와 관계없이 `max_dispatches_per_second`의 값에 따라 재설정됩니다.
`total_storage_limit`	Cloud Tasks에서 지원 중단	Cloud Tasks는 커스텀 스토리지 제한 설정을 지원하지 않습니다.

큐를 만들거나 나중에 업데이트할 때 큐 처리 속도를 설정할 수 있습니다. 다음 예시에서는 Cloud Tasks를 사용하여 이미 생성된 queue-blue라는 큐의 처리 속도를 설정합니다. queue-blue가 queue.yaml 파일을 사용하여 생성되거나 구성된 경우 아다음 예시에서는 max_dispatches_per_second 값 20에 따라 max_burst_size를 재설정합니다. 태스크 큐의 큐 처리 속도 설정과 동일한 Cloud Tasks입니다.

gcloud

gcloud tasks queues update queue-blue \
--max-dispatches-per-second=20 \
--max-concurrent-dispatches=10

클라이언트 라이브러리

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue-blue'

# Get queue object
queue_path = client.queue_path(project, location, queue)
queue = client.get_queue(name=queue_path)

# Update queue object
queue.rate_limits.max_dispatches_per_second = 20
queue.rate_limits.max_concurrent_dispatches = 10

response = client.update_queue(queue=queue)
print(response)

자세한 내용은 비율 제한 정의를 참조하세요.

큐 사용 중지 및 다시 시작

Cloud Tasks는 태스크 큐에서 사용 중지라는 용어를 사용하는 것과 동일한 방식으로 일시중지라는 용어를 사용합니다. 큐를 일시중지하면 큐가 다시 시작될 때까지 큐의 태스크가 실행되지 않습니다. 하지만 일시중지된 큐에 태스크를 계속 추가할 수 있습니다. Cloud Tasks는 태스크 큐와 동일한 방식으로 다시 시작이라는 용어를 사용합니다.

다음 예시에서는 큐 ID가 queue1인 큐를 일시중지합니다. 태스크 큐의 큐 사용 중지와 동일한 Cloud Tasks입니다.

gcloud

gcloud tasks queues pause 

queue1

클라이언트 라이브러리

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue1'

queue_path = client.queue_path(project, location, queue)
response = client.pause_queue(name=queue_path)

자세한 내용은 Cloud Tasks 참조인 큐 일시중지를 확인하세요.

큐 삭제

큐를 삭제한 후 동일한 이름으로 큐를 만들려면 7일이 지나야 합니다. 7일을 기다릴 수 없는 경우 큐에서 모든 태스크를 삭제하고 큐를 다시 구성해 보세요.

다음 예시에서는 큐 ID가 queue1인 큐를 삭제합니다. 태스크 큐의 큐 삭제와 동일한 Cloud Tasks입니다.

gcloud

gcloud tasks queues delete 

queue1

클라이언트 라이브러리

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue1'

queue_path = client.queue_path(project, location, queue)
response = client.delete_queue(name=queue_path)

자세한 내용은 Cloud Tasks 참조인 큐 삭제를 읽어보세요.

태스크 만들기 및 관리

이 섹션에서는 Cloud Tasks API를 사용하여 태스크를 만들고 관리하는 방법을 설명합니다.

태스크 만들기

다음 표에는 태스크 큐와 Cloud Tasks가 다른 필드가 나와 있습니다.

태스크 큐 필드	Cloud Tasks 필드	설명
Cloud Tasks의 새로운 기능	`app_engine_http_request`	App Engine 서비스를 대상으로 하는 요청을 만듭니다. 이러한 태스크를 App Engine 태스크라고 합니다.
`method`	`http_method`	요청 메서드를 지정합니다(예: `POST`).
`url`	`relative_uri`	태스크 핸들러를 지정합니다. 마지막 문자의 차이점을 확인합니다. uniform resource locator의 `l`이 아니라 uniform resource identifier의 `i`입니다.
`target`	`app_engine_routing`	선택사항. App Engine 태스크의 App Engine `service`, `version`, `instance`를 지정합니다. 설정하지 않으면 기본 서비스, 버전, 인스턴스가 사용됩니다.

다음 예시에서는 /update_counter 핸들러를 사용하여 이름이 worker인 App Engine 서비스로 라우팅하는 태스크를 만듭니다. 태스크 큐의 태스크 만들기와 동일한 Cloud Tasks입니다.

gcloud

gcloud tasks create-app-engine-task --queue=default \
--method=POST --relative-uri=/update_counter --routing=service:worker \
--body-content=10

클라이언트 라이브러리

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'default'
amount = 10

parent = client.queue_path(project, location, queue)

task = {
    "app_engine_http_request": {
        "http_method": tasks.HttpMethod.POST,
        "relative_uri": "/update_counter",
        "app_engine_routing": {"service": "worker"},
        "body": str(amount).encode(),
    }
}

response = client.create_task(parent=parent, task=task)
eta = response.schedule_time.strftime("%m/%d/%Y, %H:%M:%S")
print(f"Task {response.name} enqueued, ETA {eta}.")

자세한 내용은 Cloud Tasks 참조인 App Engine 태스크 만들기를 확인하세요.

대상 서비스 지정 및 라우팅

App Engine 태스크의 App Engine 대상 서비스, 버전, 인스턴스를 지정하는 것은 선택사항입니다. 기본적으로 App Engine 태스크는 태스크가 시도될 때 기본값인 서비스, 버전, 인스턴스로 라우팅됩니다.

태스크를 만드는 동안 태스크의 app_engine_routing 속성을 설정하여 태스크에 다른 App Engine 서비스, 버전, 인스턴스를 지정합니다.

특정 큐의 모든 태스크를 동일한 App Engine 서비스, 버전, 인스턴스로 라우팅하려면 큐에서 app_engine_routing_override 속성을 설정하면 됩니다.

자세한 내용은 Cloud Tasks 참조인 라우팅 구성을 확인하세요.

핸들러에 데이터 전달

태스크 큐와 마찬가지로 Cloud Tasks를 사용하는 두 가지 방법으로 데이터를 핸들러에 전달할 수 있습니다. 상대 URI에서 데이터를 쿼리 매개변수로 전달하거나 HTTP 메서드 POST 또는 PUT을 사용하여 요청 본문에 데이터를 전달할 수 있습니다.

Cloud Tasks에서는 태스크 큐에 사용되는 페이로드 용어와 동일한 방식으로 본문이라는 용어가 사용됩니다. Cloud Tasks에서 기본 본문 콘텐츠 유형은 일반 텍스트가 아닌 octet-stream입니다. 헤더에 지정하여 본문 콘텐츠 유형을 설정할 수 있습니다.

다음 예시에서는 두 가지 방법으로 /update_counter 핸들러에 키를 전달합니다. 태스크 큐의 핸들러에 데이터 전달과 동일한 Cloud Tasks입니다.

콘솔

gcloud tasks create-app-engine-task --queue=default --method=GET  \
--relative-uri=

/update_counter

?key=blue --routing=service:worker

gcloud tasks create-app-engine-task --queue=default --method=POST \
--relative-uri=

/update_counter

 --routing=service:worker \
--body-content="{'key': 'blue'}"

클라이언트 라이브러리

import json

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'default'

parent = client.queue_path(project, location, queue)

task1 = {
    "app_engine_http_request": {
        "http_method": tasks.HttpMethod.POST,
        "relative_uri": "/update_counter?key=blue",
        "app_engine_routing": {"service": "worker"},
    }
}

task2 = {
    "app_engine_http_request": {
        "http_method": tasks.HttpMethod.POST,
        "relative_uri": "/update_counter",
        "app_engine_routing": {"service": "worker"},
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"key": "blue"}).encode(),
    }
}

response = client.create_task(parent=parent, task=task1)
print(response)
response = client.create_task(parent=parent, task=task2)
print(response)

태스크 이름 지정

태스크 이름 지정은 선택사항입니다. 태스크 이름을 지정하지 않으면 Cloud Tasks는 태스크를 만드는 동안 지정한 큐에 따라 태스크 ID를 생성하고 프로젝트 및 위치(예: 리전)를 추론하여 자동으로 태스크 이름을 구성합니다.

태스크 이름은 projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID/tasks/TASK_ID 형식입니다. 태스크 이름의 TASK_ID 부분은 태스크 큐의 태스크 name 필드와 동일합니다.

태스크 이름 재사용

태스크 이름을 재사용하려면 기다려야 합니다. 태스크 이름을 재사용하기 전에 기다려야 하는 시간은 태스크를 디스패치하는 큐가 Cloud Tasks에서 생성되었는지 아니면 태스크 큐에서 생성되었는지에 따라 다릅니다.

태스크 큐(기본 큐 포함)를 사용하여 만든 큐의 태스크인 경우 원래 태스크가 삭제되거나 실행된 후 약 9일을 기다려야 합니다. Cloud Tasks를 사용하여 만든 큐의 태스크인 경우 원래 태스크가 삭제되거나 실행된 후 약 1시간을 기다려야 합니다.

다음 예시에서는 TASK_ID가 first-try로 설정된 태스크를 만들어 기본 큐에 추가합니다. 태스크 큐의 태스크 이름 지정과 동일한 Cloud Tasks입니다.

gcloud

gcloud CLI는 구성에서 프로젝트와 위치를 추론하여 태스크 이름을 구성합니다.

gcloud tasks create-app-engine-task first-try --queue=default \
--method=GET --relative-uri=

/url/path

클라이언트 라이브러리

클라이언트 라이브러리에서 TASK_ID를 지정하려면 전체 태스크 이름을 지정해야 합니다. 프로젝트 및 위치는 태스크가 추가되는 큐의 프로젝트 및 위치와 일치해야 합니다.

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'default'
# task_name = 'first-try'

parent = client.queue_path(project, location, queue)

task = {
    "name": client.task_path(project, location, queue, task_name),
    "app_engine_http_request": {
        "http_method": tasks.HttpMethod.GET,
        "relative_uri": "/url/path",
    },
}
response = client.create_task(parent=parent, task=task)
print(response)

실패한 태스크 재시도

큐를 만드는 동안 또는 큐를 업데이트하여 큐에서 태스크 재시도 구성을 설정할 수 있습니다. 다음 표에는 태스크 큐 필드와 해당 Cloud Tasks 필드가 나와 있습니다.

태스크 큐 필드	Cloud Tasks 필드
`task_retry_limit`	`max_attempts`
`task_age_limit`	`max_retry_duration`
`min_backoff_seconds`	`min_backoff`
`max_backoff_seconds`	`max_backoff`
`max_doublings`	`max_doublings`

태스크별 재시도 매개변수

태스크 큐에 구성된 태스크별 재시도 매개변수는 Cloud Tasks에서 작동하지만 수정하거나 새 태스크에 설정할 수 없습니다. 태스크별 재시도 매개변수가 있는 태스크의 재시도 매개변수를 변경하려면 원하는 재시도 매개변수가 있는 Cloud Tasks 큐로 태스크를 다시 만듭니다.

다음 예시에서는 다양한 재시도 시나리오를 보여줍니다.

fooqueue에서는 최초 실행 시도 후 최대 이틀 동안 재시도가 최대 7번 이루어집니다. 두 가지 한도를 모두 초과하면 영구적으로 실패합니다.
barqueue에서 App Engine은 최대 백오프에 도달할 때까지 각 재시도 간의 간격을 비례적으로 증가시키면서 태스크를 재시도하고, 최대 간격에서는 무한정 재시도합니다. 따라서 요청 간 간격은 10초, 20초, 30초, ..., 190초, 200초, 200초, ...와 같이 됩니다.
bazqueue에서는 재시도 간격이 10초부터 시작하여 3회 동안 두 배로 증가한 후 비례적으로 증가하고 최대 간격에 도달하면 무한정 재시도합니다. 따라서 요청 간 간격은 10초, 20초, 40초, 80초, 160초, 240초, 300초, 300초, ...와 같이 됩니다.

태스크 큐의 태스크 재시도와 동일한 Cloud Tasks입니다.

gcloud

초 단위 숫자를 지정하는 옵션을 설정할 때 정수 다음에 s를 포함해야 합니다. 예를 들어 200이 아니라 200s입니다.

gcloud tasks queues create fooqueue \
--max-attempts=7 \
--max-retry-duration=172800s  #2*60*60*24 seconds in 2 days

gcloud tasks queues create barqueue \
--min-backoff=10s \
--max-backoff=200s \
--max-doublings=0

gcloud tasks queues create bazqueue \
--min-backoff=10s \
--max-backoff=300s \
--max-doublings=3

클라이언트 라이브러리

from google.protobuf import duration_pb2

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# fooqueue = 'fooqueue'
# barqueue = 'barqueue'
# bazqueue = 'bazqueue'

parent = f"projects/{project}/locations/{location}"

max_retry = duration_pb2.Duration()
max_retry.seconds = 2 * 60 * 60 * 24

foo = {
    "name": client.queue_path(project, location, fooqueue),
    "rate_limits": {"max_dispatches_per_second": 1},
    "retry_config": {"max_attempts": 7, "max_retry_duration": max_retry},
}

min = duration_pb2.Duration()
min.seconds = 10

max = duration_pb2.Duration()
max.seconds = 200

bar = {
    "name": client.queue_path(project, location, barqueue),
    "rate_limits": {"max_dispatches_per_second": 1},
    "retry_config": {"min_backoff": min, "max_backoff": max, "max_doublings": 0},
}

max.seconds = 300
baz = {
    "name": client.queue_path(project, location, bazqueue),
    "rate_limits": {"max_dispatches_per_second": 1},
    "retry_config": {"min_backoff": min, "max_backoff": max, "max_doublings": 3},
}

queues = [foo, bar, baz]
for queue in queues:
    response = client.create_queue(parent=parent, queue=queue)
    print(response)

자세한 내용은 Cloud Tasks 참조인 재시도 매개변수 설정을 참조하세요.

큐에서 태스크 삭제

태스크를 삭제한 후 동일한 이름으로 태스크를 만들려면 queue.yaml 파일을 사용하여 만든 큐에 있었던 경우에는 9일을 기다리고 태스크가 Cloud Tasks를 사용하여 만든 큐에 있었던 경우에는 1시간을 기다려야 합니다.

다음 예시에서는 큐 ID가 queue1인 큐에서 태스크 ID가 foo인 태스크를 삭제합니다. 태스크 큐의 태스크 삭제와 동일한 Cloud Tasks입니다.

gcloud

태스크 프로젝트 및 위치는 gcloud CLI 기본 프로젝트에서 추론됩니다.

gcloud tasks delete foo --queue=queue1

클라이언트 라이브러리

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue1'

task_path = client.task_path(project, location, queue, "foo")
response = client.delete_task(name=task_path)

자세한 내용은 Cloud Tasks 참조인 큐에서 태스크 삭제를 참조하세요.

태스크 삭제

다음 예시에서는 큐 ID가 queue1인 큐에서 모든 태스크를 삭제합니다. 태스크 큐의 태스크 삭제와 동일한 Cloud Tasks입니다.

gcloud

큐 프로젝트 및 위치는 gcloud CLI 기본 프로젝트에서 추론됩니다.

gcloud tasks queues purge 

queue1

클라이언트 라이브러리

client = tasks.CloudTasksClient()

# TODO(developer): Uncomment these lines and replace with your values.
# project = 'my-project-id'
# location = 'us- central1'
# queue = 'queue1'

queue_path = client.queue_path(project, location, queue)
response = client.purge_queue(name=queue_path)

자세한 내용은 Cloud Tasks 참조인 큐에서 모든 태스크 삭제를 참조하세요.

다음 단계

Cloud Tasks 문서
Cloud Tasks 클라이언트 라이브러리
Cloud Tasks REST 참조 개요
Cloud Tasks RPC 참조 개요
튜토리얼은 App Engine 태스크 큐 push 큐에서 Cloud Tasks로 마이그레이션 Codelab을 참조하세요.

push 큐를 Cloud Tasks로 마이그레이션(Python)

Cloud Tasks에서 사용할 수 없는 기능

가격 책정 및 할당량

가격 책정

할당량

마이그레이션하기 전에

pull 큐 마이그레이션

큐 구성 보호

Cloud Tasks API 사용 설정

Cloud Tasks API에 앱 인증

gcloud CLI 다운로드

Cloud 클라이언트 라이브러리 가져오기

Python 2

Python 3

Python 2

Python 3

큐 만들기 및 관리

큐 만들기

큐 이름 재사용

gcloud

클라이언트 라이브러리

큐 처리 속도 설정

gcloud

클라이언트 라이브러리

큐 사용 중지 및 다시 시작

gcloud

클라이언트 라이브러리

큐 삭제

gcloud

클라이언트 라이브러리

태스크 만들기 및 관리

태스크 만들기

gcloud

클라이언트 라이브러리

대상 서비스 지정 및 라우팅

핸들러에 데이터 전달

콘솔

클라이언트 라이브러리

태스크 이름 지정

태스크 이름 재사용

gcloud

클라이언트 라이브러리

실패한 태스크 재시도

태스크별 재시도 매개변수

gcloud

클라이언트 라이브러리

큐에서 태스크 삭제

gcloud

클라이언트 라이브러리

태스크 삭제

gcloud

클라이언트 라이브러리

다음 단계