目次
どうする？コンテナ化する？
boom boom! Hello Cloud!どうも、しみちゃんでございます。
コンテナソリューションが当たり前に選択肢の一つとして挙げられるようになってから久しいですね。「どうする？コンテナ化も視野にいれる？」と突然話題に上がることも少なくありません。
特に、今年のMySQL 5.7のEOL(2023年10月)対応や、来年のCentOS EOL(2024年6月)、や各言語のEOL対応が議題にあがったときに、移行戦略としてリプレイスメントが視野に入ってくるのでコンテナのワードがよく聞こえてきます。
「このプロジェクトのケースはマッチするのかな？」といったことを考える機会が多いので、改めてコンテナソリューションの比較、特に Google Cloud (GCP) のコンテナサービスを比較してきたいと思います。
Cloud Functions vs Cloud Run vs GKE
今回比べるのは Cloud Functions vs GKE vs Cloud Run の3つです。
それぞれのソリューションの特徴、使い勝手、課金など色々比べてみたいと思います。
補足: 「App Engine フレキシブル環境(GAE)もコンテナじゃ？」と言う方もいらっしゃいますが、アプローチとして使用できる言語のランタイムからアプローチすることが多いことや、Cloud RunがそもそもApp Engineのエクスペリエンス改善を目指したサービスであること、GAEを入れると記事が長くなる(本音)ので今回は外しています。(GAE vs Cloud Runはこちらの公式リファレンスを見ていただくと良いでしょう)
それぞれのサービス概要
まず、概要だけさらっと復習しておきましょう。
この部分だけでも十分比較に役に立つ情報です。
Cloud Funcitons とは
デプロイしたコードを関数として実行できるマネージドサービスです。コンテナで動きます。
が、Cloud Functionsは、インフラを管理する必要がなく、コードがあればコンソール上で多少の挙動を指定するだけで関数の実行が可能になります。なのでコンテナだと意識することはほとんどないでしょう。
関数のタイプを以下の2つから選択でき、用途にあわせて選び、使用します。
- HTTP関数: URLエンドポイントを使用して、処理を実行します
- イベントドリブン関数: クラウド上のイベントをトリガーにし、処理を実行します
Cloud Run とは
Cloud Funtionより管理できる領域が多いマネージドサービスです。コンテナで動きます。
コンテナイメージのカスタマイズや特定の言語であればペストプラクティスに従ったソースベースのデプロイができたり、柔軟性が少し高いソリューションになります。
Cloud Run は以下の２種類から基本機能が選択でき、用途に合わせて選び、使用します。
- Cloud Run ジョブ: ウェブ リクエストまたはイベントに応答するコードの実行に使用
- Cloud Run サービス: 作業（ジョブ）を実行し、作業の完了後に終了するコードの
Google Kubernetes Engine(GKE) とは
Cloud Run より更に管理できる領域が多いマネージドサービスです。コンテナで動きます。
Kubernetes(K8s)という強力なコンテナオーケストレーションツールをコアとして動きます。
GKEにはK8sのコンポーネントの他に、2つのオペレーションモードが選択でき、用途に合わせて選び、使用します。
- GKE Autopilot モード: GKEクラスタ、ノード構成、スケーリング、アップグレード、ベースライン セキュリティ構成、ベースライン ネットワーキング構成などを自動管理
- GKE Standard モード: GKEクラスタ、個々のノードの構成などGKEの基盤のみを管理
GKEについて更に詳しく知りたい方は、GKEに絞って紹介しているGKE 入門 2022年度版の記事を参考にしてみてください。
独断と偏見の比較
比較する内容は結果のテーブルを見ていく方が早いでしょう。
視点1: まずはお金
最初に気になるのはやっぱりお金。課金方法と無料課金枠から。
| サービス名 | 課金計算方法 | 金額 | 無料枠 | 無料枠の計算ケース (URLの料金計算ツールの金額を記載しています) | URL |
| Cloud Functions | 1. 呼び出し回数 2. コンピューティング時間 3. データ通信(下り) の合計 | 1. $0.4/100万回 2. Tier1 $0.0000025/GB秒+$0.0000100/GHz秒 3. $0.12/GB(下り) | 1. 200 万回の呼び出し 2. 40万G秒+20万GHz秒 3. 5GBトラフィックデータ量 | 30万リクエスト 200/ms実行時間 400/KB通信量 1/最小インスタンス数 =$4.28 | 料金 料金計算ツール |
| Cloud Run | 1.CPUコンピューティング時間/秒 2.Memoryコンピューティング時間/GiB秒 3.リクエスト回数/100万 | 1. $0.000024/vCPU秒 2. $0.0000025/GiB秒 3. $0.4/100万回 + 通常のネットワーク料金 | 1. 180,000/vCPU秒 2. 360,000/GiB秒 3. 200万回/call | 1. 2/CPU(=12,000) 2. 0.5(=3,000GiB)/GBMemory 3. 3000万回 =$11.2 | 料金 料金計算ツール |
| GKE(Autopilot) 汎用Pod | 1. CPU 2. Memory 3. Storage | 1. $0.0515/vCPU 2. $0.0056998/GB 3. $0.0000635 3. $0.4/100万回 + 通常のネットワーク料金 | $74.40/請求先アカウント毎 | 1. 1/vCPU 2. 512/MiB 3. 512/MiB x 3replica =$132.05 | 料金 料金計算ツール |
| GKE(Standard) | 1. クラスタ管理手数料 2. GCE利用用金 | 1. $0.10 2. GCE利用料金 + 通常のネットワーク料金 | 1. $74.40/請求先アカウント毎(zoneクラスタのみ) | 1. 1リージョナルクラスタ 2. 3node(n1-standrd-2)/GCE利用料 =$343.81 | 料金 料金計算ツール |
※計算東京リージョンに統一(Tier1が適用される)
※完全に無料は難しいので、できるだけ料金を抑えた構成にした場合の計算シュミレーション(だいたい1000円ぐらいに抑えた場合のリクエスト量・処理量)
※GKEについては、GKEの無料枠のみ計算の対象とした
どうでしょうか。それぞれ計算方法が異なるのでぱっと見で比べるのが難しいですね。
Cloud Functions が以外と・・・
料金計算ツールでごにょごにょ計算していて思ったのが、「Cloud Functionsのネットワーク料金には要注意」ということでした。
30万リクエストを計算の基点にしているのですが、これは1万/1日x30日=30万リクエストというわかりやすさ重視の計算から来ています。
Cloud Run や GKE に関しては、通常のネットワーク料金がかかってくるので、それほど意識しなければならない金額になりませんが、上記の表の通信量を300/KB→1/MBに増やすと$35(計算ツール)、また10/MBにすると$352(計算ツール)かかる試算になりました。
開発初期の段階では、下りのネットワーク通信量はあまり意識することが少ないので、リクエスト回数が1日1000~1万回を超える想定ならば、気をつけた方が良いでしょう。
無料枠ならCloud Run？
まず、比較を簡単にするために通常のネットワーク料金の基本的な料金についておさらいしましょう。東京リージョンを例に考えてみます。
通常、VM-VM間の内部トラフィック(例:アジア)においては、$0.05/GBかかります。
| Egress between Google Cloud (GCP) regions within Asia (per GB) | $0.05 |
egress については、TB毎に$0.14~$0.23課金されます(GB換算だと、$0.00014~$0.00023)
| Monthly Usage | Network (Egress) Worldwide Destinations (excluding China & Australia, but including Hong Kong) (per GB in USD) | Network (Egress) China Destinations (excluding Hong Kong) (per GB in USD) | Network (Egress) Australia Destinations (per GB in USD) | Network (Ingress) |
| 0-1 TB | $0.14 | $0.23 | $0.19 | Free |
| 1-10 TB | $0.14 | $0.22 | $0.18 | Free |
| 10+ TB | $0.12 | $0.2 | $0.15 | Free |
Cloud Functionsと比べると、基本的に通常のネットワーク料金の方が安いことがわかります。
となると Cloud Run vs GKE の勝負、となりますが無料枠ならクラスタ料金だけが無料になるGKEと、Cloud Runの以下の無料枠を比べると、断然Cloud Runに軍配が上がるでしょう。
Cloud Runの無料枠:
1. 180,000/vCPUSec
https://cloud.google.com/run/pricing
2. 360,000/GiBSec
3. 200万回/call
視点2: コンピューティング料金をCPUから見た時
別で、CPUコンピューティング料金にフォーカスした図を貼り付けておきます。
VMの場合
| マシンタイプ | 仮想 CPU 数 | メモリ | 料金（米ドル） | プリエンプティブル料金（米ドル） |
|---|---|---|---|---|
| n1-standard-1 | 1 | 3.75GB | $31.17 | $9.67 |
| n1-standard-2 | 2 | 7.5GB | $62.34 | $19.34 |
| n1-standard-4 | 4 | 15GB | $124.68 | $38.68 |
Cloud Functionの場合
$0.0000025/GB秒 * 2592000(1ヶ月)秒 = $6.48 + α(呼び出し+データ通信量)
Cloud Runの場合
$0.000024/vCPU秒 * 2592000(1ヶ月)秒 = $51.84 + α(Memory+ネットワーク料金)
ぱっと見はCloud Functionsが安く見えますが、そこに呼び出し回数と”独自の”データ通信量がのってきて、実際にはVMの方が安いでしょう。基本的に、Google Cloud (GCP) はマネージド要素の強いものほど料金が大きくなりやすい傾向にあります。
視点3: その次は技術的な難易度
これは比較は簡単そうです。
個人的には、サービスを動かしつづけるのに必要な要素を並べてみるのが良いかと思いました。以下、私の独断と偏見で列挙した要素の表です。
| サービス名 | アプリケーションコード | GCPでのサービスパラメータの設定 | Dockerfileなどコンテナの知識 | コンテナのデプロイパイプライン | k8sの知識 | 定期メンテナンス |
| Cloud Functions | 必要 | 必要 | ||||
| Cloud Run | 必要 | 必要 | 必要 | 必要 | ||
| GKE(Autopilot) | 必要 | 必要 | 必要 | 必要 | 必要 | |
| GKE(Standard) | 必要 | 必要 | 必要 | 必要 | 必要 | 必要 |
GKEが圧倒的に多いですね。
ここではCloud Funcitonsは必要な技術的要素が一番低く見えます。おそらく、コンテナ知識0で「すぐ始めよう」とするならば、Cloud Functions か Cloud Runのどちらかから迷うべきでしょう。
だた、GKEに関しては要素数が多いため、なかなか難しい印象を受けますが、その分自由度の高いカスタマイズが可能であるということでもあるので、一概にデメリットともいえない項目になります。
で、結局3つの中でどれがよいのか
一元的な視点で考えるのはなんか微妙かな、と思うので、ケース別にそれぞれアプローチを考えてみます。
“まだ、コンテナの技術についてそれほど知見が溜まってない+シンプルなアーキテクチャ”
このケースだと、間違いなくCloud Runでしょう。無料枠がかなり強力です。上記のケースだと、GAEフレキシブルのソリューションも台頭してきますが、それはまた別の機会というか差別化の方法は公式リファレンスに載っているので、ぜひこちらをご参照ください。
“関数単位の処理を外に出したい時” or “不規則で少ないリクエストが予想される” or “独立した処理”
これは、コンテナだけにとどまらず、メインリソース、たとえばVM上でわざわざ処理する必要がないものは最初に”Cloud Functionはどうだろうか？”と考えても良いでしょう。ただし、あまり数が多くなると管理が煩雑になったり、プロダクトの成長によっては思いもよらない大きな課金を引き起こしてしまうことがあるので注意が必要です。
マネージド要素の多いものほど、利用料金は高い傾向にありますので・・・。
得に、最初は小さなスケールで使用するのが一番無難でしょう。
“うちはバリバリ自社でインフラをやっていくぜ！！” and “複雑なネットワーク構成”
自社でインフラチームを抱えている場合は、GKEを検討しても良いと思います。
ただ、先も述べた通り、Google Cloud (GCP) はマネージド要素が多くなればなるほど料金が高く、逆に自分でマネージする要素が大きくなるほど料金が安くなる傾向にあります。プロダクトが成長するにつれ、ネットワーク構成は徐々に複雑になりがちですし、自社のインフラの知見を溜めておくことも戦略の一つかと思いますので、徐々に自社でマネージする部分を増やしつつ、クラウド利用料金を安くしていくことを目指していく必要があるでしょう。
いきなりGKE Standardを使うぞ！ではなく、Cloud Run -> GKE Autopilot -> GKE Standardと、段階を経て、その時々の要件によって姿を変えていくのが健全かもしれません。
まとめ
結局、ケースによって違う、というありきたりな記事になりましたが、皆様いかがでしたでしょうか。
全体を通して、これはGoogle Cloud (GCP)だけでなく他のクラウドでも言えることですが、マネージド要素の強いサービスを選択肢にいれる時は、「納期」「浮いたエンジニアの工数」「技術レベル」のこの三つの視点を、正しいコスト感で捉えておく考え、もしくは仕組みが必要なのかなと思います。
たぶん、このあたり？↓ですかね
- マネージドを選ぶことでどれだけスピード感が上がるのか
- マネージドを選ぶことでどれだけ運用が楽になる(トラブルが減る)のか
- マネージドを選ぶことでどれだけ求められる技術レベルを落とせるのか
これらのコストの”見える化”に取り組んでいければ「なんか料金が高いな？」「これって適正？」などなんとなく不安をおぼえることも少なくなり、より納得感のあるクラウド利用ができると思います。
