MySQLとInternal ELB
VPC上でInternal ELBが提供され、slave群をInternal ELB配下に置くことで、slaveサーバの冗長化が出来るようになりました。
そこで、ELB配下に配置した際のパフォーマンスの劣化と注意点を見つけるためにパフォーマンス測定をしてみました。
色々
- DB: とあるデータ件数の多いDB
- コネクション数: 100,200,300,400,500,600,700,800
- 試行回数: 1クライアントにつき 100回
- クエリはランダムに発行
- ELB配下には２台配置
結果
スループット(qps)
- スループットが上がっているのは、キャッシュヒット率が上がっているため
| connection | DIRECT | ELB |
|---|---|---|
| 100 | 1897.5 | 1703.5 |
| 200 | 2075.1 | 1696.3 |
| 300 | 2286.79 | 1897.37 |
| 400 | 3098.5 | 2033.93 |
| 500 | 3255.8 | 2110.2 |
| 600 | 3341.2 | 2687.9 |
| 700 | 3923.7 | 2886.3 |
| 800 | 4812.3 | 3224.3 |
平均実行時間 (sec/query)
| connection | DIRECT | ELB |
|---|---|---|
| 100 | 0.052 | 0.058 |
| 200 | 0.096 | 0.11 |
| 300 | 0.13 | 0.15 |
| 400 | 0.13 | 0.19 |
| 500 | 0.15 | 0.23 |
| 600 | 0.17 | 0.22 |
| 700 | 0.17 | 0.24 |
| 800 | 0.17 | 0.25 |
振り分けセッション数
全測定で、50%ずつ振り分けられた
感想
ELBを通した場合、一定の遅延によりパフォーマンス劣化が起こり、セッション数があがるに連れて、qpsの低下が大きくなる傾向があった。
また、slaveの台数が多くなった場合DBのキャッシュヒット率が下がり、qpsが低下している
注意点
ELBがセッションを張ったまま60秒データを送信してこないクライアントを切断するので、コネクションを貼ったまま60秒以上待機すると切断されるので、エラーのハンドリングと再接続の必要がある
ELBのヘルスチェックで、tcp:3306をチェックしていると、「blocked because of many connection errors.」がでてブロクされてしまう、mysqladmin flush-hostsを実行すると解決するのと、max_connect_errorsをでかい値にしすれば少しの時間はしのげるのですが、いずれ到達してしまうので、mysqldの生存を監視するものを動かして、そいつに対してヘルスチェックをしてやります
