LoginSignup
79
38

More than 3 years have passed since last update.

Google Cloud PlatformAdvent Calendar 2019Day 1
@i-dachinEasy Easy

「Cloud functions VS AWS Lambda」を「お金」と「始めやすさ」で勝手に比較してみた

Last updated at Posted at 2019-12-01

この記事は「Google Cloud Platform Advent Calendar 2019」1日目の記事です。

▶ 対決条件

今回は最近流行りのサーバーレスの中でも「Cloud functions」と「AWS Lambda」の２つがどう違うのかを個人的な観点で勝手に比較してみることにしました！

とはいえ漠然と比較するとしても比較のしようもないので、今回は「 お金 」と「 始めやすさ 」という２つの軸で調べて比較することにしてみました！

  • お金

    • 関数に 512 MB のメモリを割り当て、3,000,000 回実行し、毎回の実行時間が1秒間だった場合にかかるお金
    • 実行回数が1,000万の月
    • 実行時間が100msecの月

  • 始めやすさ

    • ドキュメントやチュートリアルなどの充実度に限定

▶ まずは前哨戦、各種サービスの謳い文句を比較

Cloud Functions

イベント ドリブンなサーバーレス コンピューティング プラットフォーム
* クラウドで簡単にコードを実行、スケーリング
* 自動スケーリングによって実現される高い可用性と耐障害性
* プロビジョニング、管理、パッチ適用、アップデートのためのサーバーが不要
* お支払いはコードを実行した時間分だけ
* クラウド サービスを連携、拡張

AWS Lambda

サーバーについて検討することなくコードを実行できます。お支払いいただくのは、実際に使用したコンピューティング時間に対する料金のみです。

AWS Lambda を使用することで、サーバーのプロビジョニングや管理をすることなく、コードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。

Lambda を使用すれば、実質どのようなタイプのアプリケーションやバックエンドサービスでも管理を必要とせずに実行できます。コードさえアップロードすれば、高可用性を実現しながらコードを実行およびスケーリングするために必要なことは、すべて Lambda により行われます。コードは、他の AWS サービスから自動的にトリガーされるよう設定することも、ウェブまたはモバイルアプリから直接呼び出すよう設定することもできます。

所感としては、↓のようにこの時点で既に思想の違いが出ていて面白いですね。
* GCP：　Developer向け？ シンプルに特筆すべき要点だけを整理
* AWS：　ベンダー向け？　このサービスはどんなサービスかという観点で解説のように説明

▶ 比較してみた

▽ お金

なんと言っても重要なのは「いくらかかるか」だと私は思っています。
どんなに使いやすいものでも一回のデバッグに数千円とかかかったり、１アカウント数千円〜万円とかかかるのであればよほど需要があって即座にお金が回収できる宛があるか懐に余裕がなければ気軽に試すことは難しいでしょう。
実際の運用に載せるとしてもやりたいことに対して最適なコストなのかも重要な項目ですのでまずはこちらの項目から比較して行きたいと思います。
　　

さて、比較するとしても簡単な設定があったほうが計算もしやすいので今回は↓の３つのケースで考えてみたいと思います。

  • 関数に 512 MB のメモリを割り当て、3,000,000 回実行し、毎回の実行時間が1秒間だった場合にかかるお金
  • 実行回数が1,000万の月
  • 実行時間が100msecの月

では早速「 月に100万アクセスが来るアプリケーションを作ると想定した時にかかるお金 」をベースとして計算していきます。
各サービスに掛かる料金は↓の公式で求められます。

  • Cloud Functions の料金

    • 関数の呼び出し料金 = (呼び出し回数 - 2,000,000(※1)) x $0.0000004
    • コンピューティング時間(※2) = メモリ利用料金 + CPU利用料金
      • メモリ利用料金 = (利用した時間(秒) x メモリ(GB) - 400,000) x $0.0000025
      • CPU利用料金 = (利用した時間(秒) x CPU(GHz) - 200,000) x $0.0000100
    • ネットワーキング(※34) = (送信データ転送(GB) - 5GB) x $0.12
    • 合計/月 = 関数の呼び出し料金 + コンピューティング時間 + ネットワーキング

  • AWS Lambda 料金 ※5

    • コンピューティング料金(月) = (合計コンピューティング時間 (GB-秒) – 400,000(※1) ) x 0.00001667 USD
      • 合計コンピューティング時間 (GB-秒) = 実行回数 x 実行時間(秒) x メモリ(GB)
    • リクエスト料金(月) = (リクエスト件数 - 1,000,000(※1) ) x 0.20 USD / 1,000,000
    • 合計料金 = コンピューティング料金(月) ＋ リクエスト料金(月)

※1 無料枠
※2 100 ミリ秒単位で測定され、最も近い増分値に切り上げられる
※3 上り（受信）データは無料
※4 同じリージョン内の他の Google API に送信されるデータは、受信データと同様に無料
※5 米国東部 (バージニア北部) 料金の場合

