push キューの Cloud Tasks への移行(Go)

最新の App Engine サービス SDK バージョンにアップグレードする前に、 移行の概要を確認してください。

Cloud Tasks クライアント ライブラリにアップグレードする

レガシー バンドル サービスを完全に移行する場合は、Cloud Tasks API を直接使用するようにコードを移行できます。これには、アプリケーション コードのリファクタリングが必要です。

Cloud Tasks は、Task Queues RPC API でアクセスするのと同じサービスにアクセスします。つまり、既存の push キューや push タスクを再作成する必要はありません。ただし、Cloud Tasks API を使用するには、push キューまたは push タスクを作成、操作するコードを移行する必要があります。

push キューおよび push タスクは、Cloud Tasks REST と RPC API、Cloud Tasks クライアント ライブラリ、Google Cloud CLI、Google Cloud コンソールを使用して、作成および操作できます。このページでは、gcloud CLI と Cloud Tasks クライアント ライブラリを使用した場合の例を示します。

Cloud Tasks で利用できない機能

Cloud Tasks クライアント ライブラリの移行では、Cloud Tasks で次の機能は使用できません。

  • Datastore トランザクションの中でタスクをキューに追加する
  • ワーカー サービスの代わりに遅延タスク ライブラリを使用する
  • マルチテナント アプリケーションでタスクを扱う
  • ローカル開発サーバーでのシミュレーション
  • タスクを非同期で追加する

または、最新の SDK にアップグレードすると、遅延タスク、名前空間、ローカル シミュレーションなどの 機能がサポート されます。

料金と割り当て

push キューを Cloud Tasks に移行すると、アプリの料金と割り当てに影響する場合があります。

料金

移行する前に、Cloud Tasks の料金 を確認して月額料金を見積もってください。

タスクキューと同様に、Cloud Tasks push ターゲットを使用して App Engine アプリにリクエストを送信するのは無料です。ただし、タスクキューとは異なり、Cloud Tasks では、タスクの作成、削除、管理などのオペレーションに対して課金されます。そのため、無料の App Engine タスクキューと比較して、月額料金が高くなる可能性があります。

割り当て

Cloud Tasks リクエストも、App Engine リクエストの割り当てにカウントされます。

タスクキューと同様に、Cloud Tasks には サービス固有の割り当てがあります。Cloud Tasks に移行すると、割り当てが変更される可能性があります。

始める前に

以降のセクションでは、push キューを Cloud Tasks に移行する前の設定手順について説明します。

pull キューを移行する

開始する前に、 pull キューを移行 してから、このガイドの手順に沿って push キューを移行してください。push キューの移行後に pull キューを移行することは、queue.yaml ファイルの必要な使用が Cloud Tasks で予期しない動作を引き起こす可能性があるため、おすすめしません。

キュー構成を保護する

クラウドタスクへの移行プロセスを開始すると、queue.yaml ファイルを変更する際に予期しない動作が発生する場合があるためおすすめしません。キュー構成を queue.yaml ファイルによる変更から保護するには、次の手順を行います。

  1. 今後のデプロイで queue.yaml ファイルを省略するように gcloud CLI を構成します。

    queue.yaml ファイルを .gcloudignore ファイルに追加します。.gcloudignore ファイルがすでに存在しているか確認するには、ターミナルでデバイスの最上位レベルのディレクトリから次のコマンドを実行します。ファイルが存在する場合、このコマンドでファイル名が出力されます。

    ls -a | grep .gcloudignore

    .gcloudignore ファイルの詳細については、.gcloudignore リファレンスをご覧ください。

  2. queue.yaml ファイルの権限を制限します。

    キュー構成の保護に関するガイドに記載されているおすすめの方法に従ってください。

  3. クラウドタスクと queue.yaml ファイルについて学習する(省略可)。

    Cloud Tasks API を使用してキュー構成を管理する場合、queue.yaml ファイルをデプロイすると、Cloud Tasks によって設定された構成がオーバーライドされ、予期しない動作が発生する可能性があります。詳細については、 キュー管理と queue.yaml の使用をご覧ください。

