しばやん雑記

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

Azure Web Apps で crontab っぽく WebJobs のスケジュール実行が出来るようになっていた

公式サイトでは全く触れられていないっぽいですが、中の人ブログや Kudu のコミットログを見たところ、WebJobs で Azure Scheduler を使わずにスケジュール実行する機能が追加されていました。

調べたところ、一応 Kudu の Wiki にひっそりと情報が載っていました。

Scheduling a triggered WebJob
To schedule a triggered WebJob you need to add a schedule property to the settings.job file. The value of the schedule is cron expression that has 6 fields to represent the schedule: {second} {minute} {hour} {day} {month} {day of the week} .

Web Jobs · projectkudu/kudu Wiki · GitHub

Web Apps チームの Amit Apple 氏のブログには、さらに詳細な説明がありました。

Scheduling Azure WebJobs with cron expressions

これまでは Azure Scheduler でジョブを作成していましたが、crontab と同じ記法を使ってスケジュール実行出来ます。実行には Always On が必要ですが、これまで cron を使っていた人にも分かりやすいですね。

Kudu でスケジュール実行する機能は、Internal WebJob Scheduler と言うらしいです。簡単に比較します。

Azure Scheduler Internal WebJob Scheduler
費用 5 ジョブまで無料 標準モード必須、ただし追加料金は不要
制約 無料モードでは最小実行間隔が 1 時間 タイマー駆動なので Always On が必須
メリット Visual Studio でのサポート crontab 記法で細かい制御が可能(曜日指定とか)
デメリット ジョブの設定を別に行う必要がある 挙動が IIS のワーカープロセスに依存

既に標準モードを使っている場合には Internal WebJob Scheduler の方が使い勝手が良い気がしました。

気になる使い方は、WebJob として実行するアプリケーションと同じ場所に settings.job というファイルを作成して、中に crontab 形式でスケジュールを定義するだけでした。

{"schedule": "15 * * * * *"}

こんな感じに書けば毎分 15 秒に WebJob が実行されるようになります。

settings.job ファイルは Visual Studio に追加した後、出力ディレクトリにコピーするように設定しておきます。忘れると settings.job だけがデプロイされなくなります。

これで WebJob としてデプロイすると、Kudu が自動的にスケジュール実行してくれます。ちなみに Git などを使って WebJob をデプロイする方法については以下の記事を参照してください。

GitHub を使って WebJob をデプロイして、Azure WebJobs Dashboard で実行履歴を確認してみました。

設定した通り、ちゃんと 1 分ごとに WebJob が実行されていることが確認できました。

Azure Scheduler を使う場合にはポータルや Visual Studio から作成する必要があり、正直なところ結構使いにくかったです。しかし Internal WebJob Scheduler を使えば、GitHub などからデプロイするだけでスケジュール実行が可能になるので、かなり便利に使えそうです。

WebJobs を含むソリューションを Azure Web Apps へソース管理からデプロイする方法

GitHub などのソース管理システムから Web Apps にアプリケーションをデプロイする場合、自動的に Web Apps が認識してくれますが、同時に WebJobs をデプロイするといった機能はありません。

実際にドキュメントには Web アプリケーションのことしか書いてないです。

Deploy from local Git repo - Azure App Service | Microsoft Learn

しかし WebJobs のみをデプロイする場合には、Web Apps がコンソールアプリケーションを自動的に認識して WebJobs としてデプロイしてくれます。

このあたりは中の人がブログで紹介してくれていますので、そっちを参照してください。

Git deploying a .NET console app to Azure using WebJobs

現実的に Web アプリケーションと WebJobs は同じリポジトリに入れて、同時に Web Apps へデプロイしたいと思います。実際にそう思ったのでカスタムデプロイスクリプトで解決します。

まずは Kudu が生成した、典型的な WebJobs をデプロイするスクリプトを拾ってきました。

echo Handling .NET Console Application deployment.

:: 1. Restore NuGet packages
IF /I "WebJobDeploy.sln" NEQ "" (
  call :ExecuteCmd nuget restore "%DEPLOYMENT_SOURCE%\WebJobDeploy.sln"
  IF !ERRORLEVEL! NEQ 0 goto error
)

