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

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

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でしかまだ使えないのでリージョンを変更しておきます。

$gcloud components update
$gcloud components install beta
$gcloud config set run/region us-central1

Golangソースコードの準備

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

$mkdir helloworld-go
$ cd helloworld-go

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

package main

import (
        "fmt"
        "log"
        "net/http"
        "os"
)

func handler(w http.ResponseWriter, r *http.Request) {
        log.Print("Hello world received a request.")
        target := os.Getenv("TARGET")
        if target == "" {
                target = "World"
        }
        fmt.Fprintf(w, "Hello %s!\n", target)
}

func main() {
        log.Print("Hello world sample started.")

        http.HandleFunc("/", handler)

        port := os.Getenv("PORT")
        if port == "" {
                port = "8080"
        }

        log.Fatal(http.ListenAndServe(fmt.Sprintf(":%s", port), nil))
}

Cloud Buildでビルド

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

# Use the offical Golang image to create a build artifact.
# This is based on Debian and sets the GOPATH to /go.
# https://hub.docker.com/_/golang
FROM golang:1.12 as builder

# Copy local code to the container image.
WORKDIR /go/src/github.com/knative/docs/helloworld
COPY . .

# Build the command inside the container.
# (You may fetch or manage dependencies here,
# either manually or with a tool like "godep".)
RUN CGO_ENABLED=0 GOOS=linux go build -v -o helloworld

# Use a Docker multi-stage build to create a lean production image.
# https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds
FROM alpine

# Copy the binary to the production image from the builder stage.
COPY --from=builder /go/src/github.com/knative/docs/helloworld/helloworld /helloworld

# Run the web service on container startup.
CMD ["/helloworld"]

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

$gcloud builds submit --tag gcr.io/[PROJECT-ID]/helloworld

Cloud Runにデプロイ

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

$gcloud beta run deploy --image gcr.io/[PROJECT-ID]/helloworld

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

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

最新記事 by 髙妻智一 (全て見る)

• Polkadot(Substrate)のアドレスとトランザクションについて - 2023-03-09
• 【無料公開】「Goで始めるBitcoin」3章 Bitcoinノードとの通信　技術書典8 - 2020-03-08
• エンジニアがゼロから技術ブログを書くための方法をまとめました - 2019-05-25