App Service Environment を作成したので Web Apps との違いを調べてみた

公開されてから全く弄ってませんでしたが、検証のために App Service Environment を作成してみました。

作成時の記述通り、確かに 2 時間近くかかりましたが作成完了しました。

これで環境が準備出来たので、実際に Web Apps と App Service Plan を作成して試しました。

サブドメインが入ったので、サイト名はサブドメイン内でユニークになるのかと思いましたが、実際には Web Apps で共通となっていました。

既に daruyanagi.azurewebsites.net を使っているので、ASE でも使うことは出来ません。

App Service Environment に対して新しく Web Apps を作成する場合には、これまでと同じ Web Apps を作成する画面からリージョンではなく ASE 名を選択します。

最初に作成する場合には App Service Plan ごと作る必要があります。

Web Apps を作成してしまえば、これまでと全く同じように全ての機能が使えます。

しかし、スケールに関しては少しだけ異なっていて、インスタンスサイズではなく ASE を作成する時に設定したワーカープールを選択するようになっています。

ワーカープールは 3 つまで設定可能なので WP1-3 となります。

Web Apps では P1-3 まで選択可能でしたが、App Service Environment を使っている場合に限り 8 コア 14GB RAM の P4 インスタンスを選択可能です。

クラウドサービスや VM で言うところの A4 インスタンスとなります。

App Service Environment の作成には 2 時間ほどかかりましたが、ワーカープールの設定を変更する場合には最低でも 3 時間かかるとありました。

実際に変更してみましたが、確かに 3 時間ほどかかりました。Web Apps の設定からワーカープールを切り替えるのは一瞬ですが、ASE 側は時間がかかるので設定に注意したいです。

ASE 上の Web Apps はこれまでの Web Apps と全く同じなので Kudu もしっかりと存在していますが、ログインにフェデレーション認証が使われていないようで Basic 認証の画面が出てきます。

しかし、設定済みのデプロイ認証情報を入れてもログインできなかったので No.1 こと @kosmosebi に聞いてみると、フォーラムの記事を教えてくれました。

どうやら Co-admin の認証情報は使えないみたいなので、発行プロファイルに記載されている認証情報を使ったところ、問題なくログインが可能でした。

バージョンも OS イメージも全く同じようですし、互換性に関しては全く気にする必要はないでしょう。

App Service Environment 上に作成した Web Apps は共有ストレージとしてこれまでのファイルサーバーではなく、Azure Files を使うようになっているのに気が付きました。

と言っても利用者としては全く意識することなく、同じように使えるので問題ないです。

Azure Files は 1000 IOPS なので I/O パフォーマンスが改善されるかと思いましたが、少し試した感じでは遅くなっているように感じました。これに関しては追試したいです。

Network Security Group を使うことで、インターネットからのアクセスを制限することが出来ます。

なので 80/443 を閉じてしまえば Web Apps にインターネットからアクセスできなくなりますが、hosts ファイルに ASE エンドポイントの IP とホスト名を追加すれば内部 IP だけでアクセス可能でした。

しかし現状ではエンドポイントの IP アドレスをサブネットから推測するしか出来ないのと、エンドポイントが複数ある場合でも片方だけへのアクセスとなるので、もうちょっと ILB を入れるなど柔軟な設定が可能にならないと実用は難しいと思いました。

エンタープライズ的にはフロントを全て VNET 内に入れることが出来るので、セキュアなバックエンドへのアクセスは可能です。利用用途はここですね。

しばやん雑記