この記事では、Functionsの料金プランを説明します。
Functionsの料金プラン
Functions(Functions App)を新規作成する際、以下３つの中から選択することになります。
従量課金プラン
Functionsの従量課金プラン(サーバーレスプラン)は、毎月一定のアプリケーション実行量までは無料で利用できて、それ以降(無料枠分を超えたアプリケーション実行量)が、課金される料金プランです。アプリケーション実行量とは、CPU・メモリなどを使用した量・時間によって計算されます。Azureはコスト面が両親的ですね～。Azure を無料で試したい場合にもいいですよね。ただ・・・アプリケーションの処理時間・応答時間に関してクリティカルなシステム要件がある場合は、従量課金プランは使わないでください。何秒以内に処理を完了させたい！という要件があるのに従量課金プランを使って、文句を言い出してしまうケースが多いです。誰も幸せにならないのでやめましょう。(重要)
作成したFunctionsが従量課金プランなのか調べる方法
Functionsの先頭の概要ページの右側に以下の表示があります。
呼び方が複数ある
Microsoftの情報に、呼び方が４パターンも存在しています！統一してほしいですが、翻訳の影響で仕方ないんですかね。
| 公開情報 | ポータル画面 | 英語資料 | 料金計算ツール |
|---|---|---|---|
| 従量課金プラン | 消費量(サーバーレス) | Consumption | 使用量 |
４つすべて全く同じ意味ですので、覚えておいてください。
従量課金プランの無料枠について
Functionsが毎月無料で使える条件は、以下のいずれかの範囲の場合です。この範囲であれば、ポータル上でFunctions作成・プログラムコードのデプロイ・アプリケーション実行を実施しても、完全無料で利用できてしまいます。
【無料枠の詳細】
実行回数[回] が 月100万回 以下
または、
実行回数[回] と 実行時間[秒] と 平均メモリサイズ[GB] を乗じた結果が、40万GB/秒以下
概算を計算したい方は、後述する料金計算ツール(公式ドキュメント)で「Functionsの使用量」を選択して計算してみてください。
従量課金プランのメリット
- [無料枠まで無料]: Functionsを作成・デプロイ・一定量実行しても課金されません。これがあるから従量課金プランを選ぶ人が多いのかもしれません。ではいつ課金されるかというと、利用者がアクセスしてアプリケーションが動いた量が無料枠の範囲を超えてCPU・メモリが使われた分が課金されます。(これに対して、先述したとおりAppServiceプランは作っただけで、時間単位の課金がはじまります。Free無料プランもありますが。) 注意点として、従量課金プランなのにアプリケーション実行中に数十秒の遅延が発生したぞ！という文句を言う方は、AzureFunctionsの各プランを理解できていないと思います。従量課金プランは、コスト重視のプランであることを理解してください。重要なシステムの場合、必ずAppServiceプランかPremiumプランを利用してください。
- [インスタンスのスペックを選ぶ必要がない]: AppServiceプランを使う場合は適切と思われるスペックを選択する必要がありますが、従量課金プランはサーバ設定などを意識する必要がないので、ポータル画面で「サーバーレス」と表記されてます。
- [Azureが自動でスケールコントロールしてくれる]: 今動作しているインスタンス台数などでは処理を行う上でスペックが足りないとAzureプラットフォーム側が判断した場合、Azureプラットフォーム側が自動でインスタンス台数を増やしてくれたり、処理を行う上で必要な分のメモリを使わせてくれます。よって、AppServiceプランと違って、スペックが足りずに処理の途中でエラー終了してしまうということが、基本的に発生しません。
従量課金プランのデメリット
- [使用できないメトリックがある]:アプリケーションは他ユーザと共有されているインスタンス上で動作するので、アプリケーションごとのCPU使用率の取得などができない。
- [コールドスタートが発生]:しばらく関数が実行されていないと、アイドル状態になり、次回実行された時にメモリ上に展開されるため、アプリケーションの起動に時間(3分,5分とか)がかかる場合がある。
- [エラーや処理遅延が発生することがある]:Azureプラットフォーム側が必要に応じて自動でインスタンス台数を増減してくれますが、アプリケーションの処理内容によってはエラーや処理遅延が発生する場合があります。それを発生させたくなければ、AppServiceプランかPremiumプランを使用する必要があります。ポータル画面で、従量課金プランからAppServiceプランやPremiumプランに変更することはできないので、基本的にはFunctions(関数アプリ)を新規作成する必要があります。従量課金プランは、どんなアプリケーション処理でも動く万能プランではなく、コスト・手軽さ・柔軟さを重要視したプランであると理解してください。安く利用したいけど性能・パフォーマンスも期待したい、という都合の良いものはありません。
Premiumプラン
FunctionsはPremiumプランが推奨です。従量課金プランは、使用されるインスタンスのスペックがあまり高くない上にコールドスタートも発生するのでパフォーマンス面で不安定なプランといえます。(極端にいうと、コスト面しかメリットがないとも言えると思います。)それに比べてPremiumプランは、コールドスタートがない上に、EP1からEP3までスペックを選べます。
既に概要を書いてしまいましたが、以下にPremiumプランのポイントを説明します。
Premiumプランのポイント
- [ゴールドスタートが発生しない]:AppServiceプランと同じように、常にインスタンスが確保されている状態にしてくれます。そのため、コールドスタート(処理開始の遅延)が発生しません。処理時間・応答時間にシビアなアプリケーションの場合は、Premiumプラン(または、AppServiceプラン)を使用してください。
従量課金プランだと、Initializinghost(インスタンスがアクティブ状態になるまでにかかる時間)が発生してしまうので、処理開始が遅延する場合があります。従量課金プランを使って、なぜコールドスタートが発生したんだ！と調べたりする時間は無意味なので、素直にPremiumプランを使用しましょう。
- [Azureが自動でスケールコントロールしてくれる]:従量課金プランと同じく、リクエスト数が増えたら自動でスケールアウトして、増やしたインスタンスが必要なくなったらスケールインしてくれます。AppServiceプランの自動スケールは、いつ・どの程度インスタンスを増やすかの条件を自分で設定する必要がありますが、FunctionsはAzure側のスケールコントローラーが自動判断してくれます。
- [アプリが実行しただけ課金される]:従量課金プランと同じく、利用者がアプリケーションを使用した分だけ課金されます。無料枠もあるので、作ったアプリをデプロイして少し動かす程度なら無料です。
- [３つのプランから選べる]:プランの種類には EP1, EP2, EP3 と３種類あり、EP3が一番スペック(コア数・メモリ量)が高いです。
FunctionsのPremiumプランの公開情報 docs.microsoft.com
料金プランを理解するならやっぱりこの本
実際にかかる課金額(料金計算ツール)
細かい説明はわかったけど、実際にどのくらい課金が発生するんだ・・・については、どのくらいかかりますよと無責任なことを言ってしまうのが難しいので、以下の「料金計算ツール」を参考にしていただければと思います。
料金計算ツールの公開情報
azure.microsoft.com
ご注意いただきたいのは、Functionsを計算するときはStorageAccount・ApplicationInsightsなどは必要に応じて、手動で追加する必要があります。
料金プランごとの制限
このプランじゃないとこの機能は使えない、という制限が色々ありますので、一部の例を紹介します。
AppServiceプランは価格レベルによって使用できる機能が異なる
AppServiceで自動スケール・バックアップ・スロットの機能を使いたい場合は、価格レベルにStandard以上を利用する必要があります。参考に、BasicとStandard以上の場合を比較してみましょう。
Basic
Standard以上
FunctionsのVnet統合
例えばサービスエンドポイント・プライベートエンドポイントを経由してストレージアカウントにアクセスする必要がある場合、Functionsのネットワーク設定でVnet統合(公式ドキュメント)を行う必要が出てきますが、FunctionsでAppServiceプランまたはPremiumプランを利用する必要があります。（従量課金プランではVnet統合できません。）安く使いたい為に従量課金プランを使いたいけどアクセス制御をしたいのであれば、IPアドレス等でアクセス制御をすることになります。
AppService/Functionsの料金プランの説明は、以上になります。
慣れてない方は、料金プランだけでこれだけ色々覚えることがあるのか・・・と感じるかもしれませんが、何か疑問があればコメントいただければと思います。
