AZ間のレイテンシについて
Multi AZ を使う時に気になるのが、AZ間のレイテンシ。
気にならないレベルだと皆さん言いますが、地理的に数十km離れたDC間
の通信なので、どうしてもレイテンシは発生します。
裏で専用線を引いているのは確かでしょうけど。
そこで、簡易的では有りますが、実際どのくらいのレイテンシなんだろ
と思ってテストしてみました。
1a → 1a 間 (インスタンスは異なる)
$ ping -c 10 10.0.1.111 PING 10.0.1.111 (10.0.1.111) 56(84) bytes of data. 64 bytes from 10.0.1.111: icmp_seq=1 ttl=64 time=0.646 ms 64 bytes from 10.0.1.111: icmp_seq=2 ttl=64 time=0.598 ms 64 bytes from 10.0.1.111: icmp_seq=3 ttl=64 time=0.702 ms 64 bytes from 10.0.1.111: icmp_seq=4 ttl=64 time=0.606 ms 64 bytes from 10.0.1.111: icmp_seq=5 ttl=64 time=0.575 ms 64 bytes from 10.0.1.111: icmp_seq=6 ttl=64 time=0.657 ms 64 bytes from 10.0.1.111: icmp_seq=7 ttl=64 time=0.607 ms 64 bytes from 10.0.1.111: icmp_seq=8 ttl=64 time=0.650 ms 64 bytes from 10.0.1.111: icmp_seq=9 ttl=64 time=0.641 ms 64 bytes from 10.0.1.111: icmp_seq=10 ttl=64 time=0.602 ms --- 10.0.1.111 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9001ms rtt min/avg/max/mdev = 0.575/0.628/0.702/0.041 ms
まぁ、普通(オンプレミスと同等)ですね。
1a → 1b 間
$ ping -c 10 10.0.10.22 PING 10.0.10.22 (10.0.10.22) 56(84) bytes of data. 64 bytes from 10.0.10.22: icmp_seq=1 ttl=64 time=2.31 ms 64 bytes from 10.0.10.22: icmp_seq=2 ttl=64 time=2.38 ms 64 bytes from 10.0.10.22: icmp_seq=3 ttl=64 time=2.33 ms 64 bytes from 10.0.10.22: icmp_seq=4 ttl=64 time=2.39 ms 64 bytes from 10.0.10.22: icmp_seq=5 ttl=64 time=2.35 ms 64 bytes from 10.0.10.22: icmp_seq=6 ttl=64 time=2.41 ms 64 bytes from 10.0.10.22: icmp_seq=7 ttl=64 time=2.37 ms 64 bytes from 10.0.10.22: icmp_seq=8 ttl=64 time=2.38 ms 64 bytes from 10.0.10.22: icmp_seq=9 ttl=64 time=2.43 ms 64 bytes from 10.0.10.22: icmp_seq=10 ttl=64 time=2.38 ms --- 10.0.10.22 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 2.318/2.377/2.434/0.062 ms
普通のWebサイトなら許容できる範囲ですが、ソーシャルアプリや
少しのレイテンシでビジネス機会損失に繋がるサービスだと微妙かも
知れません。
1a → 1c 間
$ ping -c 10 10.0.9.249 PING 10.0.9.249 (10.0.9.249) 56(84) bytes of data. 64 bytes from 10.0.9.249: icmp_seq=1 ttl=64 time=2.30 ms 64 bytes from 10.0.9.249: icmp_seq=2 ttl=64 time=2.34 ms 64 bytes from 10.0.9.249: icmp_seq=3 ttl=64 time=2.29 ms 64 bytes from 10.0.9.249: icmp_seq=4 ttl=64 time=2.38 ms 64 bytes from 10.0.9.249: icmp_seq=5 ttl=64 time=2.36 ms 64 bytes from 10.0.9.249: icmp_seq=6 ttl=64 time=2.37 ms 64 bytes from 10.0.9.249: icmp_seq=7 ttl=64 time=2.38 ms 64 bytes from 10.0.9.249: icmp_seq=8 ttl=64 time=2.35 ms 64 bytes from 10.0.9.249: icmp_seq=9 ttl=64 time=2.34 ms 64 bytes from 10.0.9.249: icmp_seq=10 ttl=64 time=2.36 ms --- 10.0.9.249 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9016ms rtt min/avg/max/mdev = 2.296/2.351/2.388/0.052 ms
対1bへのレイテンシとほぼ同様ですね。
裏の仕組みで上手く調整しているのかな。
とどのつまり、可用性を取ってMulti AZ構成にするか、レイテンシを
嫌ってSingle AZにするかサービス要件次第です。
どれを取るかはトレードオフです。
単純なWeb/DBなシステムならMultiでも良さげですけど、NATサーバ
とか、batchサーバとか諸々冗長化するとコストがかさみます。
そして、障害切り分けや運用が面倒くさそうです。
私は、RDS以外はオールSingleにしています。
というか、gumiさんの構成を真似てみました。(P.34)
http://www.slideshare.net/kentamagawa/aws-9170814
RDSがMulti AZである以上、異なるAZのWeb→RDS間の通信はどうしても
レイテンシが発生してしますので、可用性を捨てましたw
AWSはMulti AZ構成を推してるので、実はDC周りが割りと貧弱 or アメリカ
のアーキテクチャをそのまま持ってきたみたいな流れなんじゃないかなー
と想像しています。
SLA100%なんてものはあり得ないので、Multi AZ構成をプッシュする気持
ちは解りますけどねー。
オンプレミスで、DR構成は合ってもGLB使ってDC跨ぎで本番稼働させている
システムってそうそうないんじゃないかと思います。（CDNくらい）
インフラ知らないアプリ屋さんが踊らされているだけの気も。
ともあれ、SPOF考慮するとMulitAZが可用性は高いですけどね。
サービス要件と思想次第ですかね。
・補足
同一AZであっても、EIP間の通信だと、一回インターネットに出てしまう
のでレイテンシは発生します。
なるべくプライベートIP内で完結したほうが良いみたいです。
（未検証）
・参考
http://dev.classmethod.jp/cloud/aws/careful-multi-az-elb/
以上です。