:: 2. Build to the temporary path
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\WebJobDeploy\WebJobDeploy.csproj" /nologo /verbosity:m /t:Build /p:Configuration=Release;OutputPath="%DEPLOYMENT_TEMP%\app_data\jobs\continuous\deployedJob" /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\" %SCM_BUILD_ARGS%
IF !ERRORLEVEL! NEQ 0 goto error

:: 3. Run web job deploy script
IF DEFINED WEBJOBS_DEPLOY_CMD (
  call :ExecuteCmd "%WEBJOBS_DEPLOY_CMD%"
)

:: 4. KuduSync
call :ExecuteCmd "%KUDU_SYNC_CMD%" -v 50 -f "%DEPLOYMENT_TEMP%" -t "%DEPLOYMENT_TARGET%" -n "%NEXT_MANIFEST_PATH%" -p "%PREVIOUS_MANIFEST_PATH%" -i ".git;.hg;.deployment;deploy.cmd"
IF !ERRORLEVEL! NEQ 0 goto error

やっていることはシンプルで、NuGet パッケージの復元後にプロジェクトをビルドし、KuduSync を使って wwwroot 以下にコピーという流れになります。WEBJOBS_DEPLOY_CMD の実行は hostingstart.html を書き換えるだけなので、大した意味はありません。

重要なのは MSBuild でテンポラリにビルド結果を出力している部分です。App_Data 以下に出力するので、そのまま Web アプリケーションのデプロイスクリプトに組み込むだけで動いてくれそうです。

:: 2. Build to the temporary path
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\WebJobDeploy\WebJobDeploy.csproj" /nologo /verbosity:m /t:Build /p:Configuration=Release;OutputPath="%DEPLOYMENT_TEMP%\app_data\jobs\continuous\deployedJob" /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\" %SCM_BUILD_ARGS%
IF !ERRORLEVEL! NEQ 0 goto error

注意点としてはソリューション、プロジェクトのパスと OutputPath に指定している名前です。デフォルトでは deployedJob という名前で固定されてしまうので、正しい名前に修正しておく必要があります。

Web アプリケーションのデプロイスクリプトに組み込んだサンプルを GitHub に公開しておきました。

https://github.com/shibayan/azure-webjobs-deploy

deploy.cmd が作成したカスタムデプロイスクリプトになります。このリポジトリを使って Web Apps にデプロイ後、ポータルからデプロイスクリプトの実行ログが見れます。

AzureWebJobsDeploy.Web と AzureWebJobsDeploy.Console の 2 つがビルドされていることが分かります。

ポータルから WebJobs の一覧を確認すると、先ほどデプロイした WebJobs が確認できます。

Kudu によって自動生成されたスクリプトでは continuous で固定でしたが、出力先ディレクトリを変更することで triggered にも変更可能です。

複数の WebJobs をデプロイする場合には、MSBuild 部分を増やすだけで対応できると思います。理想的には KuduScript 側で Web アプリケーションと WebJobs の同時デプロイを認識して、デプロイスクリプトを作ってもらいたいですね。

Azure Web Apps がクライアント証明書に対応したので自己署名証明書で試してみた

Azure 界の抱かれたい男 No.1 という異名を持ち、ブチザッキを書いている @kosmosebi から、Web Apps がクライアント証明書認証に対応したと教えてもらいました。

公式の Azure ブログを読みましたが、めっちゃあっさりと終わってしまっていました。

http://azure.microsoft.com/blog/2015/07/02/enabling-client-certificate-authentication-for-an-azure-web-app/

一応ドキュメントの方にクライアント証明書を有効にするための手順が紹介されているので、それを読んでおきます。やってることは clientCertEnabled を true に設定しているだけです。

Configure TLS mutual authentication - Azure App Service | Microsoft Learn

ドキュメントでは ARMClient を使っていますが、コメントで David Ebbo が書いているように Azure Resource Explorer を使っても出来ます。

ARMClient を使うより、Azure Resource Explorer の方が楽なのでお勧めしたいです。今は設定後に null と表示される問題があるらしいですが、設定自体は反映されているとのことです。

設定後に https で Web Apps にアクセスすると、証明書を選択するダイアログが表示されるようになります。

