AWS RDSとEC2のゾーン横断時の応答遅延

AWSのRDSは非常に便利だ。自分のように、仕事でWebアプリを作っているので常にDBを使っていながら、ビジネスロジックを書くのは嫌いじゃないがDBや基盤に関する愛がまったくなくて、チューニングや保守について調べたり設定したりするのが面倒で仕方ない人間にはものすごくありがたい。

で、表題の通り、EC２から使う場合に、RDSは同じゾーンに配置した方がネットワーク上の遅延の少なさから有利というのはAWS公式手引きでもちらほら見かけた気がするが、では実際どのくらい違うのかということについて、さっきたまたま調べたのでメモる。

※ 調べたと言っても、体系的にやったわけではない。自分の手許の環境ではこうだったというだけの話ではある。

EC2側のクライアントから実行したSQLの応答時間は次のようになった。

同じゾーン　0.5～1ms

違うゾーン　20～30ms

すべて東京リージョンで、違うゾーンというのは東京内の選択肢で末尾がaとかcとかそういうアレ。

5倍くらいかかっているということになるが、これがほぼネットワーク的な遅延そのものであると思われる。違うゾーンで使っている場合のこの遅延は、重いSQLをちょこちょこ散発的に投げるようなケースでは問題にならないはずだが、複雑なWebサイトの表示のように、細かくて軽いSQLを大量に投げるようなケースでは大きな問題になると思う。

意外に大きな遅延で驚いた。

ちなみに、上記の確認で投げたSQLはこんなもので、応答の確認はpsqlでtimingコマンドを有効にして行った。

xxxdb=> explain select val from test_table where id='xxxxyyyyzzzz';
                          QUERY PLAN
---------------------------------------------------------------
 Seq Scan on test_table  (cost=0.00..1.02 rows=1 width=32)
   Filter: (id = 'xxxxyyyyzzzz'::text)
(2 rows)
Time: 0.798 ms

テーブルにはデータは数件しか入っておらず、「id」列は主キー。件数が少ないのでシーケンシャルスキャンになっていたりするが、インデックススキャンになるようにしても応答時間はたいして変わらない（要は、どんな実行計画で実行しても限りなくゼロに近い時間で応答できる）。


また、使ったRDSのインスタンスはdb.t2.micro, db.t2.small, db.m3.large, db.m3.xlargeなどだが、それによる応答時間の差はほとんどなかった。