6

More than 1 year has passed since last update.

最大実行時間9分→60分になった第二世代CloudFunctionsを使ってみた。

Last updated at 2022-09-25Posted at 2022-09-25

tl;dr

2022年8月にGAとなった第二世代CloudFunctions(以下CF)。主な変更点として、最大使用可能リソースと最大実行時間が大幅に増加した。(具体的な変更点はこちら)
最大実行時間が9分→60分と、AWSのFaaSであるLambda(最大15分)も屁じゃないくらいに最大実行時間が増えたように聞こえるが、実際にはHTTP関数以外の最大実行時間は今まで通り9分のまま(参考)。

やったこと

pandasなどでbigqueryのデータをクレンジングするバッチをCloudScheduler→CloudPub/Sub→CloudFunctionsという定番構成で作っていたら、それなりに実行時間が必要な場面が出てきた。リファクタよりひとまずデプロイしたい。
第一世代では小分け実装の必要があり管理リソースが増えてしまうので第二世代の恩恵を受けたいところ。しかし2022年9月現在では、第二世代CFの実行時間はHTTP関数の場合のみ、最大3,600秒=１時間に設定できる模様。Pub/Subなどをトリガにするイベントドリブン関数は最大実行時間540秒=9分のまま。
現在の構成では最大実行時間だけ伸ばすことはできないようなので、Pub/Subの代わりにCloudWorkflowsを挟んでHTTPトリガを叩かせるようにちょっと構成を変えてみた。

Cloud Workflowsとは？(参考)

CloudFunctionsやAPI呼び出しなどを組み合わせてワークフローを作れる、AWSでいうところのStepFunctionsのようなGCPのワークフロー管理サービス。
A→B→C→D...のような、いくつか段階を踏む必要のあるデータ処理などの場合でも、「Aが成功したらBをトリガするPub/Subを叩く」みたいなことをする必要がないので管理リソースが減る&全体像を把握できるので複雑なワークフロー管理で重宝する。
今回はクラスメソッド先輩を参考にして下記のように、HTTPトリガで作成したCFを叩くワークフローを作成し、これをCloudSchedulerで定期実行させるようにできないか試した。

- cleanse_batch:
    call: http.get
    args:
        url: CFのURLを書く
        timeout:1800
        auth:
            type: OIDC
    result: response
- result:
    return: ${response}

注意

ちょっと問題だったのは、Workflows側のhttp.getのtimeoutが最大1,800秒=30分だったこと。CF側で3,600秒に設定していても、30分を超えるとWorkflows側でタイムアウトになってしまう。少し悔しいが、9分→30分でも大幅増加だし、第二世代になって増えたリソース割り当てでカバーすればひとまず困らない。
CFのHTTPエンドポイントを叩くには、type: OIDCが必須。
Workflows側のサービスアカウントにCloud Run 起動元（roles/run.invoker）のロールを付けておく必要あり(ここは第一世代と違う。第二世代はCloud Run上に構築されているため)。参考

感想

CloudWorkflowsはとても簡単にワークフロー管理ができるので、本来の用途でも大活躍しそう。今回の要件を満たすだけなら、HTTPトリガを叩くだけ用のCFを別に用意する方法でも可能とは思う。
実行時間などの第二世代の恩恵を受けられる&依存関係の管理などの拡張性を考えれば今後、定番のPub/Sub構成よりも初めからWorkflowsで実装するのもありかもしれないと思った。
イベントドリブン関数でも実行時間が拡張がサポートされるよう、今後のCF第二世代のリリースを期待したい。参考

参考

6

Register as a new user and use Qiita more conveniently

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

6