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

はじめに

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

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

IOPSを確認

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

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

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

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

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

スループットを確認

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

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

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

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

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

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

増強は果たして必要か?

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

EBSのスペック

負荷状況

上記を計算すると、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になりました。

[アップデート] Amazon EBS 汎用 SSD（GP2）の最大パフォーマンスが向上しました

EBSの切り替え

EBSは無停止でタイプも容量も変更可能になっています。
各種条件は以下の記事も参考にしてください。

【遂に来た！】EBS でボリュームサイズを変更できるようになりました（ボリュームタイプ変更も）

大切なデータを失わないように、慎重を期して作業前は検証とバックアップを忘れないようにしましょう!

終わりに

AWSの柔軟性を最大限に活用して、コストをデザインしていく必要性を痛感しました。