【小ネタ】Amazon RDSの汎用（SSD）ボリュームに負荷をかけてBurstBalanceメトリクスの挙動を見てみた

はじめに

こんにちは、城内です。 今回は、最近ちょこちょこ確認することがある、RDSのディスクI/Oに関して、小ネタをはさみたいと思います。

やってみた

Web系のシステムで画面表示が遅いなどの障害に出会った時、ボトルネックを探るためWebサーバやDBサーバのリソース状況を確認するかと思います。 1つ1つ確認していけばある程度は当たりがつくものですが、最近、DBサーバのディスクI/Oがボトルネックであるケースにあたりました。

AWSではこれは結構あることかと思いますが、汎用（SSD）ボリューム（GP2）が標準的に使われるようになった今、割とボリュームサイズが小さめだったりで思った程パフォーマンスが出ていない、なんてことありませんか？ 実は結構なディスクI/Oが発生しているのに、長時間の処理を動かしたことがなく、バーストでギリギリ乗り切っていた、なんてケースでは意外と気づかないものだったりするかと思います。

そんなこんなで調査をしながら、以下のような記事を読んでいたら、

• Tips：RDSでのIOクレジットバランスの考え方（汎用SSDボリューム）
• [EBS] gp2のBurstBalanceが確認可能となったのでボリュームサイズ別に検証してみた

なんと、CloudWatchのRDSのメトリクスにもBurstBalanceがあるじゃないですか！？

ただ、CloudWatchのドキュメントには記載がなかったので、正確にEBSのBurstBalanceと同じものかどうかは判断がつきませんでした。

• Amazon RDS のメトリクスとディメンション - Amazon CloudWatch

ということで、じゃあ、実際に動かして挙動を見てみよう、と、RDSにディスクI/Oの負荷をかけてみました。

環境は以下の通りです。

エンジン：MySQL 5.6.35 インスタンスクラス：db.m4.large ストレージタイプ：汎用（SSD） ストレージサイズ：100GB

MySQLでの負荷テストツールは、標準のmysqlslapを使いました。 以下のようなコマンドで、パラメータをちょこちょこ変えながら、どこまで高負荷をかけられるかなと実行していました。

$ mysqlslap \
>  --no-defaults --auto-generate-sql --engine=innodb --auto-generate-sql-add-autoincrement \
>  --host=mysqldb.abcdef123456.ap-northeast-1.rds.amazonaws.com --port=3306 --user=dbadmin --password=xxxxxxxx \
>  --number-int-cols=10 \
>  --number-char-cols=10 \
>  --iterations=50 \
>  --concurrency=5 \
>  --auto-generate-sql-write-number=3000 \
>  --number-of-queries=100000 \
>  --auto-generate-sql-load-type=write

結果、以下のようになりました。

800～1500IOPSくらいの負荷を何度かかけていったら、3時間ほどでクレジットが枯渇したのか、一気に300IOPSまでパフォーマンスが落ちました。 そして、また徐々にクレジットが回復していっているような様子が見て取れます。

これはEBSのBurstBalanceのメトリクスのように確認できそうですね！

さいごに

今回、初めてこんなにまじまじとGP2のクレジットが枯渇するのを目撃しました。（というか、自分でやった） GP2はよく使いますが、やはりクレジットの増減には注意が必要だなと感じました。

お手軽に使えてなんとなくいいパフォーマンスが出てしまうので、チューニングはゆるくなりがちかもしれませんが、ぜひ気をつけてみてください。