似たような機能でも思想が違うと色々違いが出るんだなと感じます。
何かを学ぶときにそれだけでを学ぶのではなく類似品をみることで特徴が掴めるのは何を学ぶにも大事ですね。
大きな考え方
₋AWSの考え方
ELBの下に仮想サーバを配置する。といったメニュー構成
₋Azureの考え方
仮想サーバに対して可用性セットを作って、さらにそのグループに負荷分散セットを作るといったメニューになっている。
可用性セットがあり、更新ドメイン、障害ドメイン、そして可用性セットがさらにそれを大きく包むという感じの構成になっているのだろう。
Bestプラクティスはあるけど好きに設定してくれというようなAWSの考えと、こうするべしというAzureの考えの差があるように感じる。
またTrafficManagerでリージョンマタギの負荷分散が可能。GCEにもあるけどこの機能は便利だなー。(TrafficManagerの実態がどこに存在するのかはわからなかった。)
ヘルスチェックURI
₋ELBの場合
ELBのヘルスチェックのコンフィギュレーションで「Ping Path」にヘルスチェックURIを設定
₋Azureの場合
画面からは設定も確認もできず、PowerShellで設定、確認する必要あり。
get-azurevm -ServiceName <リソースグループ名> -Name <VM名> | Get-AzureEndpoint
と打って出てきた中の「ProbePath」がヘルスチェックURI。デフォルトは空白なのでおそらく「/」を見に来ている。
更新するときはSet-AzureEndpointコマンドで行う。以下Pageに詳細がある。
Add-AzureEndpoint
Windows Azure Virtual Machinesで、死活監視(ヘルスチェック)しながらロードバランシングする手順 - 蒼の王座