[Advent Calendar 2017 Day11] App Service Environment って何ですか ?
記載されている内容は 2017 年 12 月 13 日 時点のものとなり、現時点におきましては変更されている可能性がありますので、ご注意下さい。
こちらの記事は、Qiita に掲載した Microsoft Azure Tech Advent Calendar 2017 の企画に基づき、執筆した内容となります。
カレンダーに掲載された記事の一覧は、
こちら
よりご確認ください。
こんにちは。Azure Dev サポートの村山です。
本日は、App Service Environment (以下 ASE) と呼ばれるサービスについて簡単に説明したいと思います。
App Service Environment や、App Service Plan、App Service など、弊社 Microsoft Azureサービス内で似通った単語がありますが、この記事では、App Service Environment (App Service 環境と訳されることもある) に関してお話をしたいと思います。
App Service Plan と App Service の違いやその概念に関しては、 別の記事 でご案内してますので、そちらをご確認ください。
App Service Environment (ASE) って？
通常のAzure App Service とは異なり、お客様の専用の App Service の環境が利用できるサービスとなります。
通常 App Service Plan はスケール ユニットと呼ばれる単位ごとに App Service の環境が構成されており、このスケール ユニットは、それぞれが異なる役割を持つインスタンスで構成されています。
詳しくは Web Apps on Linux についての記事 内で紹介されていた、弊社開発部門の Yochay および Stefan が書いた MSDN マガジンの記事 で説明されています。
WebWorker : お客様のアプリケーションが動作するインスタンスとなります。
Frontend : レイヤー 7 ロードバランサーであり、スケールユニットに来たリクエストを目的の Web Apps に振り分ける役割を持っています。SSL オフロードなどに関してもこのインスタンス上で行われます。
FileServers : お客様のアプリケーション コンテンツが保存されるインスタンスとなります。
API Controllers : Azure Portal や REST API から送信した API を受け取り、App Service の変更の処理を司ります。
Publishers : FTP や Git、VSDeploy などのデプロイメントを司るロールになります。
そのほか、アプリケーションのメタデータを保存しておく SQL Database や、その SQL Database と各インスタンスとの仲立ちの役割を果たす Data Role と呼ばれるインスタンスが存在しており、これらのインスタンスは各スケールユニットごとに存在しています。
ASEはこの App Service の環境をお客様専用にご提供するサービスとなります。
加えて ASE では、100 インスタンスまでスケールアウトが可能であり、特に、ASE v2 では インスタンスとして Dv2 シリーズを利用しておりますので、高負荷なアプリケーションもホストすることができます。
詳しくは こちら でご案内しておりますが、このほか、ASE は仮想ネットワーク上にデプロイされるため、NSG を適用してアクセスするポートを制限したり、仮想ネットワーク内の仮想マシンや、オンプレミス環境から VPN 経由で Web Apps に接続できるといった特徴があります。
App Service Environment(ASE) って使う必要あるの？
それでは、いつ ASE の利用を検討するべきでしょうか。
もちろん、負荷の高いアプリケーションをホストする場合には ASE のご利用をおすすめしています。
他にも、App Service に関しては、下記のようなお問い合わせを頻繁にいただきます。
1. App Service 利用時に不要なポートを閉じたい
2. App Service へ VPN 経由でアクセスしたい
3. 別サービスへの送信 IP を一つに絞りたい
これらはいずれも 通常の App Service では実現できません 。
このため、システムを作成する際に上記のようなご要件がある場合には、ASE をご利用いただくようご案内しています。
つまり、「 ASE を利用すればできる 」わけですが具体的にどういうことかご説明しようと思います。
App Service 利用時に不要なポートを閉じたい
App Service Environment は、仮想ネットワーク内のサブネット上にデプロイを行います。
サブネット上にデプロイするため、 NSG と呼ばれる機能が利用可能になります。
以前このブログの 別の記事 でも紹介させていただきましたが、現在は App Service Environment 作成と同時に既定で下記のような NSG が作成されます。
ASE では、弊社 Microsoft Azure プラットフォーム側が管理を行うために、いくつか開放しなくてはならないポートがあり、上記の NSG はその条件を満たした状態で作成されます。
詳しくは先ほどのブログ記事でも紹介しておりますので、もしこの他のポートも閉じる必要がある場合は上記の記事も参考にしていただけますと幸いです。
つまり、App Service 利用時に不要なポートを 閉じる必要がある場合は、 App Service Environment とNSG の利用 を検討してください。
App Service へ VPN 経由でアクセスしたい
これもよくあるお問い合わせの一つですが、結論から言いますと ASE ならできます 。
仮想ネットワーク内部や、サイト間接続したオンプレミスのネットワークから接続をする場合は、ILB を含む ASE (以下 ILB ASE) を構成するようにしてください。
ILB ASE を作成すると、オンプレミスのサイト間接続 VPN などからインターネットを経由せず App Service にアクセスすることができます。
詳しくは こちら を読んでいただければと思います。ILB ASE ご利用の際には、お客様側で仮想ネットワーク内部に、DNS サーバーを構成する必要があります。
なお、App Service 上で VNET 統合 という機能がありますが、こちらは App Service が仮想ネットワーク内部もしくはオンプレミスのリソースへアクセスする ための機能となりますので、VNET 統合では、App Service からオンプミス側にアクセスすることはできてもその逆はできません。
なお、App Service Environment では、作成時に 外部 と 内部 を選択することができますが、ASE作成後の切り替えはできませんのでご注意ください。
また、これまでASE 作成時に外部を選んだ場合は、外部向けエンドポイント、内部を選んだ場合は仮想ネットワーク内部向けエンドポイントの片方しか作成されませんでしたが、ILB ASE に関しては Application Gateway と連携して、外部と内部の両方にアクセスポイントを持つことができるようになりました。
こちらのドキュメント で詳しく説明されています。
別サービス への送信 IP を一つに絞りたい
App Service では インバウンド IP と アウトバウンド IPが分かれており、スケール ユニットごとにそれぞれ割り当てられております。
上記の MSDN マガジンでも詳細が記載されていますが、日本語の場合は こちらの記事 に詳細が書かれています。
このため、通常の App Service ではスケール ユニットごとに IP が割り当てられ、アウトバウンド IP が複数存在しており送信時には複数あるアウトバウンド IP のいずれかが利用されます。
※ App Service Plan Premium v2 (Preview) は除きます。
ASE を利用する場合は、下記のようになります。
外部 ASE : インバウンド IPとアウトバウンド IP が同一のものになります。(IP SSL利用時は、インバウンドの IP が変化します。)
内部 ASE : インバウンド IP が ILB の IP となり、インターネット経由で通信する際のアウトバウンド用パブリック IP が割り当てられます。
ASE を利用すると、お客様専用の App Service の環境が割り当てられますので、利用する IP もお客様固有のものとなります。
なお、ASE が仮想ネットワーク内部やオンプレミスのリソースへアクセスする場合は、外部/内部ともに、ASE の WebWorker インスタンスのプライベート IP が利用されます。
スケールアウトをして複数のインスタンスがある場合は、そのインスタンスごとにプライベート IP が送信 IP となります。
このため、ASE がサイト間接続 VPN でつながれたオンプレミスのリソースへアクセスする際は、オンプレミス側の設定で、ASE がデプロイされたサブネットの IP レンジからのアクセスを許可するようにしてください。
なお、ASE は今年の夏に App Service Environment v2 がリリースされており、変更点に関しては こちら に詳細な説明が書かれています。
また、クラシックの仮想ネットワーク上にデプロイする場合には、ASE v1 しか利用できませんので、ご注意ください。
最後に
ASE は通常の App Service 利用時と比べて費用がだいぶ高くなりますが、その分 App Service と比べてより高性能になっています。
上記のような要件がある場合には、通常の App Service では実現することができないので、ぜひ ASE の利用を検討してください !
※ 記事の内容は予告なく変更される場合がございますのでご了承ください。