ホーム
お役立ち
Google Service
Google Cloud （ GCP ）でアプリケーションを動かすにはどのサービスが最適？ Cloud Run 、 GCE 、 GKE、GAE まで一挙に解説！

Google Cloud （ GCP ）でアプリケーションを動かすにはどのサービスが最適？ Cloud Run 、 GCE 、 GKE、GAE まで一挙に解説！

Cloud Run
GCE
GKE
アプリケーション

公開年月日: 2021.07.08

更新年月日: 2024.09.26

Google Cloud （ GCP ）でアプリケーションを動かすにはどのサービスが最適？ Cloud Run 、 GCE 、 GKE、GAE まで一挙に解説！

本記事は、2021年5月26日に開催された Google の公式イベント「 Google Cloud Day : Digital ’21 」において、 Google Cloud ソリューションアーキテクトの長谷部光治氏が講演された「アプリケーションはどこで動かすべきか、それが問題だ - Google Compute Engine から Kubernetes Engine, Cloud Run まで - 」のレポート記事となります。

今回は Google Cloud ( GCP ) が提供している様々な Compute プロダクトのそれぞれの特徴とアプリケーションを動かすために最適なプロダクトの選び方を解説しています。

なお、本記事内で使用している画像に関しては Google Cloud Day : Digital ’21 「アプリケーションはどこで動かすべきか、それが問題だ - Google Compute Engine から Kubernetes Engine, Cloud Run まで -」を出典元として参照しております。

それでは、早速内容を見ていきましょう。

Google Cloud （ GCP ）の Compute プロダクト

Google Cloud （GCP）では、計5つの Compute プロダクトを提供しています。

Computeプロダクト

以下、それぞれのプロダクトについて詳しく解説します。

Google Compute Engine （ GCE ）

Google Compute Engine （以下 GCE と記載）はコンピュートリソースを提供するサービスであり、 CPU や OS などを組み合わせることで、柔軟な環境を作り上げることができる Compute プロダクトです。

OS は Debian や Windows など、様々な選択肢から選ぶことができ、バージョンも数多くのものを取り揃えています。

また、 OS だけではなく CPU やディスクなども豊富な選択肢が用意されており、自社の要件に合わせた希望通りの環境を Google Cloud ( GCP ) 上に構築することができます。

Compute Engine

Google Kubernetes Engine （ GKE ）

Google Kubernetes Engine （以下 GKE と記載）は、文字通り Kubernetes 環境を利用するための Compute プロダクトです。 Kubernetes とは、オープンソースのコンテナーオーケストレーションツールであり、コンテナを動かすためのデファクトスタンダードになっているシステムです。

GKE は、ユーザーが Kubernetes を構築・運用するのではなく、 Google が管理している Kubernetes 環境を利用するサービスになります。そのため、 Kubernetes 自体のアップデートや Kubernetes 環境のオートスケールなどに関しては、 Google がマネージド状態で提供しており、自社に作業負荷をかけることなく Kubernetes 環境を利用することができます。

GKE

Cloud Run

Cloud Run はコンテナをサーバーレスで提供している Compute プロダクトです。コンテナとは、 OS （オペレーティング・システム）上に「アプリケーション本体」「必要なライブラリ」「設定ファイル」などをひとまとめにしたものです。

本来、コンテナを扱うためには「 Kubernetes （オープンソースのコンテナーオーケストレーションツール）」を学ぶ必要があり、学習するための時間やコストが発生してしまいます。

単純にコンテナを扱うだけであれば Kubernetes がなくても問題ありませんが、オーケストレーション（設定や管理などの自動化）を行うためには Kubernetes の知識が必要不可欠です。

しかし、 Cloud Run を使えば、コンテナイメージを構築して Cloud Run の上に乗せるだけで、 Kubernetes が提供している様々な機能・強みを享受することができます。

Cloud Run

App Engine

App Engine はアプリケーションをサーバーレスで提供している Compute プロダクトであり、一般的には PaaS （ Platform as a Service ）と呼ばれている形態のサービスです。

App Engine はアプリケーションを簡単に構築できることはもちろん、開発者がアプリケーションのソースコード開発に集中できるように設計されています。開発者は作ったソースコードを App Engine の上に乗せるだけで、自動的にアプリケーションの実行環境が完成・提供されます。

また、アプリケーションが動作しているよりも下位のレイヤー（ランタイム、ミドルウェアなど）はフルマネージドサービスとして提供されているため、環境アップデートやパッチ適用などを自社が気にする必要はありません。

