Windows Azure アプリケーションの構成とか

Windows Azureのアプリケーションを作る際、どのようにロールを構成してエンドポイントを設定して…というのは結構悩みどころかなという気がするんですが皆様いかがでしょうか。

単純にSQL Azure(DB)+Webサーバーx n 台あればいいYO!という構成だと(インフラ的なところで)悩むところはあまりないのですが、Worker Role絡んだり、WebフロントエンドとバックエンドとDBと…とかになってくると意外とはまりそうですね。ええ、はまってますとも。

ということで今日はWindows Azureの構成とパッケージング、エンドポイントあたりをダラダラと考察したいと思います。

続きを読む

Windows Azure + PHP

Windows Azure上でPHPを動作させる場合、以前ならphp-cgi.exeも一緒にアプリケーションに含めたりしてたと思います。

でもWindows Azure SDK 1.3以降ではスタートアップタスクも利用できるし、Full IIS機能が使えるのでPHPも含めてIIS+FastCGI+PHPな環境にしたいですよね。

ということでおなじみのWebPICmdLineを利用してPHPをインストールするスタートアップタスクです。

@echo off
sc config wuauserv start= demand
md "%~dp0appdata"
reg add  "hku\.default\software\microsoft\windows\currentversion\explorer\user shell folders" /v "Local AppData" /t REG_EXPAND_SZ /d "%~dp0appdata" /f
webpicmdline /Products: PHP53 /AcceptEula
webpicmdline /Products: wincache53 /AcceptEula
reg add "hku\.default\software\microsoft\windows\currentversion\explorer\user shell folders" /v "Local AppData" /t REG_EXPAND_SZ /d %%USERPROFILE%%\AppData\Local /f
net start w3svc

ついでにPHPのアクセラレータとしても利用できるWincacheも入れてます。
※WincacheをインストールするとどうもIISが止まるようなのでサービス開始のコマンドも入れてます。

後は以下のようにサービス定義ファイル(.csdef)でタスクを呼び出すようにします。
<Startup>
    <Task commandLine="InstallPHP.cmd"  executionContext="elevated" taskType="simple" />
</Startup>

これでアプリケーションの開発者は純粋にPHP部分だけに注力できますね。

ロールのエントリポイントも別途起こせるのと、CSPackを利用すれば大分Windows Azure固有の部分を減らせる=PHP開発者がすぐにWindows Azure アプリケーションを開発できるんじゃないかなーと思います。

参考: How to Configure IIS Components in Windows Azure (MSDN)

追記。Windows Azure Command-line Tools for PHPなるものがあるので、こんな苦労しなくてもいいかも知れませんね。\(^o^)/

WCF Data Services で HTTPレスポンスヘッダにアクセスしたい

だいぶ前にWCF Data ServicesでForm認証をやりましたが、Cookieで認証してるんだからいずれCookieの期限が切れるわけです。

で、ASP.NETではCookieの自動更新を有効にするためのフラグ(slidingExpiration)があり、このフラグをtrueにしておくことで期限が半分過ぎた後にアクセスがあると、新しいCookieを発行してくれるようになります。
(レスポンスヘッダの”Set-Cookie”に新しいCookieが付与される)

<authentication mode="Forms">
  <forms name="sample" timeout="1440" cookieless="UseCookies" slidingExpiration="true" />
</authentication>

さてブラウザ等はこの辺の処理を自動的にやってくれますが、アプリだと手動でやらないといけませんね。
ではEntityFrameworkではどうでしょう?

うーんそのまんまだとCookieどころかHTTPのレスポンスさえ見れませんね。
じゃぁどうしよう?と調べたところエンティティをQueryOperationResponseにキャストしてあげると良いみたいです。こんな感じ↓

ServiceReference1.Entities context = new ServiceReference1.Entities(new Uri("http://localhost/test.svc"));
context.MergeOption = MergeOption.NoTracking;
context.IgnoreMissingProperties = true;

var nodes = context.Users;

QueryOperationResponse<ServiceReference1.Users> response = nodes.Execute() as QueryOperationResponse<ServiceReference1.Users>;
if (response.Headers.Keys.Contains("Set-Cookie"))
{
    //response.Headers["Set-Cookie"] に新しいCookieが入ってる
}

foreach (var user in response)
{

	Console.WriteLine(user.DisplayName);
}

Cookieの有効期限が半分以上過ぎてからアクセスすると、レスポンスヘッダにちゃんとSet-Cookieが付与されているのがわかりますね。
あとはこの値をゴニョゴニョしておけばOKです。
※WCF Data Servicesで認証Cookie以外のCookieははかないと思いますが…一応注意ください。

これでForm認証するWCF Data Servicesとクライアントはばっちり?ですね!

CSPack を使って CSRun したり Startup Tasks を使ったりしたい

この間の続きです。
この間は簡単にCSPackでWindows Azureのデプロイパッケージを作成する方法を記載しました。

ただ、後でわかりましたが前回のフォルダ構成だとWindows Azure SDK 1.3から使えるStartupTasksの利用時やCSRunコマンドを使ったCompute Emulatorでの実行時に問題があることがわかりました。

なので今日はその辺のフォローアップをしたいと思います。

続きを読む

WCF Data Services の通信を圧縮する

WCF Data ServicesはHTTPベース(ODataやJSON等)を使用してデータの送受信ができる強力な仕組みです。このあたりの説明はとりあえず割愛。

