Google App EngineとGoogle Compute Engineの違いは何ですか？
回答:
App EngineはPlatform-as-a-Serviceです。つまり、コードをデプロイするだけで、プラットフォームが他のすべてを実行します。たとえば、アプリが非常に成功した場合、App Engineは増加したボリュームを処理するためのインスタンスを自動的に作成します。
Compute EngineはInfrastructure-as-a-Serviceです。独自の仮想マシンインスタンスを作成して構成する必要があります。これにより、App Engineよりも柔軟性が増し、一般にコストが大幅に削減されます。欠点は、アプリと仮想マシンを自分で管理する必要があることです。
必要に応じて、App EngineとCompute Engineの両方を混在させることができます。どちらもGoogle Cloud Platformの他の部分とうまく連携します。
編集（2016年5月）：
さらに重要な違いの1つ：App Engineで実行中のプロジェクトは、リクエストが来ない場合にインスタンスをゼロにスケールダウンできます。インスタンス時間の寛大な無料割り当てを超えずに数週間進むことができるため、これは開発段階で非常に役立ちます。柔軟なランタイム（つまり、「管理されたVM」）を実行するには、少なくとも1つのインスタンスが必要です。
編集（2017年4月）：
Cloud Functions（現在ベータ版）は、抽象化の点でApp Engineの次のレベルです-インスタンスなし！開発者は、HTTPリクエスト、Cloud Storageの変更など、さまざまなイベントに応答して実行される一口サイズのコードをデプロイできます。
App Engineとの最大の違いは、関数の価格が100ミリ秒あたりであるのに対し、App Engineのインスタンスは15分間非アクティブになった後にのみシャットダウンすることです。もう1つの利点は、Cloud Functionsがすぐに実行される一方で、App Engineへの呼び出しに新しいインスタンスが必要になる場合があり、新しいインスタンスをコールドスタートするには数秒以上かかることがあります（ランタイムとコードによって異なります）。
これにより、Cloud Functionsは（a）まれな呼び出しに理想的です。何かが発生した場合に備えてインスタンスをライブに保つ必要はありません。（b）インスタンスが頻繁にスピンおよびシャットダウンする負荷が急速に変化し、場合によってはさらに多くのユースケースがあります。
基本的な違いは、Google App Engine（GAE）はサービスとしてのプラットフォーム（PaaS）であり、Google Compute Engine（GCE）はサービスとしてのインフラストラクチャ（IaaS）であることです。
アプリケーションをGAEで実行するには、コードを記述してGAEにデプロイするだけでよく、他の問題はありません。GAEは完全にスケーラブルであるため、トラフィックが増加した場合にインスタンスが自動的に取得され、トラフィックが減少するとインスタンスが減少します。実際に使用したリソースに対して課金されます。つまり、アプリが実際に使用したInstance-Hours、転送されたデータ、ストレージなどに対して課金されます。ただし、制限は、Python、PHP、Java、NodeJS、.NET、Ruby、および** Goでのみアプリケーションを作成できることです。
一方、GCEは完全なインフラストラクチャを仮想マシンの形式で提供します。そこに任意のプログラムを作成またはインストールできるため、これらのVMの環境とランタイムを完全に制御できます。実際、GCEはGoogleデータセンターを仮想的に使用する方法です。GCE では、Load Balancerを使用してスケーラビリティを処理するようにインフラストラクチャを手動で構成する必要があります。
GAEとGCEはどちらもGoogle Cloud Platformの一部です。
更新： 2014年3月、GoogleはApp Engineで管理対象仮想マシンという新しいサービスを発表しました。マネージドVMは、アプリエンジンアプリケーションに、アプリプラットフォーム、CPU、メモリオプションよりも少し高い柔軟性を提供します。GCEと同様に、これらのVMでApp Engineアプリケーション用のカスタムランタイム環境を作成できます。App Engineの実際に管理されるVMは、IAASとPAASの間の境界をある程度ぼやけさせます。
簡単に言うと、コンピューティングエンジンは、完全な制御/責任を持つサーバーを提供します。オペレーティングシステムに直接アクセスし、必要なすべてのソフトウェアをインストールします。これは通常、Webサーバーやデータベースなどです。
App Engineでは、基盤となるソフトウェアのオペレーティングシステムを管理しません。アップロードするのはコード（Java、PHP、Python、またはGo）と出来上がりだけです-実行されるだけです...
App Engineは、特に経験の浅い人のために、頭痛の種を節約しますが、2つの重大な欠点があります。可能、または1つの特定の方法でのみ可能（たとえば、ファイルの保存と書き込み）。
または、さらに簡単にするために（GAE StandardとGAE Flexを区別できない場合があるため）：
Compute Engineは仮想PCに似ており、たとえば、小さなWebサイト+データベースを展開します。インストールされたディスクドライブの制御を含むすべてを管理します。ウェブサイトを展開する場合は、DNSのセットアップなどを担当します。
Google App Engine（標準）は読み取り専用のサンドボックスフォルダーのようなもので、そこから実行するコードをアップロードし、残りは心配しません（はい：読み取り専用-ライブラリの固定セットがインストールされており、デプロイできません）自由にサードパーティのライブラリ）。DNS /サブドメインなどのマッピングはとても簡単です。
Google App Engine（フレキシブル）は、実際にはファイルシステム全体（ロックダウンされたフォルダーだけではないようなものであり、標準エンジンよりも強力です（読み取り/書き込み権限があるなど）（ただし、Compute Engineと比較すると少ない） ）。GAE標準では、ライブラリの固定セットがインストールされており、サードパーティのライブラリを自由にデプロイすることはできません。フレキシブル環境では、カスタムビルド環境（Python 3など）を含め、アプリが依存するライブラリをインストールできます。
GAE Standardは対処するのが非常に面倒ですが（Googleでは簡単に聞こえるようにしていますが）、プレッシャーにさらされた場合、それは本当に適切に拡張されます。ロックダウン環境との互換性をテストして確認し、使用するサードパーティライブラリが、GAE標準で動作しない可能性のある他の知られていないサードパーティライブラリを使用していないことを確認する必要があるため、面倒です。実際のセットアップには時間がかかりますが、単純なデプロイメントの場合、長期的に見ればより効果的です。
上記のApp EngineとCompute Engineのメモに加えて、このリストには、Google Kubernete Engineとの比較と、小規模から大規模までの幅広いアプリでの経験に基づくメモも含まれています。その他のポイントについては、Google Cloud PlatformのドキュメントのApp Engine環境の選択ページにあるApp EngineスタンダードとFlexの機能の概要を参照してください。App EngineとKubernetesのデプロイの別の比較については、Daz Wilkin App Engine FlexまたはKubernetes Engineによる投稿を参照してください。
App Engineスタンダード
長所
- 直接費用とアプリの維持費の観点から、トラフィックの少ないアプリにとって非常に経済的です。
- 自動スケーリングは高速です。App Engineの自動スケーリングは、軽量インスタンスクラスF1-F4に基づいています。
- バージョン管理とトラフィック分割は高速で便利です。これらの機能は、App Engine（StandardとFlexの両方）にネイティブに組み込まれています。
- 最小限の管理で、開発者はアプリのみに集中する必要があります。開発者は、GCEのように信頼できるVMを管理したり、GKEのようにクラスターについて学習したりする必要はありません。
- データストアへのアクセスは高速です。App Engineが最初にリリースされたとき、ランタイムはデータストアと同じ場所に配置されていました。その後、Datastoreはスタンドアロン製品のCloud Datastoreとして分割されましたが、App Engine StandardとDatastoreとのコロケーションはそのままです。
- Memcacheへのアクセスがサポートされています。
- App Engineサンドボックスは非常に安全です。GCEまたは他の仮想マシンでの開発と比較して、仮想マシンがオペレーティングシステムレベルで乗っ取られないように独自の注意を払う必要がある場合と比較して、App Engineスタンダードサンドボックスはデフォルトで比較的安全です。
短所
- 一般に、他の環境よりも制約が強いインスタンスは小さくなります。これは迅速な自動スケーリングに適していますが、多くのアプリは、最大96コアのGCEインスタンスサイズなど、より大きなインスタンスの恩恵を受けることができます。
- ネットワークはGCEと統合されていません
- App EngineをGoogle Cloud Load Balancerの背後に置くことはできません。サポートされるランタイムに限定：Python 2.7、Java 7および8、Go 1.6-1.9、およびPHP 5.5。Javaでは、サーブレットが一部サポートされていますが、完全なJ2EE標準はサポートされていません。
App Engine Flex
長所
- カスタムランタイムを使用できます
- GCEネットワーキングとのネイティブ統合
- バージョンとトラフィック管理は標準と同じように便利です
- 大きなインスタンスサイズは、大規模で複雑なアプリケーション、特に大量のメモリを使用できるJavaアプリケーションに適している場合があります。
短所
- ネットワーク統合は完全ではありません-内部ロードバランサーや共有仮想プライベートクラウドとの統合はありません
- マネージドMemcacheへのアクセスは一般には利用できません
Google Kubernetes Engine
長所
- コンテナーとのネイティブ統合により、カスタムランタイムが可能になり、クラスター構成をより詳細に制御できます。
- 不変のランタイム環境や以前のバージョンに簡単にロールバックできる機能など、仮想マシンを操作する多くのベストプラクティスを具体化します
- 一貫性のある再現可能な展開フレームワークを提供します
- クラウドとオンプレミス間の移植性のためのオープンスタンダード、特にKubernetesに基づいています。
- バージョン管理はDockerコンテナーとGoogle Container Registryで実行でき ます
短所
- トラフィックの分割と管理は自分で行うことができ、おそらくIstioとEnvoyを活用します
- ある程度の管理オーバーヘッド
- ポッド、デプロイメント、サービス、イングレス、名前空間などのKubernetesの概念を強化する時間
- プライベートクラスター（現在ベータ版）を使用していない限り、一部のパブリックIPを公開する必要がありますが、その必要はありませんが、kubectlコマンドを実行する場所へのアクセスを提供する必要があります。
- 監視の統合が不完全
- L3内部負荷分散はKubernetes Engineでネイティブにサポートされていますが、L7内部負荷分散は自分で行うことができ、おそらくEnvoyを活用します
Compute Engine
長所
- 簡単にランプアップ-KubernetesやApp Engineでランプアップする必要はなく、以前の経験から知っていることを再利用するだけです。これが、Compute Engineを直接使用する主な理由です。
- 完全な制御-多くのCompute Engine機能を直接活用して、お気に入りのものすべての最新のものをインストールして、最先端にとどまることができます。
- パブリックIPは必要ありません。パブリックIPで何かが公開されている場合、一部のレガシーソフトウェアはロックダウンするのが難しい場合があります。
- Container-Optimized OSを利用してDockerコンテナを実行できます
短所
- Cloud Launcherを含むさまざまな場所のソリューションを再利用できますが、大部分は日曜大工です。これは信頼性とセキュリティのために適切に行うのが難しい場合があります。
- より多くの管理オーバーヘッド。Compute Engineには多くの管理ツールがありますが、App EngineやKubernetes Engineのモニタリングツールのように、アプリケーションのデプロイ方法を必ずしも理解しているとは限りません
- 自動スケーリングはGCEインスタンスに基づいており、App Engineよりも遅い場合があります
- 傾向は、スノーフレークGCEインスタンスにソフトウェアをインストールすることです。
すでに説明したように、Google Compute Engine（GCE）はサービスとしてのインフラストラクチャ（IaaS）であり、Google App Engine（GAE）はサービスとしてのプラットフォーム（PaaS）です。次の図を確認して、違いをよりよく理解することができます（ここから引用し、詳しく説明しています）-
Google Compute Engine
GCEは、Google Cloud Platform（GCP）から提供される重要なサービスです。これは、ほとんどのGCPサービスが管理レイヤーの下にあるGCEインスタンス（VM）を使用しているためです（どちらが使用されているかわかりません）。これにはApp Engine、Cloud Functions、Kubernetes Engine（以前のContainer Engine）、Cloud SQLなどが含まれます。GCEインスタンスはそこで最もカスタマイズ可能なユニットであるため、アプリケーションが他のGCPサービスで実行できない場合にのみ使用する必要があります。ほとんどの場合、最小限の変更で済むため、GCEを使用してOn-PremアプリケーションをGCPに転送します。その後、アプリの別のコンポーネントに他のGCPサービスを使用することを選択できます。
Google App Engine
GAEは、GCPが提供する最初のサービスです（Googleがクラウドビジネスに参入するずっと前から）。0から無制限のインスタンスに自動スケーリングします（下にあるGCEを使用します）。標準環境とフレキシブル環境の2つのフレーバーが付属しています。
スタンダード環境は非常に高速で、誰もアプリを使用していない場合は0インスタンスにスケールダウンし、数秒でスケールアップおよびスケールダウンし、キャッシング、認証などのための専用のGoogleサービスとライブラリがあります。スタンダード環境の注意点は、非常に制限が厳しいことです。サンドボックスで実行されるためです。特定のプログラミング言語に対してのみマネージランタイムを使用する必要があります。最近追加されたのは、Node.js（8.x）とPython 3.xです。古いランタイムは、Go、PHP、Python 2.7、Javaなどで使用できます。
フレキシブル環境は、Dockerコンテナーを使用するときにカスタムランタイムを使用できるため、よりオープンです。したがって、提供されたランタイムでランタイムが使用できない場合は、実行環境用の独自のdockerfileをいつでも作成できます。ただし、誰もアプリを使用していない場合でも、少なくとも1つのインスタンスを実行している必要があります。さらに、スケールアップとスケールダウンには数分かかります。
GAEフレキシブルとKubernetes Engineを混同しないでください。後者は実際のKubernetesを使用し、より多くのカスタマイズと機能を提供します。GAE Flexは、ステートレスコンテナーが必要で、アプリケーションがHTTPまたはHTTPSプロトコルのみに依存している場合に役立ちます。他のプロトコルの場合、Kubernetes Engine（GKE）またはGCEが唯一の選択肢です。より詳しい説明については、他の回答を確認してください。
App Engineを使用すると、開発者はGoogle Compute Engineコアを制御でき、Google Compute Engineデータ処理アプリケーションにWebに接続するフロントエンドを提供できます。
一方、Compute Engineは、仮想マシンの直接かつ完全なオペレーティングシステム管理を提供します。アプリを提示するには、リソースが必要になります。GoogleCloud Storageは、アセットやデータの用途に関係なく、それらを格納するのに最適です。世界中でホスティングすることで、高速なデータアクセスが可能になります。信頼性は99.95％のアップタイムで保証されており、Googleはデータをバックアップおよび復元する機能も提供します。
Google Cloud Storageを使用してアセットを管理し、保存、取得、表示、削除できます。Cloud Storageに保持されているフラットなデータシートをすばやく読み書きすることもできます。Google Cloudラインナップの次はBigQueryです。BigQueryを使用すると、膨大な量のデータを分析でき、数百万のレコードを数秒で処理できます。アクセスは、単純なUI、Representational State Transfer、またはRESTインターフェースを介して処理されます。
データストレージは、ご想像のとおり、問題ではなく、数百TBまで拡張できます。BigQueryには、Java、.NET、Python、Go、Ruby、PHP、JavaScriptなどのクライアントライブラリのホストを介してアクセスできます。NoSQLと呼ばれるSQLのような構文が利用可能で、これらのクライアントライブラリまたはWebユーザーインターフェイスからアクセスできます。最後に、Google CloudプラットフォームのデータベースオプションであるCloud SQLとCloud Datastoreについて説明します。
大きな違いがあります。Cloud SQLはリレーショナルデータベース、主にMySQL用ですが、Cloud DatastoreはnoSQLを使用する非リレーショナルデータベース用です。Cloud SQLでは、データベースインスタンスごとに100 GBのストレージと16 GBのRAMを使用して、米国、ヨーロッパ、またはアジアのいずれかでホスティングを選択できます。
Cloud Datastoreは、1か月あたり最大50 Kの読み取り/書き込み命令と1か月あたり1 GBのデータを保存するために無料で利用できます。ただし、これらの割り当てを超えると料金がかかります。App Engineは、APIバックエンドを作成するためのCloud Endpoints、データ分析と傾向予測のためのGoogle Prediction API、または多言語出力のためのGoogle Translate APIを含む、Google Cloudプラットフォームの他のあまり知られていない、ターゲットを絞ったメンバーと連携することもできます。
App Engineだけでかなりの量を実行できますが、他のGoogle Cloud Platformサービスで簡単かつ効率的に機能する能力を考慮に入れると、急上昇する可能性があります。
私にはわかりやすい方法で説明します。
Compute Engine：自分でやる人、またはITチームがいて、特定のOS（Linuxなど）が搭載されたコンピューターをクラウドでレンタルしたい場合は、Compute Engineを使用します。あなたは自分ですべてをしなければなりません。
App Engine：（たとえば）Pythonプログラマーであり、実行中のWebサーバーを備えたLinuxと、統合に必要なモジュールといくつかのプラグインを備えた最新のpython 3を備えた、事前設定されたコンピューターをクラウド上でレンタルしたい場合他の外部サービスでは、App Engineを使用します。
サーバーレスコンテナー（Cloud Run）：ローカルセットアップ環境の正確なイメージ（例：python 3.7 + flask + sklearn）をデプロイしたいが、サーバー、スケーリングなどを処理したくない場合。コンテナーを作成します。 （Dockerを介して）ローカルマシン上で、それをGoogle Runにデプロイします。
サーバーレスマイクロサービス（クラウド関数）：特定の仕事を行う一連のAPI（関数）を記述したい場合は、Google Cloud関数を使用します。これらの特定の機能に焦点を合わせるだけで、残りのジョブ（サーバー、メンテナンス、スケーリングなど）は、機能をマイクロサービスとして公開するために行われます。
深く掘り下げていくと、ある程度の柔軟性が失われますが、不必要な技術的な側面について心配する必要はありません。また、少し多めに支払いますが、時間とコストを節約できます（IT部門）。他の誰か（Google）が代行してくれます。
負荷分散やスケーリングなどを気にしない場合は、別のストレージ（データベースまたはBLOBストレージ）に永続的なものを書き込む一連の "ステートレス" Webサービスにアプリを分割することが重要です。次に、Cloud RunとCloud Functionsがいかに素晴らしいかがわかります。
個人的に、私はGoogle Cloud Runが素晴らしいソリューション、開発の絶対的な自由（ステートレスである限り）を見つけ、それをWebサービスとして公開し、ソリューションをドッキングし、Cloud Runでデプロイしました。GoogleをITとDevOpsにしましょう。スケーリングやメンテナンスを気にする必要はありません。
私は他のすべてのオプションを試しましたが、それぞれが異なる目的に適していますが、Google Runは素晴らしいです。私にとって、それは開発の柔軟性を失うことのない本当のサーバーレスです。
Google Compute Engine（GCE）
クラウドでホストされている仮想マシン（VM）。クラウドの前は、これらはしばしば仮想プライベートサーバー（VPS）と呼ばれていました。これらは、オペレーティングシステムのインストールと構成、アプリケーションのインストール、データベースのインストール、OSの最新状態の維持など、物理サーバーを使用するのと同じ方法で使用します。これは、インフラストラクチャと呼ばれます。 as-a-Service（IaaS）。
VMは、データセンターのVMまたはサーバーで既存のアプリケーションを実行していて、それをGCPに簡単に移行したい場合に最も役立ちます。
Google App Engine
App Engineはコードをホストして実行します。オペレーティングシステム、ネットワーク、および物理サーバーやVMで管理する必要のある他の多くのことを処理する必要はありません。アプリケーションを自動的にデプロイ、バージョン管理、スケーリングできるランタイムと考えてください。これはサービスとしてのプラットフォーム（PaaS）と呼ばれます。
App Engineは、アプリケーションの自動デプロイと自動スケーリングが必要な場合に最も役立ちます。アプリケーションがカスタムOS構成を必要としない限り、App Engineは手動でVMを構成および管理するよりも有利です。