Cloud Runの特徴と仕様

Cloud Runとはサーバーレスのフルマネージドなコンテナの実行環境です。
言い換えると、開発者はコンテナのイメージを用意するだけでCloud Runでフルマネージドなサーバーを構築することが出来ます。

ここではCloud Runの特徴、類似サービスとの違い、制約事項を説明します。

Cloud Runの特徴

まず、Cloud Runの特徴を説明します。
なお、以降も同様ですが、Cloud Run for AnthosではなくフルマネージドなCloud Runについて説明になります。

利用料金が安い

Cloud Runは使用したリソースに対してのみ課金されるのに加え、無料枠の割り当てもあるので、利用料金を非常に安くすることが可能です。
Cloud Runの料金

TemPlatで構築したプロジェクトではサーバーは自動でCloud Runにデプロイされ、即時に利用可能な状態になりますが、その時点ではGCPの使用料金は発生せず、ある程度のリクエストを受けるまでは無料で利用することが可能です。
言い換えると、リクエストを受けない状態では料金は一切発生しないので、アプリケーションの初期開発でコストを抑えたい場合にはCloud Runは非常に有用です。

デプロイが簡単

Cloud Runにデプロイするために必要なのは、コンテナイメージだけです。
開発者はコンテナイメージをDockerfileを定義してビルドするだけで、Cloud Runにデプロイが可能になります。

なお、TemPlatではこの特徴を活かして、管理画面からビルドを行なったタイミングや、サーバーのソースをPushしたタイミングでCloud Buildを通してコンテナイメージをビルドしてCloud Runにデプロイする環境(CI環境)を構築していますので、開発者はビルドやデプロイを特に意識することなく、Cloud Runでの実行が可能です。

また、用意するのがコンテナイメージだけのメリットとして、他の実行環境に移行しやすい点もメリットです。
詳細は後ほど記載しますが、より大規模なプロジェクトでGoogle Kubernetes Engine(GKE)等に後ほど移行したい場合でも、コンテナイメージはそのまま利用出来るので、一切無駄のない移行が可能です。

言語の制約がない

繰り返しになりますが、Cloud Runにデプロイするために必要なのは、コンテナイメージだけです。
つまり、コンテナイメージとして用意出来るものであれば、言語の制約はありません。
もちろん、コンテナイメージとして用意出来るものであれば、ライブラリやフレームワーク等も自由に選択することが出来ます。

言語やフレームワークの制約がないフルマネージドな実行環境はアプリケーション開発の選択肢を大幅に広げることが可能です。

Cloud Runと他類似サービスとの違い

次に、GCP上で同様にコンテナを実行できるサービスである、Google Kubernetes Engine(GKE)とGoogle App Engine(GAE)との違いを説明します。

Cloud RunとGoogle Kubernetes Engine(GKE)との違い

Kubernetesとは、コンテナベースでサーバーを構築する際に必要となる、コンテナイメージのデプロイ、スケーリング、管理を出来る「コンテナオーケストレーションツール」です。
GCPではこのKubernetesをGoogle Kubernetes Engine(GKE)として提供しており、Cloud Runの登場以前はコンテナベースのサーバーはGKEで構築するのが一般的でした。

Kubernetesではコンテナイメージのデプロイ、スケーリング、管理が行えますが、それには全て定義ファイルで設定を行う必要があり、定義ファイルを用意するにはKubernetes自体の知識が必要になります。
反面、Cloud Runでは定義ファイルは必要なく、自動でフルマネージドなコンテナ実行環境が構築出来ます。
つまり、定義ファイルで細かい設定が行えるのがKubernetesで、自動でフルマネージドなコンテナ実行環境が手に入るのがCloud Runです。

なお、TemPlatが構築するサーバーはコンテナベースなので、Kubernetesでも実行可能です。
Cloud Runでは足りない設定を行いたい場合にはGoogle Kubernetes Engine(GKE)の利用を検討してください。

Cloud RunとGoogle App Engine(GAE)との違い

Google App Engine(GAE)はGCPが提供するフルマネージド型のサーバーレスプラットフォームです。
ここでは詳しい説明は割愛しますが、スタンダード環境ではPython、Java、Node.js、PHP、Ruby、Goの言語がサポートされており、フレキシブル環境では上記の言語のほかにコンテナイメージを実行することが可能です。

なお、TemPlatではWebサーバーにGoogle App Engine(GAE)のスタンダード環境(Node.js)を利用しています。

前途したように、Google App Engine(GAE)のフレキシブル環境はコンテナイメージを実行することが可能で、フルマネージド型なのでオートスケールも可能です。
Cloud RunとGoogle App Engine(GAE)の大きな違いとして、GAEはVM上でビルドされるという点で、デプロイやスケールがCloud Runよりとても遅くなります。
また、GAEのフレキシブル環境のデメリットとして、GAEのフレキシブル環境は0までスケールしないので、常にGCP上の使用料金が発生してしまいます。
(スタンダード環境は使用量に基づいた料金なので、TemPlatのWebサーバーはGCP上の使用料金は使用量に基づいた料金になります。)

上記から、今回のようなコンテナ型のサーバーを構築するのにGAEを使うメリットはありません。

Cloud Runの仕様

Cloud Runのリリース当時はWebSocketsが利用できない等の制約事項がありましたが、現状はあまりありません。
(現状ではWebSocketsも利用可能です。)
ここでは、その他のCloud Runの代表的な仕様をいくつか紹介します。

リクエスト間のメモリの共有は出来ない

Cloud Runはステートレスなコンテナ実行環境です。
簡単に言い換えると、リクエスト(厳密に言うとコンテナインスタンス)ごとにメモリは初期化されます。
つまり、リクエストの情報をメモリに残した状態で次のリクエストの処理で当該メモリの情報を使用することは出来ません。

ローカルのファイルの保存はメモリ上で行われる

Cloud Runで実行されるサーバーではローカルのファイル操作自体は可能です。
ただし、ローカルのファイルは実際にはメモリ上で操作されます。
前途したように、メモリはコンテナインスタンスごとに初期化されますので、ローカルにファイルを保存した場合でも、次のリクエスト時にそのファイルを利用することは出来ません。
また、メモリの最大サイズは8GBなので、それより大きなファイルを保存は出来ません。

もちろん、ローカルではないCloud Storageを利用すれば、上記の制約は無くなりますので、基本的にはCloud Storageを通してファイル操作は行ってください。

SSH接続は出来ない

Cloud Runで実行中のコンテナにSSH接続は基本的には出来ません。
(踏み台経由等で行う方法がない訳ではありませんが、公式な方法ではありません。)

SSH接続が確実に必要な場合は、Google Kubernetes Engine(GKE)の使用を検討してください。
また、デバッグのみが目的の場合はログ機能を有効に活用してください。

4分を超える処理は実行出来ない

コンテナインスタンスの最大起動時間は4分です。
これは1リクエストに対して実行可能な時間が4分という意味です。
つまり、バッググラウンドで長時間の処理を行うような処理はCloud Runでは行うことが出来ません。

バッググラウンドで長時間の処理を行うような処理が必要な場合は、Google Kubernetes Engine(GKE)の使用を検討してください。