このページの対象者
▶ AppServiceプランでどの価格レベルを選べばいいかわからず、本番環境なのにBasicを選んでしまう方
▶ Functionsの従量課金プランは、アプリが実行された分課金されるプランという説明しかできない方
▶ 従量課金プランとPremiumプランの違いが説明できない方
▶ Premiumプランと聞いただけで高価だろうと選択肢から除外してしまっている方
料金プランを理解できると以下のようになります
▶ AppServiceプランでどの価格レベルを選べばいいかわかる
▶ 課金の発生状況・いつ課金されるかがわかる
▶ 想定外の動作を抑えられる
▶ コールドスタート(アプリ起動までに時間がかかる)に腹を立てることがなくなる
▶ とりあえず従量課金プランを選んでいたがPremiumプランも検討しはじめる
料金プランなんてそんなに大事なのか？と思うかもしれませんが、料金プランによってアプリの動作も変わりますし、このページの内容を理解してないと、壁にぶち当たったり無駄な時間を過ごしてしまうと思います。この機会に、理解を深めていただけたらと思います。
AppServiceの料金プラン
Functions(Function Apps)の場合は３つの料金プランから選択することになりますが、AppService(Web Apps)を新規作成する際は、AppServiceプラン一択になります。
Azureポータル画面でAppServiceを新規作成する際に、AppServiceプランを割り当てることになりますが、既に作成済みのAppServiceプランを選択もできますし、AppServiceの新規作成と同時にAppServiceプランを新規作成することもできます。Azureが勝手に名前を付けてくれたまま進むと適当な名前になってしまうので、新規作成を押してご自身で名前を付け直した方が良いと思います。
AppServiceプランとは
AppServiceプランを作る＝VMサーバを１台レンタルできるイメージです。AppServiceプランを作るとき、サーバスペック(価格レベル)を以下の１８種類の中から選びます。課金の発生は、AppServiceプラン１つに対してかかるので、１つだけアプリケーションをデプロイして動作させても、複数のアプリケーションをデプロイして実行させてもAppServiceプランに課金される金額は変わらないのがポイントです。あと、AppServiceの非同期処理担当のWebジョブ(サイト内リンク)や常時接続機能(Always On)もプラス料金なしで利用できます。
価格レベルを選択
ポータル画面を日本語表示にしてると "価格レベル" ですが、 "sku" とか "tier" と表現されている所もあるので覚えておいてください。結構種類がありますね。選択する価格レベルごとに、サーバの「メモリ数」「コア数」をはじめ、使用できる機能も異なります。後述しますが、開発環境(ステージング環境)ならBasicでもいいですが、本番環境(運用環境)を作るならStandard以上は必須と思ってください。
| Free | Shared | Basic | Standard |
|---|---|---|---|
| - | - | B1 | S1 |
| - | - | B2 | S2 |
| - | - | B3 | S3 |
| PremiumV2 | PremiumV3 | Isolated | IsolatedV2 |
|---|---|---|---|
| P1V2 | P1V3 | I1 | I1V2 |
| P2V2 | P2V3 | I2 | I2V2 |
| P3V2 | P3V3 | I3 | I3V2 |
価格レベルの内容は、公開情報をみれば一目瞭然ですので、以下を参照ください。
AppServiceプラン一覧の公開情報
azure.microsoft.com
Azureをお試しで使いたい人は、Free(F1)を選択すれば無料で試せますが、カスタムドメインが設定できない・デプロイできるAppService/Functionsのアプリ数が合計１０個までなどの制限はあります。Azureを活用する上で制限詳細を把握することはとても重要ですので公式ドキュメントを見てみてください。
制限について公開情報抜粋
本番環境はどの価格レベルが適切なのか
１つのAppServiceプランに複数のアプリケーションをデプロイできますが、AppServiceプラン(サーバ)のリソースは限られているので、CPU使用率やメモリーの許容範囲を超えて動作するとシステムエラーが発生します。
- [テスト・動作確認で使う場合]: Basicでも良いですが、Standard以上でないと使えない機能(自動スケール・スロット・バックアップ等)があるので、リリース前テストのようなときに使う環境はBasicではなくStandard以上の必要があると思います。
- [本番環境(運用環境)で使う場合]: Standard 以上が必須と考えてください。ただ、最低限Standardですが、P1V2, P1V3 以上が推奨とされています。
※ AzureMVPのしばやんさん(外部サイトリンク)もP1V2を推奨してます
たまに本番環境でBasicを使ってしまっている方がいますが、それなりのボリュームのアプリケーションなのであれば、CPU使用率が高くなったのはなぜだ！リソースが足りなくなるのはなぜだ！とやっているのは時間の無駄なので素直にスケールアップ(料金プランを上げる)を検討しましょう。
補足ですが、IsolatedプランはASE(AppServiceEnvironment)構築用の料金プランです。他ユーザのアプリケーションの影響を受けたくない場合などに使う高級(月に数十万円)な専用環境ですが、仮想ネットワーク周りが充実してきて最近は使われる機会がどんどん減っている認識です。
作成したリソースのAppServiceプランの価格レベルが何か調べる方法
AppService/Functionsのスケールアップ(AppServiceのプラン)メニューからも確認できますが、先頭の概要メニューの右側に以下の情報も載っています。
AppServiceプランに登録するアプリ数
登録するアプリ数はいくつが妥当なのか？についてです。答えはケースバイケースとしか言えないのですが、基本的な考え方をお伝えするので参考にしてください。
極端な例ですが、Standardプランのインスタンス１台で２０個のアプリケーションを実行させようとすると、受信した全てのリクエストをパフォーマンスよく処理できず遅延が発生したり、インスタンスのリソースが足りなくなってシステムエラーが発生したりする可能性があります。なので、アプリを登録するたびにAzureサーバが耐えられているのかをご自身で確認・テストする必要があります。ちなみに、HelloWorldをHTMLで表示させるだけのアプリであれば２０個３０個登録して動かしても問題は起きないと思いますが、アプリがそれなりのリソース（メモリー等）を使うアプリなのかということが大きく影響するということを理解してください。（重要）
テストの方法としては、実際にAzureサーバ上で実行させてから、メトリック・問題の診断と解決でAzureサーバの負荷状況・エラー発生状況が確認できます。 負荷が高いと思った場合の対応方法としては、AppServiceプランを分ける・AppServiceプランの価格レベルを上げる・アプリ側で無駄なメモリの使い方をしていないか確認する等が考えられます。また、一つのAppServiceプランにデプロイ～実行する推奨アプリケーション数は、以下ページに記載されているので参考にしてください。ただ、アプリケーションごとの規模によっても変わりますので、テストが必須ということになります。
遅延発生やリソース枯渇が発生した場合の回避方法
アプリケーション実装の見直しが有効なのはもちろんですが、Azure側の設定での回避方法は以下になります。
- スケールアップする（インスタンス・サーバー自体のスペックをあげる）
- スケールアウトする（インスタンス・サーバー台数を増やす）
- AppServiceプランに登録したAppService/Functionsを減らす（別のAppServiceプランに分割する）
AppServiceプランを停止すれば課金は止まるのか
使用していないAppServiceプランは停止しておけば課金が止まるのかな・・・と思うかもしれませんが、そもそもAppServiceプランに「停止」というメニューはありませんので「停止」はできず、課金を止めるにはAppServiceプランを削除するしかないが答えです。また、AppServiceプランにデプロイしているAppServiceやFunctionsを停止はできますが、停止したアプリケーションが動かなくなるだけで、AppServiceプラン自体の時間単位での課金は発生し続けます。VMサーバを占有している状態になるので、停止をすれば課金が止まるという考え方は通用しませんので、覚えておいてください。
料金プランを理解するならやっぱりこの本
実際にかかる課金額（料金計算ツール）
細かい説明はわかったけど、実際にどのくらい課金が発生するんだ・・・については、どのくらいかかりますよと無責任なことを言ってしまうのが難しいので、以下の「料金計算ツール」を参考にしていただければと思います。
料金計算ツールの公開情報
azure.microsoft.com
ご注意いただきたいのは、Functionsを計算するときはStorageAccount・ApplicationInsightsなどは必要に応じて、手動で追加する必要があります。
料金プランごとの制限
このプランじゃないとこの機能は使えない、という制限が色々ありますので、一部の例を紹介します。
- [価格レベルごとに機能が異なる]: AppServiceで自動スケール・バックアップ・スロットの機能を使いたい場合は、価格レベルにStandard以上を利用する必要があります。参考に、BasicとStandard以上の場合を比較してみましょう。
- [FunctionsのVnet統合]: 例えばサービスエンドポイント・プライベートエンドポイントを経由してストレージアカウントにアクセスする必要がある場合、Functionsのネットワーク設定でVnet統合(公式ドキュメント)を行う必要が出てきますが、FunctionsでAppServiceプランまたはPremiumプランを利用する必要があります。（従量課金プランではVnet統合できません。）安く使いたい為に従量課金プランを使いたいけどアクセス制御をしたいのであれば、IPアドレス等でアクセス制御をすることになります。
AppServiceの料金プランの説明は、以上になります。
慣れてない方は、料金プランだけでこれだけ色々覚えることがあるのか・・・と感じるかもしれませんが、何か疑問があればコメントいただければと思います。
AzureFunctionsの料金プランも書きましたので、ご参考ください。 www.azureportal-site.com
以上です。
