Private Endpoint や Azure Functions Premium Plan の検証用に West US 2 に新しくリソースを作成していた時に気が付きましたが、一部のリージョンには Web Worker が Worker Role から VMSS に変更された Scale unit がデプロイされ始めているようです。
具体的には Kudu でシステムドライブを眺めていた時に、普段とディレクトリ構成が違うことに気が付きました。この名前のディレクトリがあるなら VMSS だろうと思いました。
ほぼ意識することなく VMSS な Scale unit がデプロイされていくのだと思いますが、変わりつつあることは知っておかないと予想外の部分ではまりそうなので、非公式ですが書いてみました
App Service のアーキテクチャは昔はよく紹介されていましたが、最近は話を聞かなくなってきたので古い記事ですが引っ張ってきました。Web Worker が VMSS になったのかと思いましたが、どうやらフロントの ARR 含め VMSS になっている気配があります。
一番わかりやすいのは App Service のホスト名を nslookup で引いてみた時の結果です。古い Scale unit 上で動いている場合には Cloud Services が使われているので cloudapp.net が返ってきます。
一方 VMSS で動いていると思われる App Service の場合は cloudapp.azure.com が返ってきます。
これは VM の場合に割り当てられるホスト名なので、少なくとも Cloud Services ではないことが分かります。
ついに App Service も Cloud Services から脱却しつつあることが確認できました。おめでたい。
ぶっちゃけ Cloud Services から VMSS に移行したからと言って、当然ながら App Service として普通に使う分には全く違いはありません。自分も Kudu で調べるまで全く気が付かなかったぐらいです。
1 つ大きく変わっている点としては、システムドライブが D:\ から C:\ に変更されていることです。理由は知らないですが Cloud Services はシステムドライブが D:\ に設定されていたので、App Service も同様に D:\ ベースになっていました。
VMSS ベースになることで、このよく分からないシステムドライブ構成が一般的な C:\ に変更されています。Kudu を開いて勘の良い人はこのタイミングで気が付きます。
アプリケーションで App Service の wwwroot は D:\home\site\wwwroot へ決め打ちしている場合には、新規作成時や将来的に動かなくなる可能性が高いので、環境変数 HOME を使うようにしましょう。
Program Files 系は以下のように D:\ 以下にシンボリックリンクが用意されているので、Java などでフルパスを指定していた場合でも、問題なく動作するようになっているようです。
ぱっと見で問題になりそうなのは C:\cacert と C:\devtools にいろいろ便利なものがあることを知っている人ぐらいかなと思いました。cacert.pem を App Service にデプロイされているものを使っている場合は、恐らくフルパスで指定しているので死にます。
GitHub 上のリポジトリを眺めていると ASE 周りにもアップデートがありそうなので、公式情報を待ちたいと思います。久し振りに App Service のアーキテクチャについて話して欲しい気持ちが高まっています。
