はじめに
2018年1月25日にAWS東京リージョンにも4つ目のAvailabilityZone(以下、AZ)であるAZ-dが登場し、現在EC2インスタンスを配置できるAZはAZ-a、AZ-c、AZ-dの3つになっていると思います。
【参考】
・東京リージョンに新たにアベイラビリティゾーンを追加
HadoopやElasticsearchのような並列分散型アーキテクチャのシステムを東京リージョンで構築しようとするとこれまではAZ-aとAZ-cの2つのAZしか選択できず、AZ障害時はクォーラムを維持出来なくて困っていた方が多いのではないでしょうか。ちなみに自分もその一人です(笑)
せっかくなので、AZ間のネットワーク遅延を測定してみようかなと。。。
構成図
AW東京リージョンに3つのAZ(それぞれサブネット)を作成して、測定用のEC2インスタンスを配置ました。
各EC2インスタンスから双方向にPing200発打ってネットワーク遅延を測定しました。
| Region | Subnet | IPv4 CIDR | Availability Zone | AZ ID※1 |
|---|---|---|---|---|
| ap-northeast-1 | Subnet01 | 172.31.16.0/20 | ap-northeast-1a | apne1-az4 |
| ap-northeast-1 | Subnet02 | 172.31.0.0/20 | ap-northeast-1c | apne1-az1 |
| ap-northeast-1 | Subnet03 | 172.31.32.0/20 | ap-northeast-1d | apne1-az2 |
| ※1: re:Invent 2018で発表されましたが、各AZが物理的にどこのAZにマッピングされているのか判断出来るようにAZ IDというIDが表示されるようになりました。 | ||||
 |
さて実測！！
実測してみると以下のような感じでした。
①AZ-a(az4)→AZ-c(az1)
[ec2-user@ip-172-31-31-77 ~]$ ping 172.31.8.169
PING 172.31.8.169 (172.31.8.169) 56(84) bytes of data.
64 bytes from 172.31.8.169: icmp_seq=1 ttl=255 time=2.89 ms
64 bytes from 172.31.8.169: icmp_seq=2 ttl=255 time=2.58 ms
64 bytes from 172.31.8.169: icmp_seq=3 ttl=255 time=2.70 ms
64 bytes from 172.31.8.169: icmp_seq=4 ttl=255 time=2.62 ms
64 bytes from 172.31.8.169: icmp_seq=5 ttl=255 time=2.55 ms
<以下省略>
②AZ-a(az4)→AZ-d(az2)
[ec2-user@ip-172-31-31-77 ~]$ ping 172.31.32.168
PING 172.31.32.168 (172.31.32.168) 56(84) bytes of data.
64 bytes from 172.31.32.168: icmp_seq=1 ttl=255 time=1.73 ms
64 bytes from 172.31.32.168: icmp_seq=2 ttl=255 time=1.74 ms
64 bytes from 172.31.32.168: icmp_seq=3 ttl=255 time=1.73 ms
64 bytes from 172.31.32.168: icmp_seq=4 ttl=255 time=1.76 ms
64 bytes from 172.31.32.168: icmp_seq=5 ttl=255 time=1.81 ms
<以下省略>
③AZ-d(az2)→AZ-c(az1)
[ec2-user@ip-172-31-32-168 ~]$ ping 172.31.8.169
PING 172.31.8.169 (172.31.8.169) 56(84) bytes of data.
64 bytes from 172.31.8.169: icmp_seq=1 ttl=255 time=1.07 ms
64 bytes from 172.31.8.169: icmp_seq=2 ttl=255 time=1.07 ms
64 bytes from 172.31.8.169: icmp_seq=3 ttl=255 time=0.930 ms
64 bytes from 172.31.8.169: icmp_seq=4 ttl=255 time=0.943 ms
64 bytes from 172.31.8.169: icmp_seq=5 ttl=255 time=1.03 ms
<以下省略>
上記の結果を集計するとこんな感じになりました。
多少のばらつきはありましたが、200発実施結果の平均値を見て頂ければ概ね間違いはないと思います。
まとめ
実測してみると2つのAZを利用して冗長化するのであれば、apne1-az1とapne1-az2にマッピングされたAZを利用してシステムを組んだ方がネットワーク遅延によるデメリットは少なそうですね！！
(ELBでクロスゾーン負荷分散するケースやAmazon RDSでマルチAZ配置するケースなど)
いずれにしてもEC2でElasticsearchのクラスタを組むことが多い私にとってはAZ-dの存在は嬉しい限りですが^^
AWSアカウント単位でAZ IDのマッピングがされてしまいますので、私のアカウントでは残念ながらaz3は出てこず測定はできませんでした。やはりaz-3はあるんですよね。。