More than 1 year has passed since last update.

株式会社エイチームライフデザイン

Microsoft Azure Container AppsとGoogle Cloud Runと比べてみた

Last updated at 2022-11-10Posted at 2022-11-02

Google Cloudの Cloud Run は素晴らしいクラウドサービスだと思っています。

が、一方で代替はあるのか？ということも気になっています。そこでMicrosoft Azureの Container Apps を触ってみました。

前提

2022年10月頃時点の情報をもとに書かれています。

なおGoogle CloudのCloud Runには同名のサービスとしてCloud Run for Anthosがありますが、本稿ではこちらではなく Cloud Run (fully managed) の方を扱います。

共通事項

Cloud RunとAzure Container Appsは、ともに以下のような特徴をもつサービスです。

フルマネージド のクラウドサービスである
- 裏側のインフラ（クラスター、インスタンスなど）を意識する必要がない
- Kubernetes（k8s）ベースの技術だが、k8s自体やそれに似た概念を意識しなくていい
コンテナ を使って任意のアプリケーションを実行できる
- インフラ特有のハンドラなどに依存せず、HTTP等の普通のリクエストを普通に受け取るアプリケーションを構成できる
サーバレス である
- HTTP等のリクエストに応じてサーバが動作して課金される
- 自動でよしなにオートスケールし、リクエストが来ない時はゼロにスケールもできる

こういったような特徴をもつサービスです。要するに コンテナをビルドして、デプロイしたら、すぐ動く というサービスです。
コンテナさえ使っていればアプリケーションに要求される制約がゆるく、ローカルで$ docker composeなどで開発していたアプリケーションをそのままクラウドにぶん投げて動かせます。コンテナとクラウドの両者の利点を活かした強力なサービスだと思っています。

○aaSのような総称があるのかは分かりません。コンテナを中心に動きますがCaaS（Container as a Service）と呼ばれるものとはちょっと違い¹、どちらかというとFaaS（Function as a Service）に近い特性を持つものだと思っています。

個人的に大切だと思っているのがゼロスケールで、AWS AppRunnerはこの点を満たしていなかった²ので比較対象から外しました。³
Scale to zero · Issue #9 · aws/apprunner-roadmap

共通する注意点

もちろん良いところばかりではなくて、Cloud RunとContainer Appsが共通して持っている課題も複数あります。

スケールアウト時のコールドスタート問題
ハイスペックマシンを使いたい場合などインフラ構成の自由度の低さ
フルマネージドであるがゆえの問題発生時の調査・対応のしづらさ

このあたりが大きな問題になるケースにおいては、たとえばコールドスタート時のパフォーマンス低下対策としてCDNを活用するなど、違うサービスでの解決を検討すべきだと思います。

また、インフラやk8sが十分に抽象化されていて意識しなくて良い点を長所として挙げましたが、知識があったほうがより運用しやすいという事も、他のクラウドサービスと同様にあります。

実際に使ってみた

ただコンテナをデプロイして動かすだけなら、同じことができます。次の記事では全く同じソースコード・全く同じDockerイメージで、ふたつのサービスにデプロイしています。

（パラメータ数が違う所からオチが見える）

基本的にはまったく同じアプリケーションをCloud RunとContainer Appsでそのまま動かせます。

比較

歴史

日付	できごと
2018年8月15日	Cloud Run アルファ版リリース
2019年11月14日	Cloud Run GA
2021年11月2日	Azure Container Apps パブリックプレビュー
2022年5月25日	Azure Container Apps GA

Azure Container Appsのほうが新しく、Cloud Runのほうが3年ほど歴史の長いサービスです。

コンセプト

Cloud Runの概念は以下の通り。

▲リソースモデル | Cloud Run のドキュメント | Google Cloudより引用

サービスの中に複数リビジョンがあり、リビジョンの中に複数コンテナインスタンスがあります。比較的シンプルです。
「リビジョン」は、デプロイされたコンテナと環境変数などの設定のセットです。複数あるのは履歴を持っているからです。基本的には最新のリビジョンが使われますが、トラフィックを任意の割合で振り分けてBlue/GreenデプロイやA/Bテストに利用できます。
「コンテナインスタンス」が複数あるのは、オートスケールを表しています。

Azure Container Appsの概念は以下の図の通りです。

▲Azure Container Apps 環境 | Microsoft Learnより引用

環境の中にアプリがあり、アプリの中に複数リビジョンがあり、リビジョンの中にレプリカがあり、レプリカの中にコンテナがあります。
「環境」が仮想ネットワークを構成し、その中に複数のアプリを配置できるようになっています。
「リビジョン」はCloud RunとAzure Container Appsとでほぼ同じ意味と言っていいと思います。
一方で、オートスケールを表しているのは「レプリカ」となっています。そのレプリカの中にさらに複数のコンテナが含まれています。

