@kyanny's blog

My thoughts, my life. Views/opinions are my own.

AWS の IOPS 課金でパケ死しかけた

クラウド破産 - Togetterまとめ

これより金額は一桁少ないけど、考えなしに AWS で大量の IO が発生するベンチマークを実行して請求額が跳ね上がった。次回の請求額が $231 もあって、思い当たる節があったので明細をみてみたら予想どおり SSD な EBS ボリュームに対する IOPS のコストがかさんでいた。

f:id:a666666:20141203232620p:plain

f:id:a666666:20141203232629p:plain

実行したベンチマークはこれ https://github.com/kyanny/bench_20141106 で、 MongoDB でコレクションからランダムに findOne するとき、コレクション内のドキュメント数によってパフォーマンスに差が出るのかどうかを確認したかった(インデックスを利用したクエリ)ちなみに結果は「大差なかった」。

知人に「EC2 インスタンスじゃ同一スペックでも同じハードウェアにはならないからベンチマーク取っても意味ないっしょ」と突っ込まれてなるほどと思ったけど後の祭り。短時間で発生する従量課金なので CloudWatch の Billing alarm が飛んできたとしても時すでに遅しだったと思うけど、 $10 とか低い金額にしかセットしてないのは良くないので段階的になるように alarm を増やすつもり。

先人の知恵から何も学ばなかったので高い授業料を払うはめになったけど、なにごとも一回失敗して痛い目みたほうが身につくと思っているので、これはこれで良い経験だった。でももしこれが一桁二桁違っていたらと想像して手が震えた。


そもそもなぜ月額定額の VPS ではなく従量課金の AWS でベンチマークなんてとろうと思ったかというと、ベンチマーク実行環境の再現性を考えてのことだった。

ハードウェア面で同一条件にならないという点を忘れていたので根底からロジックが破綻しているけど、ベンチマークは追試できることが重要だと考えていて、それにはベンチマークプログラムが公開されていることだけでなく、ベンチマーク実行環境と同じ環境を他の人が準備できることも重要だと思う。

「自分の MacBook Pro でやりました」とかだと、他の人が他のマシンで同じベンチマークを実行した数値と公平に比較できない。かといって「自分の個人契約している VPS でやりました」とかだと同一条件の環境を他の人が準備しづらい。 AWS ならインスタンスタイプもマシンイメージも同一の条件を用意しやすい。

追試できないので検証不可能なのと、追試できるけど誰も検証しないのとの間には大きな差がある。他の人がベンチマークをとって数値だけ見せてるのをみて、「その数値を信じる根拠は?」ともやもやを感じることがあるので、自分が数値を見せられる立場だったとき不信感が少なくなるようなやり方を考えて実践してみたらコンピューティングリソース(とお金)を無駄遣いしてしまった、というのが今回の顛末。

次からは DigitalOcean を使おうと思う。