The Good and the Bad of Google Cloud Run

Google Cloud Runの長所と短所

9 min readOct 7, 2019

FaaSとマネージドAPIサービスに関連するCloud Runの一般的な評論―AWS Lambdaとの違い

今回はGoogle Cloud Runの長所と短所についての記事です。Cloud RunとAWS Lambdaとの違いやFaaSとの違いについて詳しく書かれた内容となっています。

ライター： Ben Kehoe

今週Google Cloud NextにおいてGCPは面白そうな新しいサービスを発表しました。それは、Cloud Runというものです。この新しいサービスはこのTwitterのスレッドよりももう少しだけ複雑です。なので、この記事でCloud Runについて説明したいと思います。

この記事では、Google’s Cloud RunとAWS Lambda、そしてAPI Gatewayを比較していきたいと思っています。というのも、私はこれらのサービスやプロバイダーをよく知っているからです。しかし、以下のような私の考えはGoogle Cloud FunctionsとマネージドAPIサービスを含むFaaSに関連するCloud Runについての一般的な評論とします。プロバイダーに関係なく評論します。

What is Cloud Run?

一体、Cloud Runとは何なのでしょうか。

Google’s Cloud Runがあればいつも中のウェブサーバーを伴ったコンテナイメージを引き渡すことができます。そして、メモリー/CPUリソースのコンビネーションを指定し、コンカレンシー(並行性)を保ちます。コンテナ内のロジックはステートレスでなければなりません。

それで、Cloud RunはHTTPエンドポイントの生成を手伝います。リクエストを受けとったり、コンテナにルーティングしたり、多くのリクエストをコントロールできるくらい確実にコンテナが走っているかを確認したりもします。自分のコンテナがリクエストを扱っている一方で、100ミリ秒単位で請求されます。

How is this different than AWS Lambda?

ではAWS LambdaとCloud Runとの違いは一体何でしょうか。

Lambdaの方に似ているように思えますが、でもどういう点が違うのでしょうか？単一のコンテナの中でたくさんのリクエストを取り扱っていますよね。基本的なレベルにおいて、Cloud Runは単にとても素晴らしいロードバランサーとしてのみ機能します。

全てのウェブロジックはコンテナの中にあります。例えば、認証*、バリデーション、エラーハンドリング（エラーの処理）などです。しかし、リソースのユーティライゼーションを測定する代わりに、もしくはロードのためのプロキシである他のメトリックを測定する代わりに、Cloud Runはリクエストを理解し、スケールやルートの方法を知るためにロードの計測としてそれらを直接使います。

注：もしGCP IAM を使っていて、Cloud Runのマネージドバージョン上で走らせているのであれば、そのサービスはあなたの代わりに認証が可能です。カスタムオーソライザーは存在しません。また、将来、Webサーバーに配置するだけではないので、今後もそうなるとは思いません。

Lambdaの中では検証や認証を行わずにすべてをLambdaに渡すようにAPI Gatewayをセットアップできますが、これらの機能を実行する豊富な管理機能を逃してしまうでしょう。

What’s the Good?

Cloud Runの長所は何なのでしょうか？

・コンテナ化したステートレスなウェブサービス使う人たちがものすごくシンプルに利用できるようになり、サーバーレスによる恩恵を受けられるようになる。

・よりよいスケーリングときめ細やかな請求。

・またローカルにテストをするのがとても簡単。コンテナの中はすべての機能を果たす完全装備のウェブサーバーだからです。

What’s the Bad?

Cloud Runの短所は何なのでしょうか？

コンテナの中はすべての機能を果たす完全装備のウェブサーバーなのです！

・サーバーレスのポイントは事業価値にフォーカスしていることである。そして、そのための最善の策は、できるすべてのことのためにマネージドサービスを使うこと。つまり、理想を言えば、ビジネスロジックのためにカスタムコードのみに頼ることである。

・Cloud RunをLambda関数実行環境内でできることと比較しようとすると、論点が変わってくる。

・ポイントは、Lambda内に配置するコード（責任のあるコード）は、より多くのロジックをサービス自体に移動できるため、より小さく、より集中できることである。

The FaaS Model: Handling each request in isolation

FaaS Model:それぞれのリクエストを別々に処理する

