Cloud Functions第二世代がやってくる - 公開プレビュー版から見る仕様とユースケース

テクノロジーコンサルティング本部　マネジャーの中川です。

私は以下のロールで活動を行っています。

• Intelligent Cloud Enabler（ICE） Cloud Native Solutions チームのManager
• Accenture Google Business Group（AGBG）のSolution Architect / Engineer

私はAccentureに入社する以前からApp Engine、Cloud Runそしてこのエントリーでご紹介するCloud Functionsといった、フルマネージドかつサーバレスなサービスを用いたデリバリーを行っており、また個人としても、趣味・学習を兼ねてこれらの環境を使ったアプリケーション開発を行っています。

• 軽量のAPI、Slack通知Bot等の小規模Web Application（Webhook利用含む）
• 小規模のデータを扱うデータ処理バッチ・ETL
• Cloud Storageの変更等をtriggerとしたイベント駆動処理

といったユースケースにおいてFaaS（Function as a Service）であるCloud Functionsを使っているのですが、年のはじめにCloud Functions第二世代がPre-GA（公開プレビュー）になりました。

新しい Cloud Functions（第 2 世代）でイベント ドリブン アーキテクチャを強化

 このエントリーではPre-GA時点のCloud Functions 第二世代の仕様で抑えておきたいポイントおよび、想定されるユースケースについて共有します。

前提条件

このエントリーは2022年6月末時点のPre-GA版Cloud Functions 第二世代を元に記載しております。GA（正式リリース版）および、Pre-GAにおいて仕様等が変更される可能性があるのでご注意ください。 

第一世代と第二世代の仕様について

まずはじめに仕様面でどのような変化があるか、表にまとめました。

要点をまとめると、以下のとおりです。

• 1リクエストあたりの最大処理時間の延長および、利用可能なCPU / Memoryが大幅に増加。
• 同時実行および最小インスタンス指定時のウォームアップ等、よりスケーラビリティの高い関数が実行可能。
• 同一関数内で違うリビジョンの関数を実行可能。例えば「最新バージョンを20%、残りを1世代前のバージョンに割り当てる」といったトラフィック分割が可能となった。
• Cloud Runのイベント・トリガーであるへの対応、イベントデータの標準的な定義であるCloudEvents形式のサポートにより、対応するイベントソースが充実。第一世代の方式も利用しつつ、新たなユースケースにも対応可能。
• 利用可能な言語・Frameworkは第一世代から変更なし。実装はFunctions Frameworkの利用が推奨となる。第一世代の関数をFunctions Frameworkで再実装することにより、スムーズな移行が実現（なおFunctions Frameworkを使わなくても動きます）。

Cloud Functions 第二世代はベースとなるPlatformがCloud Runとなっており、Cloud Runの潤沢なコンピューティング・リソース及びトラフィック管理がCloud Functionsで利用できるという仕様になっています。

• 比較的軽量なアプリケーションかつ、言語ごとの標準的なライブラリ及びGoogle Cloudの各種APIを用いて開発する場合はCloud Functions
• 標準的なライブラリだけでなく、コンテナイメージそのものから構築・管理する必要がある（OS等に依存するなど）場合はCloud Run

といったように、「軽量な構成ならCloud Functions」「コンテナイメージから管理したい場合はCloud Run」といった使い分けになるのかなと思います。

また、Cloud Runの恩恵に授かる以外にも、イベントソースの増加やFunctions Frameworkによる開発の標準化が可能といった長所もあります。

Cloud Functions第二世代の想定ユースケース

Cloud Functionsを使うケースとして、

• 軽量のAPI、Slack通知Bot等の小規模Web Application（Webhook利用含む）
• 小規模のデータを扱うデータ処理バッチ・ETL
• Cloud Storageの変更等をtriggerとしたイベント駆動処理

いずれも「App EngineやCompute Engineでアプリを作るほどではない、軽量かつシンプルな処理」を行うためのFaaSとしてのユースケースです。

第二世代においてもこれらのユースケースは有効で引き続き利用可能であると同時に、

• 大規模なデータ処理・ETLの構築・運用。リクエストあたりの処理時間増加およびコンピューティングリソースの強化により、第一世代の関数よりリッチな処理が可能。
• 本格的なWebアプリケーション。トラフィック管理機能によるトラフィック分割が可能となり、Cloud Functionsのみでもカナリアリリース・A/Bテストが可能となった為、従来App EngineやCloud Runで運用を想定していたようなアプリケーションも運用可能。

Cloud Runの潤沢なコンピューティング・リソース及びトラフィック管理がCloud Functionsでも利用できるようになったことにより、本来コンテナで行っていたような処理・実装が可能となります。

具体例を上げると、

• HTTP（s）をプロトコルとするWebアプリケーション
• Cloud Scheduler等のスケジューラー、GCS/Firebase等の変更イベントをトリガーにPub/Sub経由に動かすバッチアプリケーション

これらをすべてCloud Functionsで実現することが可能です（下図）。

これはあくまで一例ですが、小規模なシステムのアプリケーションはすべてCloud Functionsで構築・運用できるような未来が来るかもしれません。

まとめ

Cloud Functions 第二世代を公開プレビュー版の仕様を元に紹介しました。

このエントリーを執筆する前に、実際に第二世代でのアプリケーションの構築および、第一世代の関数からのMigrationを行い、知見と手触りした熱量を持ってこのエントリーを執筆したのですが、十分使えそうであるという実感を得ました、正式公開が待ち遠しいです。

なお、DevOps的なアプローチでの管理はまだ検証していないので、引き続き触って知見を得た上で続編が書ければと思っております。

最後までお読みいただきありがとうございました。