Cloud Tasks API に対してアプリを認証する

Cloud Tasks API に対してアプリを認証する必要があります。このセクションでは、2 つの異なるユースケースの認証について説明します。

アプリをローカルで開発またはテストするには、サービス アカウントを使用することをおすすめします。サービス アカウントを設定してアプリに接続する手順については、サービス アカウントの認証情報を手動で取得して提供するをご覧ください。

アプリを App Engine にデプロイする場合、新たに認証を行う必要はありません。アプリケーションのデフォルト認証情報(ADC)では、App Engine アプリの認証の詳細が推測されます。

Cloud クライアント ライブラリをインポートする

App Engine アプリで Cloud Tasks クライアント ライブラリを使用するには、次の手順を実施します。

  1. Cloud Tasks クライアント ライブラリの依存関係をダウンロードします。

    go get cloud.google.com/go/cloudtasks/apiv2
  2. Cloud Tasks クライアント ライブラリの依存関係を、タスクの作成とキューへの追加で使用するファイルにインポートします。

    import (
      "context"
      "fmt"
    
      cloudtasks "cloud.google.com/go/cloudtasks/apiv2"
      taskspb "cloud.google.com/go/cloudtasks/apiv2/cloudtaskspb"
    )

キューを作成して管理する

このセクションでは、Cloud Tasks API を使用してキューを作成および管理する方法について説明します。

Cloud Tasks では、キューの作成や管理に queue.yaml ファイルを使用しません。その代わりに、Cloud Tasks API が使用されます。 queue.yaml ファイルと Cloud Tasks API の両方の使用はおすすめしませんが、アプリによってはタスクキューから Cloud Tasks への移行が避けられない場合があります。ベスト プラクティスについては、キュー管理と queue.yaml の使用をご覧ください。

キューの作成

アプリでプログラム的にキューが作成される場合、またはコマンドラインから追加のキューを作成する場合は、このセクションをお読みください。

クラウドタスクのキューの名前は projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID という形式に従います。キュー名の LOCATION_ID の部分は、 Google Cloud リージョンに対応しています。キュー名の QUEUE_ID の部分は、Task Queues キューの name フィールドと同じになります。キュー名は、プロジェクト、リージョン、およびユーザーが指定した QUEUE_ID に基づいて、キューが作成される際に生成されます。

一般に、キューのロケーション(つまりリージョン)はアプリのリージョンと同じである必要があります。このルールに対する 2 つの例外は、europe-west リージョンを使用するアプリと us-central リージョンを使用するアプリの場合です。クラウドタスクのこれらのリージョンは、europe-west1 および us-central1 とそれぞれ呼ばれます。

キューを作成する際にオプションのキュー構成を指定できるだけでなく、作成の後にキューを更新することもできます。

既存のキューを再作成する必要はありません。その代わりに、このガイドの関連部分を読んで、既存のキューを操作するコードを移行してください。

キュー名を再利用する

同じプロジェクトとロケーション(つまりリージョン)に同じキュー ID を持つキューを作成する場合、キューを削除してから 7 日間待つ必要があります。

次の例では、クラウドタスクを使用して 2 つのキューを作成しています。最初のキューのキュー ID は queue-blue です。すべてのタスクが 5/s のレートでバージョン v2 のサービス task-module に送信されるように構成されています。2 番目のキューのキュー ID は queue-red です。1/s のレートでタスクがディスパッチされます。どちらも、プロジェクト ID が のプロジェクトのロケーション us-central1 に作成されます。 これは、タスクキューにおいてキューを作成することと同等の 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 キューの作成をご覧ください。

キューの処理速度を設定する

次の表に、Task Queues と Cloud Tasks で異なるフィールドを示します。

Task Queues のフィールド Cloud Tasks のフィールド 説明
rate max_dispatches_per_second キューからタスクがディスパッチされる最大レート。
max_concurrent_requests max_concurrent_dispatches キューからディスパッチできる同時タスクの最大数
bucket_size max_burst_size

