queue.yaml을 사용하여 큐 관리

queue.yaml 파일을 사용하여 큐를 관리할 수 있지만 큐 관리 메서드를 함께 사용하면 예기치 않은 결과가 발생할 수 있습니다. 이 가이드에서는 이러한 메서드를 함께 사용할 때의 위험을 설명하고 일반적인 구성 문제를 해결하는 방법을 보여줍니다.

Cloud Tasks API는 App Engine 작업 큐 서비스에 독립적인 인터페이스를 제공합니다. 이 인터페이스를 사용하면 Google Cloud 콘솔 또는 Google Cloud CLI를 통해 큐를 관리할 수 있습니다. Cloud Tasks API로 만든 큐는 App Engine SDK에서 액세스할 수 있으며(플랫폼별 API, 독립형 도구, 런타임 파일 모음) App Engine SDK로 만든 큐는 Cloud Tasks API에서 액세스할 수 있습니다.

호환성을 유지하기 위해 App Engine SDK의 구성 파일인 queue.yaml을 사용하여 Cloud Tasks API의 큐를 만들고 구성할 수 있습니다. 하지만 이 파일과 Cloud Tasks API를 사용하여 큐를 관리하면 이 가이드에 자세히 설명된 문제가 발생할 수 있습니다.

시작하기 전에

Cloud Tasks 또는 App Engine을 처음 사용하는 경우 Cloud Tasks API만 사용하여 큐를 관리하고 queue.yaml은 사용하지 않도록 합니다. Cloud Tasks 큐 관리 메서드를 사용하면 큐를 생성, 업데이트, 삭제하는 데 더 많은 옵션을 사용할 수 있습니다.

기존 queue.yaml 사용자라면 큐 관리 메서드를 함께 사용할 때의 위험을 알고 있는 경우에만 Cloud Tasks 큐 관리 메서드로 전환하는 것이 좋습니다.

큐 관리 메서드 적용

큐 관리 메서드를 함께 사용하는 것을 방지하려면 큐를 생성, 업데이트, 삭제하는 웹 앱 또는 명령줄 도구를 만들면 됩니다. 해당 도구가 Cloud Tasks 큐 관리 메서드 또는 queue.yaml 중 어떤 것을 사용하는지는 사용자가 신경 쓸 필요 없는 구현 세부정보입니다. 도구 사용을 적용하면 메서드가 실수로 함께 사용되는 것을 방지할 수 있습니다. 도구에 Cloud Tasks 큐 관리자 Identity and Access Management (IAM) 역할을 부여하고 사용자 인증을 요구합니다. 액세스 관리에 대해 자세히 알아보려면 큐 구성 보호를 참조하세요.

큐 구성 지연

큐 구성 변경사항이 적용되는 데 몇 분 정도 걸릴 수 있습니다. 예를 들어 CreateQueue 또는 UpdateQueue를 호출한 후 해당 큐에서 CreateTask를 호출하려면 몇 분이 지나야 합니다.

App Engine default

default라는 App Engine 큐는 App Engine SDK 및 Cloud Tasks API에서 특별하게 처리됩니다.

default 큐는 언제 생성되나요?

default 큐가 없는 경우 다음과 같은 상황에서 생성됩니다.

  • App Engine SDK를 사용하여 default 큐 에 태스크를 처음 추가하는 경우
  • queue.yaml 파일을 지정하는 default 큐가 업로드되는 경우
  • CreateQueue 또는 UpdateQueue가 호출되어 default 큐를 만드는 경우
Cloud Tasks는 어떤 제한사항을 적용하나요?

App Engine과의 호환성을 유지하기 위해 Cloud Tasks는 default 큐와 관련하여 다음과 같은 제한사항을 적용합니다.

  • Cloud Tasks API는 default 큐 또는 그 외 모든 큐를 자동으로 만들지 않습니다.
  • default라는 큐가 생성되면 큐에서 App Engine 태스크를 사용해야 합니다.
  • default 큐에 GetQueue를 호출하면 큐가 아직 존재하지 않는 경우 not found 오류가 반환됩니다.
  • default 큐는 생성될 때까지 ListQueues 출력에 표시되지 않습니다.
  • default 큐 구성을 UpdateQueue 호출을 사용하여 수정할 수 있습니다.
  • 생성된 후에는 default 큐를 삭제할 수 없습니다.

