当記事はみずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画で執筆されたものです。

Web サービスの可用性や運用効率を最大化するには、ユースケースにあったコンピューティングプロダクトの選定が重要です。Google Cloud では複数のコンピューティングプロダクトが提供されており、速やかなアーキテクチャ選定ができるようにそれぞれの特徴を体系的に整理することにしました。

G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) が提供している Computing プロダクトについて、それぞれの特徴とユースケース、ノックアウトファクターなどを解説します。

Google Cloud の Computing プロダクト
Google Compute Engine (GCE)
Google Kubernetes Engine (GKE)
Cloud Run
Google App Engine (GAE)
Cloud Functions

Google Cloud の Computing プロダクト

Google Cloud の Computing プロダクトでは、Google が世界各地に保有するデータセンターのインフラリソースを使用し、ユーザーがハードウェアの調達、設定、管理を行うことなくアプリケーションを実行することができます。
大きく分けて 5 種類の Computing プロダクトが存在し、アプリケーションによって適切な環境が提供されるプロダクトを選ぶことが極めて重要です。

プロダクト	提供されるもの
Google Compute Engine (GCE)	特定の OS が動作する仮想マシン (VM)
Google Kubernetes Engine (GKE)	マネージドな Kubernetes クラスタ
Cloud Run	フルマネージドなコンテナ実行環境
Google App Engine (GAE)	フルマネージドなウェブアプリケーション実行環境
Cloud Functions	フルマネージドな関数（コード）実行環境

プロダクトによって、OS やミドルウェア、パッケージなどの構成の柔軟性や、ユーザーが運用管理に責任を持たなければならない範囲が異なり、基本的に構成の柔軟性とインフラの運用負荷はトレードオフの関係になっています。

Google Compute Engine (GCE)

特徴

GCE では、Google Cloud のインフラストラクチャ上で実行される仮想マシンが提供されます。
ユーザーは仮想マシンの CPU、メモリ、ディスク、GPU の構成をプロビジョニングし、実行する OS や追加のソフトウェアを決定することができます。
Computing プロダクトの中では最高の柔軟性があり、他の Computing プロダクトにデプロイできるものは GCE にもデプロイすることができます。
その代わり、OS 以上のレイヤはすべてユーザーが構築・管理する必要があり、最も運用保守にコストがかかるプロダクトとなります。

GCE の詳細については以下の記事もご一読ください。

blog.g-gen.co.jp

料金

GCE においてメインとなる料金はコンピュートリソース（CPU・メモリ）の使用料であり、仮想マシンのために確保したコンピュートリソースの量に応じて、仮想マシンを実行している間、常に料金が発生します。
CPU 数とメモリ量の組み合わせが マシンタイプ としてまとめられており、必要なリソースを確保できるマシンタイプを選択します（カスタムマシンタイプとして CPU 数とメモリ量を個別に選択することも可能）。

Cloud Run や Cloud Functions といったサーバーレスのプロダクトと異なり、仮想マシンが実行されている（コンピュートリソースがその仮想マシンのために確保されている）ときは、何も処理していなくても確保リソース分の料金が発生するため、ホストされているサービスによっては仮想マシンを休日夜間などに停止し、コンピュートリソースを一時的に解放して課金を防ぐ運用を考える必要があります。

また、GCE ではインスタンスの実行時間が 730時間/月 を超えた場合に、継続利用割引 が自動的に適用されます。

参考：Google Compute Engine の料金

ユースケース

仮想マシン用に確保するコンピュートリソース（vCPU数とメモリ量）を柔軟に選択することができ、上限もかなり大きめに設定されているため、Cloud Run などのサーバーレスプロダクトでは実現できないステートフルなアプリケーションの実行に向いています。また、仮想マシンには GPU を追加することもでき、機械学習やデータ処理などの負荷の高いワークロードを高速化することができます。
既存システムの Google Cloud へのマイグレーション（リフト & シフト）。オンプレミスで動作している既存システムの変更を最小限に抑えてクラウド移行したい場合などに選択します。
他のマネージドな Computing プロダクトでは要件を満たせないワークロードで使用します。たとえば、Windows Server や Oracle DB など、システムが特定の OS やライセンスに依存している場合や、サードパーティアプリケーションを実行したい場合などがあります。

参考：Google Compute Engine のユースケース

ノックアウトファクター

Computing プロダクトの中では運用負荷が最も高く、OS やミドルウェアのパッチ適用、可用性の確保など、非機能要件に関する考慮事項が多くなります。
自動スケーリングの設定をすることで負荷の分散ができますが、スケーリングが仮想マシン単位のため、コンテナを使用する他プロダクトと比較するとスケーリング速度が劣ります。

Google Kubernetes Engine (GKE)

特徴

