さる学会の方から、できるだけ安いサーバでWebとメーリングリストを運用したいとの要望を受けたのでAmazon EC2などはどうだろうと思いさわってみることにした。
このアマゾンのクラウドサービスは、一読しても理解しにくいテクニカルタームが頻出する。サービスの名前さえもEC2とかS3とかEBSとか、いったい何のサービスか名前だけでは想像がつかず、使ってみるまでは良くわからない。使ってみて初めて納得するが、そのために余計な経費を掛けてしまうことになる。それもアマゾンの意図なのだろうか？
それはさておき、EC2は、比較的最近、西海岸にサーバが立ち上がったようなので少しお値段は張るがそちらを選んでみる。なにせバージニアのサーバは遅いので。
結果はなかなか快適である。ただ、利用できるOSのイメージ数は東海岸に比べると圧倒的に少ない。OpenSolarisも使ってみたかったが、西海岸にはないので今回は見送ることにした。
いくつか気がついたことを記録しておこう。
EC2のインスタンス・ストアで立ち上げたサーバのイメージはS3に保管しておかないと消えてしまうので面倒ながら定期的に保存する必要がある（これは最近できたEBSからのブート機能を使い、スナップショットをとるようにすればだいぶ楽にはなる*1）。ところがこの時、うっかりS3の保管場所の指定をしないで保存すると、私の使っている西海岸のS3にではなく、東海岸のS3に保存されてしまう。保存されるのは結構だが、そのイメージを立ち上げようとすると、カーネルIDが違うと言われて起動しない。EC2とS3は同じ保管場所場所にないと動かないことになっている。
最初に私は、この問題に気づかず、もういいやと思ってインスタンスを落としてしまった。そこにイメージがあるのに、もう起動することもできない。だからといって作り直すのも業腹だと思い、しばらく考えて、一度ローカルに落として、ローカルのAMIツールで西海岸にあげなおした。
またデフォルトのイメージはFedoraだが、このFedoraの中でCentOSなら割と簡単にイメージを作ることができる。アマゾンのマニュアルにも掲載されている。
しかし、作られたイメージは、EC2のインスタンスでは、そのイメージの中にあるカーネルが動くわけではなく、Xenのカーネルで動くので、そのままでは、モジュールが何もない状況になってしまう。そこでアマゾンから対応する専用のモジュールをダウンロードして、トップディレクトリで解凍してdepmod -aを実行するか再起動する。デベロッパーのサイトで議論されていた。でも、この部分がマニュアルに書かれていないのはなぜだろう。
そんなこんなで少し苦労したがサーバは立ち上がった。そこで学会の方にお見せしたら「うちの学会のお偉いさんに、アマゾンを毛嫌いしている方がいる。」と言われてしまい没になった。まあ、ちょっと遊んだので損した気にはならないが、いろんな人がいるものである。
因みにFreeBSDはXenのEC2のバージョンが古いために利用できないようである。いささか残念というか不便ではある。
*1:EBSからブートさせるためには、少し前までは、pythonのbotoライブラリを使わないといけなかった（しかもバグがあった）ようだが、最近のec2-api-toolsを使えば比較的簡単である。EBSにOSをインストールしてsnapshotを作成し、それをec2-registerコマンドで登録すればよい。そのうちコントロールパネルでもさらに簡単にできるようになるのだろう。
しかしEBSにしたところで、実行するインスタンスはその実行の都度作成されるテンポラリーなEBSなので、結局インスタンスを終了するときには、終了前にコントロールパネルからEBSのイメージ作成を選択して別のイメージを作成する必要がある。本来EBSブートに期待されている面倒さの低減と言うことからすれば今ひとつではある。しかも、イメージ作成にもそれなりの時間がかかる。ただ、その間サイトをオフラインにして完全な形でイメージを作成しようとするところなどは、私はそれなりに感心した。
