このページの対象者
▶ AppServiceプランでどの価格レベルを選べばいいかわからず、本番環境でBasicを選んでしまう方
▶ AppServiceプランのPremiumプランと聞いただけで高価だと選択肢から除外してしまい、Standardしか選択肢にない方
▶ Functionsの従量課金プランは、アプリが実行された分課金されるプランという説明しかできない方
▶ Functionsの従量課金プランとPremiumプランの違いが説明できない方
料金プランを理解できると以下のようになります
▶ AppServiceプランでどの価格レベルを選べばいいかわかる
▶ 課金の発生状況・いつ課金されるかがわかる
▶ 想定外の動作を抑えられる
▶ コールドスタート(アプリ起動までに時間がかかる)に腹を立てることがなくなる
▶ とりあえずBasicや従量課金を選んでいたがPremiumプランも検討し始める
料金プランなんてそんなに大事なのか?と思うかもしれませんが、料金プランによってアプリの動作も大きく変わるのでとても大事です。このページの内容を理解してないと、壁にぶち当たったり無駄な時間を過ごしてしまうと思います。この機会に、理解を深めていただけたらと思います。
AppServiceの料金プラン
Functions(Function Apps)の場合は3つの料金プランから選択することになりますが、AppService(Web Apps)を新規作成する際は、AppServiceプランを使うことになります。(これはAzureの仕様を説明しているだけです。)
Azureポータル画面でAppServiceを新規作成する際に、AppServiceプランを割り当てることになりますが、既に作成済みのAppServiceプランを選択もできますし、AppServiceの新規作成と同時にAppServiceプランを新規作成することもできます。Azureが勝手に名前を付けてくれたまま進むと適当な名前になってしまいます。自動生成された名前が推奨されているわけではないので、新規作成を押してご自身で名前を付け直しましょう。
AppServiceプランとは
AppServiceプランを作る=VMサーバを1台レンタルできるイメージです。AppServiceプランを作るとき、サーバスペック(価格レベル)を以下の18種類の中から選びます。課金の発生は、AppServiceプラン1つに対してかかるので、1つだけアプリケーションをデプロイして動作させても、複数のアプリケーションをデプロイして実行させてもAppServiceプランに課金される金額は変わらないのがポイントです。あと、AppServiceの非同期処理担当のWebジョブ(サイト内リンク)や常時接続機能(Always On)もプラス料金なしで利用できます。
価格レベルを選択
ポータル画面を日本語表示にしてると "価格レベル" ですが、 "sku" とか "tier" と表現されている所もあるので覚えておいてください。結構種類がありますね。選択する価格レベルごとに、サーバの「メモリ数」「コア数」をはじめ、使用できる機能も異なります。後述しますが、開発環境(ステージング環境)ならBasicでもいいですが、本番環境(運用環境)を作るなら Standard S1 以上は必須と思ってください。Standard S1 が推奨というのも古くなり、2024年は Standard S1 とほぼ同額の Premium v3 P0V3 が推奨されている時代ですが。
Free | Shared | Basic | Standard |
---|---|---|---|
Free F1 | Shared D1 | Basic B1 | Standard S1 |
- | - | Basic B2 | Standard S2 |
- | - | Basic B3 | Standard S3 |
Premium | Premium v2 | Premium v3 | Isolated | Isolated v2 |
---|---|---|---|---|
Premium P1 | Premium v2 P1V2 | Premium v3 P0V3 | I1 | I1v2 |
Premium P2 | Premium v2 P2V2 | Premium v3 P1V3 | I2 | I2v2 |
Premium P3 | Premium v2 P3V2 | Premium v3 P2V3 | I3 | I3v2 |
メモリー強化版
Premium mv3 | Isolated mv2 |
---|---|
P1mv3 | I1mv2 |
P2mv3 | I2mv2 |
P3mv3 | I3mv2 |
価格レベルの内容は、公開情報をみれば一目瞭然ですので、以下を参照ください。
AppServiceプラン一覧の公開情報
azure.microsoft.com
Azureをお試しで使いたい人は、Free(F1)を選択すれば無料で試せますが、カスタムドメインが設定できない・デプロイできるAppService/Functionsのアプリ数が合計10個までなどの制限はあります。Azureを活用する上で制限詳細を把握することはとても重要ですので公式ドキュメントを見てみてください。
制限について公開情報抜粋
本番環境はどの価格レベルが適切なのか
1つのAppServiceプランに複数のアプリケーションをデプロイできますが、AppServiceプラン(サーバ)のリソースは限られているので、CPU使用率やメモリーの許容範囲を超えて動作するとシステムエラーが発生します。
- [テスト・動作確認で使う場合]: Basicでも良いですが、Standard以上でないと使えない機能(自動スケール・スロット・バックアップ等)があるので、リリース前テストのようなときに使う環境はBasicではなくStandard以上である必要があります。
- [本番環境(運用環境)で使う場合]: 以前は Standard S1 以上を推奨とされていましたが、最低限は Standard S1 ですが、2024年以降は特に、Premium v3 P0V3・Premium v3 P1V3などが推奨とされています。公式ドキュメントの料金表を見るとわかりますが、Standard S2 と Premium v3 を見比べても、ひと月辺りの金額は大きく変わりません。Premium 系はコストとパフォーマンスのバランスが良いという評判もあるので、是非ご検討ください。
※ 少し古い記事にはなりますが、AzureMVPのしばやんさん(外部サイトリンク)もP1V2を推奨してます
レガシという表記について
これは数年前から動きのあったことなので、 Azure VMSS (Virtual Machine Scale Sets) は、自動スケーリング機能と管理の容易性を兼ね備えた仮想マシンのクラスタリングサービスです。App Serviceを含む多くのAzureサービスがVMSSのアーキテクチャを利用することで、以下の利点を提供します:
- 自動スケーリング: トラフィックの増減に応じて自動的にインスタンスをスケールアップ・ダウンする機能。
- 高可用性: 複数のインスタンスにまたがって負荷を分散することで、単一障害点のリスクを減少。
- 効率的なリソース利用: 使用状況に基づいてリソースを動的に割り当てることで、コストとパフォーマンスの最適化を実現。
作成したリソースのAppServiceプランの価格レベルが何か調べる方法
AppService/Functionsのスケールアップ(AppServiceのプラン)メニューからも確認できますが、先頭の概要メニューの右側に以下の情報も載っています。
AppServiceプランに登録するアプリ数
登録するアプリ数はいくつが妥当なのか?についてです。答えはケースバイケースとしか言えないのですが、基本的な考え方をお伝えするので参考にしてください。
極端な例ですが、Standardプランのインスタンス1台で20個のアプリケーションを実行させようとすると、受信した全てのリクエストをパフォーマンスよく処理できず遅延が発生したり、インスタンスのリソースが足りなくなってシステムエラーが発生したりする可能性があります。なので、アプリを登録するたびにAzureサーバが耐えられているのかをご自身で確認・テストする必要があります。ちなみに、HelloWorldをHTMLで表示させるだけのアプリであれば20個30個登録して動かしても問題は起きないと思いますが、アプリがそれなりのリソース(メモリー等)を使うアプリなのかということが大きく影響するということを理解してください。(重要)
テストの方法としては、実際にAzureサーバ上で実行させてから、メトリック・問題の診断と解決でAzureサーバの負荷状況・エラー発生状況が確認できます。 負荷が高いと思った場合の対応方法としては、
・AppServiceプランを分ける
・AppServiceプランの価格レベルを上げる
・アプリ処理で無駄なメモリの使い方をしていないか等を確認する
という方法が考えられます。
また、一つのAppServiceプランにデプロイ~実行する推奨アプリケーション数は、以下ページに記載されているので参考にしてください。ただ、アプリケーションごとの規模によっても変わりますので、テストが必須ということになります。
azure.github.io
公式ドキュメントに、各料金プランのアプリ最大数 (目安) が書かれていますので、参考にしましょう。これ以上追加できないようになっている制限事項という意味の情報ではないので、ご留意ください。
learn.microsoft.com
遅延発生やリソース枯渇が発生した場合の回避方法
アプリケーション実装の見直しが有効なのはもちろんですが、Azure側の設定での回避方法は以下になります。
- スケールアップする(インスタンス・サーバー自体のスペックをあげる)
- スケールアウトする(インスタンス・サーバー台数を増やす)
- AppServiceプランに登録したAppService/Functionsを減らす(別のAppServiceプランに分割する)
実際にかかる課金額(料金計算ツール)
細かい説明はわかったけど、実際にどのくらい課金が発生するんだ・・・については、まずはAppService新規作成画面の価格プランに表示されるこちらで「1ヶ月稼働させた場合の(推定)金額」を目安としてください。ただ、AppServiceプランでスケールアウト(1→2)したら(推定)金額の約2倍かかったりします。
その他の手段は、「料金計算ツール」です。注意点としては、例えばFunctionsを計算するとき、StorageAccount・ApplicationInsightsなどを必要に応じて手動で追加する必要があります。どのサービスのリソースが作られるかを把握していないと見積もりが出せないということです。
料金計算ツールの公開情報
azure.microsoft.com
AppServiceプランを停止すれば課金は止まるのか
使用していないAppServiceプランは停止しておけば課金が止まるのかな・・・と思うかもしれませんが、そもそもAppServiceプランに「停止」というメニューはありませんので「停止」はできず、課金を止めるにはAppServiceプランを削除するしかないが答えです。また、AppServiceプランにデプロイしているAppServiceやFunctionsを停止はできますが、停止したアプリケーションが動かなくなるだけで、AppServiceプラン自体の時間単位での課金は発生し続けます。VMサーバを占有している状態になるので、停止をすれば課金が止まるという考え方は通用しませんので、覚えておいてください。
料金プランを理解するならこの本
料金プランごとの制限
このプランじゃないとこの機能は使えない、という制限が色々ありますので、一部の例を紹介します。
- [価格レベルごとに機能が異なる]: AppServiceで自動スケール・バックアップ・スロットの機能を使いたい場合は、価格レベルにStandard以上を利用する必要があります。参考に、BasicとStandard以上の場合を比較してみましょう。
- [FunctionsのVnet統合]: 例えばサービスエンドポイント・プライベートエンドポイントを経由してストレージアカウントにアクセスする必要がある場合、Functionsのネットワーク設定でVnet統合(公式ドキュメント)を行う必要が出てきますが、FunctionsでAppServiceプランまたはPremiumプランを利用する必要があります。(従量課金プランではVnet統合できません。)安く使いたい為に従量課金プランを使いたいけどアクセス制御をしたいのであれば、IPアドレス等でアクセス制御をすることになります。
AppServiceの料金プランの説明は、以上になります。
慣れてない方は、料金プランだけでこれだけ色々覚えることがあるのか・・・と感じるかもしれませんが、何か疑問があればコメントいただければと思います。
AzureFunctionsの料金プランも書きましたので、ご参考ください。 www.azureportal-site.com
以上です。