GKE は Google Cloud 上に構成された マネージドな Kubernetes クラスタ が提供されるプロダクトです。
ユーザーはアプリケーションをコンテナ化し、Kubernetes リソースとしてクラスタにデプロイすることで、オートスケーリングやセルフヒーリングなどの Kubernetes によるオーケストレーションの恩恵を受けることができます。

GKE には Standard モードと Autopilot モードの 2 つの運用モードがあります。
Standard モードではユーザー自身がクラスタ構成を詳細に制御することができる代わりに、ノードのスケーリング設定、クラスタのセキュリティ、Kubernetes のバージョン管理なども、ユーザー自身が運用管理する必要があります。
Autopilot モードではクラスタの構成が GKE のベストプラクティスを反映したものになり、運用管理の大部分が自動で行われますが、ユーザーによるカスタマイズ可能な項目が大きく制限されます。

基本的には Autopilot モードの利用が推奨されており、Autopilot モードでは実現できない要件がある場合に Standard モードの利用を検討します。

GKE の詳細については以下の記事もご一読ください。

blog.g-gen.co.jp

料金

GKE では Standard モードと Autopilot モードで課金の単位が異なり、Standard モードでは Kubernetes ノードとして構成されている GCE 仮想マシンの実行時間、Autopilot モードではノードで実行中の Pod がリクエストしている CPU、メモリ、エフェメラルストレージの量だけ料金が発生します。

Standard モードではノードを構成している仮想マシンを停止することができないため、仮想マシンの台数分のリソース料金が常に発生します（GCE 同様、継続利用割引は適用されます）。
それに対して Autopilot モードでは、未使用のリソースに対しては料金が発生せず、クラスタで実行している Pod ごとに設定されたリソースのリクエストに応じて料金が発生します。

また、各モード共通の料金として、クラスタの管理手数料として $74.40/月 の料金が発生します（条件を満たせば 1 クラスタまで無料）。

参考：Google Kubernetes Engine の料金

ユースケース

コンテナを利用するワークロードにおいて、コンテナ実行環境の OS、コンピュートリソース、ネットワーキングなどを完全に制御したい場合に選択します。
GCE 同様、ノード用に確保するコンピュートリソース（vCPU数とメモリ量）を柔軟に選択することができ、サーバーレスのプロダクトでは実装しにくいステートフルなアプリケーションや、GPU を利用するワークロードに向きます。
各機能をコンテナ化し、複数のコンテナでアプリケーションを構成するマイクロサービスアーキテクチャで利用します。フルマネージドのサービスメッシュである Anthos Service Mesh を使用することで、複雑なワークロードにおけるトラフィックの制御、保護を実現することができます。
アプリケーションを OSS である Kubernetes のリソースとして構成することで、オンプレミスや Amazon Elastic Kubernetes Service (EKS) 、Azure Kubernetes Service (AKS) などの GKE 以外の Kubernetes クラスタへの移植が容易になり、ベンダーロックインを回避することができます。また、Google Cloud で提供されている Anthos を利用することで、ハイブリッドクラウド、マルチクラウドに展開した Kubernetes 環境を統合管理することも可能です。

参考：Google Kubernetes Engine のユースケース

ノックアウトファクター

アプリケーションを Kubernetes リソースとしてデプロイするため、Kubernetes を用いた開発・運用の知識が必要となり、アプリケーションのコンテナイメージだけではなく、Kubernetes マニフェストの管理・運用も考慮する必要があります。
Kubernetes は 4 ヶ月に 1 回ほどのマイナーバージョンリリースがあり、非推奨となった API が使用できなくなる可能性があるため、定期的なアップグレード作業が必須となります。マイナーバージョンのサポート期限は 14 ヶ月間となっています。

Cloud Run

特徴

Cloud Run は Google Cloud のフルマネージドなコンテナ実行環境を使用して、インフラストラクチャを運用管理することなく、コンテナを直接実行することができる サーバーレス のプロダクトです。
負荷に応じたスケーリングは Cloud Run が自動で行い、コンテナ単位の高速なスケーリング を行われるほか、処理を行っていないときはコンテナインスタンスの数が 0 までスケールインする のが大きな特徴です。

ユーザーが Docker コンテナのイメージをデプロイするだけで、実行環境や HTTPS エンドポイントのプロビジョニングが自動で行われ、それらの運用管理をユーザー側で行う必要はありません。
また、デプロイ単位がコンテナイメージのため、後述の GAE、Cloud Functions と比べると実行環境の制約が少なく、ある程度のカスタマイズができます。

サーバーレスなウェブアプリケーション実行環境というコンセプトは GAE と共通する部分がありますが、Cloud Run は Knative という OSS をベースとしており、デプロイしたコンテナは GKE やその他 Kubernetes クラスタ上に容易に移植することが可能です。

