で、Cloud Run と App Engine って何が違うの？

はじめに

こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。

この投稿は AoTo Advent Calendar 2024 21日目の記事です。

普段から Google Cloud を利用されている方や、PaaS やマネージドコンテナをの利用を検討する方が直面する、「で、Cloud Run と Google App Engine って何が違うの？」という疑問を解消するべくこのブログを執筆しています。

今回の比較対象は App Engine スタンダード環境・App Engine フレキシブル環境・Cloud Run services の3つです。特に、これらのサービスは全く異なる基盤から構成されていますが、それぞれの機能追加の結果、類似点が非常に多くなっています。App Engine のスタンダード/フレキシブル環境の違いに触れながら、Cloud run services とのユースケースの違いを考察します。

App Engine スタンダード環境と Cloud Run services はそれぞれ第一世代と第二世代があり、本ドキュメントは第二世代を対象として解説しています。

Cloud Run 内の serivces, jobs, functions は『で、Cloud Functions と Cloud Run って何が違うの？』で解説しています。

まとめ

実行環境

• App Engine スタンダード環境は、コンテナインスタンスに事前構成されたランタイム環境上でコードをデプロイする
• App Engine フレキシブル環境は、Compute Engine を基盤とした Docker コンテナ内でコードを実行する
• Cloud Run services は、Knative Serving 互換のコンテナ上で実行する
• App Engine フレキシブル環境と Cloud Run services は、Dockerfile 利用したコンテナイメージのデプロイができる

スケーリングとセキュリティ

• どのサービスも、アプリケーションの需要に応じたオートスケールが備わっている
• App Engine スタンダード環境と Cloud Run services は、ゼロスケールに対応している
• セキュリティパッチは App Engine スタンダード環境とコンテナイメージランタイムを除く App Engine フレキシブル環境に自動適用され、Cloud Run sevices はベースイメージ自動更新が対応している

サービス構成

• Cloud Run services のみ GPU 構成に対応している
• App Engine スタンダード環境 のみ静的ファイルハンドラを構成し、コンピューティングリソースを使用せずに静的コンテンツを配信できる
• App Engine フレキシブル環境と Cloud Run services は、WebSocket 通信を利用できる
• App Engine スタンダード環境と Cloud Run services は、起動時間に応じた課金がされる
• App Engine と Cloud Run はリソースモデルが異なる

Simplified Chart

	App Engine スタンダード環境	App Engien フレキシブル環境	Cloud Run services
デプロイ単位	ソースコード	ソースコード コンテナイメージ	ソースコード コンテナイメージ
デプロイ構成	app.yaml dispatch.yaml	app.yaml dispatch.yaml	service.yaml (Knative 仕様)
実行環境	gVisor 上のコンテナ	GCE 上の Docker	Knative Serving 互換
タイムアウト	自動:10分 手動:24時間	60分	デフォルト:5分 最大:60分
VPC 接続	サーバレス VPC コネクタ	サーバレス VPC コネクタ	サーバレス VPC コネクタ or ダイレクト VPC Egress
デプロイ時間	秒単位	分単位	秒単位
エントリポイント	app.yaml の entrypoint 属性 or ランタイムデフォルト	app.yaml の entrypoint 属性 or ランタイムデフォルト	言語固有の構成 or GOOGLE_ENTRYPOINT 環境変数

選定方法

今回に限らず、クラウドサービスの利用を検討する際は複数の類似サービスを比較・検討することが重要です。利用者はより運用・管理コストの低いマネージドサービスから検討していくことで、クラウドのメリットを最大限に享受できます。

App Engine, Cloud Run はどちらもソースコードデプロイとコンテナデプロイが可能なマネージドサービス(PaaS, CaaS)です。従来は App Engine が PaaS、Cloud Run が CaaS として棲み分けされていましたが、それぞれの機能追加の結果、現在は類似機能がとても多くなっています。

こうした背景からも、どういった実行基盤で動作しており、どのような制限があるかを理解することで、どのようなユースケースに向いているかを知ることができます。

さらに、それぞれのサービスを選定する基準や方針は以下のように言い表せます。