で、便利が故にぽんぽん使ってるとそれなりに転送量や帯域も消費するわけでして。でHTTPベースであればgzipで圧縮して通信したいと思うのが世の常。

というわけでさくっとgzip圧縮する方法です。

続きを読む

CSPack で Windows Azure デプロイパッケージを作成する

なぜ Windows Azure Tools for Visual Studio があるのにわざわざCSPackなのか。答えはそこに運用があるから。

とか適当に言ってみましたが、今日はCSPackのお話しです。
CSPack.exeは簡単にいうとWindows Azureのホストサービス上に、展開する際に必要な各ロールのファイル群が固まっているデプロイ用パッケージファイル(.cspkf)を作成する、Windows Azure SDKに含まれるコマンドラインツールです。

結局のところ Windows Azure Tools for Visual Studio も発行メニューから最終的なパッケージを作る際にCSPackを呼び出すか同等の事をやっています。

で、最初の一言に戻りますが、なんでVisual Studio等のIDEで簡単にやってくれるのにわざわざコマンドラインツールが必要なの?というところですが、逆に言うとVisual Studioなりのツールない人はどうするの?という問題を解決するにはこのCSPackしかないのですよね。

小規模であれば、開発する人、Windows Azureにデプロイする人、Azureに関連する技術に詳しい人は同一人物か、もしくは少人数なので対して問題にはなりませんがそれなりの規模を回すとなると必ず分業することになってくると思います。

今回はそういった分業する際のある程度の指針と、実装方法を考えると共にCSPackでのパッケージ作成を紹介したいと思います。

続きを読む

Windows Azure の Full IIS で MachineKeyが上書きされる件

Windows Azure SDK 1.3 を使用してFull IISなWeb RoleをWindows Azure上に展開した際、Web.configに指定していたMachineKeyが上書きされる(IISによって自動設定される)という問題がありました。

※ただし最初の仮想サイトのみ。追加した仮想サイトや仮想アプリケーションは影響受けない(だったと思う)

さて、こちらの問題ですがこの間リリースされた Windows Azure SDK 1.4 では修正されているので、困ってた方はSDK 1.4を採用することも検討頂くといいのではないでしょうか。
他の問題もいろいろ修正されてるようですし。。。

ただまぁSDK1.2 以降でがらっと変わってる部分もあるので一概にOKとは言えないかもしれませんが。

Windows Azure + ARR で勝手キャッシュ・リバースプロキシサーバーを構築する

前回Squidを利用してキャッシュ・リバースプロキシサーバーを構築しましたが、Squid版では以下の問題がありました。

  • Locationヘッダ等によるリダイレクトを抑制できない
  • 絶対パスのリンクを書き換えられない

これらはURLのRewriteをリバースプロキシな処理の中で行えば解決しますが、外部公開サイトに対してはいろいろグレー+Squidだと少し面倒でした。

さて代替方法として(緊急で対応する必要もだいぶ減ったので)IIS+Application Request Routing 2.0を使用してキャッシュ、リバースプロキシ、URL Rewriteを行いたいと思います。

※今回実装にあたってはMicrosoftさんを始めJAZUな面々、多数の方にご協力頂きました。ありがとうございます。

デプロイパッケージを作成するにあたって実装している点は以下の通りです。

  • WebPICmdLineツールを使用してStartup TasksでARRのインストール(依存するWeb Farm Frameworkもインストール)
  • 設定の簡略化のためにApplicationHost.configを直接書き換え(そのためにRoleのEntryPointが特権で動作するように設定)

コードはやっつけ仕事もいいとこですね。

成果物はこちらからダウンロードください。

利用方法は上記パッケージをダウンロードしてDeployPackageフォルダにある .cscfg のインスタンス数や対象URL、公開URLを修正してデプロイするだけです。

今は1:1の書き換えしか対応できません。もし1つのサーバーで複数展開する場合は現状のコードでは対応できませんので、RDPの設定をして頂き、展開後手動でIIS+ARRの設定を行ってください。
非常時用ですのでこんな感じです。

CDNを利用する場合や、より細かな対応、本格的にAzure化する為にコンテンツホルダーとの調整が必要な場合等は こちらのサイト を参考にして頂き、Microsoftさんへコンタクトを取っていただくのもよいと思います。

Windows Azure + Squid による勝手キャッシュ&リバースプロキシサーバーの構築

3月11日、東北地方太平洋沖地震が発生しました。私のほうではうまく表現できません。ただ心より祈るばかりです。

とはいっても、できることはないだろうか?と漠然と思っていたところ、日本赤十字社のサイトが過負荷で見えない、という話題が流れていました。
ぱっと思いついたのはとりあえずキャッシュサーバーとリバースプロキシを組み合わせて負荷を軽減できないか?ということでした。

幸い、リソースはWindows Azureですぐに展開できますし、SquidとDelegateは少し触ったことがあったので @halmnm を巻き込んでSquidを構築することに決めました。

並行してMicrosoftさんがAzure Passの90日無償開放、4インスタンス、転送量無制限という臨時仕様で解放してくれました。ありがとうございます。

続きを読む

誰も知らなかったWindows Azure CDN

タイトルはホッテントリメーカーで生成しました。内容とはあまり関係ないと思われます。

さてWindows Azure CDNが新しくなったので、試してみました。

目玉としては、

  • Web/VMロールでCDNサポート
  • HTTPSなエンドポイントをサポート

だと思うので(QueryStringでどうのこうのもありそうですが検証が大変そうなので今回は置いておきます)、それぞれ見てみようと思います。

続きを読む