インスタンス管理が不要なサーバレスコンピューティング AWS Lambda・Azure Functions・Cloud Functions について機能・料金比較を行います。
目次
サーバレスコンピューティングとは
サーバレスコンピューティングとは、IaaS のようにインスタンスを起動し続けるのではなく、 外部からのリクエストや、起点となるイベントが発生したときだけプログラムが実行される仕組みです。 FaaS (Function as a Service) と呼ばれることもあります。
各クラウドサービスにおいては、
- Amazon では AWS Lambda
- Azure では Azure Functions
- GCP では Cloud Functions
というサービス名で展開されています。
サーバレスコンピューティングのメリット
IaaS (EC2 や Azure Virtual Machine)・PaaS (Azure App Service や Google App Engine) の場合、 やるべき仕事があろうがなかろうが、インスタンスを維持し続ける必要があり、 その分お金がかかります。また、IaaS や PaaS の起動にはおおむね10秒〜数分程度の時間がかかり、 やるべき仕事があるときだけ起動するのは難しいです。
一方、サーバレスコンピューティングの場合、実行中のみ料金がかかります。 1秒で処理が終了すれば 1秒、0.5秒なら 0.5秒だけの料金です。 また、Docker 等のコンテナ技術を使っているため、短時間で起動ができます。 さらに短時間起動が実現できるため、リクエスト数に応じてスケールさせることができます。
OS やミドルウェアの環境構築や、セキュリティパッチあてなどが不要なのは、 PaaS も FaaS も同様です。
サーバレスコンピューティングは、昔なつかしの CGI (Common Gateway Interface) に似た技術と言えるでしょう。 CGI は下記の流れでした。
- Apache 等の Web サーバが常駐している。
- ブラウザからのリクエストが来たら Perl などのプロセスを起動
- プロセスは環境変数なりを見て、適切な処理をし、レスポンスを返し、プロセスは終了する。
一方、サーバレスコンピューティングは下記です。
- クラウドサービス事業者が、イベントやリクエストを待っている。
- イベントやリクエストが来たら、コンテナを起動し、定義されたプログラムを実行。
- プログラムは適切な処理をし、(必要なら) レスポンスを返し、コンテナは消える (実際は初期化処理を省くために、一定時間内であればコンテナは再利用されます。CGI でも同じアプローチの FastCGI がありましたね)。
使いどころと不向きなところ
サーバレスコンピューティングの使いどころは下記です。
- データ保存: 受け取ったデータを S3 などのオブジェクトストレージや DynamoDB などに保存する。
- データ送信: 受け取ったデータを別システムに送信する。
- データ加工: 画像ファイルが S3 などに配置されると、画像サムネイル生成を行う。
- 定期的なデータ集計: 毎分/毎時間など、なにかしらの値を集計し、集計結果を保存または通知する。
- 通知: Slack やメール等に通知する。
- バッチ実装: 細かなバッチのパーツを作成し、AWS Step Functions などでコントロールする。
- 定期的なデータ削除: N日経過したデータの削除など。
一方、サーバレスコンピューティングに不向きな処理は下記です。
- 長時間実行される処理。AWS の実行時間上限は 5分、GCP は 9分、Azure は 10分です。
- データ連携先がスケールしない場合。例えば受け取ったデータを RDBMS に保存するとして、同時に 1000件データ受信してしまうと RDBMS が受けきれません。
AWS Lambda・Azure Functions・Cloud Functions の機能比較
| – | AWS Lambda | Azure Functions | Cloud Functions |
|---|---|---|---|
| 動作タイプ | サーバレスのみ | サーバレス・App Service (PaaS) | サーバレスのみ |
| 対応言語 | Node.js 6/8, Python2/3, Java, C#, Go, PowerShell, Ruby. カスタムランタイム | Node8/10, C#, F#, Java8, Python3 (プレビュー), Typescript | Node.js 6, Node.js 8, Node.js 10 (beta), Python3, Go |
| 起動方法 | Amazon S3, Amazon DynamoDB, Amazon Kinesis Data Streams, SNS, SES, CloudWatch Logs, CloudWatch Events (スケジュール含む), CodeCommit, Alexa, Lex, API Gateway, CloudFront など (他にもある) | HTTP, Blob Storage, Queue Storage, Event Hubs, タイマー, GitHub, Dropbox | HTTP/HTTPS, Cloud Pub/Sub, Cloud Storage, Firestore, Firebase (DB, Storage, Analytics, Auth), Stackdriver Logging, Cloud SDK |
| OS | Amazon Linux | Windows, Linux (Linux は App Service のみ) | Linux |
| 最大実行時間 | 900秒 | 600秒 (App Service 上なら無制限) | 540秒 |
| 最大実行時間 (個別設定) | ○ | ○ | |
| スケジュール実行 | CloudWatch Events 起点 | タイマートリガーによる cron 書式 | 直接的な方法はなし。Composer → Function、App Engine Cron → App Engine → Pub/Sub → Function、GKE CronJob → Function などがあり得る |
| ファンイン/ファンアウト | × | ○ (Durable Functions) | × |
| インバウンド通信 | 不可 | . | 可 |
| アウトバウンド通信 | 可 | 可 | 可 |
| メモリ | 事前定義 (超過時は即終了) | 実使用量 (最大 1.5GB) | 事前定義 (128MB, 256MB, 512MB, 1GB, 2GB) |
| リクエスト料金 | $0.2/100万リクエスト | 22.4円/100万リクエスト (東日本) (App Service なら無料) | $0.4/100万リクエスト |
| 使用量課金 | メモリ $0.00001667/GB-秒 | 0.001792円/GB-秒 (App Service なら無料) | メモリ $0.0000025/GB-秒、CPU $0.00001/GHz-秒 |
| 課金対象時間 | △ 100ミリ秒単位切り上げ | ◯ 1ミリ秒単位切り上げ | △ 100ミリ秒単位切り上げ |
| 毎月無料枠 | 100万回、400,000 GB-秒 まで無料 | 100万回、400,000 GB-秒 まで無料 | 200万回、400,000 GB-秒、200,000 GHz-秒 まで無料 |
| 一時ディスク | /tmp (500MB) | . | /tmp (tmpfsなので、/tmp を使うとメモリ使用量が上がる) |
| スケール | . | 最大200インスタンス | . |
| 同時実行数制御 | 関数ごとに設定可能 | batchSize指定? EventHub 経由? | 関数ごとに設定可能 |
| リトライ | . | . | . |
| 任意環境構築 | △ カスタムイメージ | ○ Docker対応 | △ ファイルやバイナリ持ち込みは可能 |
| ローカル開発環境 | docker-lambda (公式ツールではない) | △ emulator ( | |
| 動作タイプ | REST, Websocket | ||
| Swagger | ○ | ||
| プライベート | ○ (API Gateway にてプライベートAPIを作成) |
動作タイプについて
| – | AWS Lambda | Azure Functions | Cloud Functions |
|---|---|---|---|
| 動作タイプ | サーバレスのみ | サーバレス・App Service (PaaS) | サーバレスのみ |
AWS Lambda と Google Cloud Functons は、サーバレスな環境しかありません。 一方 Azure Functions は「従量課金プラン」というサーバレスで動作するモードと、「App Service プラン」という PaaS 上で動作するモードがあります。
「App Service」とは、Azure におけるアプリケーション PaaS サービスで、 あらかじめ OS や Web サーバが準備されていて、利用者は Web アプリケーションをデプロイするだけ、というものです。 この App Servce のインスタンス内で、Azure Functions を動作させることができるということです。
もしすでに App Service を利用していて、とりあえず Azure Functions を試してみたいということであれば、 既存 App Service に相乗りするのがよいでしょう。App Service で動かす場合、すでに App Service 分の料金を払っているわけですから、 Azure Functions の料金は無料となります。
対応言語について
| – | AWS Lambda | Azure Functions | Cloud Functions |
|---|---|---|---|
| 対応言語 | Node.js, Python2/3, Java, C#, Go, PowerShell, Ruby | Node8/10, C#, F#, Java8, Python3 (プレビュー), Typescript | Node.js 6, Node.js 8, Node.js 10 (beta), Python3, Go |
最大実行時間について
| – | AWS Lambda | Azure Functions | Cloud Functions |
|---|---|---|---|
| 最大実行時間 | 900秒 | 600秒 (App Service 上なら無制限) | 540秒 |
各サービスとも、最大実行時間に制限があります。 これを超えると強制的に実行が打ち切られます。
- AWS Lambda 900秒 (15分) 2018/10 に 300秒から 900秒に拡大)
- Azure Functions 600秒 (10分) ただし App Service 上なら無制限
- Cloud Funtions 540秒 (9分)
最大実行時間は上記のとおりですが、AWS Lambda・Azure Functions・Cloud Funtions いずれも、各関数それぞれで上記の最大実行時間を短縮設定することが可能です。例えば「この関数は通常は 1秒で終わるはずだから、上限を10秒に設定しておこう」ということができます。
なお、AWS Lambda は 2014年発表当初は 60秒、2015/11 頃 300秒、2018/10 に 900秒と最大秒数が順調に拡大されています。実行時間が長くなったとしても利用者はその分お金を払うのですから、30分とか 1時間でもいけるようになるといいですね。
Azure において App Service (PaaS) 上で動かす場合は、上限時間は無制限となります。