クラウドタスクでは、max_dispatches_per_second の値に基づいてキュー内のタスクの処理速度を制限する取得専用の max_burst_size プロパティが計算されます。このフィールドを使用すると、キューのレートが高くなり、タスクがキューに登録された直後に処理が開始されますが、短時間で多くのタスクがキューに登録された場合にリソースの使用が制限されます。

`queue.yaml` ファイルを使用して作成または更新された App Engine キューの場合、max_burst_size は最初は bucket_size と同じです。ただし、クラウドタスクの インターフェースを使用してキューが update コマンドに渡されると、max_dispatches_per_second が 更新されたかどうかに関係なく、 max_dispatches_per_second の値に基づいて max_burst_size がリセットされます。

total_storage_limit Cloud Tasks では非推奨 Cloud Tasks は、カスタム ストレージ上限の設定をサポートしていません

キューの作成やキューの更新の際に、キューの処理速度を設定できます。以下の例では、Cloud Tasks を使用して、すでに作成された queue-blue という名前のキューの処理速度を設定しています。queue-bluequeue.yaml を使用して作成または構成された場合、以下の例では、20max_dispatches_per_second の値に基づいて max_burst_size がリセットされます。この Cloud Tasks は、Task Queues でキュー処理率を設定する場合と同等です。

gcloud

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

詳細については、レート上限の定義をご覧ください。

キューを無効にして再開する

Cloud Tasks では、タスク キューの「無効」という用語と同じ意味で、「一時停止」という用語が使用されます。キューを一時停止すると、キューが再開されるまで、キュー内のタスクの実行が停止します。ただし、一時停止中のキューに対してもタスクを追加し続けることができます。Cloud Tasks では、タスクキューの場合と同じ意味で、「再開」 という用語が使用されます。

次の例では、queue1 というキュー ID のキューを一時停止しています。これは、Task Queues でキューを無効にするに相当する Cloud Tasks です。

gcloud

gcloud tasks queues pause queue1

詳細については、Cloud Tasks リファレンスの キューの一時停止をご覧ください。

キューを削除する

キューを削除した場合、同じ名前のキューを作成するまで 7 日間待つ必要があります。7 日間待てない場合は、キューからすべてのタスクを削除し、キューを再構成することを検討してください。

次の例では、キュー ID が queue1 のキューを削除しています。これは、Task Queues でキューを削除するに相当する Cloud Tasks です。

gcloud

gcloud tasks queues delete queue1

Cloud Tasks リファレンスの キューの削除をご覧ください。

タスクを作成して管理する

このセクションでは、Cloud Tasks API を使用してタスクを作成および管理する方法について説明します。

タスクを作成する

次の表に、Task Queues と Cloud Tasks で異なるフィールドを示します。

Task Queues のフィールド Cloud Tasks のフィールド 説明
なし app_engine_http_request App Engine サービスを対象とするリクエストを作成します。これらのタスクは App Engine タスクと呼ばれます。
method http_method リクエスト メソッド(POST など)を指定します。
url relative_uri タスクハンドラを指定します。最後の文字の違いに注意してください。「l」(uniform resource locator)ではなく「i」(uniform resource identifier)です。
target app_engine_routing 省略可。App Engine タスクに対して、App Engine の serviceversioninstance を指定します。設定されていない場合は、デフォルトのサービス、バージョン、およびインスタンスが使用されます。

次の例では、デフォルトの App Engine サービスでハンドラ /update_counter にルーティングするタスクを作成します。これは、タスクキューにおいて タスクを作成すること と同等の Cloud Tasks です。

gcloud

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

詳細については、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 を使用してハンドラにデータを渡す方法は 2 つあります。相対 URI でデータをクエリ パラメータとして渡す方法と、HTTP メソッドの POST または PUT を使用してリクエスト本文でデータを渡す方法があります。

クラウドタスクでは、タスクキューで「ペイロード」という用語を使用するのと同じ意味で、「本文」という用語を使用します。クラウドタスクでは、本文のコンテンツ タイプのデフォルトはプレーン テキストではなく、オクテット ストリームです。本文コンテンツ タイプを設定するには、ヘッダーで指定します。