ここでキャンセルを選択すると、500 エラーが表示されるようになっているみたいです。

証明書の検証とかはどうするのという感じですが、先ほどのドキュメントにはしっかりと書かれています。

Special Considerations for Certificate Validation

The client certificate that is sent to the application does not go through any validation by the Azure Web Apps platform. Validating this certificate is the responsibility of the web app.

Configure TLS mutual authentication - Azure App Service | Microsoft Learn

要約するとクライアント証明書の要求と、送信された証明書は渡すところまでは Web Apps でやるので、後はアプリ側で何とかしろということです。見事なほどの丸投げで惚れ惚れする勢いですね。

つまり、結局のところ Web Apps では ARR に以下の記事のような設定を行うだけです。

Configuring ARR with Client Certificate - AsiaTech: Microsoft APGC Internet Developer Support Team - Site Home - MSDN Blogs

仕方ないので自己署名証明書を作ってクライアント証明書での認証が行えるところまで試してみました。証明書の作り方は以下の記事を参考にしました。というか、そのままです。

クライアント証明書の作り方 | 日々雑記

作成した PFX は Windows にインストールしますが、client-ca.crt の中身はアプリ側に埋め込んでおくことにしました。占有インスタンスならちゃんと動く気がします。

ARR からは X-ARR-ClientCert ヘッダーで Base64 エンコードされた証明書が送られてくるので、アプリ側でデコードして検証を行います。めんどくさくなってきたのでコードを載せます。

protected void Page_Load(object sender, EventArgs e)
{
    var clientCert = Request.Headers["X-ARR-ClientCert"];
    var x509Cert2 = new X509Certificate2(Encoding.ASCII.GetBytes(clientCert));

    var chain = new X509Chain();

    var verify = chain.Build(x509Cert2);

    if (!verify && chain.ChainStatus[0].Status == X509ChainStatusFlags.UntrustedRoot)
    {
        var root = chain.ChainElements[chain.ChainElements.Count - 1];
        verify = root.Certificate.Equals(_clientCaCert);
    }

    if (!verify)
    {
        Response.StatusCode = 401;
        Response.End();
    }
}

private const string ClientCa = "...";
private static readonly X509Certificate2 _clientCaCert = new X509Certificate2(Encoding.ASCII.GetBytes(ClientCa));

信頼された CA から発行されたクライアント証明書を使う場合には X509Certificate2 の Verify メソッドを呼ぶだけで良さそうですが、今回は自己署名証明書なので X509Chain を使いました。

検証に失敗した理由が UntrustedRoot だった場合、チェーンからルート CA の証明書を取ってきて埋め込んだ CA の証明書と同じか確認します。正直、これで合ってるのかは分かりません。

この後にアプリをデプロイするのですが、クライアント証明書を有効にすると Visual Studio からデプロイ不可能になるので、一時的にオフにしておく必要があります。不具合っぽいのでフィードバック済みです。

デプロイ後にアプリにアクセスすると作成したクライアント証明書が一覧に表示されるので、正しい証明書を選択します。この場合には問題なくアクセス可能なはずです。

他の証明書を選択した場合にはページは表示されないはずです。

このあたりの処理は HttpModule か Global.asax にまとめた方がいいと思いました。

ARM から設定すると Azure Web Apps で JDK 8 と Tomcat 8 が使えるようになっていた

Azure Web Apps は JDK 7 と Tomcat 7 がインストールされているので、管理ポータルから有効にするだけで Java アプリケーションの実行が出来るようになってます。

しかし、実際には JDK 7 以外にもインストールされているので、変更可能です。

メジャーな方法としてはアプリケーション設定から JAVA_HOME を書き換えてしまうことです。

http://blogs.msdn.com/b/azureossds/archive/2015/05/08/running-java8-on-azure-web-app.aspx

これでデフォルトの JDK 7 ではなく 8 を使うことが出来ますが、ソースの修正が必要になるのでちょっと面倒です。Azure Web Apps には管理ポータルから切り替え可能になってほしいんですが、ARM 的には対応していたので設定してみました。

ARM を直接使うのは面倒なので、Azure Resource Explorer を使って設定を行います。

https://resources.azure.com/

