Google Apps ScriptとCloud Tasksを組み合わせてAPIレートリミットを制御しながら1クリックで安定運用する

ツール導入前の課題

あるGASを使ったシステム内で外部 API のレートリミットを守りながら大量のリクエストを安全に処理したく、Cloud Tasks を導入しました。
元々のシステムのフローは「スプレッドシート→ Google Apps Script（以下 GAS） → Cloud Run（生成処理） → GAS → スプレッドシート（結果書き込み）」という構成でした。 このシステムには2つの制限がありました。1つ目は GAS 側の仕様で、1実行あたりのタイムアウト制限があるため、長時間の処理が実行できません。2つ目は呼び出し先 API のレートリミットで、リクエストが集中すると制限に引っかかり実行できません。 さらに、非エンジニアでも使えるように、スプレッドシートのボタンを1クリックすれば処理が走る構成にするという要望がありました。レートリミットに達した場合でも操作を弾くのではなく、自動的に上限内で処理が流れてほしい、という点が重要でした。 これらを踏まえて作成したシステムのフローは「スプレッドシート → GAS → Cloud Tasks（キュー） → Cloud Run（生成処理） → スプレッドシート（結果書き込み）」という構成です。

どのような状態を目指していたか

そのため、外部 API への大量リクエストを安全かつ効率的に処理できる構成を目指していました。

• Pub/Sub

同時実行数を調整できるかどうかを重視しました。API 側のレートリミットを守りつつ、処理待ちが積み上がりすぎない運用にしたかったためです。

キュー単位で同時実行数や配信レートを直接設定できる点が決め手でした。
Pub/Sub でも近い制御はできますが、Cloud Tasks は max_concurrent_dispatches でキューごとの同時実行数を直感的に設定でき、dispatchDeadline（タスクのタイムアウト上限）も最大 30 分まで対応しています。スプレッドシート起点の複数リクエストでも、受け側に過負荷をかけずに処理できます。

導入前は、リクエストが集中すると外部 API のレートリミットに引っかかり、手動での再実行が必要なケースがありました。

Cloud Tasks を導入したことで以下が変わりました。

• スプレッドシートのボタン1クリックでリクエストがキューで制御されながら流れるようになり、安定稼働するようになりました
• Cloud Tasks のリトライ制御により、タイムアウトや API エラーが起きても自動でリトライされるため、継続的に処理できる状態を保てています

Cloud Tasks 自体の機能というより、実行主体と権限の整理に時間がかかりました。

最初に発生したのはタスク作成時の 403 です。当初 GAS 実行ユーザーに Queue Adminを付与していました。ですが、このロールはキュー管理用でタスク追加権限がないため、正しくは Cloud Tasks Enqueuer が必要でした。

その後も 403 が続きました。Cloud Tasks が Cloud Run を呼び出す際は、GAS 実行ユーザーではなく専用のサービスアカウントが使われます。GAS 実行ユーザーがそのサービスアカウントに成り代わる権限（Service Account User）を持っていなかったことが原因でした。

最終的な権限構成は以下のとおりです。

• GAS 実行ユーザー
  • キューに対して: Cloud Tasks Enqueuer
  • サービスアカウントに対して: Service Account User
• Cloud Tasks に紐づくサービスアカウント
  • Cloud Run に対して: Cloud Run Invoker

どのアイデンティティにどのロールが必要かの整理に手間取りましたが、専用サービスアカウントを用意して役割を分離することで解消しました。詳細は Cloud Tasks の IAM アクセス制御 も参考になります。

Google Cloud を普段から使っている方は、認証の統合をスムーズにできるため導入しやすいと思います。
また、キューイングシステムのメンテナンスコストを減らしたいというケースにも向いています。