이 페이지에서는 태스크 큐에서 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 Console을 사용하여 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 요청 할당량에 영향을 줄 수 있습니다.
마이그레이션하기 전에
이 섹션에서는 push 큐를 Cloud Tasks로 마이그레이션하기 전에 수행해야 할 작업에 대해 설명합니다.
pull 큐 마이그레이션
이 가이드를 사용하여 push 큐를 마이그레이션하기 전에 pull 큐 마이그레이션 가이드를 사용하여 pull 큐를 마이그레이션하세요.
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
자바용 클라이언트 라이브러리 가져오기
App Engine 앱에서 자바용 Cloud Tasks 클라이언트 라이브러리를 사용하려면 다음 단계를 따르세요.
pom.xml
파일에 Cloud Tasks 클라이언트 라이브러리 종속 항목을 지정합니다.<dependency> <groupId>com.google.cloud</groupId> <artifactId>google-cloud-tasks</artifactId> <version>1.3.0</version> </dependency>
태스크를 만들고 큐에 추가하는 파일에서 Cloud Tasks 클라이언트 라이브러리 종속 항목을 가져옵니다.
import com.google.cloud.tasks.v2.AppEngineHttpRequest; import com.google.cloud.tasks.v2.CloudTasksClient; import com.google.cloud.tasks.v2.HttpMethod; import com.google.cloud.tasks.v2.QueueName; import com.google.cloud.tasks.v2.Task;
큐 만들기 및 관리
이 섹션에서는 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가 your-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
클라이언트 라이브러리
자세한 내용은 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는
|
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
클라이언트 라이브러리
자세한 내용은 비율 제한 정의를 참조하세요.
큐 사용 중지 및 다시 시작
Cloud Tasks는 태스크 큐에서 사용 중지라는 용어를 사용하는 것과 동일한 방식으로 일시중지라는 용어를 사용합니다. 큐를 일시중지하면 큐가 다시 시작될 때까지 큐의 태스크가 실행되지 않습니다. 하지만 일시중지된 큐에 태스크를 계속 추가할 수 있습니다. Cloud Tasks는 태스크 큐와 동일한 방식으로 다시 시작이라는 용어를 사용합니다.
아래 예시는 큐 ID가 queueName
인 큐를 일시중지합니다. 태스크 큐의 큐 사용 중지와 동일한 Cloud Tasks입니다.
gcloud
gcloud tasks queues pause queueName
클라이언트 라이브러리
자세한 내용은 Cloud Tasks 참조인 큐 일시중지를 확인하세요.
큐 삭제
큐를 삭제한 후 동일한 이름으로 큐를 만들려면 7일이 지나야 합니다. 7일을 기다릴 수 없는 경우 큐에서 모든 태스크를 삭제하고 큐를 다시 구성해 보세요.
아래 예시에서는 큐 ID가 foo
인 큐를 삭제합니다. 태스크 큐의 큐 삭제와 동일한 Cloud Tasks입니다.
gcloud
gcloud tasks queues delete foo
클라이언트 라이브러리
자세한 내용은 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 를 지정합니다. 설정하지 않으면 기본 서비스, 버전, 인스턴스가 사용됩니다. |
다음 예시에서는 기본 App Engine 서비스에서 /worker
핸들러로 라우팅하는 태스크를 만듭니다. 태스크 큐의 태스크 만들기와 동일한 Cloud Tasks입니다.
gcloud
gcloud tasks create-app-engine-task --queue=default \ --method=POST --relative-uri=/worker?key=key
클라이언트 라이브러리
자세한 내용은 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입니다. 헤더에 지정하여 본문 콘텐츠 유형을 설정할 수 있습니다.
다음 예시에서는 두 가지 방법으로 /worker
핸들러에 키를 전달합니다. 태스크 큐의 핸들러에 데이터 전달과 동일한 Cloud Tasks입니다.
console
gcloud tasks create-app-engine-task --queue=default --method=GET \ --relative-uri=/worker?key=blue --routing=service:worker
gcloud tasks create-app-engine-task --queue=default --method=POST \ --relative-uri=/worker --routing=service:worker \ --body-content="{'key': 'blue'}"
클라이언트 라이브러리
태스크 이름 지정
태스크 이름 지정은 선택사항입니다. 태스크 이름을 지정하지 않으면 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=/worker
클라이언트 라이브러리
클라이언트 라이브러리에서 TASK_ID
를 지정하려면 전체 태스크 이름을 지정해야 합니다. 프로젝트 및 위치는 태스크가 추가되는 큐의 프로젝트 및 위치와 일치해야 합니다.
실패한 태스크 재시도
큐를 만드는 동안 또는 큐를 업데이트하여 큐에서 태스크 재시도 구성을 설정할 수 있습니다. 아래 표에는 태스크 큐 필드와 해당하는 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
클라이언트 라이브러리
자세한 내용은 Cloud Tasks 참조인 재시도 매개변수 설정을 참조하세요.
큐에서 태스크 삭제
태스크를 삭제한 후 동일한 이름으로 태스크를 만들려면 queue.yaml
파일을 사용하여 만든 큐에 있었던 경우에는 9일을 기다리고 태스크가 Cloud Tasks를 사용하여 만든 큐에 있었던 경우에는 1시간을 기다려야 합니다.
다음 예시에서는 큐 ID가 queue1
인 큐에서 태스크 ID가 foo
인 태스크를 삭제합니다. 태스크 큐의 태스크 삭제와 동일한 Cloud Tasks입니다.
gcloud
태스크 프로젝트 및 위치는 gcloud CLI 기본 프로젝트에서 추론됩니다.
gcloud tasks delete foo --queue=queue1
클라이언트 라이브러리
자세한 내용은 Cloud Tasks 참조인 큐에서 태스크 삭제를 참조하세요.
태스크 삭제
다음 예시에서는 큐 ID가 foo
인 큐에서 모든 태스크를 삭제합니다. 태스크 큐의 태스크 삭제와 동일한 Cloud Tasks입니다.
gcloud
큐 프로젝트 및 위치는 gcloud CLI 기본 프로젝트에서 추론됩니다.
gcloud tasks queues purge foo
클라이언트 라이브러리
자세한 내용은 Cloud Tasks 참조인 큐에서 모든 태스크 삭제를 참조하세요.
자바 8 Cloud Tasks 예시
다음 예시는 Cloud Tasks로 큐를 만들고 큐에 태스크를 추가하기 위한 기본 설정입니다. 여기서는 개발자가 클라이언트 라이브러리 가져오기 섹션의 설명대로 Cloud Tasks 종속 항목을 지정하기 위해 pom.xml
파일을 만들었다고 가정합니다. 태스크 큐의 자바 8 태스크 큐 예시와 동일한 Cloud Tasks입니다.
태스크를 만들고 큐에 추가하는 파일은 태스크를 만들어 자바용 Cloud Tasks 클라이언트 라이브러리를 사용하여 기본 큐에 추가합니다.
작업자를 정의하는 파일이 태스크를 처리합니다.
다음 단계
- Cloud Tasks 문서
- Cloud Tasks 자바용 클라이언트 라이브러리
- Cloud Tasks REST 참조 개요
- Cloud Tasks RPC 참조 개요