というわけでWindows Azure SDK 1.7（2012年6月版）以降では、Windows Azureのネットワーク周りが大幅に強化されてます。（これはVirtual NetworkやVPN周りの影響でしょうね）

さてトピックを見ていきましょう。何事も新機能の確認はMSDNから。

UDPのサポート

Windows AzureのネットワークでUDPの受信（インターネットからデータセンターへの方向）がサポートされました。

InputEndpoint、InternalEndponit、InstanceInputEndpointそれぞれでUDPを許可することができます。

以前、こんなことを書いてたわけですがもう不要です！素晴らしいですね。

ただUDPサポートありますがたぶんユニキャストのみでしょうね。マルチキャストとかはダメな気がする（未検証）

InstanceInputEndpoint の追加

Endpoints要素にInstanceInputEndpoint要素が追加されました。従来外部からの通信は必ずロードバランサ経由でアフィニティなしで各インスタンスに分散されていたので、（RDP等内部でフォワードかけたりする仕組みを持っているものを除いて）狙ったインスタンスに接続させることは不可能でした。

InstanceInputEndponitでは以下のようにサービス定義ファイルに記述することで、指定された外部ポートを各インスタンスの指定ポート（この場合はtcp/80）にマップさせることができます。

    <Endpoints>
      <InstanceInputEndpoint name="direct" protocol="tcp" localPort="80">
        <AllocatePublicPortFrom>
          <FixedPortRange min="90" max="100" />
        </AllocatePublicPortFrom>
      </InstanceInputEndpoint>
    </Endpoints>

ポートフォワードのような感じですね。AllocatePublicPortFrom要素と併せて利用します。

ちなみにprotocolはtcp/udpのどちらかです。（http/httpsはtcpにしましょう）

InternalEndpoint のAnyサポート

InternalEndPointのプロトコルにAnyが指定できるようになりました。

    <Endpoints>
      <InternalEndpoint name="AnyProtocol" protocol="any" port="*"/>
    </Endpoints>

内部通信用に全部許可させることができます。便利ー。

AllocatePublicPortFrom の追加

InstanceInputEndpoint要素内で利用します。子要素にFixedPortRange要素を含めて利用します。

この要素配下のFixedPortRange は少し意味合いが変わって外部に公開してインスタンスと紐づけるためのポート範囲を定義する形になります。

監視の追加

ロードバランサがインスタンスのポートの応答を見てトラフィックを転送するかどうかの判定をカスタムで定義できるようになりました。（以前はインスタンスの状態がBusyだと除外とかそんな感じのみ）

サービス定義ファイルにLoadBalancerProbeスキーマが追加されてるので、そちらでどのポートを探査（監視）するか定義することができます。

※探査対象はhttpかtcpとなります。UDPはプロトコルの性質的に監視できません。

定義した探査設定はInputEndpointのloadBalancerProbe属性で指定しましょう。

	<LoadBalancerProbes>
		<LoadBalancerProbe name="probe" protocol="http" path="/" port="80" intervalInSeconds="15" timeoutInSeconds="11" />
	</LoadBalancerProbes>

※ServiceDefinition要素の直下に記述しないとスキーマの検証に失敗してエラーとなります。注意。

loadbalancerProbe要素で設定する属性は以下のとおりです。

Virtual Networkコンフィグの追加

詳細はこちら。新しいWindows Azure Virtual NetworkのVPN機能で使用するコンフィグです。

Wnidows Azure内部の（自分たちが管理する）仮想ネットワーク、DNSサーバー、外部（企業内など）ネットワーク、VPNゲートウェイなどを定義することができます。

VPN機能そのものが結構ボリューム大きいので説明は割愛。

デモ

実際に以下のような設定でいろいろ見てみたいと思います。

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzure1" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2012-05.1.7">
	<LoadBalancerProbes>
		<LoadBalancerProbe name="probe" protocol="http" path="/" port="80" intervalInSeconds="15" timeoutInSeconds="11" />
	</LoadBalancerProbes>
	<WebRole name="MvcWebRole1" vmsize="ExtraSmall">
		<Sites>
			<Site name="Web">
				<Bindings>
					<Binding name="WebEndpoint" endpointName="WebEndpoint" />
				</Bindings>
			</Site>
		</Sites>
		<Endpoints>
			<InputEndpoint name="WebEndpoint" protocol="http" port="80" loadBalancerProbe="probe" />
			<InputEndpoint name="dnsudp" protocol="udp" port="53"/>
			<InternalEndpoint name="AnyProtocol" protocol="any" port="*"/>
			<InstanceInputEndpoint name="direct" protocol="tcp" localPort="80">
				<AllocatePublicPortFrom>
					<FixedPortRange min="90" max="100" />
				</AllocatePublicPortFrom>
			</InstanceInputEndpoint>
		</Endpoints>
		<Imports>
		</Imports>
	</WebRole>
</ServiceDefinition>

サンプルのWebアプリはロールのインスタンスIDが見れるようにしておきました。

リロードすると（今回は3インスタンスなので）適当にばらけます。

インスタンスへの直接接続

90番ポートから順にインスタンス直へのポートとして割り当てるようにInstanceInputEndpointを定義しましたので、そのようにアクセスしてみます。

という感じで90、91、92ポートと順番にそれぞれのインスタンスに割り当てられたことがわかります。もちろん負荷分散されてませんので、何度リロードしても結果は変わりません。

監視のテスト

インスタンス2（_IN_1のやつ）のWeb.configを適当に壊して500エラーとかになるようにします。

まずはダイレクトアクセスしてみましょう。

つながらななくなりました。つまりLB側で転送しないようになってるみたいですね。（ASP.NETのエラーでもなく、そもそも繋がっていないことに注目してください）

インスタンス直ではないInputEndpointに接続すると、_IN_1を除いた2台にだけ分散されて接続されます（死活監視でエラーになったのが除外されている）。

それから、インスタンスそのもののステータスとしては何も問題ないということも注目ですね。

あくまで提供するサービスだけの状態を見て、必要であれば除外するということができるのがわかります。

タイムアウトをうまく設定することで、過負荷になってレスポンスが落ちてそうなインスタンスだけすぐ除外とかできるのがいいですね。

UDPの確認

UDPの確認ですが、適当にDNSサーバーでもインスタンス上に立てて試してみます。

クライアントからnslookupで確認してみましょう。

問題ないですね。

おまけ

サービス定義ファイル等に schemaVersion属性が追加されてますね。サービス定義ファイルのサイドバイサイドができるようになりました。SDKに合わせて定義できるように複数バージョンの定義を併記できるみたいです。今は1つですけど。てか使うかなぁ。

まとめ

ネットワーク周り強化されたことで、今まで回りくどいことをしてたり、諦めてたことが実現できそうで面白いですね。

参考

• Windows Azure Service Definition Schema (.csdef File)
• LoadBalancerProbe Schema
• Windows Azure Virtual Network Config (.netcfg)