先日、Sekkaの辞書を作るためにAWSのEC2サービスを利用した。 Sekkaの辞書を作る処理は半年に1回程度しか必要にならないのだが、手元のMacBookで実行すると24時間位はかかるような重い処理だ。(CPUとメモリの両方を大量に使う) 手元のMacBook Proは電源を入れっぱなしにしたくないので、できればどこかのサーバー上で処理したかった。

一般的にいって、こういう用途にAWSのEC2はぴったりだ。Microインスタンスを使えば課金はタダのような値段だ。(少なくともそのハズだった) しかし、EBSの重量課金の罠にハマってしまったので、広く失敗事例を公開しておこうと思う。

Microインスタンスでスラッシング発生

上記のような根拠でEC2のMicroインスタンスを使ってSekkaの重い処理を実行開始した。 急ぎでもなかったので、バッチを開始して1週間くらい放置しておけばできあがっているだろうと気楽に考えていた。 実際、1日放置してみたが、進捗状況から、あと6日前後で処理は完了することが推測できた。

2日間放置したところで、たまたまAWSの課金状況を他の件(DynamoDBがどうなってるか気になった)で確認することがあり、EBSの課金がとんでもないことになっているのに気がついた。 以下が画面キャプチャ。 なんと、EBSのI/Oリクエストで1日 $10程度課金されていた。(後で、AWSの”Account Activity”からCSVを出力して詳細な操作ログを確認したが、本当に1日 $10相当のI/Oがあった) 心当たりはスワップしか無い。 Sekkaの辞書作成用処理はメモリを1.5GByte程度消費するので、常時1GByte程度がスワップアウトする計算になる。

スワップパーティションはEBSを2GByte割りあてており、1GByte程度が常時スラッシングしていたに違いない… なんということだ… EBSのI/Oリクエスト回数はどうせ安いだろうと気にしたこともなかったので盲点であった。 もし、7日間放置していたらどうなっていたことか… 単純計算で$70になるじゃないか…

EC2でのスワップはどこに確保すべきか

少しググってみたが、OSのスワップ領域をEBS以外に取る方法は見つけられなかった。 大勢の人がEBS上にmkswapしているようだ。 くれぐれもその方達のMicroインスタンスがスワップしないことを祈ろう。 エフェメラル領域に確保すれば良いのかもしれないが、Microにはエフェメラル領域は無い。これも重ねて落とし穴にハマりやすい仕様になっている。

解決策は？

基本はEC2ではスワップさせないこと。 一時的にスワップするのは問題無いが、何日もスワップする場合は使い方が間違っている。 一つ上のスペックのインスタンスタイプを使ってスワップしないメモリ容量を確保しよう。

まとめ

EC2ではスワップさせていけない。 スワップしても長時間はダメ。EBSへのI/Oリクエスト課金がEC2のコンピューティング課金を上まわる。

---

コメント by そういえば:
少し高いですがSSDのEBSでは、I/Oリクエスト課金がなくなりました。 http://aws.amazon.com/jp/ebs/details/

新しいt2.microインスタンスは、メモリが1GBになっている点もいいですね。

---

コメント by kiyoka:
本当ですね。情報ありがとうございます。 SSDのEBSでは1GB単位で予めI/O料金を含んでいるんですね。 http://aws.amazon.com/jp/ebs/pricing/

コメント by そういえば:
少し高いですがSSDのEBSでは、I/Oリクエスト課金がなくなりました。 http://aws.amazon.com/jp/ebs/details/

新しいt2.microインスタンスは、メモリが1GBになっている点もいいですね。