AutoScaleの履歴
AutoScaleがサービスに対して何を行ったかの確認とログを残すことが簡単になりました。これをサポートするために、現在4つの新しいAutoScale履歴機能があります。
1つ目は、Windows Azureの操作ログ機能に、AutoscaleActionとPutAutoscaleSettingという2つの新しい操作が追加されました。AutoScaleがスケールを変更するたびに記録され、詳細には新しいインスタンスと前回のインスタンスの数が含まれています。また、AutoScale設定を誰かが変更するたびに記録されるので、チームメンバーがいつどのようにオプションを変更したか確認できます。Windows Azure管理ポータルの新しいManagement ServicesノードのOperation Logsタブにどちらも公開されています。
クラウドサービスには、過去7日間のインスタンス数を示した履歴グラフも追加しています。これにより、1週間ごとのAutoScaleの傾向が確認できます。
3つ目に、もしAutoScaleが一度に2時間以上失敗した場合、自動的にメールでサブスクリプションのサービス管理者と共同管理者に通知します。
4つ目に、サブスクリプションのアカウント管理者である場合は、アカウントの通貨でAutoscaleの課金情報を表示します。
AutoScaleがオンになっている場合、現在のインスタンス数と最大インスタンス数の差異を示し、それによりどのくらい節約できているかが表示されます。
AutoScaleがオフになっている場合、AutoScaleをオンにした場合にどれくらい節約できるかの予測が表示されます。つまり、今後の請求書の更新で支払の節約方法の提案も含まれてきます（私の上司には内緒でお願いします… <g>）。
仮想マシン：ロードバランサプローブ設定のサポート
Windows Azureに展開しているすべての仮想マシン、クラウドサービス、Webサイト、Mobile Serviceには、ビルトインのロードバランササポートがあり、アプリのスケールアウトや高可用性の有効化に使用することができます。このロードバランササポートは、Windows Azureにビルトインされており、追加料金はありません（他のほとんどのクラウドプロバイダでは追加料金を請求されます）。
今回のWindows Azure更新には、仮想マシンのロードバランシングをさらに簡単に構成および管理できる素晴らしい新機能がいくつか含まれています。また、ロードバランサが、仮想マシンのヘルスチェックとロードバランサーのローテーションに含めておくべきかどうかの判断に使用する、独自のネットワークプローブロジックのサポートも含まれています。
ロードバランサプローブを理解する
複数のVM間のトラフィックをスケールアウトしたり、アプリのフロントエンドまたはバックエンドの仮想マシンの高可用性を有効化するためには、複数の仮想マシンのインスタンス間でネットワークトラフィックをロードバランシングすることは重要です（SQL ServerのAlwaysOnのセクションを参照）。
ネットワークプローブは、障害の原因がソフトウェアなのかハードウェアなのか、Windows Azureロードバランサーが1つ以上の仮想マシンインスタンス障害を検出する方法です。
ネットワークプローブが、ある特定の仮想マシンインスタンスに問題を検出した場合、自動的にトラフィックを問題のない仮想マシンインスタンスにフェールオーバーして、お客様がアプリケーションがダウンしているかどうかを気にしなくてもいいようにします。
Windows Azureのロードバランサーからのネットワークプローブのデフォルト設定は、アプリケーションがロードバランシングしているのと同じポート上でTCPを使用しているだけです。
以下の例に示しているように、負荷分散されたセット内の各仮想マシンは、パブリックインターネット（WebサイトやWebサービスなど）から、ポート80上のTCPトラフィックを受信しています。単なるTCPプローブだと、ロードバランサは、ヘルスチェックのために、各仮想マシンに同じポートで進行中のメッセージを、デフォルトだと15秒ごとに送信します。
仮想マシンがWebサイトを実行しているので、仮想マシンおよびWebサービスが正常であれば、自動的にロードバランサに通常のACKを送信してTCPプローブに返答します。このACKが継続されている間は、ロードバランサは、Webサイトが応答可能なので、トラフィックの送信を続けます。
Webサイトに不具合がある場合、ロードバランサはWebサイトからのレスポンスを受信しません。
これが発生すると、ロードバランサは、以下の仮想マシン2のように、障害のある仮想マシンへのトラフィック送信を停止し、直接その他のインスタンスへ送信します。
この単純な高可用性オプションは、VM内に特別なコードを記述しなくても、ネットワークプローブへの応答は動作し、アプリケーション、仮想マシン、基盤のハードウェアが原因の障害から防御されます（注：Windows Azureが障害を検知した場合、自動的に仮想マシンインスタンスを新しいサーバーに移行します）。
Windows Azureでは、各ネットワークプローブの送信間隔（デフォルトは15秒）とロードバランサがインスタンスをオフラインにする前のプローブの試行回数（デフォルトは2）をどちらも設定することができます。つまり、デフォルトだと、Webサービスからレスポンスを受信しなくなってから30秒後に、ロードバランサは応答不能と判断し、正常な応答が受信されるまで（1プローブあたり15秒×2プローブ）、トラフィックの送信を停止します。
また、より上級なオプションになりますが、独自のHTTPプローブを設定することもできます。HTTPプローブでは、現在ロードバランシングしているものとは別のネットワークポートに送信されるロードバランサのネットワークプローブリクエストが構成できます（このポートはインターネットに開放されている必要がなく、ロードバランサだけがアクセスできるプライベートポートを推奨します）。これを行うには、サービスまたはアプリケーションが別のポート上で傍受していて、アプリケーションの状態に応じて、プローブリクエストへ応答する必要があります。HTTPプローブでは、ネットワークプローブリクエストからHTTP 200 OKの応答を受信した場合、ロードバランサは仮想マシンへトラフィックの送信を続けます。
上記のTCPの間隔と同様に、デフォルトでは、仮想マシンが30秒後（2×15秒プローブ）にHTTP 200 OKと応答しない場合、ロードバランサは次のプローブでHTTP 200 OKが返ってくるまで自動的にトラフィックローテーションからマシンを外します。
この上級オプションでは、別のポートで傍受・応答するためのコードを作成する必要がありますが、サービスに配信されるトラフィック制御の自由度が高くなります。
