Google Cloud （ GCP ）でアプリケーションを動かすにはどのサービスが最適？ Cloud Run 、 GCE 、 GKE、GAE まで一挙に解説！
- Cloud Run
- GCE
- GKE
- アプリケーション
本記事は、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 プロダクトを提供しています。
以下、それぞれのプロダクトについて詳しく解説します。
Google Compute Engine （ GCE ）
Google Compute Engine （以下 GCE と記載）はコンピュートリソースを提供するサービスであり、 CPU や OS などを組み合わせることで、柔軟な環境を作り上げることができる Compute プロダクトです。
OS は Debian や Windows など、様々な選択肢から選ぶことができ、バージョンも数多くのものを取り揃えています。
また、 OS だけではなく CPU や ディスクなども豊富な選択肢が用意されており、自社の要件に合わせた希望通りの環境を Google Cloud ( GCP ) 上に構築することができます。
Google Kubernetes Engine （ GKE ）
Google Kubernetes Engine （以下 GKE と記載）は、文字通り Kubernetes 環境を利用するための Compute プロダクトです。 Kubernetes とは、オープンソースのコンテナーオーケストレーションツールであり、コンテナを動かすためのデファクトスタンダードになっているシステムです。
GKE は、ユーザーが Kubernetes を構築・運用するのではなく、 Google が管理している Kubernetes 環境を利用するサービスになります。そのため、 Kubernetes 自体のアップデートや Kubernetes 環境のオートスケールなどに関しては、 Google がマネージド状態で提供しており、自社に作業負荷をかけることなく Kubernetes 環境を利用することができます。
Cloud Run
Cloud Run はコンテナをサーバーレスで提供している Compute プロダクトです。コンテナとは、 OS （オペレーティング・システム）上に「アプリケーション本体」「必要なライブラリ」「設定ファイル」などをひとまとめにしたものです。
本来、コンテナを扱うためには「 Kubernetes （オープンソースのコンテナーオーケストレーションツール）」を学ぶ必要があり、学習するための時間やコストが発生してしまいます。
単純にコンテナを扱うだけであれば Kubernetes がなくても問題ありませんが、オーケストレーション（設定や管理などの自動化）を行うためには Kubernetes の知識が必要不可欠です。
しかし、 Cloud Run を使えば、コンテナイメージを構築して Cloud Run の上に乗せるだけで、 Kubernetes が提供している様々な機能・強みを享受することができます。
App Engine
App Engine はアプリケーションをサーバーレスで提供している Compute プロダクトであり、一般的には PaaS （ Platform as a Service ）と呼ばれている形態のサービスです。
App Engine はアプリケーションを簡単に構築できることはもちろん、開発者がアプリケーションのソースコード開発に集中できるように設計されています。開発者は作ったソースコードを App Engine の上に乗せるだけで、自動的にアプリケーションの実行環境が完成・提供されます。
また、アプリケーションが動作しているよりも下位のレイヤー（ランタイム、ミドルウェアなど）はフルマネージドサービスとして提供されているため、環境アップデートやパッチ適用などを自社が気にする必要はありません。
さらに、アプリケーションのバージョンも App Engine のプラットフォーム上で管理しているため、アプリケーションの管理にかかる負荷を軽減することができます。
Cloud Functions
Cloud Functions はクラウドサービスを構築して接続するためのサーバーレス環境であり、その名前の通り Functions （関数）をサーバーレスで提供している Compute プロダクトです。
特定のイベント発生をキッカケとして Cloud Functions 上で動いているアプリケーションを呼び出す仕組みとなっています。つまり、 Google Cloud ( GCP ) が提供している様々なサービスの状態変化を感じ取り、一定の条件に基づいて 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 にも当てはまります。また、イベント駆動で使うこともできるため、サーバーレスに該当する部分もあります。
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 、開発言語、デプロイ形式などを複合的に判断して、最適なプロダクトを選んでください。
以下、各プロダクトの機能と技術要件の一覧表です。
なお、機能と技術要件は評価しやすい指標ですが、それだけで判断せずに他の要素も踏まえて考えることが重要です。
運用（ 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 | ・ランタイムのバージョンアップ ・低頻度 ・影響度：中 |
上記の通り、 GKE は比較的プロダクト起因で発生する作業が多めですが、その他のプロダクトはそこまで大きな影響はありません。このように、各プロダクトを使うことでどのような影響が出るのかを正しく認識することが大切です。
コスト
コストに関しては、プロダクトの利用料金だけでなく、潜在的なコストも含めて考えることが重要です。
以下、それぞれ分けてご説明します。
利用料金
以下、各プロダクトの料金体系をまとめた表になります。
利用料金を考える上では、上記のようなコストの考え方やワークロードの特性を理解することが大切です。また、正確なコストを算出する時は、実際のワークロードを用いて試算してください。
潜在的なコスト
潜在的なコストの例としては、以下のようなものが挙げられます。
- Day 2 operations で発生するコスト
- プロダクトの学習コスト
- 将来、他のテクノロジーに移行するコスト
- エキスパートを採用するコスト
このように、プロダクトの利用料金以外にどのようなコストが発生する可能性があるのかを理解して、総合的にコストを判断することが大切です。
Cloud Run に関する質問
Q . Cloud Run に向いていない利用ケースはありますか？
A . Cloud Run はディスクがメモリと共用のため、ステートフルなアプリケーションには適しておりません。
Q . Cloud Run for Anthos は AWS 上の Anthos でも動作しますか？
A .現在はプレビューとなっております。 GA （ General Availability ）をお待ちください。
Q . Cloud Run はどれくらいの時間でインスタンスが起動しますか？
A .アプリケーションの作り方、言語に依る部分も大きいですが、短い場合は秒単位で起動します。
まとめ
本記事では、 Google Cloud ( GCP ) の Compute プロダクトについて、それぞれの特徴とアプリケーションを動かすために最適な Compute プロダクトの選び方をご説明しました。
Google Cloud （ GCP ）では様々な Compute プロダクトを提供しているため、自社の利用目的に合わせて正しいサービスを選択することが大切です。各プロダクトの特徴を理解し、機能、技術要件、運用、コストなど、多角的な観点から適切なプロダクトを選んでください。
そうすることで、自社の状況に合った Compute プロダクトを正しく選択でき、効率的にアプリケーションを開発・運用できます。本記事を参考にして、最適なプロダクトを検討してください。
また、 Google Cloud （ GCP ）を契約するのであれば、トップゲートがオススメです。トップゲート経由で契約することで
- Google Cloud （ GCP ）の利用料金が3% OFF
- クレジットカード不要で請求書払いが可能
- 導入後サポートが充実
など、様々なメリットを享受することができます。
本記事を参考にして、ぜひ Google Cloud （ GCP ）の導入を検討してみてはいかがでしょうか。
弊社トップゲートでは、専門的な知見を活かし、
- Google Cloud (GCP）支払い代行
- システム構築からアプリケーション開発
- Google Cloud (GCP）運用サポート
- Google Cloud (GCP）に関する技術サポート、コンサルティング
など幅広くあなたのビジネスを加速させるためにサポートをワンストップで対応することが可能です。
Google Workspace（旧G Suite）に関しても、実績に裏付けられた技術力やさまざまな導入支援実績があります。あなたの状況に最適な利用方法の提案から運用のサポートまでのあなたに寄り添ったサポートを実現します！
Google Cloud (GCP）、またはGoogle Workspace（旧G Suite）の導入をご検討をされている方はお気軽にお問い合わせください。
この記事を読んだ方へのおすすめ記事をご紹介！
最後までご覧いただきありがとうございます。トップゲート編集部がこの記事を読んだ方におすすめしたい「 Google Cloud Day : Digital ’21 」で発表された、Google Cloud (GCP)関連の最新情報記事を厳選しました。
ご興味ある記事をぜひご覧ください！
2021最新機能を搭載した Cloud Run で高次元なセキュリティ対策を実現！
こんなにあるの？ Google Compute Engine （ GCE ）の2021最新情報やアップデートを一挙紹介！
弊社トップゲートでは、TOPGATE Broadcaster と称してウェビナーを定期開催しております。
- クラウドに関すること
- Google Cloud (GCP) の最新情報やお役立ち情報
- Googleのテクノロジーを活用した生産性の向上に関すること
など、 仕事で差がつく情報を忙しいビジネスパーソンのために短時間でコンパクトにお届けしております。
参加者さまからの「わかりやすかった」「勉強になった」など好評いただいております。取っ付きにくい内容も講師がわかりやすく解説しております。参加費は無料であるウェビナーがほとんどです！
以下のボタンをクリックして、気になるウェビューへお気軽にご参加ください！
メール登録者数3万件！TOPGATE MAGAZINE大好評配信中！
Google Cloud（GCP）、Google Workspace（旧G Suite） 、TOPGATEの最新情報が満載！