次の例では、2 つの異なる方法で、ハンドラ /update_counter にキーを渡しています。これは、 タスクキューで ハンドラに データを渡すことに相当する Cloud Tasks です。

gcloud

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'}"

タスク名を指定する

タスク名の指定は省略可です。タスク名を指定しない場合、Cloud Tasks によってタスク ID が生成され、タスクを作成する際に指定したキューに基づいてプロジェクトとロケーション(つまりリージョン)を推定することによりタスク名が作成されます。

タスク名の形式は projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID/tasks/TASK_ID です。タスク名の TASK_ID の部分が Task Queues タスクの name フィールドと同等になります。

タスク名を再利用する

タスク名を再利用する際には、待機する必要があります。待機する時間は、タスクをディスパッチするキューがクラウドタスクまたはタスクキューのどちらで作成されたかによって異なります。

タスクキューを使用して作成されたキュー(デフォルト キューを含む)のタスクの場合、元のタスクが削除または実行された後、約 9 日間待つ必要があります。クラウドタスクを使用して作成されたキューのタスクの場合は、元のタスクが削除または実行されてから約 1 時間待ちます。

次の例では、TASK_IDfirst-try に設定されたタスクを作成し、デフォルトのキューに追加します。クラウドタスクにおいてこれは、タスクキューの名前付けタスクに相当します。

gcloud

gcloud CLI では、構成からプロジェクトとロケーションを推測してタスク名が作成されます。

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

失敗したタスクを再試行する

タスクの再試行の設定は、キューの作成中に行うか、キューの更新によって設定できます。Task Queues のフィールドと、それぞれに対応する Cloud Tasks のフィールドを次の表に示します。

Task Queues のフィールド 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 でも機能しますが、編集や新規タスクの設定はできません。タスク固有の再試行パラメータを持つタスクの再試行パラメータを変更するには、目的の再試行パラメータを持つクラウド タスクキューを使用してタスクを再作成します。

次の例に、さまざまな再試行のシナリオを示します。

  • fooqueue では、タスクは最初の試行から 2 日間を期限とし、7 回を上限として再試行されます。両方の上限に達すると、タスクは完全に失敗し、再試行されなくなります。
  • barqueue では、App Engine は、再試行の回数に応じて間隔を長くしながらタスクを再試行し、最大バックオフに達すると、最大間隔で無限に再試行します(リクエストの間隔は 10 秒、20 秒、30 秒、...、190 秒、200 秒、200 秒、... となります)。
  • bazqueue では、再試行間隔は 10 秒から開始し、3 回 2 倍ずつ間隔を長くして、その後は直線的に間隔が広げられます。最終的には、最大間隔で無限に再試行します(リクエストの間隔は 10 秒、20 秒、40 秒、80 秒、160 秒、240 秒、300 秒、300 秒、... となります)。

クラウドタスクにおいてこれは、タスクキューの再試行タスクに相当します。

gcloud

秒数を指定するオプションを設定する場合は、整数の後に s を指定します(たとえば、200s200 など)。

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 のタスクを削除しています。これは、タスクキューにおいてタスクを削除するのと同等のクラウドタスクです。

gcloud

タスクのプロジェクトとロケーションは、gcloud CLI のデフォルト プロジェクトから推定されます。

gcloud tasks delete foo --queue=queue1

詳細については、Cloud Tasks リファレンスの キューからタスクを削除するをご覧ください。

タスクを完全に削除する

次の例では、キュー ID が queue1 のキューからすべてのタスクを完全に削除しています。クラウドタスクにおいてこれは、タスクキューのタスクを完全に削除するに相当します。

gcloud

キューのプロジェクトとロケーションは、gcloud CLI のデフォルト プロジェクトから推定されます。

gcloud tasks queues purge queue1

詳細については、Cloud Tasks リファレンスの キューからすべてのタスクを完全に削除するをご覧ください。

次のステップ