EBSのIOPSとスループットをCloudWatchから確認してみる

瀬田安弘

2018.12.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

瀬田@大阪オフィスです。

システムの運用をしていると、現状どれだけの性能が出ているのか、リソースをどれだけ食っているのかといったキャパシティ情報を監視し、将来的なリソース追加計画を立てて行く必要があります。
オンプレ時代、リソースはとりあえず大きめにマージンを取り余裕を見るといったことをしていましたが、AWSの場合にこれをするとコストに直結するため、適切な状況把握がより重要となってきます。
今回は、EBSのI/O状況をCloudWatchから確認し、EBSのスケールアップに必要な情報を集めてみたいと思います。

IOPSを確認

IOPSは秒間I/O操作の総数なので、
CloudWatchのVolumeReadOps(読み込み数)とVolumeWriteOps(書き込み数)から計算します。
CloudWatchで対象のボリュームの値を確認して見ましょう。

5分ごとに値が取得できていることが確認できますね。
この値は、5分間に発生したI/O数を示しているので以下の意味になります。

VolumeReadOps	３００秒の間に発生した読み込み回数
VolumeWriteOps	３００秒の間に発生した書き込み回数

さて、計算して見ましょう。

(VolumeReadOps　(4260回) + VolumeReadOps(567回)) / メトリクスの範囲(300秒)

以上から「16.9 IOPS」が算出されます。

スループットを確認

スループットは秒間I/Oのデータ量なので、
CloudWatchのVolumeReadBytes(読み込みバイト)とVolumeWriteBytes(書き込みバイト)から計算します。
CloudWatchで対象のボリュームの値を確認して見ましょう。

5分ごとに値が取得できていることが確認できますね。
「統計」は「合計」にして下さい。(計算には「期間内に転送されたバイトの総数」を使います)

この値は、5分間に発生したI/Oバイトを示しているので以下の意味になります。

VolumeReadByte	３００秒の間に発生した読み込みバイトの合計
VolumeWriteByte	３００秒の間に発生した書き込みバイトの合計

では、計算して見ましょう。

(VolumeReadByte　(3.76MByte) + VolumeReadByte(1.52MByte)) / メトリクスの範囲(300秒)

以上から「17.6 Kbyte」が算出されます。

増強は果たして必要か?

上記の計算を使って、増強が必要になりそうな状況をシミュレーションして見ます。

EBSのスペック

タイプ	容量	最大IOPS	最大秒間スループット
gp2	1TB	3000	~~160MB/秒~~250MB/秒

負荷状況

VolumeReadOps(読み込み数)	100k
VolumeWriteOps(書き込み数)	800k
VolumeReadBytes(読み込みバイト)	4GByte
VolumeWriteBytes(書き込みバイト)	37GByte

上記を計算すると、IOPSは3000、スループットは137MB/秒でした。

検討

IOPSが上限ギリギリなので、増強が必要と判断され、IOPSを4000まで上げようと考えます。
IOPSをあげれば、スループットも増えるはずなので、IOPSが4000になった時のスループットを推測します。
IOPSに比例して伸びるとして、IOPSが1000増えると、スループットが45MB/秒増えると推計されます。
~~なので、単純にIOPSを上げても、gp2の最大スループット(160MB/秒)上限にひっかかかると考えられます。<brassmethod.jp/cloud/aws/increases-performance-gp2/~~

gp２のボリュームあたりのスループットが160 MB/sから250 MB/sになりました。