さらに、アプリケーションのバージョンも App Engine のプラットフォーム上で管理しているため、アプリケーションの管理にかかる負荷を軽減することができます。

App Engine

Cloud Functions

Cloud Functions はクラウドサービスを構築して接続するためのサーバーレス環境であり、その名前の通り Functions （関数）をサーバーレスで提供している Compute プロダクトです。

特定のイベント発生をキッカケとして Cloud Functions 上で動いているアプリケーションを呼び出す仕組みとなっています。つまり、 Google Cloud ( GCP ) が提供している様々なサービスの状態変化を感じ取り、一定の条件に基づいて Cloud Functions 上のアプリケーションが起動する、というイメージです。

Cloud Functions

CNCF ホワイトペーパーの3つのクラウドネイティブモデル

CNCF は「 Cloud Native Computing Foundation 」の略であり、クラウドネイティブコンピューティングの技術を社会へ啓蒙している団体です。 CNCF はクラウドネイティブに関するモデルを定義しており、そのモデルごとにメリット、デメリット、ユースケースなどをホワイトペーパーにまとめて発信しています。

CNCF のホワイトペーパーの中では、クラウドネイティブモデルを以下の3つに分類しています。

サーバーレス
CaaS （ Container as a Service ）
PaaS （ Platform as a Service ）

本章では、この3つのモデルの特徴と、 Google Cloud （ GCP ）の Compute プロダクトがどのモデルに対応しているのかを順番にご説明します。

サーバーレス

サーバーレスはサーバーの管理なしにアプリケーションを開発・稼働させることができるモデルです。サーバー運用が不要であり、アイドル状態でもコストが発生しない点が大きなメリットになります。

サーバーレスモデルは「 FaaS （ Functions as a Service ）」または「 BaaS （ Backend as a Service ）」の機能のうち、1つもしくは両方を提供すると定義されています。

FaaS はイベント駆動アーキテクチャで利用されることが多く、イベントや HTTP リクエストで起動します。 BaaS はアプリケーションの主要機能の一部を置き換えるための API ベースのサードパーティサービスになります。

Google Cloud （ GCP ）の Compute プロダクトでは、 Cloud Functions がサーバーレスに該当します。

CaaS （ Container as a Service ）

CaaS はコンテナを大規模で利用するためのプラットフォームであり、一般的にはコンテナオーケストレーションツールなどを指します。 CaaS はインフラを抽象化することで、オンプレミス・クラウドなどの環境を問わずに使用できます。

そのため、 CaaS はポータビリティに優れており、自社の状況に合わせた柔軟な運用を実現可能です。また、強力なインフラ制御を行える点も CaaS のメリットの一つであると言えるでしょう。

Google Cloud （ GCP ）の Compute プロダクトでは、 GKE が CaaS に該当します。

PaaS （ Platform as a Service ）

PaaS はアプリケーションの構築・稼働に特化したサービスであり、その他の部分はプラットフォームが担う形になります。 PaaS は様々な言語のランタイムを利用して、アプリケーションを開発できます。

また、コンテナや OS を設定・管理する必要はなく、アプリケーションに構成情報を読み込ませることで、アプリケーションに関連する一連の作業をすべて完結できます。そのため、PaaS は既存の web アプリケーション開発に適したソリューションであると言えます。

Google Cloud （ GCP ）の Compute プロダクトでは、 App Engine が PaaS に該当します。

まとめ

このように、 CNCF のホワイトペーパーで定義されているクラウドネイティブモデルには、それぞれのモデルに対応する Google Cloud （ GCP ）の Compute プロダクトが存在しています。

なお、 Cloud Run は様々なケースに対応しています。コンテナが使える点では CaaS に該当しますし、 web アプリも利用可能なため PaaS にも当てはまります。また、イベント駆動で使うこともできるため、サーバーレスに該当する部分もあります。

対応しているGCPサービス

CNCF ホワイトペーパーの懸念点に対する Google プロダクトの対応状況

CNCF のホワイトペーパーでは、前章でご説明した3つのモデルに対する懸念点が明記されています。

本章では、 Google Cloud （ GCP ）の Compute プロダクトが、懸念点に対してどのように対応しているのかをご説明します。

サーバーレスモデルの懸念点への対応

成熟度

サーバーレスモデルは比較的新しいモデルであるため、サービスの成熟度が懸念点として挙げられています。