以下の点が、Cloud Runの図とは少し異なっています。

仮想ネットワークを構成する「環境」がある
「レプリカ」の中に複数コンテナがある

コンテナの種類

いずれもLinuxコンテナ（linux/amd64）にのみ対応しています。

Azure Container AppsはMicrosoftだからWindowsに対応しているとかそういう事はないようです。

裏側の技術

Cloud RunとAzure Container Appsは、いずれもk8sベースになっています。（公言されていたかどうかは怪しいですがおそらく）それぞれのk8sサービスであるGoogle Kubernetes Engine（GKE）とAzure Kubernetes Service （AKS）がバックグラウンドにありますが、先程も述べたとおりそれらを意識しなくても良い設計になっています。

Azure Container Appsは、KEDA、Dapr、Envoyなど、周辺機能もCNCFのOSSの技術の上に作られています。ちょっとMicrosoftらしくない感じですが、嬉しいですね。

最小/最大スケーリングの設定

-	Azure Container Apps	Cloud Run
最小インスタンス数	0〜	0〜
最大インスタンス数	〜30	〜100

いずれも最小インスタンス数・最大インスタンス数を設定して、スケーリングを制御できます。
細かい違いはありますが、インスタンス数が0になると課金が発生しない点、最小インスタンス数を1以上にしてリクエストを処理していない場合「アイドル状態」となり割引が適用されたりする点なども、共通しています。

Cloud Runでは当初は最小インスタンス数を指定できず、放っておくとゼロにスケールしてしまうためコールドスタートの影響を受けやすいという懸念がありましたが、アップデートで解消されています。

オートスケールのトリガー

Cloud Runはシンプルです。最小インスタンス数・最大インスタンス数・最大同時実行数の設定によって、来たリクエストに応じて自動的に増えたり減ったりします。

一方Azure Container Appsは、オートスケールの設定としていくつか選択できます。
HTTPトラフィック・TCPトラフィックで設定すると、Cloud Runとだいたい似たことができます。
また、「CPU・メモリの使用量が一定%以上になったらスケールする」という設定もできます。（この設定の場合、ゼロスケールはできない）
さらにKEDA（Kubernetes Event-driven Autoscaling）でのイベントドリブンスケーリングというのにも対応しており、実際にメッセージキューの溜まり具合によってスケーリングを制御する例が公開されています。
このように、色々と設定できるようになっています。

CPUとメモリのスペック

-	Azure Container Apps	Cloud Run
メモリ最小	512MiB	第1世代は128MiB、第2世代は512MiB
メモリ最大	4GiB	32GiB
vCPUコア最小	0.25	1
vCPUコア最大	2	8

こちらはCloud Runの方が高いスペックのマシンを動かせる印象です。特にメモリが32GiBも使えるので、要求メモリの大きい言語モデルも動かせます。
またAzure Container AppsもCloud Runも、メモリ・vCPUを自由に設定できるのではなく組み合わせに制約があります。Cloud Runのほうが柔軟に設定できる印象です。

一方で、GPUなどハイスペックな環境にはいずれも対応していません。

Azure Container Apps
- Azure Container Apps のコンテナー | Microsoft Learn
Cloud Run
- CPU 制限 | Cloud Run のドキュメント | Google Cloud
- メモリ上限を構成する | Cloud Run のドキュメント | Google Cloud

トリガーの対応

Cloud RunとAzure Container Appsは、いずれも普通にHTTPで叩く以外に、gRPCやWebSocketをサポートしています。

また、HTTP等のリクエストを伴わずバックグラウンドジョブとしてコンテナを実行することもできます。この場合Cloud Runは最大60分でタイムアウトするのですが、Azure Container Appsは時間制限は無く動かしっぱなしにできると言われていた記憶があります（ドキュメント失念）

VPC

Cloud Runでは、「サーバレスVPCアクセス」というのを使ってVPCに外部から接続しに行く形になります。

一方Azure Container Appsですが、コンセプトの項にて「環境」というものを作ってその中にアプリを配置すると説明しました。この「環境」が仮想ネットワークを持っていて、デフォルトだと適当に新規作成されますが、既存の仮想ネットワークに環境を作ってそこにアプリをデプロイもできるようです。

データベースへのアクセス

具体的な例として、コンテナアプリからデータベースへアクセスしたい場合について考えてみます。

Cloud Runでは、「Cloud SQL Auth Proxy」か「サーバレスVPCアクセス」を用いることになります。

Azure Container Appsでは、先述のVNET統合を使ってプライベートなDBにアクセスを確立できると思います。（良い例が見つからず）
サービスコネクタを使ってDBに「マネージドID」で接続情報を秘匿しながらPostgreSQLデータベースにアクセスする例がありました。