Cloud Run の詳細については以下の記事もご一読ください。

blog.g-gen.co.jp

料金

Cloud Run では、サーバーレスプロダクトの特徴として、処理のためにプロビジョニングしたリソースの料金ではなく、実際の処理に使用したリソース に料金が発生します。
コンテナインスタンスに割り当てた CPU 数とメモリ量に応じて処理時間あたりの料金が発生し、またコンテナインスタンスがスケールアウトした場合、その分だけ料金が発生します。
前述したように、処理を行わないときはコンテナインスタンスの数を 0 までスケールインし、コンピュートリソースを完全に解放することができるため、ユースケース次第ではかなり安価で利用することが可能です。
反面、料金が実際の処理の量に依存するということは、発生する料金の予測がしにくいという欠点にもなります。

参考：Cloud Run の料金

ユースケース

開発言語の制約を受けず、柔軟かつサーバーレスな実行環境にアプリケーションをホストしたい場合に選択します。ウェブサイトのホスティングや、バックエンド処理の実行環境として使用できます。
Cloud Scheduler をトリガーとした Cron ジョブ、Cloud Storage へのデータ格納をトリガーとした ETL ジョブといったイベントドリブンな定型処理にも利用できます。

参考：Cloud Run のユースケース

ノックアウトファクター

コンテナに対するリクエスト 1 つあたりの処理時間に 最大 60 分 の制約があり、それを超えるとタイムアウトとなります。
インスタンスを 0 までスケールインできる反面、インスタンス数が 0 のときにリクエストがあった場合に、1 つ目のインスタンスが起動されるまでのレイテンシが発生してしまいます（コールドスタート）。コンテナインスタンスの最小数を 1 以上にすることでレイテンシを改善できますが、起動しているインスタンスの料金が常に発生してしまうため、サーバーレスの利点が損なわれてしまいます。
コンテナインスタンスあたりの使用できる CPU 数、メモリ量の上限が GCE、GKE と比べると低く、極端に重い処理を行うのには向いていません。また、GPU を使用することができないため、GPU が必須となるワークロードでは GCE もしくは GKE の使用を検討する必要があります。
VPC 内に作成されるリソース (Cloud SQL や Memorystore など) にプライベート接続するには専用のコネクタインスタンスを VPC に作成する必要があり、構成が複雑になります。

Google App Engine (GAE)

特徴

GAE は Cloud Run 同様、Google Cloud が管理する実行環境に Web アプリケーションをホストすることができるサーバーレスのプロダクトです。
2008 年から提供されている Google Cloud 最初期のプロダクトであり、Cloud Run の前身のような位置づけにありますが、こちらはコンテナイメージではなく、プログラムと設定ファイルをデプロイするだけでアプリケーションを稼働させることができます。

GAE では スタンダード環境 と フレキシブル環境 の 2 種類の実行環境が提供されています。

スタンダード環境ではサポートされる言語の制限があるものの、Cloud Run 同様にサーバーレスな実行基盤にアプリケーションをホストすることができ、Google によって事前構成されたコンテナ環境でアプリケーションが実行されます。
スタンダード環境では、以下の言語がサポートされています（参考）。

Node.js
Python
Go
Java
Ruby
PHP

またスタンダード環境では、Cloud Run 同様、負荷に応じて 0 ~ N 個のインスタンスに高速でスケーリングすることができます。

それに対してフレキシブル環境では、サポートされる言語の制限がなく、アプリケーションはマネージドな GCE 仮想マシン上の Docker コンテナにホストされます。
フレキシブル環境は名前の通り柔軟な構成が可能ですが、GCE 仮想マシン上で動作するため、スタンダード環境のような 0 ~ N のスケーリングはできず、必ず 1 台以上のインスタンスが実行されます。
また、スケーリングが仮想マシン単位となるため、スタンダード環境と比較してスケーリング速度が遅いという欠点があります。

フレキシブル環境ではアプリケーションが GCE 仮想マシン上で動作し、したがってインスタンスは VPC 内で実行されます。
VPC 外で実行されるスタンダード環境のインスタンスや Cloud Run とは異なり、Cloud SQL や Memorystore といった VPC に紐づくリソースをシンプルな構成で利用することができるほか、SSH でインスタンスに接続してデバッグを行うことも可能です。

GAE の詳細については以下の記事もご一読ください。

blog.g-gen.co.jp

料金

GAE の料金設定は環境ごとに異なります。

スタンダード環境では、事前定義された CPU 数とメモリ量の組み合わせである インスタンスクラス によって、インスタンスの実行時間あたりの料金が発生します。
インスタンスクラスには接頭辞が「B」のものと「F」のものがあり、「B」のクラスは 9時間/日、「F」のクラスは「28時間/日」の無料枠があります。
たとえば 2 台のインスタンスが 24 時間実行されている場合、実行時間の合計は 48 時間/日 となるため、「B」のクラスは 39 時間/日、「F」のクラスは 20 時間/日 の料金が発生します。

