読むと以下のようになれます！ ▶ どの価格レベルを選べばいいかわかる
▶ 課金の止め方がわかる
▶ 想定外の動作を抑えられる
▶ Basicで済ませずPremiumプランも検討できる
AppServiceプランを作る＝VMサーバを１台レンタルできるイメージです。そして選択する料金プランによって、パフォーマンス・使用できる機能・制限事項が変わるので理解した上で選択することが必要があります。下調べせずに使用すると想定しない動作・状況になるかもしれないので、この機会に理解を深めましょう。
AppServiceの料金プラン
Functionsは５つの料金プランから選択することになりますが、AppServiceについては、AppServiceプランの使用一択になります。(これはAppServiceの仕様です。)
Azureポータル画面でAppServiceを新規作成する際に、AppServiceプランを割り当てることになりますが、既に作成済みのAppServiceプランを選択もできますし、AppServiceの新規作成と同時にAppServiceプランを新規作成することもできます。Azureが勝手に名前を付けてくれたまま進むと適当な名前になってしまいます。自動生成された名前が推奨されているわけではないので、新規作成を押してご自身で名前を付け直しましょう。
概要説明
◎ AppServiceプランとは ▽
AppServiceプランを作る＝VMサーバを１台レンタルできるイメージです。AppServiceプランを作るとき、サーバスペック(価格レベル)を以下の１８種類の中から選びます。課金の発生は、AppServiceプラン１つに対してかかるので、１つだけアプリケーションをデプロイして動作させても、複数のアプリケーションをデプロイして実行させても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のアプリ数が合計１０個までなどの制限はあります。Azureを活用する上で制限詳細を把握することはとても重要ですので公式ドキュメントを見てみてください。
制限について公開情報抜粋
◎ 価格レベルの確認方法 ▽
作成したリソースのスケールアップメニューからも確認できますが、[概要]メニューの右側に載ってます。
◎ 適切な価格レベル ▽
１つの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を推奨してます
レガシ表記
◎ レガシ表記について ▽
スケールアップ画面などの価格レベルを選択する画面に上記の表記があり、この「レガシ」とは？についてです。
「レガシ」というワードは、「古くなってきている」「いつか廃止されるかもしれない」という意味で捉えて良いと思います。ただ、じゃあ使わない方が良いのか？近いうちに廃止される可能性があるのか？というと、あまりそう考えなくても大丈夫だと思います。
正確な見解・レガシという表記の意味は、公式ドキュメントの確認やサポートへの問い合わせをする必要があると思いますが、少なくとも言えそうなことは、Standard プランが廃止されるとしたら１年以上前から予告があるはずということです。その予告がないのであれば「いつか廃止されるかもしれない」と不安になる必要はないとは思います。また、AppServiceプランの料金表を見ると、Standard と Premium の課金額の差が小さくなってきているので、不安なのであれば Premium プランの利用も検討されることを推奨します。
以降は補足情報となりますが、まず Azure VMSS (Virtual Machine Scale Sets) というものがあり、これは自動スケーリング機能と管理の容易性を兼ね備えた仮想マシンのクラスタリングサービスというものです。App Serviceを含む多くのAzureサービスがVMSSのアーキテクチャを利用していて、以下の利点があります。
- 自動スケーリング: トラフィックの増減に応じて自動的にインスタンスをスケールアップ・ダウンする機能。
- 高可用性: 複数のインスタンスにまたがって負荷を分散することで、単一障害点のリスクを減少。
- 効率的なリソース利用: 使用状況に基づいてリソースを動的に割り当てることで、コストとパフォーマンスの最適化を実現。
上記を維持・継続するためには、Standard ではスペック不足になってくる可能性がある、という話なのかなとは思いますが、なぜ Standard 等がレガシ扱いなのかは、公式ドキュメントやサポートを頼っていただけたらと思います。
課金額・アプリ数・制限事項
課金額
◎ 実際にかかる課金額 ▽
課金額については、まずはAppService新規作成画面の価格プランに表示される「１ヶ月稼働させた場合の (推定) 金額」を目安としてください。また、AppServiceプランでスケールアウト（１→２）すると約２倍の金額がかかったりします。
その他の確認方法は、「料金計算ツール」です。料金計算ツールの注意点は、例えばFunctionsを計算するとき、追加で使用するサービスである StorageAccount・ApplicationInsights なども手動で追加する必要があります。どのサービスのリソースが作られるかを把握していないと、正確な見積もりは出せないということです。
料金計算ツールの公開情報
azure.microsoft.com
◎ 課金を止める方法 ▽
使用していないAppServiceプランは停止しておけば課金が止まるのかな・・・と思うかもしれませんが、そもそもAppServiceプランに「停止」というメニューはありませんので「停止」はできず、課金を止めるにはAppServiceプランを削除するしかないが答えです。また、AppServiceプランにデプロイしているAppServiceやFunctionsを停止はできますが、停止したアプリケーションが動かなくなるだけで、AppServiceプラン自体の時間単位での課金は発生し続けます。VMサーバを占有している状態になるので、停止をすれば課金が止まるという考え方は通用しませんので、覚えておいてください。
登録するアプリ数
◎ アプリの妥当数 ▽
登録するアプリ数はいくつが妥当なのか？についてです。答えはケースバイケースとしか言えないのですが、基本的な考え方をお伝えするので参考にしてください。
◎ システムエラー発生 ▽
極端な例ですが、Standardプランのインスタンス１台で２０個のアプリケーションを実行させようとすると、受信した全てのリクエストをパフォーマンスよく処理できず遅延が発生したり、インスタンスのリソースが足りなくなってシステムエラーが発生したりする可能性があります。なので、アプリを登録するたびにAzureサーバが耐えられているのかをご自身で確認・テストする必要があります。ちなみに、HelloWorldをHTMLで表示させるだけのアプリであれば２０個３０個登録して動かしても問題は起きないと思いますが、アプリがそれなりのリソース（メモリー等）を使うアプリなのかということが大きく影響するということを理解してください。（重要）
◎ リリース前にテスト ▽
テストの方法としては、実際にAzureサーバ上で実行させてから、メトリック・問題の診断と解決でAzureサーバの負荷状況・エラー発生状況が確認できます。 負荷が高いと思った場合の対応方法としては、
・AppServiceプランを分ける
・AppServiceプランの価格レベルを上げる
・アプリ処理で無駄なメモリの使い方をしていないか等を確認する
という方法が考えられます。
また、一つのAppServiceプランにデプロイ～実行する推奨アプリケーション数は、以下ページに記載されているので参考にしてください。ただ、アプリケーションごとの規模によっても変わりますので、テストが必須ということになります。
azure.github.io
公式ドキュメントに、各料金プランのアプリ最大数 (目安) が書かれていますので、参考にしましょう。これ以上追加できないようになっている制限事項という意味の情報ではないので、ご留意ください。
learn.microsoft.com
料金プランごとの制限
◎ 制限事項の例 ▽
このプランじゃないとこの機能は使えない、という制限が色々ありますので、一部の例を紹介します。
- [価格レベルごとに機能が異なる]: AppServiceで自動スケール・バックアップ・スロットの機能を使いたい場合は、価格レベルにStandard以上を利用する必要があります。参考に、BasicとStandard以上の場合を比較してみましょう。
- [FunctionsのVnet統合]: 例えばサービスエンドポイント・プライベートエンドポイントを経由してストレージアカウントにアクセスする必要がある場合、Functionsのネットワーク設定でVnet統合(公式ドキュメント)を行う必要が出てきますが、FunctionsでAppServiceプランまたはPremiumプランを利用する必要があります。（従量課金プランではVnet統合できません。）安く使いたい為に従量課金プランを使いたいけどアクセス制御をしたいのであれば、IPアドレス等でアクセス制御をすることになります。
遅延発生・リソース枯渇等の問題
◎ 発生時の回避方法 ▽
アプリケーション実装の見直しが有効なのはもちろんですが、Azure側の設定での回避方法は以下になります。
- スケールアップする（インスタンス・サーバー自体のスペックをあげる）
- スケールアウトする（インスタンス・サーバー台数を増やす）
- AppServiceプランに登録したAppService/Functionsを減らす（別のAppServiceプランに分割する）
Azure基礎を覚えるならこの本
 |  |
AppServiceの料金プランの説明は、以上になります。
慣れてない方は、料金プランだけでこれだけ色々覚えることがあるのか・・・と感じるかもしれませんが、何か疑問があればコメントいただければと思います。
AzureFunctionsの料金プランも書きましたので、ご参考ください。 www.azureportal-site.com
以上です。