1. Knative Serving 互換の環境で service.yaml で構成しコンテナをデプロイしても良い
   コンテナ設計を考慮せず、ソースコードデプロイで柔軟にスケールする環境が欲しい
2. アプリケーションコードのみを管理したい上で、独自の app.yaml を扱える
3. コンテナイメージの管理不要で Dockerfile のみで柔軟にスケールする環境が欲しい
4. 各アプリケーションランタイムの制約が影響なく、独自の app.yaml を扱える

さて、ここまで対等に比較していましたが、App Engine には重大な制約があります。
各 Google Cloud プロジェクトに含めることができる App Engine アプリケーションは $\huge{1 つだけ}$なんです。¹また、作成後に App Engine アプリケーションのロケーションを変更することもできません。

こうした制限はドキュメントを眺めるだけではなかなかわかりづらいため、机上で検討する前に Google Cloud Console でも実際に検証してみることをお勧めします。

このように Cloud Run と App Engine はコンテナデプロイやソースコードデプロイが可能な類似したマネージドサービスですが、リソースモデルが大きく異なります。

App Engine は単一で最上位の Application リソースと、対応する default サービスが必要となります。この他に Application リソースは以下に Service, Version, Instance を配置する形になります。

サンプルアーキテクチャ

最後に、それぞれのサービスの特徴を活かしたアーキテクチャを考えてみましょう。

App Engine スタンダード環境と Cloud Storage で静的ウェブサイトのホスティング

App Engine を介して Cloud Storage 上の静的コンテンツをホスティングするアーキテクチャです。App Engine スタンダード環境の静的ファイル ハンドラを構成して、URI パスに応じたコンテンツ配信できます。

App Engine スタンダード環境は静的ファイルハンドラを構成できるため、Cloud Storage 上の静的コンテンツをコンピューティング リソースを使用せずに配信できます。

App Engine フレキシブル環境でコンテナイメージを管理せず Rust アプリケーションの実行

App Engine フレキシブル環境を用いた、任意のアプリケーション言語をカスタムランタイムを用いて実行するアーキテクチャです。app.yaml と Dockerfile、アプリケーションコードを用意するだけで、Cloud Build を介して簡単に任意のアプリケーションをビルド・デプロイし App Engine で実行できます。

App Engine フレキシブル環境は Docker ベースのカスタムランタイムを実行することができるため、アプリケーションランタイムの制約を考慮せずにアプリケーションを実行できます。この時 Cloud Build を用いることで、ソースコードの変更がコミットされるとその他の要素を管理することなく新たなバージョンをデプロイできます。

Cloud Run services でマルチコンテナ LLM アプリのホスティング

Cloud Run services を用いた、GPU を必要とするワークロードを実行する LLM アプリケーションをホスティングするアーキテクチャです。Cloud Run 内でフロントエンドコンテナと LLM アプリ、それらのパフォーマンスを監視するための監視エージェントをデプロイし、Cloud GPU を活用した LLM ワークロードを信頼性高く実行できます。

Cloud Run services は常時リソースを必要とするサービスをホスティングし、GPU を活用したワークロードを実行できます。この時、GPU の利用と マルチコンテナによってコンテナ毎に役割を分離し、複雑な LLM ワークロードを安定的に実行しパフォーマンスを監視できることが特徴です。²

おわりに

App Engine と Cloud Run はどちらも多機能なサービスです。

どちらにもアップデートの歴史がありますが、App Engine は15年を超える歴史を持っており、それ故に当初の役割から大きく進化したサービスを提供しています。

一方で Cloud Run は5年という短い歴史で、Google Cloud のメインストリームとして、積極的な機能アップデートやサポート技術の追加を色濃く受けているサービスです。

本ブログを通して、全てのケースに Cloud Run* を利用せずとも、App Engine を活かせる場面がいくつか残っていることがお分かりいただけたかと思います。

この考え方は、Cloud Run services と Google Kubernetes Engine(GKE) の選定の際も同様で、サービスに対する理解を深めることが重要です🐶

1. App Engine 用の Google Cloud プロジェクトの設定より引用 ↩

2. 筆者のやりたいことを詰め込んだ内容のため、サービス選定や各要素の必要性は度外視してご覧ください🐶 ↩