GCE経験者のCloud Run入門

1. はじめに：VMは扱えるものの、Cloud Runには少し距離を感じていました

Google Cloudでアプリを動かすとき、私がずっと使ってきたのは Compute Engine（GCE）でした。仮想マシンを立てて、その上にアプリを載せる——昔ながらのやり方ですが、正直これが一番イメージしやすいと感じていました。

しかし、Google Cloudのイベントに参加しているうちに「Cloud Run」というサービスをよく聞くようになりました。名前は知っている。サーバーレスらしい。でも、実際どう違うのか、GCEとどう使い分けるのかが自分の中でずっとモヤモヤしていました。

そこで、GCEの利用経験を持つ私が、Cloud Runを一から学んでみることにしました。この記事では、その中で気づいたことや、GCEに慣れているからこそ発想を切り替える必要があると感じたポイントを、同じようにGCEを使ってきた方向けに整理します。

2. Cloud Runとは何か（私の理解）

Google Cloudの公式ドキュメントを確認しながら整理すると、Cloud Runは、コンテナイメージやソースコードからアプリをデプロイし、Googleのマネージド基盤上で実行できるサーバーレスのアプリケーションプラットフォームです。Cloud RunにはServices、Jobs、Worker poolsなどがありますが、本記事では主にWebアプリやAPIの実行に使うCloud Run Servicesを取り上げます。

GCEを「専用の部屋を長く借り、VMの中のOSやミドルウェアを自分で管理する」イメージだとすると、Cloud Run Servicesは「必要なときに使えるマネージドな実行環境」に近い感覚です。物理サーバーや基盤の管理はどちらもGoogle側ですが、Cloud RunではOSレベルの管理範囲までGoogle側に寄せられるため、利用者はアプリに集中しやすくなります。ただし、アプリのコード、依存ライブラリ、コンテナイメージの内容などは引き続き利用者側の管理対象です。

図 1

3. 気づき①：GCEで対応していた作業の多くが、Cloud Runでは不要になる

学んでみて最初に印象的だったのが、この点です。

GCEで可用性や自動スケールまで含めて構成する場合、MIG（マネージドインスタンスグループ）やInstance Template、ロードバランサ、Backend Service、ヘルスチェックなど、アプリの外側にある構成要素も設計します。VPCやファイアウォールについても、要件に応じたネットワーク設計が必要です。

さらにGCEでは、ゲストOSやミドルウェアのパッチ適用、脆弱性対応も利用者側の運用対象になります。この「対応事項の多さ」が積み重なり、運用負担につながると感じていました。

Cloud Run Servicesでは、こうした管理範囲を大きく減らせます。ただし、すべてが「不要」になるわけではありません。既定のサービスURLでシンプルに公開する場合は自前のロードバランサを省けますが、独自ドメイン、Cloud Armor、Cloud CDN、複数サービスへの経路制御などが必要な場合は、外部Application Load Balancerを組み合わせる構成が適しています。また、VPC内リソースへ接続する場合はDirect VPC egressなどのネットワーク設定が必要です。

では、代わりに何をするのでしょうか。Cloud Runは既存のコンテナイメージをデプロイできるだけでなく、gcloud run deploy --source .のようにソースコードから直接デプロイすることもできます。デプロイが完了するとサービスURLが発行されます。なお、Cloud Run Servicesは既定では非公開で、IAMによる認証が必要です。一般公開する場合は、意図したサービスに対して明示的に公開アクセスを設定します。

図 2

4. 気づき②：便利さの裏で「頭を切り替える」べき3つの前提

ここまで学ぶと「それならすべてCloud Runでよいのではないか」と考えそうになりますが、GCEに慣れている私だからこそ、つまずきやすいと感じたポイントが3つありました。これらを理解せずに移行しようとすると、コード改修が必要になる場合もあるため、自分自身の整理も兼ねて共有します。

① ローカル状態を永続データとして扱わない

GCEのVMでは永続ディスクなどへ状態を保持する設計を取りやすい一方、Cloud Runのコンテナファイルシステムは書き込み可能でも一時的です。インスタンスが終了するとデータは失われ、スケールアウト時には別インスタンスと共有されません。そのため、ローカルファイルを永続データとして前提にしない設計が基本です。

そのため、セッション情報やアップロードファイルなどの永続データは、Cloud Storageやデータベース、必要に応じてNFSなどの外部ストレージへ持たせるのが基本です。「VMのローカルに置いておけばよい」という考え方のままだと、移行段階で作り直しが発生しやすいため、状態の置き場所を早い段階で整理することが重要です。

