webサーバーと異なるアベイラビリティゾーンに置いた(Multi-AZ利用)RDSの速度検証

はじめに

こんにちは、hacknoteのohnoです。

今回はRDSのMulti-AZ配置を行ったときに起こる可能性が高い別アベイラビリティゾーンに配置されたサーバー-RDSの通信についての速度検証を行ってみました。

Multi-AZについて

Multi-AZは異なるアベイラビリティゾーンに配置する設定です。

アベイラビリティゾーンとは、データセンター単位で分かれており、物理的な災害が発生しても別のアベイラビリティゾーンに置いていれば安全です。

Amazon Web Services ブログ

自然災害やデータセンター単位の障害などビジネスに影響を与えるリスクを最小化するよう地理的に影響を受けない十分離れた場所にあり、フェイルオーバーを実現し事業継続性を確保できるインフラストラクチャです。

しかし、データセンターが離れているということは、同一データセンターで動作させているよりもレイテンシが大きくなるはずということです。

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か何かでいれておくと良いかもしれません。