懸念点	Cloud Functions の対応状況	Cloud Run の対応状況
ドキュメント、サンプル、ツール、ベストプラクティスなどの情報が不足している	ベータ版リリースから4年が経過し、アセットが揃ってきた	アルファ版リリースから3年弱が経過し、各種アセットが拡充中
IaaS や PaaS と比較してデバッグが困難である	・Cloud Debugger や Cloud Logging を利用して効率的にデバッグ・Functions Framework を使ったローカルでの開発	・Cloud Debugger や Cloud Logging を利用して効率的にデバッグ・Docker などを使ったローカルでの開発
アイドル状態が続くと次の実行がコールドスタートになる	極力コールドスタートを避けるためのベストプラクティスを提供	最小インスタンスや同時実行を最適化し、コールドスタートを回避

上記の通り、 Google プロダクトのサービスリリースから期間が経過したことで、成熟度の課題は改善傾向にあります。また、デバッグ面においても、別の Google プロダクトと連携することで解決可能です。

オープン性

成熟度に加えて、サービスのオープン性もサーバーレスモデルの懸念点として挙げられています。

懸念点	Cloud Functions の対応状況	Cloud Run の対応状況
複雑なケースでは、ロジック量と比較して多くの操作が必要になる	関数は複雑なロジックの構築に向いていない	アプリケーション単位で実行できるため、ロジックをまとめて対応可能
標準化やエコシステムが成熟していない	オープンな Functions Framework を利用して、エコシステムを拡充中	オープンソースの Knative コミュニティと共にエコシステムを拡充中
提供プラットフォームにロックインする可能性	オープンなフレームワークを使うことで、ロックインを回避	オープンなフレームワークを使うことで、ロックインを回避

オープン性に関しては、そもそも Google プロダクト自体がオープン性を重視して設計されたサービスであるため、心配する必要はありません。

CaaS モデルの懸念点への対応

運用負荷

CaaS モデルは自社で運用する形態であるため、運用負荷が懸念点として挙げられています。

懸念点	GKE （ Standard ）	GKE （ Autopilot ）	Cloud Run
セキュリティパッチ対応などの実行環境管理	コントロールプレーンは Google 、ノードは利用者と Google の共同責任	コントロールプレーン・ノードともに Google の責任	Google が責任を持ち、利用者は気にする必要がない
ロードバランシングとスケーリング	利用者が設定を行い Google がその設定どおりに稼働させる責任を持つ	利用者が設定を行い Google がその設定どおりに稼働させる責任を持つ	自動で設定・スケーリングが行われる
キャパシティ管理	利用者がノードのキャパシティや自動スケーリング設定を行う	要求されたリソースが確保される	キャパシティを意識する必要はない

GKE はマネージドサービスであるため、 Google が運用負荷を一部軽減しています。また、 Cloud Run に関しては、利用者が運用負荷を気にする必要はありません。

作業負荷

運用負荷に加えて、ビルド、デプロイ、モニタリング、ロギングなどの作業かかる負荷も懸念点として挙げられています。

懸念点	GKE （ Standard ）	GKE （ Autopilot ）	Cloud Run
スタートアップに時間がかかる	イメージの事前展開などスタートアップの時間を短縮する各種プラクティス	イメージの事前展開などスタートアップの時間を短縮する各種プラクティス	各種コールドスタートを低減する設定や機能
アプリケーション構成に関して「ガードレール」の役割を果たすものが少ない	様々なプラクティス、ポリシー管理、セキュリティ管理機能を提供	ベストプラクティス、セキュリティ設定が初めから組み込まれている	構成が抽象化されており、セキュリティを担保
ビルド、デプロイのメカニズムを用意	Cloud Build など Google Cloud が提供するサービスと簡単に連携	Cloud Build など Google Cloud が提供するサービスと簡単に連携	Cloud Build など Google Cloud が提供するサービスと簡単に連携
モニタリング、ロギング、その他の共通サービスとの連携管理	運用管理に利用する Cloud Operations、その他プライベートコンテナレジストリ、プライベート Git リポジトリといったサービスと簡単に連携	運用管理に利用する Cloud Operations、その他プライベートコンテナレジストリ、プライベート Git リポジトリといったサービスと簡単に連携	運用管理に利用する Cloud Operations、その他プライベートコンテナレジストリ、プライベート Git リポジトリといったサービスと簡単に連携