②「ゼロスケール」と「コールドスタート」

Cloud Run Servicesは、トラフィックがない場合に既定でゼロインスタンスまでスケールできます。これはコスト効率につながる一方、ゼロからインスタンスを起動する際には起動待ちによる追加レイテンシが発生する場合があります。遅延の大きさはアプリの起動処理、イメージ、設定などによって変わるため、「数秒」と一律には決まりません。

レイテンシを重視するサービスでは、最小インスタンス数（min-instances）を設定してインスタンスをウォーム状態に保つことで、スケールゼロからの起動待ちを緩和できます。ただし、最小インスタンスを設定するとアイドル時にも料金が発生するため、性能とコストのトレードオフとして考える必要があります。

③「実行時間の制限」がある

Cloud Run Servicesにはリクエストタイムアウトがあり、デフォルトは5分、最大60分です。そのため、長時間かかるバッチ処理や重い集計を、HTTPリクエストへの応答を前提とするServicesにそのまま載せるのは適していません。

このような「応答することよりも、最後まで処理を実行して完了させること」が重要な処理にはCloud Run Jobsがあり、1タスクあたり最大168時間（7日）まで設定できます。また、HTTPリクエストを受けない継続的なワーカープロセスにはCloud Run Worker poolsという選択肢もあります。GCEから移行する際は、Services、Jobs、Worker poolsのどれがワークロードに合うかを切り分けて考えることが重要です。

5. 気づき③：課金の「考え方」もGCEと違った

GCEではVMがRUNNINGの間、vCPUやメモリなどの計算リソースに対する料金が発生します。一方、Cloud Run Servicesは課金方式を選択でき、デフォルトはRequest-based billingです。こちらはリクエスト処理中に加え、インスタンスの起動時・終了時などが主な課金対象になります。

Cloud Run ServicesにはRequest-based billing（デフォルト）とInstance-based billingがあります。Request-based billingでは、リクエスト処理中、起動時、正常終了処理中などが課金対象です。min-instancesを0にしている場合、リクエストがなくインスタンスがゼロまで縮退している時間はインスタンスのアイドル課金を避けられます。最小インスタンスを設定している場合や、ネットワーク・ストレージなど周辺サービスを利用している場合は別途料金が発生します。

そのため、トラフィックが不定期だったり、夜間はほとんどアクセスがなかったりするWeb/APIでは、Cloud Runのスケールゼロと相性がよい場合があります。一方、常時高負荷のワークロードは、Cloud RunのInstance-based billingやCommitted Use Discounts、GCE側のマシンタイプや各種割引も含めて比較するのが適切です。「Cloud Runなら必ず安い」「高負荷なら必ずGCEが安い」とは一概に言えません。

図 3

6. GCEはもう要らないのか？（学んでみた結論）

ここまで読むとCloud Run一択のように感じるかもしれませんが、学んでみた私の結論は「必ずしもそうではない」です。

OSやカーネルレベルの細かな制御が必要な場合、Cloud Runの実行環境では動かせない特殊なエージェントや特権処理が必要な場合、あるいはコンテナ化が難しいレガシーシステムを移行したい場合などは、GCEが適しています。HTTPリクエストを受けない継続処理については、2026年現在はGAのCloud Run Worker poolsも選択肢に入るため、「長時間動く＝GCE」と単純には決めず、必要な制御レベルで判断するのがよさそうです。

7. まとめ：GCE出身の私なりの、Cloud Runとの付き合い方

GCEしか知らなかった私がCloud Runを学んでみて、一番腑に落ちたのはこの一言です。

新規のWebアプリやAPIならCloud Runを第一候補にし、OS・ネットワーク・実行形態などの要件が合わない場合にGCEを選ぶ。

VMを立てて運用してきた経験は、決して無駄にはなりません。むしろ「GCEで自分が対応していた作業のうち、どこをCloud Runへ任せられるのか」を理解しているからこそ、使い分けがしやすくなります。同じようにGCEを使ってきた方は、小さなWeb/APIからgcloud run deploy --source .を試し、Cloud Runの管理範囲と制約を実際に確認してみるのがおすすめです。

参考：Google Cloud公式ドキュメント

• What is Cloud Run
• Deploy services from source code
• Billing settings for services
• Configure request timeout for services