読者です 読者をやめる 読者になる 読者になる

しばやん雑記

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

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

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

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

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

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

サイト名は Web Apps と重複不可

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

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

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

リージョンではなく ASE を選ぶ

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

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

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

スケールアップはワーカープール単位

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

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

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

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

P4 インスタンスが利用可能

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

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

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

ASE のスケール変更には 3 時間かかる

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

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

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

Kudu はフェデレーション認証非対応

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

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

Unable to access SCM for ASE hosted Web App

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

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

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

共有ストレージとして Azure Files を利用

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

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

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

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

内部 IP でのアクセスが可能(制限あり)

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

How To Control Inbound Traffic to an App Service Environment

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

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

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

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