この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに
AzureのPaaS型Webサービス基盤であるWeb Appsですが、非常に便利な「スケールイン/アウト」機能があります。
これは、Web Appsの処理を行うVMインスタンス数を変動させることができる機能で、これによってユーザーアクセスの量に応じて必要な性能に縮退・拡張し、アクセスを適切なリソースとコストで処理することが可能となります。
この時、Web Appsとしては、フロントエンドにロードバランサー、バックエンドに処理を行うVMインスタンス、という構成となり、ロードバランサーはアクセスの振り分けをランダムで各VMインスタンスに振り分けるのですが、この構成の設定については微妙にクセがあるため、本記事ではフロントエンドからバックエンドへのインスタンスへの振り分け設定について、実際の運用の中で確認したポイントについて何点かご紹介したいと思います。
なお、基本の構成については以下サイトをご参照ください。

Azure App Service の自動スケールと負荷テスト

Web App（App Service）の構成について

 

①デフォルトの振り分け設定について
世のロードバランサーのサービスは、振り分け先が正常に稼働していない場合、アクセスの振り分けを停止するといった機能があります。
Web Appsにおけるロードバランサーにも似たような設定があります、が、あくまでお守り程度の機能というのが正直なところです。
デフォルトの設定は以下の通りです。
—
・ロードバランサーによる、各VMインスタンスに対して機密の内部正常性チェックにて異常と判断された場合、インスタンスへのアクセス振り分けを止める
・該当インスタンスへ既に振り分けられていたアクセスについては、インスタンスを新規で立ち上げ通信をそちらにリダイレクトする
・機密の内部正常性チェックは1分以下の間隔で定期的に行われる
・機密の内部正常性チェックの詳細については非公開、ただし、IIS以上のレイヤーのアプリケーション停止/異常状態でも、内部正常性チェックでは検知されない
→あくまでMS管理領域の異常を検知するもの、というイメージ
—

②1度割り振られたインスタンスには継続して同じインスタンスにアクセスさせる
エンドユーザーがアクセスした際に、同一セッションのアクセスにおいては、常に同一のVMインスタンスへアクセスを振り分けたい場合があります。
この設定においては「セッションアフィニティ」機能を有効に設定する必要があります。

【設定方法】
Web Apps上のweb.configファイル内、[customHeaders]に、以下の記述を追加する
—
<add name="Arr-Disable-Session-Affinity" value="false"/>
—

③各インスタンスVMから200応答が返ってきてからアクセスを振り分ける
オートスケールなどによって、エンドユーザーからアクセスがどんどん来ている状態でVMインスタンスが追加等される場合があります。この時、Webアプリケーションがまだ起動しきっていない状態でアクセスをVMインスタンスに振り分けてしまうと、そのアクセスは正常にページを読み込むことができません。
そこで、アプリケーションが起動完了しないとHTTP200応答を返さないパスを用意し、アクセスの振り分けはそこから200応答を受けないと開始しない、という設定を行うことができます。

【設定方法】
Web Apps上のweb.configファイル内、[applicationInitialization]に、以下の記述を追加する
—
-<applicationInitialization>
<add hostName="Web AppのURL" initializationPage="起動完了してから200応答をかえすパス"/>
</applicationInitialization>
—

④ ③の設定で、HTTP→HTTPSのリダイレクト応答を無視する設定
③の設定を行ったものの、HTTPの通信が来た時にHTTPSへリダイレクトする設定を入れていると、パスで設定した宛先が正常応答する状況でない場合でも、リダイレクト応答を正常応答を判断して、アクセス振り分けを行ってしまう場合があります。この時は以下の設定で上記事象を回避することが可能です。

【設定方法】
Web Apps上のweb.configファイル内に以下の記述を追加する
—
<rule name="No redirect on warmup request" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_USER_AGENT}" pattern="Initialization" />
</conditions>
<action type="Rewrite" url="{URL}" />
</rule>
—

おわりに
Web Appsの内部ロードバランサーは、Azureサービスのロードバランサーとは仕組みが違うところも多く、非公開の情報も多いため、IIS以上のレイヤーである程度設定が必要だったりします。とはいえ、やはりリソースを適切に変動できる機能はクラウドの大きな利点でもあるため、使っていきながらカスタマイズしてデメリットを減らし、メリットの効果を大きくしていければと思います。