計算式自体はAWSの方がシンプルに見えますが、実際にお得なのはどちらなのかでしょうか。
例題に当てはめて計算して見てみましょう。
今回は前提としてどちらも無料枠が生きている前提で行っていきます。

なお、気づいた方もいるかも知れませんが、この問題はAWSの公式で例題として出している料金プラン例を拝借しております。

○ 関数に 512 MB のメモリを割り当て、3,000,000 回実行し、毎回の実行時間が1秒間だった場合にかかるお金

Cloud functions

式に当てはめて計算していきますが、今回この関数はバックグラウンド関数として請求対象となる下りデータもないこととしておきます。

  • 関数の呼び出し料金 = (呼び出し回数 - 2,000,000) x $0.0000004

    • = (3,000,000 - 2,000,000) x $0.0000004
    • = $0.4

  • コンピューティング時間(※2) = メモリ利用料金 + CPU利用料金

    • メモリ利用料金 = (利用した時間(秒) x メモリ(GB) - 400,000) x $0.0000025
      • = (3,000,000 x 1 x 512 / 1024 - 400,000) x $0.0000025
      • = (1,500,000 - 400,000) x $0.0000025
      • = $2.75
    • CPU利用料金 = (利用した時間(秒) x CPU(GHz) - 200,000) x $0.0000100
      • = (3,000,000 x 1 x 800 / 1000 - 200,000) x $0.0000100
      • = (2,400,000 - 200,000) x $0.0000100
      • = $22

  • ネットワーキング(※34) = (送信データ転送(GB) - 5GB) x $0.12

    • = $0

  • 合計/月 = 関数の呼び出し料金 + コンピューティング時間 + ネットワーキング

    • = 0.4 + 2.75 + 22 + 0
    • = $25.15

Cloud functionsでは「 $25.15/月 」掛かることがわかりました。

AWS Lambda

では次にAWS Lambdaで見てみましょう

  • 合計コンピューティング時間 (GB-秒) = 実行回数 x 実行時間(秒) x メモリ(GB)

    • = 3,000,000 x 1 x 512 ÷ 1024
    • = 1,500,000 GB-秒

  • コンピューティング料金(月) = (合計コンピューティング時間 (GB-秒) – 400,000(※1) ) x 0.00001667 USD

    • = 1,500,000 - 400,000 x 0.00001667
    • = 18.34 USD

  • リクエスト料金(月) = (リクエスト件数 - 1,000,000(※1) ) x 0.20 USD / 1,000,000

    • = (3,000,000 - 1,000,000) x 0.20 USD / 1,000,000
    • = 0.40 USD

  • 合計料金 = コンピューティング料金(月) ＋ リクエスト料金(月)

    • = 18.34 USD ＋ 0.40 USD
    • = 18.74 USD/月

AWS Lambdaでは「 $18.74/月 」掛かることがわかりました。

○ 実行回数が1,000万の月

さて、ベースとなる基準では「AWS」の方に軍配があがりました。
では次はそれぞれの条件が変わったらどうなるかで検証していきましょう。

まずは「実行回数」が単純に増えた場合で比較してみましょう。
他の条件は一緒としてみます。

Cloud functions

  • 関数の呼び出し料金 = (呼び出し回数 - 2,000,000) x $0.0000004

    • = (10,000,000 - 2,000,000) x $0.0000004
    • = $3.2

  • コンピューティング時間(※2) = メモリ利用料金 + CPU利用料金

    • メモリ利用料金 = (利用した時間(秒) x メモリ(GB) - 400,000) x $0.0000025
      • = (10,000,000 x 1 x 512 / 1024 - 400,000) x $0.0000025
      • = $11.5
    • CPU利用料金 = (利用した時間(秒) x CPU(GHz) - 200,000) x $0.0000100
      • = (10,000,000 x 1 x 800 / 1000 - 200,000) x $0.0000100
      • = $78

  • ネットワーキング(※34) = (送信データ転送(GB) - 5GB) x $0.12

    • = $0

  • 合計/月 = 関数の呼び出し料金 + コンピューティング時間 + ネットワーキング

    • = 3.2 + 11.5 + 78 + 0
    • = $92.7

Cloud functionsでは「 $92.7/月 」掛かることがわかりました。

AWS Lambda

では次にAWS Lambdaで見てみましょう

  • 合計コンピューティング時間 (GB-秒) = 実行回数 x 実行時間(秒) x メモリ(GB)

    • = 10,000,000 x 1 x 512 ÷ 1024
    • = 5,000,000 GB-秒

  • コンピューティング料金(月) = (合計コンピューティング時間 (GB-秒) – 400,000(※1) ) x 0.00001667 USD

    • = 5,000,000 - 400,000 x 0.00001667
    • = 76.682 USD

  • リクエスト料金(月) = (リクエスト件数 - 1,000,000(※1) ) x 0.20 USD / 1,000,000

    • = (10,000,000 - 1,000,000) x 0.20 USD / 1,000,000
    • = 1.8 USD

  • 合計料金 = コンピューティング料金(月) ＋ リクエスト料金(月)

    • = 76.682 USD ＋1.8 USD
    • = 78.482 USD/月