使い方は Azure Blog で紹介されているので、そっちを参考にしてください。

https://azure.microsoft.com/blog/2015/04/02/azure-resource-explorer-a-new-tool-to-discover-the-azure-api/

設定手順ですが、左側のツリーから Web Apps の config を開くと、JavaVersion と JavaContainerVersion が存在するはずなので、そこの値をそれぞれ 1.8.0_25 と 8.0.23 に変更して保存します。

前までは保存するとバリデーションエラーが発生していましたが、今は保存可能になっていました。

これで作成したサイトをブラウザから表示すると、JDK 8 と Tomcat 8 に切り替わっていることが確認できると思います。ポータルが対応すれば簡単に切り替え可能になると思われます。

注意点としては、この状態で管理ポータルから設定を確認すると、下のように表示がおかしくなる点です。

表示はおかしいですが、ちゃんと JDK 8 と Tomcat 8 が選択された状態になっています。こればかりはポータルが JDK 8 に対応するのを待つ必要がありそうです。

Azure Application Gateway が公開されたので試してみた

今朝に突然、Azure Application Gateway というサービスが公開されて、GA になってました。

プレビューとして公開されることなく GA というのは珍しい気がします。詳細は Azure 界の抱かれたい男 No.1 こと @kosmosebi のブログであるブチザッキに任せるので、簡単に調べてみました。

要するに HTTP(S) のロードバランサーなんですが、Azure LB と違って SSL オフロードやセッションアフィニティも使える L7 のロードバランサーです。どっかで聞いたことあるような機能です。

価格はゲートウェイ 1 つ当たりの時間で計算されるみたいです。インスタンスサイズが S / M / L とありますが、それぞれのパフォーマンスについて何の情報も書いてないのでちょっと選びにくいです。

単純にクラウドサービスのインスタンスサイズな気もするので、CPU / メモリ容量 / 帯域幅ぐらいの差かなと思います。MSDN で情報が公開されるのを待ちたいです。

とりあえず実際に作ってみました。ポータルからは作れないので PowerShell 必須です。と言っても、ドキュメント見ながらコマンド叩くだけなので簡単です。

Quickstart: Direct web traffic using PowerShell - Azure Application Gateway | Microsoft Learn

App Gateway は VNET に入れないといけないので、そこだけ少し注意したいですね。

ドキュメント通りに作成し、設定の XML を使って IP アドレスなど指定すれば、あとは起動させるだけです。

初回だけなのかもしれませんが、普通にクラウドサービスの VM を作成して起動させてるみたいなので、結構時間がかかりました。これは仕方ない気もします。

App Gateway が起動した後に設定を確認するコマンドを叩くと、VIP や DNS 名を見れます。

クラウドサービス使っているみたいなので、ドメインを設定する場合には CNAME がお勧めなんでしょうけど、App Gateway を削除や停止させなければ IP 変わらない気がするので A レコードも大丈夫かも。

DNS 名でアクセスして HTTP レスポンスを確認すると、IIS 8.5 と ARR 2.5 で動いてることがわかりました。

今更 ARR 2.5 は無いだろうと思いつつ、フィードバックは No.1 に任せておきました。ARR 3.0 では無いため、App Gateway では WebSocket はまだ使えないということになります。

実体としては App Gateway は Managed ARR 2.5 になるのだと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実際に変更してみましたが、確かに 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 の認証情報は使えないみたいなので、発行プロファイルに記載されている認証情報を使ったところ、問題なくログインが可能でした。

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

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

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

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

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

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

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

Control inbound traffic v1 - Azure App Service Environment | Microsoft Learn

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

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

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

Xamarin.iOS でも Application Insights を使ってみる

最近は @normalian が Application Insights SDK for Java を弄っていたので、何となく iOS で Application Insights SDK を使ってみようと思いました。

ちゃんと Microsoft から iOS 向けの SDK が公開されています。

GitHub - microsoft/ApplicationInsights-iOS: Microsoft Application Insights SDK for iOS

残念なことに、まだ Xamarin で使えるバインディングが無さそうだったので、自作して試してみました。

追記

Microsoft から Xamarin 向けの Application Insights SDK がリリースされました。

