はじめに
こんにちは、hacknoteのohnoです。
今回はRDSのMulti-AZ配置を行ったときに起こる可能性が高い別アベイラビリティゾーンに配置されたサーバー-RDSの通信についての速度検証を行ってみました。
Multi-AZについて
Multi-AZは異なるアベイラビリティゾーンに配置する設定です。
アベイラビリティゾーンとは、データセンター単位で分かれており、物理的な災害が発生しても別のアベイラビリティゾーンに置いていれば安全です。
自然災害やデータセンター単位の障害などビジネスに影響を与えるリスクを最小化するよう地理的に影響を受けない十分離れた場所にあり、フェイルオーバーを実現し事業継続性を確保できるインフラストラクチャです。
しかし、データセンターが離れているということは、同一データセンターで動作させているよりもレイテンシが大きくなるはずということです。
Multi-AZのアベイラビリティゾーンについて
AZ空間を同一で立てればとりあえず早いんだろう、ということは上のことからわかりますが、そうはいかないケースがあります。
RDSのMulti-AZ配置を使った場合には再起動、アップデートなどの影響で切り替わることになるためです。
変わった時に再度差し戻しが必要なレベルか、いずれまた切り替わるので放置で大丈夫なのかを確認するためにも
異なるアベイラビリティゾーンに置いたWordPressを動かすサーバーと、Single-AZで同じアベイラビリティゾーンに置いたサーバーでそれぞれ比較してみます。
速度検証用インスタンス作成
まずはRDSをap-northeast-1aに配置しました。
また、webサーバーをt2microで作成、ap-northeast-1aとap-northeast-1cに配置しました。
作成方法はhacknoteの記事にありますので、そちらを参考にしてwebサーバーにWordPressを設置、RDSを参照させてアクセスできるようにします。
速度検証
まずは単純に各インスタンスからRDSにnpingコマンドを発行、データを見てみます
同一アベイラビリティゾーン（A-A）サーバー
Max rtt: 1.040ms | Min rtt: 0.449ms | Avg rtt: 0.595ms Raw packets sent: 100 (4.000KB) | Rcvd: 100 (4.400KB) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 99.22 seconds
別アベイラビリティゾーン(A-C)サーバー
# nping -c 100 xxxxxxxxxx.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -p3306 --tcp Max rtt: 3.674ms | Min rtt: 2.672ms | Avg rtt: 2.757ms Raw packets sent: 100 (4.000KB) | Rcvd: 100 (4.400KB) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 99.23 seconds
rtt(最初にレスポンスが返ってくるまで)平均でも0.595ms→2.757msと速度が落ちている事がわかります。
なので、DBに頻繁にアクセスするサーバーであればアベイラビリティゾーンは同一にしておいたほうが良いでしょう。
速度検証(WordPress)
これが例えばWordPressであった場合にはどれくらいのアクセス速度に差が出るかを今度は検証してみます。
2msくらいの誤差ならそんなに差はでず、インスタンスガチャのほうが大きいのではないかなーと思いながらもトライ。
テスト方法は、シンガポールリージョンに配置したec2インスタンスからのabコマンドで計測してみます。
同一アベイラビリティゾーン（A-A）サーバー
Concurrency Level: 20
Time taken for tests: 32.909 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 53335000 bytes
HTML transferred: 53049000 bytes
Requests per second: 30.39 [#/sec] (mean)
Time per request: 658.188 [ms] (mean)
Time per request: 32.909 [ms] (mean, across all concurrent requests)
Transfer rate: 1582.68 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 68 68 0.9 68 80
Processing: 236 583 108.6 589 888
Waiting: 100 445 111.6 453 752
Total: 306 651 108.6 657 956
別アベイラビリティゾーン(A-C)サーバー
Concurrency Level: 20
Time taken for tests: 31.445 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 53314000 bytes
HTML transferred: 53029000 bytes
Requests per second: 31.80 [#/sec] (mean)
Time per request: 628.897 [ms] (mean)
Time per request: 31.445 [ms] (mean, across all concurrent requests)
Transfer rate: 1655.74 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 70 70 1.8 70 108
Processing: 300 553 98.5 556 864
Waiting: 160 411 100.0 414 724
Total: 370 623 98.4 625 935
同一のが遅い・・・。まぁわかっていたけど、初期のWordPressでわかるほどの差は出ません。 ゴリゴリと検索などを使ったりしているwebサーバーで速度問題がDBだと判明していたら試したらいいかと思います。
まとめ
サーバーにもよりますが、普通のwebサーバーであれば気にしないでもいいと思います。
大量にSQLを処理するというサーバーでもレイテンシより処理内容のほうが影響が大きいかと。
なんか復旧してから前より遅いなーと思ったら試してみて、
改善されたらAZ反転時に戻す処理をlambdaか何かでいれておくと良いかもしれません。
