ぴりっと刺激的な WASABi ～ Windows Azure の Autoscaling ～ クラウドカバー Episode 74
Wade がホストするのも最後となるクラウドカバー（「Episode 74 - Autoscaling and Endpoint Protection in Windows Azure」）。
今回は、Patterns & Practices グループ（通称 PAG (パグ)) の Grigori Melnik をゲストに迎え、Windows Azure のコンピューティングインスタンスの起動数を自動で調整する 「The Autoscaling Application Block」、通称 WASABi （わさび）についてお届けします。
まずはいつものようにニュースから。
◆The Differences Between Development on Windows Azure and Windows Server
「ASP.NET 開発者のための Windows Azure 入門」の位置づけとして、Windows Server 上で ASP.NET アプリケーションを開発してきた開発者向けに、Windows Azure でのアプリケーション開発時にどのようなポイントに差異があり、気を付けるべきかをまとめたエントリです。
ゼネラルなお話として、「ステートレスに設計しましょう」というのはご存知かと思いますが、具体的にセッションステートやキャッシュをどうすればよいか、デバッグ環境の違い、デプロイメントの概念の違いなどがまとまっています。
◆ The Beauty of Moving SQL Azure Servers between Subscriptions
以前のクラウドカバーのニュースでも触れられていましたが、SQL Azure ではサブスクリプションをまたぐデータベースの移動が可能になっています。
日本語でもブログ「蒼の王座」の「サブスクリプション間のSQL Azureサーバの移動ができるようになりました」にて、わかりやすい情報を載せていただいていますので、一読いただければよいかと。
◆ Programmatically finding Deployment Slot from code running in Windows Azure
Windows Azure においてコンピューティング サービスを利用する際には、「Production」(本番）環境と、「Staging」（ステージング）環境を利用して、デプロイを行うことができますが、基本的にはこの両者に違いはなく、特別に振る舞いが異なることはありません。
一方で、アプリケーションによっては、Production と Staging 環境を切り分けたい場合があるかもしれません（たとえば、本番系のDBと、ステージングのDBを分離して、使い分ける、など）。
そのような場合に、アプリケーションの方から、現在デプロイされている環境が Production なのか Staging なのかを判別する方法を紹介したのが、このブログ エントリです。
基本的にはサンプルコードが付いていますので、試してみたい！、ということはコードも確認ください。
ということで、本日の本題、Windows Azure の Autoscaling へ。
Autoscaling Application Block は通称 WASABi と呼ばれており、もともとは開発時のコードネームでしたが、名前がユニークな方が見つけてもらいやすい、ということで現在も WASABi と呼んでいるそうです。Unity はもう少しユニークにすればよかった、、、、とか。
Nuget Gallery でも、「wasabi」で検索できますね。
さて、本日のゲスト Grigori が所属する PAG チームですが、直接製品を作っているわけではなく、リリースされた製品に対して開発者が感じている Pain Point や、ギャップに対して、ソリューションを提供するのがゴールとのこと。
これまで Enteprise Library として各種のアプリケーションブロックを提供してきたわけですが、Windows Azure においてもその Enteprise Library はほぼ問題なく使える、ということで Windows Azure における Pain Point は何かを開発者に聞いてみたそうです。
すると、その中でオートスケールについて、スケジュールするというだけでも意外と苦労していることを認識した、とのことです。
ということで、登場したのが Autoscaling Application Block で、アプリケーションの使用パターン（たとえば昼休みにアクセスが増える、とか）に基づく自動スケジュールでのオートスケールと、アクセスが増えてきた時（あるいは減った時）のオートスケール（リアクティブなオートスケール）、についてサポートしています。
WASABi を使用しない場合、スケールしようとすると ①管理ポータルでインスタンス数を手動で変更する、② パートナーのサービスを使う、③ 自身で API を利用してロジックを書く、のいずれかの方法を使う必要がありました。
WASABi は他のアプリケーション ブロックがそうであるように、アプリケーションに組み込んで使っていただけるコンポーネントであり、自由に設定を行っていただくことが可能です。
この点が、Service Bus や、Cache などのサービスとは異なります。
また、WASABi を使用いただく際には、いくつかの設定等も必要ですが、簡単に実施いただくことができます。
WASABi を組み込みたいアプリケーションがありましたら、まず最初に Nuget などで入手し、プロジェクトに組み込みます。
そして、以下のように、AutoScaler をインスタンス化し、Start() メソッドを呼びだす、といったイメージで使用できます。
もちろん、実際の使用においては、コンフィギュレーションが必要になります。
これについては、２種類のコンフィギュレーション、一つ目は「オペレーション」に関わるコンフィギュレーションを、二つ目は「ビジネス」に関わるコンフィギュレーションが必要です。
前者は、コネクション ストリングや、証明書、あるいはオートスケールさせるターゲットなどの情報です。
後者はオートスケールさせる際のインスタンス数のレンジや、特定の時間帯における特別ルールなどを設定するものです。
例えば、下記の設定では、”PublicWebSite” のインスタンス数は通常時に「２インスタンスから５インスタンス」と設定されていますが、平日の始業時間帯においては「３インスタンスから６インスタンス」とする、といったビジネスルールになっています。
なお、ルールの優先度は Rank によって設定します（Rank = 1 が最も低い優先度）。
次に、スケジュールされたルールとは異なる、リアクティブなルールについて。
リアクティブなルールは、アクセス数が増えた際などに、自動的にインスタンス巣を増減させるためのルールです。
次のような形で敷居を決めておき、敷居を超えた際にインスタンス数を増やすことが可能です。
逆にインスタンス数を減らす側のルールは以下のような感じです。
なお、XML で記述されたこのルールは、プロジェクトに含めずに Windows Azure Storage に配置することができ、したがって、アプリケーションの再配置なしに、ルールを変更できるようになっています。
さて、実際に WASABi を利用したデモアプリケーション、Tailspin の管理ポータルを見ていきましょう。
まず下記はモニタリングのページで、Tailspin で利用しているインスタンス数の時間別の動きを確認することが可能です。
また、ルールの確認画面では、現在有効になっているルール（通常の黒文字になっている上の二つ）と、適用されていないルール（下の方にあるグレーアウトされたルール）が確認できます。ここからルールの有効化を行うことが可能です。
再び画面をモニタリングのページに戻して、もう少し詳しく見ていきましょう。
モニタリングの情報ですが、薄いブルーの帯がインスタンス数のレンジで、通常は「２から５」のルールですが、時間によって「３から６」になり、また、今回のクラウドカバー収録時間に合わせて「３から８」のルールを適用しているのが確認できます。
また、青い四角の前にある数字は、実際に利用しているインスタンスの個数を表しています。
さて、ここで Wade から、「アプリケーションのオートスケールを行うための効率的なメトリクス、ルールってのは、PAG で提供してるの？」との質問。
これに関して、もしアプリケーションに最適化して使いたいのであれば、PAG のデフォルトルールをそのまま使うのではなく、まずはアプリケーションの使用状況やレスポンス状況をモニターして、個々のアプリケーションごとにビジネス上重視しているポイントを勘案しながら、期待する動きになるように指標やルールを調整する必要がある、とのこと。
また、パフォーマンスモニタリングに関してもどの程度の頻度で行うか、あるいはオートスケールに関しても、どの程度の間隔で行うか、などの調整が必要です。
例えば、Windows Azure ではコンピューティング サービスは一時間単位での課金になっていますので、インスタンス数を増やした後、５分後にインスタンス数を減らす、といった動きは無駄になってしまいます。
そのため、インスタンス数を変更した後には、クールダウンのための時間を設定し、適度な間隔をあける、といったことも行ってください（WASABi には Stabilizer とよばれる、このためのコンポーネントが用意されています）
さて、WASABi ですが詳しい情報は、Windows Azure のホームページの Autoscaling の項目（英語）にてご確認いただけます。
ダイナミックなインスタンス数調整を行いたい！、という開発者の方は、ぜひこの WASABi を活用ください！
ということで、最後は恒例の Tip of the week!
今回の Tip of the Week では、Windows Azure に対応した Microsoft Endpoint Protection (MEP)の紹介です。
Windows Azure のアンチ マルウェア機能を持つ Endpoint Protection は、現在プレビュー公開中で、無償で利用いただくことが可能です。（詳しくは Microsoft Endpoint Protection support in Windows Azure を参照ください）
実際にダウンロード、インストールを行うと、Windows Azure の SDK のフォルダにて、plugins 配下に必要なファイルが展開されます。
このファイルの中には、Windows Azure のスタートアップ タスクの中で、インストール、および起動するためのコマンドや、インストールに必要なアセンブリ等が含まれています。
また、実際に MEP を利用したい Windows Azure のアプリケーションでは、サービス定義において Antimalware のプラグインの使用を宣言しておきます。
同時に、サービスコンフィギュレーションにて、各種設定を行います。
また、実際的な設定として、Role インスタンスにおいて、もし Antimalware のプラグインから何らかの情報があった場合、Table ストレージに対してその診断情報を書き込んでおく、というロジックを用意しておきます。
Wade は今回のデモのために、MEP をインストールした Windows Azure のコンピューティング インスタンスを用意しています。
MEPにより、マルウェアから守られた状態にあるこのインスタンスですが、マルウェアのデータをダウンロードするために、コンフィギュレーションで MEP の機能をオフにし、リアルタイム監視が働いていない状態にします。
MEP 機能がオフになったことで、リアルタイム監視がなくなりました。この状態で、あらかじめ用意したマルウェアデータをこのインスタンスでダウロードします。
さて、ダウンロードが終わったら、MEP の機能をオンにしましょう(MEPの画面が赤いのは、MEP機能をオフにしているからで、現時点でマルウェアは検知されていません）。
この状態で、先ほどダウンロードしたマルウェア(zip)をダブルクリックすると、MEP によりマルウェアと診断され、オープンすることを拒否されます。
また、この情報（MEPにより、マルウェアの恐れのあるデータ展開が中止された、という情報）は、Table Storage に対して書き込まれます。
現在 MEP はプレビュー公開中ですが、将来的には正式版としてリリースできるように準備中です。
是非、ご期待ください。
ということで、Wade にとって最後となるクラウドカバー、以上で終了です。
それでは！