Google CloudのCloud Runの特徴、サーバレスとの違い、メリットまとめ




Google CloudからCloud Runというマネージドサーバ上でDockerコンテナを起動できるサービスが新たにリリースされました。

 

本記事の内容
  • Cloud Runの特徴
  • Cloud Runを試してみる
  • Cloud Functionsのようなサーバレスとの違い
  • GKEやAWSのECSとの違い

Cloud Runの特徴

まずは下記動画をみるとCloud Runの特徴が理解しやすいです。

 

Cloud Runはコンテナとサーバレスを合わせたもの

動画からCloud Runの要点をまとめるCluud Runはコンテナとサーバレスのいいところを合わせたものと説明されています。

コンテナのメリットは簡単にいうとなんでも自由に使うことができるという点ですね。

  • 任意のプログラミング言語を使える
  • 任意のフレームワークを使える
  • 任意のライブラリを使える

 

サーバレスのメリットはインフラの管理工数の削減と、利用分のみの請求という柔軟さですね。

  • インフラを意識しなくていい
  • 自動スケーリング
  • 使用した分だけの課金

 

これらを合わせたものがCloud Runと説明されています。

 

使い方の説明

Cloud Runは下記手順で実行します。

  1. Define
  2. Publish
  3. Deploy

まずはアプリケーションコードを含んだDockerfileの定義を行います。

チュートリアルではCloud Buildを使ってビルドを行い、Cloud Repositoryにイメージを登録します。

最後にイメージをCloud RunにデプロイすることでURLが発行されアプリケーションにアクセすることができます。

 

Cloud Runを試してみる

Cloud Runには簡単に試せるチュートリアルが用意されているので試してみます。実際にソースコードをDockerイメージに含めてそれをCloud Runで起動するようにします。

 

事前準備

コンポーネントのアップデート、Cloud Runはbeta機能なのでいインストール、us-central1でしかまだ使えないのでリージョンを変更しておきます。

 

Golangソースコードの準備

ディレクトリを作成します。

 

helloworld.goに描きソースコードを書きます。

 

Cloud Buildでビルド

Dockerfileを同じディレクトリに準備します。

 

2つのファイルをCloud Buildでビルドします。

 

Cloud Runにデプロイ

下記コマンドでCloud Runにデプロイが完了するとURLが発行されます。

 

そのURLにアクセスすると初回アクセスはコールドスタートなので遅いですが、2回目以降はすぐにレスポンスが返ってくるようになります。

 

Cloud Functionsのようなサーバレスとの違い

Cloud FunctionsやAWS LambdaのようなFaaSはサーバの管理が必要ないのでアプリケーション開発に集中することができます。

 

Cloud RunはRuntimeやミドルウェアを自由に選択できる

しかし、Runtimeを自由に選択したり、自由にミドルウェアを変更することができません。したがって、クラウドサービスが提供しているFaaSを使うということはそのサービス独自のシステムにロックインされること前提でした。

 

Cloud Runはこのような問題を解決します。起動できるDockerコンテナさえ準備すればどのようなものでもCloud Run上で起動できるので、Runtimeとミドルウェアに制限がありません。

 

Cloud FunctionsではNode.js、Golang、Pythonが使えますが、Cloud Runではそれ以外のどんな言語でも使用できます。

 

Cloud FunctionsなどFaaSのメリットはマネージドサービスとの連携

Cloud Runは自由にコンテナを作ってそれをマネージド環境で扱えるのは非常にメリットが大きいです。

 

Cloud FunstionsやAWS LambdaなどのFaaSのメリットはCloud FirestoreやDynamoDBからのイベントをトリガーに起動できることなので、それぞれお使いどころは明確に分かれるなという印象です。

 

GKEやAWSのECSとの違い

サーバ管理の有無による違いによる

GKEやAWS ECSではサーバの管理が必要になりますが、Cloud Runではサーバの管理が必要になりません。

 

GKEなどでサーバを管理する場合はその内部のネットワークを自由に扱うことができますが、Cloud Runが起動するネットワークをいじることはできません。また、VPCにもアクセスできません。

 

料金

また、GKEやECSは常にサーバを起動しているので使用していなくても課金されますが、Cloud Runは100ミリ秒単位で使用したCPU、メモリ、ネットワークに対しての課金となります。

 

Cloud Functionsでは処理できない、たまにしか起動しない処理はCloud Runを使うことでお金以外のコストも下げることが可能になりそうです。

 

AWS LambdaをKubernetesで使えるものもある

おまけ情報ですが、Cloud Runよりも先にAWS LambdaをKubernetes上で起動できるknative-lambda-runtimeというものが登場していました。

 

今後はクラウドプラットフォームに依存しないサーバレスかつコンテナを起動できるサービスが一つにトレンドになりそうです。

 

まとめ

Cloud Runはこれまでありそうでなかった、マネージド環境で自由にDockerコンテナを起動できる柔軟性が非常に高いサービスです。

 

これまでの使える技術が限定的であったCloud Functionsなどのサーバレスと、コンテナは使えるけどサーバを管理しないといけなかったGKEのいいとこどりのサービスであるCloud Runを積極的に使っていきたいなと思いました。

 

あと、Knativeをベースに作られたCloud Runは今後のトレンドとなるクラウドプラットフォームに依存しないバックエンド構築という点で要チェックな技術です。本日は以上です。

The following two tabs change content below.

髙妻智一

2013年CyberAgent新卒入社 スマホゲームを作る子会社に所属し、サーバーサイドのエンジニアを担当。2年目の終わりから新規子会社の立ち上げに参加し、サーバーサイドのエンジニアリーダーとしてサービースのリリースから運用までを担当。 2018年仮想通貨のスマホウォレットを提供するGinco Incにブロックチェーンエンジニアとして入社。






よく読まれている関連記事はこちら



2 件のコメント

  • 「Cloud FirestoreやAWS LambdaなどのFaaSのメリットは」の部分は、「Cloud FunctionsやAWS LambdaなどのFaaSのメリットは」が正しいでしょうか?

  • コメントを残す

    メールアドレスが公開されることはありません。 * が付いている欄は必須項目です