【ITニュース解説】Part-44: ⚡Google Cloud Functions: HTTPS & Event-Driven Serverless Computing

Google Cloud Functions (GCF)は、システムエンジニアを目指す上で知っておくべき重要な技術の一つだ。これはFunction as a Service (FaaS)と呼ばれるサーバーレスプラットフォームであり、私たちが書いたコードを、基盤となるサーバーやインフラの管理に一切気を煩わせることなく実行できる画期的なサービスである。GCFは、コードを特定のイベントに応じて動かすことを目的としている。

このサービスが「サーバーレス」と呼ばれるのは、開発者がサーバーの購入、設定、メンテナンス、パッチ適用、スケーリングといった煩雑な作業から完全に解放されるためだ。GCFは完全にGoogleが管理しており、コードが実行された分だけ料金が発生する「従量課金制」が採用されている。そして、アクセスが急増しても自動的に必要なだけリソースを増やし、アクセスが落ち着けば元に戻る「自動スケーリング」の機能も備わっている。これにより、開発者は純粋にアプリケーションのロジック開発に集中できるという大きなメリットがある。

GCFの基本的な仕組みは非常にシンプルだ。開発者は実行したい処理を「関数」として記述し、その関数をどのような状況で実行するかを示す「トリガー（イベント）」を設定する。あとはGoogle Cloudが、その関数を実行するために必要なサーバーの準備（プロビジョニング）、需要に応じた規模の調整（スケーリング）、そして実際のコード実行といった全ての裏方作業を自動的に処理してくれる。例えば、ウェブサイトへのアクセスがあった時（HTTPSトリガー）、メッセージングサービスに新しいメッセージが投稿された時（Cloud Pub/Sub）、あるいはオンラインストレージにファイルがアップロードされた時（Cloud Storage）など、様々なイベントをトリガーとして設定できる。

Google Cloud Functionsを使う主な理由としては、やはり「サーバーレス」である点が挙げられる。これにより、開発者はサーバーの管理という重荷から解放され、アプリケーションのビジネスロジックに集中できる。次に、「自動スケーリング」の機能があるため、イベントの発生頻度が急増しても、システムが自動で対応し、ダウンすることなく安定してサービスを提供し続けられる。また、Python、Node.js、Go、Java、.NET、Rubyといった複数のプログラミング言語に対応しているため、開発者は慣れ親しんだ言語で関数を作成できる柔軟性がある。

Cloud Functionsには大きく分けて二つの種類がある。一つは「HTTPS Functions」と呼ばれるもので、これはHTTPまたはHTTPSのリクエストをトリガーとして実行される関数だ。ウェブAPIの構築、外部システムからの通知を受け取るウェブフック、ウェブフォームの送信処理など、ウェブ経由のインタラクションに対応するのに理想的である。GET、POST、PUT、DELETE、OPTIONSといった主要なHTTPメソッドをサポートしている。もう一つは「Event-Driven Functions」と呼ばれるもので、これは他のGoogle Cloudサービスから発生する特定のイベントをトリガーとして実行される関数だ。例えば、Cloud Storageに新しいファイルがアップロードされた時、Cloud Pub/Subにメッセージが発行された時、データベースのFirestoreにデータが変更された時などに自動的にコードが実行される。これらのイベントはEventarcというサービスを通じて、125以上の多様なGoogle Cloudソースと連携して利用できるため、非常に広範囲な自動化が可能となる。

具体的な活用例としては、素早くREST APIを構築したり、ファイルがアップロードされた際に画像のリサイズやメタデータの抽出といった処理を自動で行うワークフローを組んだりすることが挙げられる。また、リアルタイムのデータストリームをCloud Pub/Subから受け取り、それを加工・分析する処理や、Cloud Schedulerと連携して定期的に特定のタスクを実行するような用途にも適している。

Google Cloud Functionsは、その進化の過程で「1st Generation (第1世代)」と「2nd Generation (第2世代)」という二つのバージョンが存在する。1st Genは初期にリリースされたバージョンであり、基本的なサーバーレス機能を提供していた。しかし、より高度な機能や柔軟性が求められるようになり、登場したのが2nd Genである。2nd Genは、Google Cloudの別の強力なサービスである「Cloud Run」と「Eventarc」を基盤として構築されており、これにより大幅な機能強化が実現されている。

両世代の主な違いを見てみよう。まず「タイムアウト」に関して、1st GenではHTTP関数が最大9分、イベント駆動型関数も最大9分という制限があった。しかし、2nd GenではHTTP関数が最大60分、イベント駆動型関数も最大10分と、処理時間が大幅に延長された。これにより、より時間のかかる複雑な処理もGCFで実行できるようになっている。次に「コンピューティング能力」について、1st Genでは最大8GBのメモリと4vCPUまでが提供され、CPUは自動で割り当てられるため、詳細な選択肢はなかった。しかし、2nd Genでは最大32GBのメモリと8vCPUまで利用可能となり、CPUの割り当てを明示的に選択できるようになり、より高いパフォーマンスが求められるアプリケーションに対応できるようになった。

さらに、「同時実行性（Concurrency）」という点で大きな違いがある。1st Genでは、例えば10個のリクエストが同時に来ると、それぞれのリクエストに対して10個のコンテナインスタンスが起動する仕組みだったため、リソースの効率が悪くなる可能性があった。これに対し、2nd Genでは同時実行がサポートされ、設定によっては1つのコンテナインスタンスで複数のリクエストを同時に処理できるようになった。これにより、リソース利用の効率が向上し、コスト削減にもつながる。ただし、対応していないランタイムも一部存在する点には注意が必要だ。

また、「トラフィック分割」機能は2nd Genで初めて導入された重要な特徴である。1st Genでは新しいバージョンの関数をデプロイする際、一度に全てのトラフィックが新しいバージョンに切り替わるため、万が一問題があった場合に大きな影響が出るリスクがあった。しかし、2nd GenはCloud Runを基盤としているため、例えば新しいバージョンに10%だけトラフィックを流し、残りの90%は古いバージョンで処理するといった段階的なロールアウトが可能になった。これにより、リスクを最小限に抑えながら安全にアップデートを適用できる。

最後に、「イベントトリガーの数」も大きく異なる点だ。1st GenではHTTP、Cloud Storage、Cloud Pub/Sub、Cloud Firestore、そしていくつかのFirebaseトリガーに限定されていた。しかし、2nd GenではEventarcの活用により、HTTPSトリガーはもちろんのこと、それ以外の125を超える多様なGoogle Cloudサービスからのイベント、さらには一部のサードパーティからのイベントにも対応できるようになった。これにより、Google Cloud Functionsで実現できる自動化と連携の範囲が飛躍的に広がっている。

Google Cloud Functionsは、インフラ管理の手間なく、イベント駆動型でコードを実行できる強力なサーバーレスプラットフォームだ。特に2nd Genの登場により、処理能力、柔軟性、拡張性が大幅に向上し、システムエンジニアを目指す上で知っておくべき、現代的なアプリケーション開発の選択肢として非常に魅力的なサービスである。