AWS Lambdaでは「 $78.482/月 」掛かることがわかりました。

○ 実行時間が100msecの月

ここまではAWS優勢と言ったところでしょうか。
しかし、アプリケーションがちゃんとチューニングをして実行時間が早くなったケースではどうでしょう？

次に実行時間が「100msec = 0.1秒」となったケースで比較してみましょう。
今回も他の条件は一緒としてみます。

Cloud functions

  • 関数の呼び出し料金 = (呼び出し回数 - 2,000,000) x $0.0000004

    • = (3,000,000 - 2,000,000) x $0.0000004
    • = $0.4

  • コンピューティング時間(※2) = メモリ利用料金 + CPU利用料金

    • メモリ利用料金 = (利用した時間(秒) x メモリ(GB) - 400,000) x $0.0000025
      • = (3,000,000 x 0.1 x 512 / 1024 - 400,000) x $0.0000025
      • = $0
    • CPU利用料金 = (利用した時間(秒) x CPU(GHz) - 200,000) x $0.0000100
      • = (3,000,000 x 0.1 x 800 / 1000 - 200,000) x $0.0000100
      • = (2,400,000 - 200,000) x $0.0000100
      • = $0.4

  • ネットワーキング(※34) = (送信データ転送(GB) - 5GB) x $0.12

    • = $0

  • 合計/月 = 関数の呼び出し料金 + コンピューティング時間 + ネットワーキング

    • = 0.4 + 0 + 0.4 + 0
    • = $0.8

Cloud functionsでは「 $0.8/月 」掛かることがわかりました。

AWS Lambda

では次にAWS Lambdaで見てみましょう

  • 合計コンピューティング時間 (GB-秒) = 実行回数 x 実行時間(秒) x メモリ(GB)

    • = 3,000,000 x 0.1 x 512 ÷ 1024
    • = 150,000 GB-秒

  • コンピューティング料金(月) = (合計コンピューティング時間 (GB-秒) – 400,000(※1) ) x 0.00001667 USD

    • = (150,000 - 400,000) x 0.00001667
    • = 0 USD

  • リクエスト料金(月) = (リクエスト件数 - 1,000,000(※1) ) x 0.20 USD / 1,000,000

    • = (3,000,000 - 1,000,000) x 0.20 USD / 1,000,000
    • = 0.40 USD

  • 合計料金 = コンピューティング料金(月) ＋ リクエスト料金(月)

    • = 0 USD ＋ 0.40 USD
    • = 0.4 USD/月

AWS Lambdaでは「 $0.4/月 」掛かることがわかりました。

お金の対決結果

残念ながらCloud FunctionsはAWS Lambdaに価格面では少し割高になってしまうという結果となってしまいました。
しかし、アプリケーションのチューニング次第ではAWS Lambdaと同じくらいのお値段になることは分かりましたので、利用する際には是非ともアプリケーションの実行時間には気をつけて実装していきましょう。

▽ 始めやすさ

次の比較は「始めやすさ」です。
こちらではドキュメントやチュートリアルなどの充実度を比較していこうと思います。

１．公式ドキュメント

  • Cloud functions

    • ドキュメント見やすい
    • LPからもすぐ飛べる
    • サイドメニューは目的別となっているが見出しが他のものと共通なのでパット見で戸惑う人もいるかも
    • https://cloud.google.com/functions/docs/?hl=ja no1.jpg

  • AWS Lambda

    • https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html
    • 文字が多いのとUI的に硬い印象
    • サービスとしてどういうシチュエーションに適しているかがわかるように最初から説明を用意している
    • サイドメニューにはAWS Lambdaの情報だけがまとまっているとわかりやすい no2.jpg

２．公式のチュートリアル

  • Cloud functions

    • シンプルにまとまっている
    • 「とりあえず動かしてみよう」という感じで使うことができる no3.jpg

  • AWS Lambda

    • チュートリアルはあるにはあるが、色々なところに点在している
    • 他のサービスとの関連、という形では詳しく書いてある no4.jpg

３．検索結果の数

  • Cloud functions

　→　約 274,000,000 件

  • AWS Lambda

　→　約 15,400,000 件

使いやすさの結果

所感ではありますが、こちらはGCPの方がドキュメントが充実＆見やすいかと思います。
AWSも丁寧ではありますが少し文字が多いので最初のイメージを掴むのは大変かもしれません。

▶ 結論

何も知らない状態でまずは始めてみよう！というのには公式のドキュメントのわかりやすさや試しやすさからもCloud Functionsの方が簡単そうな感じがします。
しかし、サービスの規模が大きくなってきた場合は単純にはAWSの方が安くなります。

ただ、どちらのサービスでもチューニングをしっかりとしないと大きなコストとなってきてしまうので、使う際はしっかりと運用する必要がありそうです。

79
38
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
79
38