しばやん雑記

Azure Serverless とメイドさんが大好きなフリーランスのプログラマーのブログ

Azure App Service の新しい Premium V3 インスタンスが使えるようになった

Ignite 2020 で発表された Premium V3 が最近になってようやく試せるようになったので、気になっていた点を実際にデプロイして一通り試したので残します。

9 月末から限られたリージョンでは Azure CLI から試せるようになっていましたが、利用可能なインスタンス数の制限や Azure Portal でのサポートが遅れたため結局は今日まで待つ必要がありました。

まだ多少の表示上の問題*1はあるようですが、デプロイ自体は問題なく行えます。

以下のように App Service の作成時に Premium V2 と Premium V3 から選べるようになっているはずです。そろそろ Windows の Recommended pricing tiers から S1 を外して欲しい気持ちが凄くあります。

f:id:shiba-yan:20201007000703p:plain

Pricing ページがまだ更新されていないので、ひとまず Azure Portal から金額を確認しておきます。Ignite 2020 で公開された時間単価を使って確認しましたが、この金額は正しそうです。

10/8 追記

Pricing ページが更新されて Premium V3 のリージョン毎価格が確認出来るようになりました。

Azure Portal で確認できる金額と同じですが。計算ツールを使うことで Dev / Test 向け Pricing の確認も行えるようになっていました。

先に言っておくと Premium V3 は良い意味で普通だなと思いました。Premium V2 からの順当なアップグレードなので当たり前ではありますが、コストパフォーマンスは良くなっていてインスタンス世代も最新です。

App Service としてのインフラも最新の VMSS ベースになっているので、新機能の追加も期待できます。*2

Premium V3 の特徴

後半の裏側を弄った結果が長すぎるので、先に Premium V3 と Web App for Containers (Windows) の特徴をまとめておきました。ここを読んでおけば Premium V3 を理解した状態になるはずです。

基本的なこと

  • 全ての App Service で Premium V3 を利用可能
    • Windows / Linux / Containers (Linux, Windows) / Functions (ASP) の全て
  • Premium V3 の稼働する Stamp は VMSS ベースになった
    • Windows / Linux / Containers (Linux, Windows) の全て
    • Stamp 単位の対応なのでスケールダウンしても VMSS のまま
    • Additional Outbound IP Addresses の数がかなり多いのでスケールダウンには注意
  • 利用可能なリージョンは限定的
    • Japan East は対応、Japan West は Dv4 がそもそも使えないので非対応
    • 一覧は Azure CLI で az appservice list-locations --sku P1V3 を実行すると取得可能

金額について

  • Linux の Premium V3 はかなり安い (Windows 比 50% ぐらい)
    • 2 コア以上を使うなら Premium V3 を選ぶべき
    • 長期で使うことが確定しているなら Reserved Instance の利用も検討したい
  • Windows の Premium V3 もそこそこ安い (同コア数比 20% ぐらい)
    • 2 コア以上を使うなら Premium V3 を選ぶべき
    • 長期で使うことが確定しているなら Reserved Instance の利用も検討したい
  • Windows Containers は普通の Windows よりも 10% ほど高い
    • PC2-4 の頃を考えるとお得になったとは思う
    • 使い捨て用途ではないと思うので Reserved Instance を使いたい
  • Visual Studio Subscriber 向けの価格が凄い
    • P1V3 が S2 より安くなっている衝撃
    • 予告通りとにかく安くなっているので最高

デプロイ・アップグレード

  • 古い App Service Plan をデプロイ済みリソースグループにはデプロイ出来ない
    • 新しいリソースグループを作成してデプロイする必要がある*3
    • Retrofit は基本的に行われないと思っておいて良さそう
  • 既存の App Service Plan は Premium V3 へのアップグレードは出来ない
    • 新しい Stamp が必要なので新しいリソースグループへのデプロイが必要
    • 本当に極めて運のよいケース*4に限りアップグレードが可能
  • Windows と Linux の App Service Plan の混在は出来ないまま
    • ただし Windows と Windows Containers の混在は出来る(前から?)

プラットフォーム

  • App Service (Windows) は Windows Server 2016
    • 現行インスタンスから変更なし
    • インストールされているパッケージ類も全く同じ
  • Web App for Containers (Windows) は Windows Server, version 2004
  • Web App for Containers (Windows) から Private Endpoint が使える
    • つまり WEBSITE_VNET_ROUTE_ALL が動作するということ

Premium V2 の時にも発生しましたが、既存の App Service Plan のアップグレードや、同一リソースグループへの新規デプロイはほぼエラーになります。例外的に VMSS ベースの Stamp を掴んだ時だけ可能ですが、この 1,2 か月以内にデプロイしていて凄く運が良ければというレベルだと思います。

VMSS ベースの App Service について興味がある極々一部の方は、以前に書いたエントリを参照ください。