큐 관리 메서드를 함께 사용할 때의 위험

기본 서비스의 경우 queue.yaml 파일 사용이 최종적입니다. 프로젝트의 생성 방법에 관계없이 프로젝트에서 기존 큐를 생략하는 queue.yaml 파일을 업로드하면 큐가 사용 중지되거나 일시중지 됩니다. 예를 들어 Cloud Tasks API를 사용하여 CreateQueue 또는 UpdateQueue를 호출한 다음 이러한 큐를 생략하는 queue.yaml 파일을 업로드하면 큐가 사용 중지됩니다. 그러면 사용 중지된 큐를 다시 시작해야 합니다.

큐 관리 메서드를 함께 사용하면 예기치 않은 동작이 발생할 수 있습니다. 예를 들어 다음 시나리오를 고려해 보세요.

시나리오 1

CreateQueue를 호출하여 cloud-tasks-queue라는 큐를 만든 다음 다음 콘텐츠가 포함된 queue.yaml 파일을 업로드합니다.

queue:
- name: queue-yaml-queue

그러면 다음과 같은 큐 상태가 됩니다.

  • cloud-tasks-queue라는 큐와 이전에 있던 그 외 다른 큐는 DISABLED 상태입니다.
  • queue-yaml-queue라는 큐는 RUNNING 상태입니다.

시나리오 2

Cloud Tasks API를 사용하여 큐를 사용 중지했지만 나중에 업로드된 queue.yaml 파일에 표시됩니다. 큐가 다시 시작됩니다.

시나리오 3

DeleteQueue 메서드로 큐를 삭제했지만 나중에 queue.yaml 파일에 표시됩니다. 삭제 후 며칠 동안 큐 이름을 재사용할 수 없으므로 queue.yaml 업로드가 실패할 수 있습니다.

감사 로그를 사용하여 디버그

프로젝트의 관리자 활동 감사 로그를 검사하여 큐 생성, 업데이트, 삭제를 포함한 큐 구성 변경 내역을 검색할 수 있습니다.

예를 들어 queue.yaml 업로드로 기존 큐가 사용 중지되는 경우 다음 명령어를 실행하여 Disabled queue QUEUE_NAME 로그 메시지를 com.google.appengine.legacy.queue_updated 메서드를 통해 반환할 수 있습니다.

gcloud logging read \
  'protoPayload.methodName=
   (com.google.appengine.legacy.queue_created OR
    com.google.appengine.legacy.queue_updated OR
    google.cloud.tasks.v2.CloudTasks.CreateQueue OR
    google.cloud.tasks.v2.CloudTasks.UpdateQueue OR
    google.cloud.tasks.v2.CloudTasks.DeleteQueue)'

자세한 내용은 로그 항목 읽기를 참조하세요.

queue.yaml 업로드로 사용 중지된 큐 다시 시작

큐 관리 메서드를 함께 사용하는 경우 queue.yaml 파일을 업로드하면 Cloud Tasks API를 통해 만들어진 큐가 우발적으로 사용 중지될 수 있습니다. 큐를 다시 시작하려면 큐에서 ResumeQueue를 호출하거나 queue.yaml에 추가하고 업로드하면 됩니다.

이전에 커스텀 처리 ratequeue.yaml 구성에서 설정한 경우 ResumeQueue는 큐를 기본 rate로 재설정합니다. 이는 응답의 maxDispatchesPerSecond 필드에 반영됩니다.ResumeQueue

할당량 문제 해결

queue.yaml을 사용하여 큐를 만드는 경우 프로젝트에는 만들 수 있는 최대 큐 수에 대한 기본 할당량이 있습니다. Cloud Tasks API를 사용하여 만든 큐에도 기본 할당량이 있습니다. 다른 경우와 마찬가지로 queue.yaml과 Cloud Tasks API 메서드를 함께 사용하면 예기치 않은 결과가 생길 수 있습니다.

예를 들어 queue.yaml을 사용하여 큐를 만든 다음 할당량 증가를 받은 경우 Cloud Tasks API를 사용하여 추가 큐를 만들면 할당량 초과 오류가 발생할 수 있습니다. 이 문제를 해결하려면 콘솔을 Google Cloud 사용하여 할당량을 관리하면 됩니다. 자세한 내용은 콘솔을 사용하여 할당량 관리를 참조하세요.

다음 단계