この記事の後半は独自にライブラリへのバインディングを作る際の参考にしてください。

バインディングを作成

Xamarin Studio で iOS 向けのバインディングプロジェクトを作成し、Objective Sharpie で定義をある程度自動生成するという流れです。つまり、伊勢さんの記事と同じことをやります。

http://qiita.com/iseebi/items/36c4fe2bd0c996163db5

いつからなのかは分かりませんが、Objective Sharpie 自体が GUI では無くなったみたいなので、頑張ってコマンドを叩いて定義を作成していきます。

Creating Bindings with Objective Sharpie - Xamarin | Microsoft Learn

幸いなことに、Application Insights SDK for iOS は Framework として提供されているので、ダウンロードした Framework に対して 1 回コマンドを叩くだけです。

sharpie bind -framework ApplicationInsights.framework -sdk iphoneos8.3

sdk のパラメータはインストール済みの SDK に合わせて指定します。これで自動生成されました。

ApiDefinition.cs と StructsAndEnums.cs が同じディレクトリに作成されているので、この中身をバインディングプロジェクトにコピーします。名前空間が付いていないので、ファイルコピーだと面倒です。

他には Framework からスタティックライブラリをコピーする必要がありますが、とりあえず省略してビルドを通すように頑張っていきます。

とても面倒なことに、Application Insights SDK for iOS はショートカット用にインスタンスメソッドとスタティックメソッドが、同じ名前でたくさん定義されてます。

このあたりの調整は面倒くさそうだったので、ひとまずはスタティックなメソッドがあるものはそれを優先して、インスタンスメソッドはコメントアウトしておくことにします。

作成したバインディングプロジェクトを GitHub で公開したので、適当にビルドしてください。

ビルドが無事に成功すると dll が生成されます。何と無く Release ビルドにしておきました。

この dll を Xamarin.iOS アプリケーション側の参照に追加することで、やっと Application Insights が使えるようになります。次は実際にアプリケーションに組み込んでみます。

アプリケーションに組み込む

適当に Xamarin.iOS アプリケーションを作成しておき、参照の編集ダイアログからついさっきビルドした ApplicationInsights.dll を参照に追加しておきます。

これで SDK が使えるようになったので、AppDelegate.cs に Application Insights の初期化コードを追加します。

public override bool FinishedLaunching(UIApplication application, NSDictionary launchOptions)
{
    MSAIApplicationInsights.SetupWithInstrumentationKey("...");
    MSAIApplicationInsights.Start();

    return true;
}

InstrumentationKey は Application Insights を作成すると取得できます。疲れてきたので Application Insights を作る部分は紹介しません。

起動したかどうかだけというのも面白くないので、もう少し AppDelegate.cs にコードを追加します。よく使いそうなトレースメッセージを吐き出すコードを仕込んでみます。

public override void DidEnterBackground(UIApplication application)
{
    MSAITelemetryManager.TrackTraceWithMessage("Enter Background");
}

public override void WillEnterForeground(UIApplication application)
{
    MSAITelemetryManager.TrackTraceWithMessage("WillEnterForeground");
}

これで準備ができたので、実際にアプリケーションをシミュレーターで動かして、本当にプレビューポータルの Application Insights から見れるのか確かめてみます。

プレビューポータルから確認

Azure のプレビューポータルから該当する Application Insights を選んで表示してみました。ちゃんとユーザーとセッション数、そしてクラッシュログも取れていることが確認できますね。

ブレードの下の方にある Diagnostic search を開くと、アプリケーションから送信されてきた情報を一覧で表示したり、絞り込んで確認することができます。

仕込んでおいたメッセージが送信されていることも確認できました。絞り込みが結構便利そうです。

クラッシュログも取得できていましたが、dSYM のアップロードに対応していないみたいなので、スタックトレースやメッセージに関しては不完全な状態ですね。

まだ beta3 ですし今後に期待しておきたいと思います。それよりも PCL 化してくれたら、わざわざバインディングを作る必要もないのに。と少し思いました。*1

*1:エラーハンドリング周りは PCL では難しいとは思いつつも要望したい

7/19 から段階的に Azure Web Apps の SSL/TLS 暗号スイートから 3DES と RC4 が削除される

