背景
前に書いた記事より。
どのゾーンを指し示すのかはサブスクリプション毎に違います。AWSのゾーンIDみたいですね。
ソースは・・・どこかで見た気がするんですが、見つかりませんでした・・・
ソースが見つからなかったので試しました。
これやらないと、ゾーン1ばかり使われて分散しないみたいな事象になってしまうので、何かしらやっているはず。だけど確証がなかった。
2022/06/06 追記: 書いてありました。2021年12月頃に追記されていました。
Each data center is assigned to a physical zone. Physical zones are mapped to logical zones in your Azure subscription. Azure subscriptions are automatically assigned this mapping at the time a subscription is created.
検証
検証方法
同じゾーンなら物理距離的にpingの応答が早いはずです。
そこで、2つのサブスクリプションA, Bで1,2,3ゾーンのVM計6台を立て、それぞれ(6x6=36ケース)でpingを50回行い、その最小値を取りました。
東日本で試しました。
手順
以下のリポジトリにまとめました。
結果
VMのサイズを変えたので2回分あります。1回目(B1s), 2回目(D2sv4)の結果を見てみましょう。
赤背景が強いほど遅いものです。赤字は別サブスクリプション中で最も早い値です。
一応、結果のログを置いておきます
考察
この結果から、おそらく以下のように対応していると考えられそうです。
- A-zone1 == B-zone1
- A-Zone2 == B-Zone3
- A-zone3 == B-Zone2
また、数値だけ見るとA-zone3、B-Zone2に関しては、自身に対しても1msオーバーするという調子が悪そうな傾向は一致しています。
つまり、ゾーン番号は必ずしも実体のゾーンと一致しない というのは言えそうです。
リソースグループが絡む可能性はありますが、リソースグループ間の通信をゾーンを合わせて連携させるというケースは十分あり、リソースグループで分けてしまうと予期しない性能劣化をすることとなってしまいます。なのでリソースグループは絡んでいないと考えています。
試した回数が少ないので正確なことは言えませんが、おそらくはサブスクリプション毎に異なると思います。
蛇足
ゾーン間のレイテンシ
東日本内の別ゾーン間は3ms弱といえそうです。
サブスクリプション移動はできなさそう
サブスクリプションで変わるならサブスクリプション移動したら、例えばA-zone2からB-zone3となってわかりやすいのでは？と思い、リソースグループ内のリソース（VM,NIC,OS-Disk,NSG,VNET）を移動しようとしたら、PublicIP等が引っかかって出来ませんでした。
Public IPもゾーン指定しているので、そういったリソースがある場合は無理なのかもしれない。
まとめ
分かりやすい場所に明記してください・・・