この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
この記事はクラスメソッド Google Cloud Advent Calendar 2021の9日目の記事です。
Google Cloud自体ナンもわからないマンが、以前から気になっていたCloud Runをあれこれ動かしながら学んでみた様子をお届けします。もともとAWSのApp Runnerがお気に入りのサービスだったので、それとの機能上の違いも入れています。
（祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 Cloud Run祭りﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ
注意事項：この記事には両者のサービスの優劣をつける意図は全くありません
そもそも、違うプラットフォームに存在するサービスを単独で機能比較して優劣がはっきり出るほど、パブリッククラウドは単純なものではありません。AWSもGoogle Cloudもサービス単体で利用するよりは、そのエコシステムの中でビルディングブロック的に他のサービスと連携して使う前提になっているものが多くあるため、サービス単体での機能優劣は意味がない場合が多いです。
じゃ、そもそもなんでそれらを比べてみようと思ったのか？理由はこんなところです。
- 自分がGoogle Cloudなんも知らない
- App Runnerが好き
- それぞれが似た者同士の匂いがする
Google Cloudを学んでいくとき、多くのAWS経験者は、意識的にも無意識的にもAWSとのマッピングを通してGoogle Cloudを理解している人が多いです。であれば、Cloud Runを知る時に、App Runnerとの違いを感じながらやってみるのが、理解への近道かと思いましたと。
というわけで、App Runnerについて既に知っている人が、Cloud Runを理解するという観点でも参考になれば幸いです。
App Runnerの概要
AWS App Runner – フルマネージド型のコンテナアプリケーション - Amazon Web Services
AWS App Runner は、コンテナ化されたウェブアプリケーションや API を開発者が簡単かつ迅速にデプロイできるフルマネージド型サービスです。大規模に、しかも事前のインフラ経験を必要とせずにデプロイすることができます。
ソースコードからでも、コンテナイメージからでも始められます。App Runner がウェブアプリケーションを自動的にビルドおよびデプロイし、暗号化しつつトラフィックのロードバランスを実行します。
また App Runner は、トラフィックのニーズに応じて自動的にスケールアップまたはスケールダウンします。App Runner を使用すれば、サーバーやスケーリングについて煩わされることもなく、アプリケーションに集中できる時間が増えます。
フルマネージド型との記載がある通り、AWS環境でコンテナをホストする時に通常必要なVPCと関連するネットワークやセキュリティグループなどの設定が皆無、というのが大きな特徴です。
AWS App Runnerのリリースは2021年5月18日。AWSの歴史の中では、かなりフレッシュな新人ですね。
Cloud Runの概要
Cloud Run のドキュメント | Google Cloud
Cloud Run はマネージド コンピューティング プラットフォームで、リクエストまたはイベント経由で呼び出し可能なコンテナを実行できます。Cloud Run はサーバーレスです。インフラストラクチャ管理が一切不要なため、最も重要な作業であるアプリケーションの構築に集中できます。
Cloud Runも基本的な思想として「インフラストラクチャ管理が一切不要」と提示してますね。両者とも、コンテナをインフラを気にせずにホスティングするという点に特化しているのが伺えます。
Cloud RunのGAは、2019年11月14日。歴史の長さを感じますね。
利用できるコンテナレジストリとイメージ
まず最初に、利用できるコンテナレジストリとイメージについて。
App Runnerの場合
App Runner service based on a source image - AWS App Runner
利用できるコンテナレジストリは以下の通り。
- ECR
- ECR Public
ECRは古くからあるAWSフルマネージドなコンテナレジストリで、ECR Publicは、AWSの権限が無くても利用できるパブリックなコンテナレジストリ。
App RunnerでECR Publicが利用できるようになったのは、2021年9月（Release: Direct container launch from Amazon ECR Public Gallery on September 29, 2021 - AWS App Runner）で、さらにre:Invent2021期間中には、なんと、Docker Hubの公式イメージがECR Publicで利用できるようになり（Docker 公式イメージが Amazon Elastic Container Registry Public で利用可能になりました）、より広く手軽に、公式含めた様々なイメージをApp Runnerで利用しやすくなっています。
Cloud Runの場合
コンテナ イメージのデプロイ | Cloud Run のドキュメント | Google Cloud
利用できるコンテナレジストリは以下の通り。
- Container Registry
- Artifact Registry
両者ともGoogle Cloudフルマネージドなコンテナレジストリで、現在は、コンテナイメージのホストはContainer Registryではなく、Artifact Registryが推奨されているようです。
Artifact Registryは2020年11月16日にリリースされた、新しいアーティファクトイメージの格納サービスでコンテナレジストリだけではなく、OSやソースコード、言語パッケージなどのいわゆるアーティファクトを総合的に管理できます。こんなのあるの正直知らんかった。すげぇな。
Container Registryは頻繁にアクセスする公開Docker Hubイメージをmirror.gcr.ioにキャッシュする機能があり、それを使うことでContainer Registry経由でのDocker Hubイメージの利用もできるようです（キャッシュに保存された Docker Hub イメージの pull）。ただ、Docker Hubのレート制限が強めになっている昨今、Google Cloud側でも依存関係をContainer RegistryやArtifact Registryに移行することを推奨されています。
両者共通点
意外だったのは、両者ともDocker Hubのイメージ利用には対応していない点。技術的には問題無さそうに感じるんですが、パブリッククラウドのマネージドサービスからのDocker Hubの利用は、レート制限など厳しくて、Docker Hubから利用を制限されているのかな？と一瞬考えました。
が、よく考えると、AWSでもECSやEKSでは普通にDockr Hubのイメージが利用できますし、それはGKEでも同じ。なのに、コンテナフルマネージドサービスのApp RunnerとCloud Run双方でDocker Hubイメージが利用できないのは、不思議に感じます。
利用できるソースコード
コンテナホスティングのフルマネージドサービスである両サービスですが、Dockerイメージが無くてもソースコードからの直接のホスティングにも対応しています。このあたり、対象ランタイムは今後両サービスとも拡充されていくと思いますが、2021年12月時点での現状をまとめます。
App Runnerの場合
- Python 3
- Nodejs 12
Cloud Runの場合
ソースコードからのデプロイに記載があるとおり、対応言語はこちら。
- Go
- Node.js
- Python
- Java
- .NET Core
詳細なバージョンはこちらに記載があります。
このあたり、Cloud Runのほうが手広い感じですね。.NET Coreまであるのはびっくりした。
コンテナに利用できるキャパシティ
コンテナひとつあたりに設定できるキャパシティ（メモリとCPU）です。ここはスケーリング設定とも綿密に関わってくる点なので、多く設定すればするほど良いというわけではないですが、とりあえず利用可能な設定値を拾ってみました。
App Runnerの場合
明示的に利用できるキャパシティに関するドキュメントが見当たらなかったんですが、とりあえずマネジメントコンソールのプルダウンから拾ってみた結果を記載します。
- メモリ
- 2GB
- 3GB
- 4GB
- CPU
- 1vCPU
- 2vCPU
Cloud Runの場合
公式の関連ドキュメント。
設定可能なキャパシティの一覧です。
- メモリ
- 128MB
- 256MB
- 512MB
- 1GB
- 2GB
- 4GB
- 8GB
- 16GB（Preview）
- CPU
- 1
- 2
- 4
また、現在プレビューですが、Cloud RunにはCPUを常に割り当てる設定があり、受信トラフィックが安定して緩やかであれば、こちらの機能を設定することが推奨されています。また、バックグラウンドタスクやその他非同期処理でもこちらの設定が推奨されています。
このあたり、Cloud Runのユースケースによって、割当の方式を変えることができるのはよいですね。
VPCリソースへのアクセス
両者とも「インフラを意識させない！」という思想が強く出ているサービスですが、そうは言ってもVPCリソースへのアクセスは、根強いニーズがあります。
App Runnerの場合
こちらのRoadmapで議論されていますが、まだ現在利用できません。
issue番号が1ということで、公式側でも一番に認識していた機能だなと伺えますね。2021年11月中旬ぐらいに、Comming Soonに移行していて、もうまもなく、リリースされる予感がしている状態です。
Cloud Runの場合
公式機能として提供されています。
VPC ネットワークへの接続 | Cloud Run のドキュメント | Google Cloud
リリースノート（Cloud Run release notes）を眺めていると、リリースされたのが2020年6月30日。Cloud Run自体のGAからはある程度時間がかかっていることをみても、ここの根強いニーズと、技術的なハードルの高さを感じます。
カスタムドメインの管理
これは、両サービスとも実現可能です。特に指定しない限り、任意のドメインがHTTPSで割り当てられますが、両者それぞれの機構でカスタムドメインの設定ができます。
App Runnerの場合
Managing custom domain names for an App Runner service - AWS App Runner
所有しているRoute 53のドメインからレコードを作成することでカスタムドメインを設定できます。
Cloud Runの場合
カスタム ドメインのマッピング | Cloud Run のドキュメント | Google Cloud
- Firebase Hostingを使用してカスタムドメインを接続
- サーバーレスネットワークエンドポイントグループでHTTPSロードバランサに接続
- Cloud Runのドメインマッピングを使用（プレビュー）
など、複数の方法があります。「サーバーレスネットワークエンドポイントグループでHTTPSロードバランサに接続」は、使い勝手が良いですね。
その他Cloud Runみていてすげぇと思った機能（トリガー方式とその他サービスとの連携）
Cloud Runをトリガーする方式として、思いの外、Google Cloudの他のサービスとの連携処理がマネージドで提供されているものが多かったのが印象的です。ドキュメントのトリガーの章をみてると、いろんなトリガーのパターンが記載されています。
これを利用することで、Cloud Storageからのイベント受信、Cloud Runからの独自のカスタムイベントのパブリッシュができます。
Cloud Tasksと連携して、タスクをキューに格納した後、Cloud Runによって非同期に処理させることが可能。
Cloud Schedulerとの連携も可能と。
その他、Cloud Runを呼び出す機能がもろもろ用意されており、他のサービスとの連携といった部分にも柔軟に対応できるってのは、ユースケースが多くなって良いですね。
- HTTPSでの呼び出し
- WebSocketの使用
- gRPCの使用
- ワークフローの一部としての呼び出し
- Webhookターゲットのホスティング
また、Cloud SQLを通して、MySQL、PostgreSQL、SQL Serverへ接続できるのも、RDB利用のユースケースとして便利ですね。
- Cloud Run から Cloud SQL への接続 | Cloud SQL for MySQL | Google Cloud
- Cloud Run から Cloud SQL への接続 | Cloud SQL for PostgreSQL | Google Cloud
- Cloud Run から Cloud SQL への接続 | Cloud SQL for SQL Server | Google Cloud
Cloud RunはGoogle Cloudの中に深く根ざしているんだなぁとしみじみ感じる
もともと、良いという噂は聞いていたんですが、非常に簡素に利用できるにも関わらず、設定項目が豊富でかつGoogle Cloudの他のサービスとの連携が非常に充実していて、良い意味で裏切られました。
コンテナの可搬性を活用しつつインフラを気にせずデプロイでき、Webホスティングだけにとどまらずに非同期処理やバッチ処理としても利用できるような機能拡充がされていて、Google Cloudのエコシステムの中で無くてはならない存在感を感じましたね。
Google Cloudなんもわからないマンでしたが、そのエコシステムと文化を理解する上で、Cloud Runを触ってみたことは、入り口として非常に良かったなと感じております。また、ここから、いろいろ触ってみたいと思います。
それでは、今日はこのへんで。濱田（@hamako9999）でした。
9
