AzureとAWSの可用性ゾーン(AZ)

Microsoft Azureの「可用性ゾーン(AZ)」が東日本で利用できるようになっています。西日本はもう少しかかりそうですが、いずれは利用できるようになるそうです。

AzureのAZは、リージョンあたり3つと決まっています。AWSは「2つ以上」だったでしょうか。

Azureのリージョン間は数百Km以上離れているので非常に安全ですが、少々距離が遠すぎます。一方、AZ間の距離は(同一リージョン内の)数十Kmと、かなり短くなっています(AWSと同程度です)。阪神大震災でも40Kmも離れればほとんど影響はありませんでしたから、実用上はAZで十分でしょう。

従来の可用性セット(AS)は、最短でサーバーラックが分離されるだけですから、大規模災害に対しては少々不安が残ります。災害リスクを考えるとAZが必要でしょう。また、日本に関しては、可用性セットで分離できる障害ドメイン(サーバーラック)は2つですから、障害範囲に関しても現時点ではAZの方が有利なようです。

ただし、AZは仮想マシンを作るときにゾーンを明示的に指定する必要があります。それに対してASは「とりあえず同じASにする」という設定で、適当に分散してくれます。何も考えなくてもいいので、ASの方が設定は楽です。

以上のことから、災害対策を想定する場合はAZ、ハードウェア障害を想定する場合はASと使い分けるのがいいようです。なお、Azureでは災害対策にはASR(Azureサイトリカバリ)も利用できます(ASRはリージョン間の複製です)。ASRを使っているならAZを使う必要はないでしょう。

また、「AzureのAZはAWSのAZと同じ」という説明がされていますが(私もしています)、実際には違いもあります。

AWSでは、AZ単位でサブネットを分割する必要があります。これに対して、Azureでは同一サブネット内に異なるAZのサーバーを配置できます。

もっとも、AZが違えばデータ伝送遅延時間が違うので、異なるAZを同じサブネットにするのが適切かどうかは分かりません。AWSと同じように、異なるAZは異なるサブネットにした方が分かりやすいのではないでしょうか。

試しに、複数のAZに複数のサブネットを構成してpingを実行してみました。Windowsのpingは応答時間の分解能が低いのでLinux(Ubuntu)を使っています。

図のように、AZ内では1ミリ秒程度、AZ間では2ミリ秒程度の遅延がありました。サブネットの有無は速度に影響しません。これもAWSと同様のようです。

アプリケーションにとっては1ミリ秒と2ミリ秒の違いが重要な場合もあるので、サブネットを自分で分けた方が分かりやすそうです。