API Gatewayがあれば、カスタム承認の利用が可能になります。それは、自分のコードがリクエストを拒否できるという意味です。（そのコードはLambdaの中では何もしません）

ダウンストリームのウェブハンドリングコードへのアクセスをリクエストすることさえも考える必要がない
リクエストハンドラーのLambdaのインボケーション(呼び出し)に費用がかからない
API Gatewayリクエストに対しての支払いも不要
カスタム認証レスポンスはAPI Gatewayによってキャッシュされるため、すべてのリクエストで認証を評価するための費用はかからない

API Gatewayがあれば、今からくるリクエストのスキーマバリデーションを実行できます。もし、そのリクエストがバリデーションに失敗しても、Lambdaが呼び出されることはありません。自分のコードは不正なリクエストの心配をする必要は不要なのです。

注意：API Gatewayのモデルバリデーションは残念なことに、私が先ほど説明したよりももう少し複雑です。このトピックについては近い将来に私と Richard Boydがまた記事を投稿するので、そちらをご覧ください。

FaaSモデルではそれぞれのリクエストが別々に処理されます。これに対して文句を言う人たちもいます。AWSがLambdaをプッシュしていることに不満を持つ人がいるというのも聞いたことがあります。その理由は、ユーザーがリクエスト間でリソース使用量を最適化できないことは、彼らにとって有利だからです。

ただし、使用効率がやや劣る使用モデルには利点があります。つまり、クロストーク効果を心配する必要がないということです。Lambdaでは、あるリクエストが別のリクエストに影響を与える可能性があるかどうかを考える必要はありません。すべてが別々になっているからです。これにより、推論が容易になり、開発プロセスで考える必要があるもう1つのことがなくなります。

セキュリティ対策は難しいものです。コードがセキュリティに関連しているということを可能な限り詳しく調べる能力はとても有効です。セキュリティへの影響を超えたところでは、自分の責任である未確定な要素が少なくなるでしょう。

Cloud RunもまたLambdaのカスタムランタイムとは異なります。カスタムランタイムは最終的な手段であるということ以上に、サーバーを実行する必要はありません。その代わり、 an HTTP クライアントが必要なだけです。これにより、自分のコードがしているのは小さなウェブサーバーとして機能していないということをより明確にしてくれます。

Cloud Run is not FaaS

Cloud RunはFaaSではありません。つまり、Cloud RunはFaaSとは同じものでもなく、類似したものでもないということです。Cloud Runでは基本的にコードの所有権が大幅に増えます。 Cloud Runはサーバーレスという梯子の上にかかっているしっかりとているツールであり、このサービスにはさらに多くの機能があります。

そして、それが私の一番の懸念材料になのです。Cloud RunとGCPは一般的に従来のアーキテクチャーに満足できるようなシステムをみんなに提供し、完全に管理されたサービスへの可能な限りのアプリケーションという多くの側面をオフロードするサービスフルアーキテクチャーに（ゆっくりと）移行することには大きなメリットがありますが、そのためにはそれらをプッシュすることはしません。

Googleの戦略はクラウドアーキテクチャーに対するソリューションとしてKubernetesをプッシュしようとしています。そして、その理由としては、Kubernetesは、みんながよく知っているアーキテクチャーのパラダイム内にとどまりながら、みんなの問題を上手に解決してくれます。そして、Googleはすべての利用可能な基本的なインフラストラクチャー上にKubernetesレイヤーを生成するという素晴らしい役割を担っています。

しかし、Kubernetes はずっとサーバーを走らせ、サーバーのインフラストラクチャーの概念を排除してくれます。しかし、Kubernetes はCloud Runコンテナ内のようなアプリケーションサーバーを実行し続けることを推奨します。

Kubernetesをオンプレミスに置くという機能はデベロッパーを満足させてくれます。そしては、潜在的にパブリッククラウドへの組織の移行を遅らせる可能性があります。アプリケーション開発の面から見たときの違いはそれほど明白ではなく、オンプレミスであるために高くなる総所有コストが分からなくなります。

Cloud Runは既存のウェブサーバーインフラストラクチャーをより有効に使用できるようにしてくれる一方で、FaaSとサービスフルアーキテクチャーのパラダイムシフトに脅かされてる開発者を安心させてくれます。これにより、より価値に重きを置いた開発アプローチへの移行がさらに遅れることになります。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。