AmazonWebService実践入門を読んで実践する「その１：I/Oの高速化」続き２
「その１：I/Oの高速化」の結果検証
前回のブログに記載した結果が、検証前仮説と異なる結果になったため、詳細に検証・分析してみたいと思います。
ログの内容を見比べる
- bw(帯域幅)が、IO1(プロビジョンドIOPS）の場合だけ、1/5ぐらい低い。
- 4タイプ（Sequential-Read、Sequential-Writes、Random-Read、Random -Writes）の帯域幅を合計した値で ストレージタイプごとのbw（帯域幅）を見るとよくわかる。
ボトルネックを解消する
* 帯域幅がボトルネックになっているときは、EBS最適化オプションを使うことを「AmazonWebService実践入門」ではおすすめしていた。
EBS最適化オプションを使う。
- EBS最適化オプションとは…EC2インスタンスとEBSボリュームはネットワークを介して接続されているが、そのネットワークはEBSへのアクセス以外のアクセスにも利用されている。そのネットワーク帯域を占有して、EBSへのアクセスを最大化するためのオプションがEBS最適化オプションである。
EBS最適化オプションを適用する。
インスタンスタイプをt2.microで利用していたため、EBS最適化オプションの利用できるタイプにインスタンスタイプを変更する必要があった。そのため、以下の手順で『m4.large』へ変更した。
①AWSマネジメントコンソールから、インスタンスを停止して、「アクション」→「インスタンスの設定」→「インスタンスタイプの変更」を選択する。
- ②次に出てきたモーダルウィンドウでEBS最適化にチェックの入っているインスタンスタイプを選択する。
※EBS最適化オプションが利用できるインスタンスタイプは限られている。詳細は、こちらへ
※また、EBS最適化オプションを適用する方法は、こちらの公式ページにも掲載されています。
再計測
インスタンスの状態を『m4.large』＋「EBS最適化オプションをオン」にして、再計測しました。
結果：まったく変わらず。
HDDにおいては、エラーになり、ログ記録が全くされていない。
汎用SSDは、Read、Randreadしか記録されない。という状態。
ORZ
うーん。何がいけないのか。。。もう一度再考が必要。
計測方法の再考
本に書かれているベンチマークの方法と違いを探してみる。
- １インスタンスにボリュームを複数アタッチしている。
- ブロックサイズが小さい。
- directオプションを利用している。
- numjobsオプションを利用している。
- runtimeオプションを利用している。
- group_reportingオプションを利用している。
- 対象ディレクトリが違う。
ということでこのあたりを教科書通りにして再度チャレンジしてみる。 今日はここまで。
