Amazon Elastic Block Store(EBS)でmysqlを動かしてみたよ
Good job, Amazonということで、実際にやってみました。
詳しくは
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1663&categoryID=100
を参照していただければと思いますが、日本語の方が良いという方はこちらをご参考までに。
$で始まるコマンドはクライアントのterminalから。
#で始まるコマンドはECサーバーで実行。
とりあえず、テスト目的なので、ゼロからEC2インスタンスを作るところからやっています。
インスタンス起動とポート確認
とりあえず、僕自身は一番centosが慣れているのですが、Amazonオフィシャルのイメージにcentosが無いので、rightscaleが提供しているイメージを使うことに。
詳しくは
http://vividtone.seesaa.net/article/97841106.html
を参照の上、自分に最適なイメージを使ってください。
僕の場合は、ami-5c08ed35を使いました。
$ ec2-describe-images -x all | grep rightscale
$ ec2-run-instances ami-5c08ed35 -k mymachine
$ ec2-authorize default -p 22
$ ec2-describe-instances
inctance idをメモる。i-xxxxxxと書きます。
zoneもメモる。us-east-1bみたいなもの。
EBS volumeを作ってattachする
$ ec2-create-volume -z us-east-1b -s 1
us-east-1bの部分はEC2が起動しているzoneを指定した方がいいかと。
最後の1は1GB分のvolumeを作るという意味です。
vol idをメモる。vol-xxxxxxと書きます。
$ ec2-describe-volumes vol-xxxxxx
$ ec2-attach-volume -d /dev/sdh -i i-xxxxxx vol-xxxxxx
マウントする
# mkfs.xfs /dev/sdh
# echo "/dev/sdh /vol xfs noatime 0 0" >> /etc/fstab
# mkdir /vol
# mount /vol
mysqlのデータを移動して、設定ファイルを書き換えてコピー
mysqlが動いている場合はmysqlを一旦止めて、mysqlのdatadirを全部/vol/log/mysql/にコピー。
# /etc/init.d/mysqld stop
# mkdir /vol/log /vol/log/mysql
# mv /var/lib/mysql/* /vol/log/mysql
設定ファイルを書き換え。
以下の2行は本当に最小限度のものであって、bin-logとかslow-query-logとかは同じ感じで書き換えてください。
# vi /etc/my.cnf
- -
再起動して、DBが作れることを確認。
# /etc/init.d/mysqld start
# mysql -p -e 'CREATE DATABASE tutorial_sample'
# mysql -p -e 'SHOW DATABASES'
EBS volumeをdelete（作ったままだとお金かかっちゃうから）
# /etc/init.d/mysqld stop
# umount /vol
$ ec2-detach-volume vol-xxxxxx
$ ec2-delete-volume vol-xxxxxx
EC2インスタンスをdelete
$ ec2-terminate-instances i-xxxxxx
確認
$ ec2-describe-instances
$ ec2-describe-volumes
テストにかかった費用
以下の通り、25セント。途中でタバコすったりいろいろパラレルで作業してたりしたから、ec2が2時間つかってることになっていたり、ムダが多いので実際はもっと安くなるかと。
AmazonのElastic Block Store(EBS)がなぜ素晴らしいかについて（Amazonへの要望付き）
実際にEBSにmysqlを入れてみたという実験記事は、
http://d.hatena.ne.jp/shibataism/20080822/1219422913
に書きました。エンジニアの方はこちらもどうぞ。
最初に結論を。EBSがなぜ素晴らしいかというと、
EBSの登場によって、AWSの一連のサービスで、もはやサーバーを自前で買ったり、データセンターに高いお金を払う必要が全く無くなったと言ってもいいから。
です。
すっぽり抜けていたパーツを埋めるEBS
これも分かる人には当たり前なのですが、既に提供されてきたEC2とS3というのはそれぞれ、ざっくり書くと
です。
それぞれとてもパワフルで、EC2であれば、非常に協力なマシン（インスタンス）を借りられたり、必要な時間だけ起動できたり、（一部トラブルはあったものの）基本的には安定稼働します。
S3に関しても、お金さえ払えば、無限に近い量のデータをどかんと預けられるストレージサービスで、ストレージのスケーラビリティの悩みから解放してくれるサービスでした。
ところが、これら2つは疎にしか結合できないものでした。
というのは、
EC2から見た場合、S3のストレージがローカルディスクのように使うことはできない
ということが問題だったのです。（一時、S3のディスクをマウントするツールも出ていましたが、Amazonの推奨する方法じゃないことは明らかでした。）
ローカルディスクのように使えないと一番問題になるのが、データベースです。
データベースのデータを、EC2からローカルディスクとみなせる場所で、かつ、比較的安定したストレージに保存できない、というのが最大の問題でした。
データベースを使いたいサービスは、Amazon AWSでは事実上、作れなかったのです。
Simple DBがあるじゃないかという人もいるかもしれませんが、まぁ新しいSQL覚えるくらいなら、自分が良く慣れているDBで実装したいよね、と思うのが普通なわけです。
逆に今回のEBSの登場で、このパーツが埋まったわけで、通常のウェブサービスを使う上では、ほぼほぼ問題なくなったと言えると思います。
つまり、
- CPUやメモリが必要な処理はEC2で行い、
- データベースなど、EC2と密接に連携した処理に関係するデータはEBSに保存し、
- EC2とは疎でも良いが、大量のデータをS3に保存する
コストはどうか
というわけで、AWS上でサービスを作るということに関しての技術的な障壁はほぼゼロになりました。
次は、経済的な点からの考察。
まずは、AWSで一番小さいEC2のインスタンスを1ヶ月間動かし続けると、$72程度。その他、S3やEBSを使って、$100/月（約月間1万円）というのが最小構成と思って良いでしょう。
日本で専用サーバーを借りる場合と比べると、大体どこも月間1万円くらいは取られます。またAWSと比べて以下の点で、日本の専用サーバーレンタルが劣ります。
- サーバーのスペックがEC2の最小インスタンスよりも著しく低い（とくにメモりたくさん積めない）
- ディスクが壊れたり、サーバーごとぶっ飛んだ場合、データ等は保証してくれない。（サービスごとダウンします。）
というわけで、日本で専用サーバーを借りるくらいなら、AWSの方が遥かによさそうです。
これは、家庭のインターネット回線が非常に高速な日本だからできる技ですが、自宅サーバーという選択肢も捨てがたいです。
こちらの場合、HP ML115(送料込約2万円)を買って、メモリを4GBもしくは8GB(約2万円)にして、HDDを多少良いもの2本でRAID1(約2万円)として、1台6万円でそこそこのスペックのサーバーが作れます。
このサーバーを2年間使うとして、48ヶ月で定額法で償却すると考えると、月間1250円くらい。
電気代が大体、家庭用の30Aの場合で1台あたり3000円くらい。
ネットワーク代がマンションタイプの安いので、ミニマム4000円くらいかな。
ネットワークは通常のPC利用と共用にしたり、サーバー台数が増えてもある程度までは1本でいけるだろうというのもあるけど、まぁ1台だけ構築するとすれば、ざっくり8250円/月がコストです。
値段的には、自宅サーバーの方が安いことは確かです。僕も自宅にサーバーありますが、騒音、熱、故障との闘いはそれなりに辛いもので（サーバー運用したことある人なら分かりますよね）、1750円/月のコスト負担でこれらが解決されるなら、それなりに有力な選択肢になると思います。
（というわけで、僕も自宅サーバーを全部つぶして、AWSに乗り換えようか検討中。）
Amazonに改善してほしい点
というわけで、EBSの登場自体は非常に喜ばしいニュースでAmazon, Good Job!という感じなのですが、一つだけまだ大きな問題があります。
それは、日本からの回線スピードがまだまだ遅いです。
$ ec2-describe-availability-zones
AVAILABILITYZONE us-east-1a available
AVAILABILITYZONE us-east-1b available
AVAILABILITYZONE us-east-1c available
とこのようにサーバーが全部、アメリカ東海岸にあるようで、これじゃ日本からアクセスしたら遅いよねという話です。
日本向けにサービスを提供する場合、回線が遅いのはとても致命的です。
というのは、上述のように日本の場合、ユーザー側の回線が滅茶苦茶早いので、サーバー側が遅い（あるいはサーバーに到達するのに時間がかかる）というのはユーザーにとってもとてつもなくストレスに感じてしまうのです。
アメリカの場合、クライアント側が遅かったりするので、回線自体が遅いのか、サーバーが遅いのかが分かりにくいですが、日本だと遅いサイトは全てサーバー側に問題があると言って過言ではないでしょう。
というわけで、最後のお願い。日本からのアクセスを速くしてください。Googleはできてるんだから、Amazonにも出来るはずだ、と言ってみるテスト。
シンガポールにDC作るとかどうですか？もちろん日本でも良いですが。
