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

# はじめに
2018年1月25日にAWS東京リージョンにも4つ目の**AvailabilityZone**(以下、AZ)であるAZ-dが登場し、現在EC2インスタンスを配置できるAZはAZ-a、AZ-c、AZ-dの3つになっていると思います。

**【参考】**
・[東京リージョンに新たにアベイラビリティゾーンを追加][01]

HadoopやElasticsearchのような並列分散型アーキテクチャのシステムを東京リージョンで構築しようとするとこれまではAZ-aとAZ-cの2つのAZしか選択できず、AZ障害時は[クォーラム][03]を維持出来なくて困っていた方が多いのではないでしょうか。ちなみに自分もその一人です(笑)

せっかくなので、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][02]で発表されましたが、各AZが物理的にどこのAZにマッピングされているのか判断出来るように**AZ ID**というIDが表示されるようになりました。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/211371/8122742d-6304-5f4d-7b00-4550f1d678d8.png)

# さて実測！！
実測してみると以下のような感じでした。

**①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発実施結果の平均値を見て頂ければ概ね間違いはないと思います。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/211371/bcf968ce-b2de-2986-fc8b-18a77794b7cf.png)

# まとめ
実測してみると2つのAZを利用して冗長化するのであれば、apne1-az1とapne1-az2にマッピングされたAZを利用してシステムを組んだ方がネットワーク遅延によるデメリットは少なそうですね！！
(ELBでクロスゾーン負荷分散するケースやAmazon RDSでマルチAZ配置するケースなど)
![image.png](https://qiita-image-store.s3.amazonaws.com/0/211371/4ef1d605-c86f-1390-9cba-e52bd80b4f91.png)

いずれにしてもEC2でElasticsearchのクラスタを組むことが多い私にとってはAZ-dの存在は嬉しい限りですが^^

AWSアカウント単位でAZ IDのマッピングがされてしまいますので、私のアカウントでは残念ながらaz3は出てこず測定はできませんでした。やはりaz-3はあるんですよね。。


[01]:https://aws.amazon.com/jp/blogs/news/the-fourth-new-availability-zone-tokyo-region/ "東京リージョンに新たにアベイラビリティゾーンを追加"
[02]:https://dev.classmethod.jp/cloud/use-az-id-for-identify-az-crossing-over-account/ "AWSアカウントに因らずアベイラビリティゾーンを識別できるAZ IDを利用しよう"
[03]:https://ja.wikipedia.org/wiki/Quorum "Quorum"