フレキシブル環境では、GCE と同様にマシンタイプを選択し、マシンタイプに設定された CPU 数、メモリ量に応じてインスタンスの実行時間あたりの料金が発生します。

参考リンク：App Engine の料金

ユースケース

Cloud Run 同様、ユーザの管理が不要な Google マネージドな実行環境にウェブアプリケーションをホストしたいときに選択します。ユーザがコンテナイメージを用意し、それを実行する環境が提供される Cloud Run とは異なり、GAE ではサポートされている言語であれば、アプリケーションコードと設定ファイルをデプロイするだけでアプリケーションを実行することができるため、Cloud Run よりも柔軟性は低くなる代わりに、よりアプリケーションコードの開発のみに集中することができます。

ノックアウトファクター

Google Cloud プロジェクト 1 つあたりにデプロイできる GAE アプリケーションは 1 つとなっています。1 つのサービスに複数の GAE 環境を利用したい場合はプロジェクトを都度作成する必要があり、管理が煩雑になります。
スタンダード環境の GAE では開発言語の制限があるため、サポート対象外の言語でサーバーレスなアプリケーション実行基盤を利用したい場合は Cloud Run を、コンテナイメージの管理をしたくない場合や GAE の機能を利用したい場合はフレキシブル環境の GAE を使用します。
フレキシブル環境の GAE はアプリケーション GCE 仮想マシン上にホストされるため、GCE 同様の料金が発生します。スケーリングの単位が仮想マシンとなるためスケールアウトが遅く、またインスタンス数を 0 までスケールインできないため、「実際に使用したぶんだけ料金を支払う」サーバーレスの特性が損なわれます。

Cloud Functions

特徴

Cloud Functions はいわゆる FaaS (Functions as a Service) と呼ばれるタイプのプロダクトであり、Cloud Run や GAE よりもさらにシンプルに、特定の開発言語で書かれたコードのみをアップロードするだけで、サーバーやコンテナをプロビジョニング、管理することなく処理を実行することができる関数をデプロイすることができます。

Cloud Functions では、以下の言語がサポートされています（参考）。

Node.js
Python
Go
Java
.NET
Ruby
PHP

Cloud Run と同様のサーバーレスなプロダクトであり、処理を行っていないときは関数の実行環境を 0 までスケールインすることができ、需要に応じた高速な自動スケーリングが可能です。第 1 世代と第 2 世代の実行環境が提供されており、最大実行時間の制限などが改善されていることから、現在は後発の第 2 世代の利用が推奨されています。

また、Cloud Functions は Functions Frameworkというオープンソースライブラリにより、Google Cloud 以外の様々な場所に関数を移植して実行することが可能となっています。

Cloud Functions の詳細については以下の記事もご一読ください。

blog.g-gen.co.jp

料金

Cloud Functions の料金は主に 関数の呼び出し回数 と 関数の実行時間 で決定します。
呼び出し回数については 200万回/月 の無料枠があり、関数の用途次第では無料枠の範囲内に収まることもあります。
関数の実行時間あたりの料金は、関数に割り当てたコンピュートリソースに応じて単価が増加します。Cloud Run 同様、処理を行っていないときはコンピュートリソースが確保されないため、料金が発生しません。

参考：Cloud Functions の料金

ユースケース

HTTP リクエストや Pub/Sub 、Google Cloud 上のリソースの更新などのイベントを起点とした、単純な処理を実行することに向いています。デプロイに必要なものはコードのみであり、最小限の運用負荷で処理を実装することができます。Cloud Scheduler をトリガーとした Cron ジョブや、Cloud Storage に格納されたデータの ETL ジョブ、Firebase 上にホストされたアプリケーションのバックエンド処理などのユースケースが一般的です。

参考：Cloud Functions のユースケース

ノックアウトファクター

開発言語の制限があるため、サポートされていない言語を使用してサーバーレスに処理を行いたい場合は、より柔軟な構成ができる Cloud Run による実装を検討します。
Cloud Run 同様、インスタンス数が 0 のときにリクエストがあった場合はコールドスタートが発生します。
第 1 世代の関数ではトリガーの種類を問わず 9 分、第 2 世代の関数では HTTP トリガーが 60 分、イベントトリガーが 10 分の最大実行時間制限があります。このことから、処理時間の長いバッチ処理には向きません。
Cloud Run 同様、Cloud SQL などの VPC に紐付いたリソースへのアクセスには専用のコネクタインスタンスを経由する必要があり、構成が複雑になる上、インスタンスぶんの追加の料金が発生してしまいます。