EC2に接続したEBSボリュームのI/O待ちが疑われる。AWS/EBSの同じVolumeIdについて、同一の60秒間隔でキューの滞留と完了した読み書き操作の傾向を比較したい。
まず指標を正しく読むことが目的で、キュー長だけから性能不足を断定しない。操作回数をIOPSへ換算する方法も確認する。
最も適切なメトリクスと統計の組み合わせはどれか。
同じVolumeId・期間で待機キューのAverageと完了OpsのSumを比較し、IOPSは期間秒数で割って求める。
詳細解説
バイト数は転送データ量であり、待機要求数ではない。
ネットワーク送信量は対象EBSボリュームの待機I/O数ではない。
待機要求の平均と期間内の完了操作数を比較でき、操作数の合計を60で割ると平均IOPSになる。
期間内の回数を秒当たりの率と混同している。60秒期間なら秒数で割る必要がある。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式メトリクス表の単位・統計・VolumeIdと、Ops/sの計算式、I/Oサイズと性能上限の説明を確認する。
参考にした公式資料
確認できる内容
60秒で読み書き合計6,000操作なら平均100 IOPSと計算し、キュー長だけで原因を断定しない。
理解のポイント
- VolumeQueueLength
- VolumeReadOps
- VolumeWriteOps
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
件数と率を同じ時間軸で読む
VolumeQueueLengthは完了を待つ読み書き要求数で、Averageを使って滞留傾向を見る。ReadOps／WriteOpsは完了操作の回数で、Sumを期間秒数で割って率へ換算する。60秒で合計6,000操作なら100 IOPSである。バイト数から求めるスループットとは単位が違う。
キュー長から追加調査へ進む
キューの増加は需要やI/Oサイズにも左右され、単独では故障やIOPS不足を確定できない。遅延、転送量、ボリュームのIOPS・スループット上限とEC2側のEBS帯域を照合する。高いキュー長がすべてのボリュームで異常という共通しきい値は置かない。