サイドカー

Cloud Runでは1サービスあたり1コンテナであり、サイドカーコンテナに非対応です。
これがCloud Runを使わない理由として挙げられる事もあるようです。

一方Azure Container Appsは1アプリに対して複数のコンテナをデプロイするサイドカーパターンに対応しています。Daprを使った実装例がいくつか公開されています。

永続化可能なファイルシステム

サーバレスな仕組みなので原則としてファイルシステムは一時的なものであり、保存したデータなどは通常スケールインした時などに揮発します。そのためアプリケーションの動作コンテナはステートレスに設計するほうがCloud RunやAzure Container Appsで使いやすくなります。

ですが、なんらかの利用でファイルシステムを永続化したい場合。Cloud Runでは第2世代環境であればネットワークファイルシステムを、Azure Container AppsであればAzure Filesを、それぞれマウントすることで永続化されたファイルシステムをコンテナアプリから利用できるようになっています。

料金

東日本リージョン・ドル建ての場合で比較します。

-	Azure Container Apps	Cloud Run
vCPU（$ / vCPU秒）	$0.000024	$0.00002400
メモリ（$ / Gib秒）	$0.000003	$0.00000250
リクエスト（$ / 100 万リクエスト）	$0.40	$0.40

秒単位だとよくわからないので、30日間動作しっぱなしだった場合に換算すると下記です。

-	Azure Container Apps	Cloud Run
vCPU（$ / vCPU 30日間）	$62.208	$62.208
メモリ（$ / Gib 30日間）	$7.776	$6.48

Cloud Runのほうが若干安いですがほとんど同じです。
いずれも無料利用枠が結構用意されているので、少し試す程度であれば無料で利用できると思います。

Cloud Run
- 料金 | Cloud Run | Google Cloud
Azure Container Apps
- Azure Container Apps - 価格 | Microsoft Azure

コンテナレジストリ

Cloud Runは、Google Cloudのレジストリ （Container RegistryまたはArtifact Registry） のイメージをデプロイできます。ローカルでDockerを使ったり、Cloud Buildを使ったりして、ビルドしたイメージを上げてあげる必要があります。

Azure Container Appsには Azure Container Registry も当然ありますが、その他の Docker Hub などのレジストリもサポートされています。

Cloud Runに対するArtifact Registryと、Azure Container Appsに対するAzure Container Registryが出てきました。これらの価格に着目してみます。

Artifact Registryは1GBあたり月額 \$0.1です。
それに対してAzure Container Registryは10GBからで日額\$0.167、つまり30日換算で約\$5となっています。容量の単位が違うので単純比較はできませんが、Azureのほうがかなり高額になっている印象です。

Google Cloud Artifact Registry
- 料金 | Artifact Registry | Google Cloud
Azure Container Registry
- 価格 - Container Registry | Microsoft Azure

サーバ自体の費用に比べると少額になることが多いと思うので、そこまで気にする必要は無いかもしれません。
しかしアプリケーションを頻繁にゼロにスケールインさせる場合、サービス自体の料金はほとんど掛かりませんが、アプリケーションが起動していなくてもコンテナレジストリの料金は継続的に発生するため注意が必要です。

まとめ

Google Cloud RunとAzure Container Appsは、それぞれ単体ではほとんど似たように使うことができます。
Cloud Runの方が歴史があるぶんサービスとしても整っていますが、Azure Container Appsも拡張性に有利があります。
コンセプトとして、Cloud Runは単一コンテナによるコンパクトな構成のサービスを想定しています。一方Azure Container Appsは複数コンテナによるマイクロサービスアーキテクチャを意識しているようです。このあたりは好みが分かれそうです。

いくつか異なる点はありましたが、実際に利用するものをどちらにするか比較する際はこの二者の優劣で決めると言うよりは、Google CloudとMicrosoft Azureの周辺サービスの要件等によって決まる事の方が多いのではないか、と感じました。

こういうクラウドサービスは競合に類似サービスが立つと互いに成長が促進されるイメージですので、両者発展して欲しいと感じました。
特に、よりハイスペックなインスタンスが使えるようになったり、GPUに対応したりしてくれれば、できることが増えると思いました。

参考

Azure Container Apps の特徴と Azure Web Apps / Azure Functions との違い - しばやん雑記

https://cloud-ace.jp/column/detail323/ によると、CaaSとしてGoogle Kubernetes Engineが挙げられている ↩
AWSのWebコンソールやCLIを使って、手動での一時停止・再開はできるらしい ↩
他にも公式のIssueにはWebSocketやHTTP/2など未対応な機能や、不具合のような挙動が残っているなど問題点が多く挙げられている。プライベートエンドポイントも設定不能だったが本稿執筆中に対応されたらしい。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up