東京リージョンAZ間のネットワーク性能測定

東京リージョンAZ間のネットワーク性能測定:

はじめに

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はあるんですよね。。