Windows / Linux / Containers 全てが VMSS ベースになったのと、今後リリースされる ASE v3 も VMSS ベースになることが確定しているので、何年越しか分かりませんが Cloud Services とはおさらばです。

さようなら Cloud Services、さようなら何故か D:\ 以下にいた Windows。

Premium V3 の裏側を調べた話

ここから先は普通に App Service で Premium V3 を使う場合には必要ない情報ばかりなので、裏側に興味がある人以外は読み飛ばしてよい内容です。

App Service (Windows)

流石に App Service (Windows) 側の OS バージョンは WIndows Server 2016 から上がることはありませんでした。既存のインスタンスが 2019 にアップデートされない限り、同じバージョンのままになるでしょう。

f:id:shiba-yan:20200929185358p:plain

プラットフォームとしては VMSS 由来のドライブレター以外は全く変わっていないので、アプリケーションの互換性について気にする必要はないです。

CPU はドキュメント通り Xeon Platinum 8272CL が使われていました。ベースクロックが Dv2 でよく使われている Xeon E5-2673 v3 より少し高いですが、Hyper Threading が有効になった仮想コアなので、ACU は Dv2 より若干低めになっているのは前回書いた通りです。

f:id:shiba-yan:20200929185236p:plain

全コア 3.4 GHz までブーストするらしいので、単純なシングルスレッド性能は Dv2 より高そうです。

Turbo Boost が有効になっているからか、App Service Plan を選んだ時に表示される ACU は minimum 付きです。本当にブーストするのかを確認する手段が App Service だとありませんが、ここは信用しましょう。

f:id:shiba-yan:20200929215416p:plain

もちろん Azure Functions も Premium V3 な App Service Plan にデプロイ出来ます。これまで通りですね。

プレビュー中にも行えたのかは確認していませんが、App Service (Windows) と Web App for Containers (Windows) は同じリソースグループ内にデプロイすることが出来ました。

f:id:shiba-yan:20201001020338p:plain

Windows と Linux を同じリソースグループにデプロイ出来ないのはこれまで通りです。

App Service (Linux), Web App for Containers (Linux)

Docker ベースの App Service (Linux) では Web Worker の調査をするのが非常に難易度が高いというかほぼ無理ですが、マシン名や DNS から引いた名前から VMSS ベースになっていることは確認できます。

f:id:shiba-yan:20201001004424p:plain

IMDS v2 を使って情報を取れないか試しましたが、当然ながら塞がれていたので分かりませんでした。

去年に Linux に関しては Premium V2 の大幅な値下げが行われていますが、Premium V3 はそれよりもさらに値下げされているのでかなりコストパフォーマンスが良くなっています。かなり驚いています。

Premium V2 よりもメモリが増えているので、これまでよりも Container 向けではあると思います。32GB メモリまで選べるという余裕は重要だと思いました。

Web App for Containers (Windows)

2 年間のプレビューを経て GA となった Web App for Containers (Windows) ですが、プレビュー中を含め OS バージョンが 2 回上がっています。最終的には LTSC ではない SAC な 2004 が使われるようになりました。

Windows Containers はそれなりにリソースを食うので、最新世代 VM が使われている Premium V3 の中でも 8 コア 32GB メモリの P3V3 が、本番環境向けでの現実的な選択肢になると思います。

f:id:shiba-yan:20200929185609p:plain

2004 の Docker Image はプレビュー開始当時の 2016 に比べるとかなりコンパクトになっているので、ようやく Windows Containers に周りの環境が追いついたという感じすらあります。

Docker Image サイズの縮小と .NET Framework での対応については結構面白い話が多いので、参考までにリンクを共有しておきます。NGEN 周りで本当に苦労していたようです。

最近は Docker すら全く使っていなかったので、Windows Containers を触るのは久しぶりでしたが、WinRM を使ったリモート接続が Cloud Shell から行えるようになっていたのが便利でした。

クライアント側で WinRM の起動やパスワードなどを扱うことなく、Cloud Shell からであればリソースグループ名と Web App 名を指定するだけで接続できます。

f:id:shiba-yan:20200929204146p:plain

Private Endpoint へのアクセスが行えるのかが気になっていたので、適当に Private Endpoint を有効にした Storage Account を作成して WinRM 経由で通るか確認したところ、問題なく接続できました。

f:id:shiba-yan:20200929204408p:plain

これで機能としては Windows Containers は Linux Containers とほぼ同等になったと考えて良さそうです。

*1:Premium V3 に対応していない App Service Plan でもスケールアップが可能なように見える

*2:Regional VNET Integration は新しい Stamp にしか対応していなかった

*3:これは Premium V2 や Regional VNET Integration の時にも発生した

*4:VMSS ベースの Stamp にデプロイされていたケース