Google Cloud （ GCP ）では、利用者の負荷を低減するための様々なマネージドサービスを提供しているため、これらを活用することで作業負荷の懸念点を払拭できます。

PaaS モデルの懸念点への対応

PaaS モデルはアプリケーションの抽象度を高めているため、アプリケーション環境における制約が懸念点として挙げられています。

懸念点	App Engine	Cloud Run
ランタイムバージョンに翻弄される	同じ様に提供ランタイムに影響を受ける可能性がある	ランタイムバージョンを気にする必要はない
「12ファクター」のプラクティスに縛られて、アーキテクチャの柔軟性が失われる可能性	「12ファクター」にあるような stateless なアプリケーション作成に適している	「12ファクター」にあるような stateless なアプリケーション作成に適している
提供プラットフォームにロックインする可能性	ロックインになってしまう可能性がある	コンテナやオープンな Knative をベースとすることでロックインを回避

上記の通り、 App Engine は制約に縛られてしまうケースもありますが、 Cloud Run はコンテナを利用可能なため、ランタイムバージョンやロックインを気にする必要はありません。

まとめ

Google Cloud （ GCP ）の Compute プロダクトは、 CNCF のホワイトペーパーで指摘されている懸念点を以下3つの要素で解決しています。

Google Cloud （ GCP ）の他サービスとの連携
マネージドでの機能提供
オープン性の追求

そのため、企業は安心して Google Cloud （ GCP ）の Compute プロダクトを利用でき、効率的にアプリケーションを開発・運用することができます。

Google Cloud （ GCP ）でアプリケーションを動かすための Compute プロダクトの選び方

Google Cloud （ GCP ）の Compute プロダクトを選ぶ際は、最初に GCE の必要性を判断してください。何故なら、 GCE が必要かどうかは、状況次第で判断しやすいためです。

例えば、既存のアプリケーションをそのままクラウド化したい場合や、仮想マシンでしか要件を満たせない場合などが挙げられます。まずは自社の要件を整理して、先に記載したような希望がある場合には GCE を選択してください。

つまり、適切な Compute プロダクトを選ぶためには「 GCE かそれ以外か」という判断が最初に必要になります。ここから先は、 GCE 以外のプロダクトを選ぶ際のポイントをご説明します。

機能と技術要件

最適な Compute プロダクトを選択するためには、機能と技術要件が大切なポイントになります。 OS 、開発言語、デプロイ形式などを複合的に判断して、最適なプロダクトを選んでください。

以下、各プロダクトの機能と技術要件の一覧表です。
/useful/uploads/2021/06/https-www.topgate.co_.jpgoogle-cloud-compute-product-1.webp

なお、機能と技術要件は評価しやすい指標ですが、それだけで判断せずに他の要素も踏まえて考えることが重要です。

運用（ Day 2 operations ）

運用面においては、 Day 2 operations を重要視することが大切です。ソフトウェアライフサイクルを考える際、 Day 2に該当する「監視、問題発見・修正、最適化」といった要素が、最も負荷の大きい作業になります。そのため、アプリケーション開発・運用を成功に導くためには、この Day 2 の負荷を抑えることが重要なポイントになります。

また、 Day 2 operations においては「 Google Cloud （ GCP ）のプロダクト起因で発生する作業がどれだけ少ないか」を判断指標としてください。考えるべき作業としては、メンテナンス、セキュリティ更新、バージョンアップなどの不可避な作業が挙げられます。

その理由として、問題発見や修正、デプロイなどの作業に関しては、プロダクトごとに大きな差がないことが挙げられます。これらはすべてのプロダクトで同じように対応できるため、プロダクト起因の作業に注目することが最適なサービス選択に繋がります。

また、最適化の観点では「サーバーレスなら負荷を減らせるのでは？」と思うかもしれませんが、サーバーレスを利用する場合でもアプリケーションに合わせた知識の習得や最適化が必要となるため、負荷が発生するという点では同じことです。

では、各サービスのプロダクト起因で発生する作業を見ていきましょう。

Compute プロダクト	プロダクト起因で発生する作業
GKE	・コントロールプレーン、ノードのバージョンアップ、セキュリティ対応・Stable チャンネルの場合は数ヶ月に1回・影響度：中〜大
Cloud Run	・特になし
App Engine	・ランタイムのバージョンアップ・低頻度・影響度：中
Cloud Functions	・ランタイムのバージョンアップ・低頻度・影響度：中