正月休みを利用して、Amazon EC2で遊んでみた。 去年の11月ごろ、自宅サーバーが故障する直前までMongoDBを試していたが、クラウド上に復旧するのに時間が空いてしまって今になってしまった。 「Amazon EC2」と「さくらのクラウド」の両方を使っているが、その使いわけがわかってきたのでエントリを書いておこう。 自分の同じような使いかたをしている人はいないかなとググッてみたが、自分ほどガチで使っている話題はなかったので、書いとく価値はあるかな…

伸び縮みのメリット(EC2)

[Sumibi.org]の10MレコードオーダーのapacheログをMapReduceで集計した。 後でMongoDBのデータベースが30GByteくらいに膨れあがることに気がついたのでAWSにしておいた良かった。 Wiki(oldtype.sumibi.orgドメイン)のapacheログもmongoimportすると最終的にはMongoDBのデータベースサイズが50G Byteくらい消費した。 予想を越えるDISK消費だったのでMongoDB用に 80G ByteのEBSを追加した。

apacheログからmongoimportできるjsonファイルに変換するのに大量のCPUリソースが欲しかったので、EC2のインスタンスを「ラージ インスタンス(64bit)」から「ハイ CPU エクストララージ インスタンス(64bitの8コア)」に変更して”make -j 6”で処理した。 8時間かかっても終わらなかった処理が2時間ちょうどで終わった。 ※ “make -j 8”にすると、Emacsでの編集作業でさえひっかかるため、”make -j 6”にした。

急にDISKを大量に使いたいとか、CPUを大量に使いたいという時にはそのの柔軟性のおかげで、EC2の便利さが体感できた。 プライベートであっても、処理を待っている間に別のハックをすると裏で走っている処理が気になる。 短時間で処理が終わって頭を次のタスクに切り替えれるのはありがたい。 時間を金で買うという感じだ。

タスクの切れめが縁の切れめ(EC2)

いざ集計を終えてみると、EC2は不要になった。 多分、次に重い処理をするまでは使わない。

bit単価が高い(EC2)

「ラージ インスタンス(64bit)」が時間 30円くらいで、「ハイ CPU エクストララージ インスタンス(64bitの8コア)」が時間70円くらい。 「マイクロ インスタンス(64bit)」は時間 1.3円くらいで安いのだけど、はっきりいって何もできないくらい遅い。 マイクロではEmacsでコピーアンドペーストをするだけで、5秒くらいかかる。文章の編集さえできないので使う意味は無い。 「スタンダード」というランクがあれば良いのだけど、32bit環境にしか無い。普段64bitのソフトウェアを使いたいので、それも無し。

結局「さくらのクラウド」が常用環境

「さくらのクラウド」にSumibi.orgサイトを起動しっぱなしにしているので、普段はそちらを使えばいいという結論になった。 ちなみに、本エントリ時点の「さくらのクラウド」のサイズはRAM 3GByte / HDD 80GByte / 月額約 5000円。 MySql(常時300 MByte消費)、Apache、sekka-server(tokyocabient使用)、Kahua(worker process10個)という構成。 EmacsをX forwarding over sshで手元のMacBook Proに転送している。(twitter-modeとw3mも使う。特に問題ない速度) 本エントリも、「さくらのクラウド」上のEmacsとsekka-serverで書いている。

まとめ

• Amazon EC2は必要な時だけ使う。
• 常用環境は、費用対効果を考えると「さくらのクラウド」になる。

参考: 2011-12-28Cloud* 自宅サーバが全壊したので「さくらのクラウド」に[Sumibi.org]環境を再構築した