Cloud Tasks で HTTP リクエストをバッファリングする

※この投稿は米国時間 2023 年 5 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Tasks は、App Engine や任意の HTTP エンドポイントに対する大量のタスクの実行、ディスパッチ、非同期配信を管理するフルマネージド サービスです。Cloud Tasks キューを使用すれば、サービス間でリクエストをバッファリングし、より堅牢なサービス内通信を行うこともできます。  

Cloud Tasks には、新しいキューレベル ルーティング構成と BufferTask API という 2 つの新機能が導入されています。これらを組み合わせることで、Tasks クライアント ライブラリを必要とすることなく HTTP タスクの作成とキューへの追加が可能になります。

Cloud Tasks の要約

新機能について説明する前に、少し復習をしましょう。Cloud Tasks では、HTTP リクエストなどの独立したタスクがキューに追加され、App Engine アプリや任意の HTTP エンドポイントが非同期に処理するまで保持されます。

Cloud Tasks には、次のような多くの復元機能が備わっています。

• タスクの重複除去: 複数回追加されたタスクが 1 回でディスパッチされます。

• 配信保証: タスクは少なくとも 1 回配信されることが保証されており、通常は 1 回だけ配信されます。

• レートと再試行の制御: タスクがディスパッチされるレート、試行の最大回数、試行間の最小の待機時間を設定して実行を制御できます。

• 将来のスケジューリング: タスクが実行される時刻を制御します。

HTTP ターゲット タスクとは

これは素晴らしいことですが、注意点があります。呼び出し元は、Cloud Tasks クライアント ライブラリを使用して HTTP リクエストをタスクでラップし、それをキューに追加する必要があります。例として、次の C# サンプルは、HTTP リクエストを Task と TaskRequest でラップしてからキューに追加する方法を示しています。

これでは、呼び出し元にタスクを作成する負担がかかるとともに、HTTP リクエストをタスクでラップすることにより、呼び出し元と Tasks クライアント ライブラリとの間に不要な依存関係が生じてしまいます。また、キューの恩恵を受けるのはターゲット サービスであるため、タスクを作成する負担は、呼び出し元ではなく、ターゲット サービスにあるべきです。新しいキューレベル ルーティング構成と BufferTask API は、こうした問題に対処し、より簡単なタスクの作成方法を提供します。では、詳しく見ていきましょう。

キューレベル ルーティング構成とは

キューレベルのタスク ルーティング構成は、新規と保留中のすべてのタスクのキュー全体について、HTTP タスク ルーティングを変更します。これにより、HTTP ターゲットをタスクレベルで設定する必要がなくなり、より簡単にタスクを作成できるようになります。サービス プロバイダは、キュー内のすべてのタスクのターゲットを設定できる立場になり、これまで以上に制御がしやすくなります（元のバックエンドが利用できない場合にトラフィックを別のバックエンドにルーティングするなど）。

次のように、ルーティング構成を使用してキューを作成し、ターゲット URI に追加またはオーバーライドします。

これで、呼び出し元がターゲット URI を指定しているかどうかに関係なく、キューレベルで指定された URI にキューがタスクをリダイレクトするようになります。

キューレベル ルーティング構成は、ターゲット サービスがダウンした場合など、キューに追加されている保留中のすべてのタスクについて HTTP URI を変更し、別のサービスにすばやくルーティングする必要がある場合にも役立ちます。

ここで、「それが HTTP タスクの簡易化にどのように役立つのか」と疑問に思われるかもしれません。この良いご指摘とともに、次のトピックである新しい BufferTask API に進みましょう。

BufferTask API とは

BufferTask は、呼び出し元がタスク構成（HTTP URL、ヘッダー、認証）を提供することなく HTTP タスクを作成できる新しい API です。呼び出し元は通常の HTTP リクエストを Buffer API に送信するだけでよく、Buffer API がキューレベル ルーティング構成のデフォルトを使用して HTTP リクエストを HTTP タスクでラップします。

BufferTask API を使用することで、サービスとのインテグレーションが簡単になります。また、呼び出し元側でコードを変更することなく、Cloud Tasks をサービスの前にデプロイできるようになります。BufferTask API に送信された任意の HTTP リクエストがタスクとしてラップされ、キューレベルで設定された宛先に配信されます。

BufferTask API を使用するには、キューにターゲット URI 構成が設定されている必要があります。すなわち、キューレベル ルーティング構成機能は、BufferTask API を使用するための前提条件になります。

クライアント ライブラリを使用した HTTP タスクの作成もシンプルになります。たとえば、次の C# サンプルでは、HTTP GET リクエストが BufferTask API に直接送信されます。リクエストは Task と TaskRequest でラップされないため、Cloud Tasks のクライアント ライブラリはまったく必要ありません。

Pub/Sub と Cloud Run との間のバッファとしての Cloud Tasks

サービス間のバッファとしての Cloud Tasks の具体例や、新しいキューレベル ルーティング構成と BufferTask API 機能がどのように役立つかを見てみましょう。

Eventarc が管理する Pub/Sub トピックにメッセージをパブリッシュするアプリケーションがあり、Eventarc がそのメッセージを Cloud Run サービスにルーティングするとします。

そして、アプリが生成するメッセージが多すぎるため、レート制限を適用するとします。レート制限を適用すると、Cloud Run サービスの過剰な自動スケーリングが防止されます。この場合、Cloud Tasks キューをバッファとして統合することで負荷を調整できます。

レート制限を適用し、サービスの過負荷を避けるには、次の手順を行います。

1. ルーティング構成と URI オーバーライドを使用して Cloud Tasks キューを作成し、Cloud Run サービスを参照するようにします。

2. 1 秒に 1 リクエストなど、キューに適用するレート制限を設定します。

3. Pub/Sub サブスクリプション エンドポイントを変更して、BufferTask API を参照するようにします。

必要な操作は以上です。これで、パイプラインの途中のキューを設けて、コードや複雑な構成を使用せずに、設定したレートでサービスへのメッセージを調整できるようになります。この設定方法の詳細については、GitHub のサンプルをご覧ください。このパターンは、HTTP リクエストを BufferTask API に送信でき、Cloud Tasks から HTTP リクエストを受信できる 2 つのサービスに適用できます。

これで、Cloud Tasks とその新機能に関する説明は終わりです。ご不明な点やフィードバックがございましたら、Twitter で @meteatamel までお気軽にお問い合わせください。詳細については、以下をご覧ください。

• ブログ投稿のサンプル: GitHub の cloudtasks-samples リポジトリ

• 実践的な Codelab: Codelab「Cloud Tasks で HTTP リクエストをバッファリングする」