昨日ぐらいから Azure Web Apps を使っている人には以下のようなメールが届いているはずです。

7/19 から段階的に SSL/TLS の暗号スイートが更新されることを伝える内容です。

殆どの場合には影響を受けることは無いと思いますが、具体的にはどう変わるのか気になったので、サンプルの URL について現状の Web Apps と比較してみました。

今までの SSL/TLS 設定


7/19 からの SSL/TLS 設定


まとめ

一目で分かる大きな違いとしては、今までの Web Apps では AES の他に 3DES と RC4 が暗号スイートとして使えるようになってますが、7/19 からは AES のみ使用可能になる点です。そして AES-GCM が追加されることも期待出来そうですね。

そして暗号スイートの更新によって、モダンブラウザで Forward Secrecy が有効になります。*1

TLS_FALLBACK_SCSV は今のところ IIS というか SChannel に実装されていないようなので、現時点ではどうしようもない感じです。TLS session resumption に関しては、Windows Server 2012 R2 から使えるようになるという情報がありました。

What's New in TLS-SSL (Schannel SSP) | Microsoft Learn

Azure Web Apps は 2012 ベースなので、これもまたアップデート期待という感じです。

*1:前までは ECDHE が使えなかったはずなので、既にアップデートが行われた気がする

Azure Web Apps は Memcache プロトコルをサポートしてるけど知られてないっぽい

最近はキャッシュとして Redis Cache を使うことが多いですが、何故か Azure Web Apps では Memcache プロトコルで Redis Cache を使えるようになってます。

ぶっちゃけ Memcache プロトコルで Redis Cache を使うよりも、最初から Redis Cache プロトコルで通信するべきだと思いますが、移行の都合で Redis Cache を使えない場合に使えます。

管理ポータルから以下のアプリケーション設定を追加すると、Memcache Shim がローカルで起動します。

  • REDIS_HOST
    • Redis Cache のホスト名
  • REDIS_KEY
    • Redis Cache へのアクセスキー
  • MEMCACHESHIM_REDIS_ENABLE
    • true / false

実際に設定してみると以下のような感じになります。

アプリケーション設定を追加後に Kudu の Process Explorer を見ると、IIS のワーカープロセス単位で MemCacheAsWJ.exe が起動しています。

Web Apps は権限の関係で新しくポートを開けることが出来ないので、Memcache Shim はかなり特殊です。そして Web Apps は当然ながらマルチテナントで動作しているので、ポート 11211 番は使えません。

その代わり、環境変数 MEMCACHESHIM_PORT で待ち受けポートを渡してくれるので、このポート番号と localhost を指定することで Memcache プロトコルが使えます。

最近のモダンなプログラミング言語なら Redis クライアントが用意されているはずなので、わざわざ Memcache Shim を使う機会はないと思いますが、In-Role Cache が使えない Web Apps で使えるのは助かることがあるのではないかと思いました。

個人的には、どうやって Memcache Shim を動かしているのか気になっています。

Azure Web Apps の Auto-Healing 機能が簡単に使えるようになっていた

少し前、Azure プレビューポータルに Troubleshoot という項目が増えているのに気が付きました。

内容から見て Support Site Extension へのリンク集という感じですが、一番下にある Mitigate という機能は記憶になかったので開いてみると、Auto-Healing の設定が行えるようになっていました。

有効にして適当に条件を作ってみると、applicationHost.config に monitoring セクションが追加されました。

ARMExplorer で設定を確認してみると、こっちにも保存されています。ARM の設定を元に applicationHost.config が作られるので、当然と言えば当然です。

Web.config の修正は、ギャラリーからデプロイした WordPress などに対しては手間がかかりましたが、設定項目として用意されたので手動で弄る必要がありません。

Auto-Healing 機能自体は 1 年前にリリース済みですが、Web.config を自分で弄らなくてもブラウザだけで設定可能になったのは便利ですね。

http://blogs.msdn.com/b/windowsazurej/archive/2014/02/13/blog-auto-healing-windows-azure-web-sites.aspx

特に FastCGI で動作する PHP では、メモリ使用量やリクエスト数を条件にしてワーカープロセスをリサイクルさせると、安定して動作させることが出来そうです。