‘WebARENA’ タグのついている投稿
WebARENA CLOUD9を使ってみた感想
WebARENA CLOUD9を解約することが出来た。
トラブルなどもあったが、冷静に振り返って、使ってみた感想を書いてみようと思う。あくまで個人の感想なので、必ずしもそうでは無い場合もあるという前提で。
クラウドで立てたレンタルサーバ
オンラインサインアップでサーバはすぐ開通した。これはクラウドならではの部分だと思う。
ただ正直、それだけだった印象。そこから先はVPSと同じ使い勝手。
費用は月額で、スペックの変更は日割り料金となっている。時間単位の課金のAmazon EC2と比べて考えると、現時点ではずっと立ち上げて使う前提のサービスと言える。時間従量課金は2011年春頃の予定らしい。
デフォルトのスペック(メモリ1GB CPU1コア共有)は、WebARENA SuitePROよりも低く、確かに動作は遅いと感じた。スペックアップして体感速度を確認したかったけど、「ちょっと確認してみる」が現時点では難しいというのが切ない。ちょっと＝1日なのが現状。1時間なら費用は1/24で済む。
スペックアップも、デフォルトを含めて5段階で、もう少し細かくしてもらえないものかと感じた。2GB1コア共有にするとWebARENA SuitePROとスペックと金額がほぼ同じになるが、1コア共有でCPUスピードが変わらないのであれば、もしかしたらSuitePROの方が速いかも知れない。
また、WebARENA SuitePROは、サーバ稼働率100%保証なんだけど、CLOUD9はそうじゃないようだ。表記が見つけられない。
実際、契約期間中に障害も経験した。2月にも結構長い時間の障害が起きていた様子。
ということで、現状、root権限ありのサーバをレンタルしたいのであれば、WebARENA SuitePROを選択した方が無難だと考える。同時にWebARENA SuitePROも利用た上での感想としてそう思う。
もちろん、今後の開発計画が進んでいくことで、より便利に使えるようになるだろう。オートスケールアウトなどは、便利な機能だと思う。
もしかして急いでサービスインしたのでは
サービスインした、2010年10月の開発計画の段階で、1年先までの予定が用意されているというのは、もしかして、何かの理由で急いでサービスインしたのでは無いか？などと勘ぐってしまう部分もある。
やはり従量制や複数台構成の作業が出来てこそ、クラウドの威力を発揮する部分だと考えるのだが、そこのところ、間に合っていなかったのかなぁ…なんて思ってしまう。
サービスインから半年近く経過しているが、2011年秋以降の開発計画が追加されないのも、スタート当初に機能が間に合わないから、先の予定をひとまず書いたのでは…なんて、自分でもやったことあるような無いような事を思ってしまった。
Amazon EC2が日本国内にデータセンタを設置し、ニフティクラウドといった国内での競合も現れてきている。これからも安定したサービスと、機能の開発に頑張っていただきたいと思う。
短い間でしたけど、勉強になりました。ありがとうございました。
WebARENA CLOUD9、解約しようとしたら、3ヶ月無料キャンペーンは、1年契約になるので3ヶ月経過後すぐには解約出来なかった。がーん。
仕方が無いので、あんまり落ちてくれるなよと祈りつつ色々実験機として使うことにした。
クラウドストレージの登場で、外部バックアップがしやすくなった
バックアップデータは曜日単位でバックアップを取るなどすると掛け算で容量が増えるのでストレージを結構圧迫する。また、同一ストレージ上にあるよりは、別ストレージに逃がした方が当然良い。
Dropboxなどクラウドストレージは、上記要件の解として有効なもののひとつだと思う。問題点は、ストレージの速度とセキュリティの問題か。プライベートクラウドなど、今後はより安全で安定なサービスも増えると思うが、今回はwordpressの記事データをバックアップするという単純な用途なので、あまり難しく考えずDropboxにmysqlのダンプを退避してみる。
参考サイト
http://wiki.dropbox.com/TipsAndTricks/TextBasedLinuxInstallを参考にした。
日本語で個人の方が書いている方法もあったが、その当時よりも対応が進んでいて、より簡単に出来た。この記事だって数ヶ月もしたら、もっと簡単な方法に置き換わると思われる。
Pythonのインストール
CentOSにデフォルトでインストールされているPythonは、2.4.3。DropboxのCLIは2.5以上を要求しているので、現時点で2.X系で最新の2.7.1をインストールした。
その際、すでにインストールされているPythonとぶつからないようにした。
#wget http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tgz #tar -zxvf Python-2.7.1.tgz #cd Python-2.7.1 #./configure --prefix=/usr/local/bin/Python-2.7.1 #make #make install #ln -s /usr/local/bin/Python-2.7.1/bin/python /usr/bin/python2.7.1 #python2.7.1 -V Python 2.7.1
Dropboxのインストール
dropbox.pyからDropbox本体をインストール出来るので、dropbox.pyを先にダウンロードする。
#wget -O dropbox.py "http://www.dropbox.com/download?dl=packages/dropbox.py" #python2.7.1 ./dropbox.py start -i Starting Dropbox... Dropbox is the easiest way to share and store your files online. Want to learn more? Head to http://www.dropbox.com/ In order to use Dropbox, you must download the proprietary daemon. [y/n] y Downloading Dropbox... 100% Unpacking Dropbox... 100% Done! #python2.7.1 ./dropbox.py start To link this computer to a dropbox account, visit the following url: https://www.dropbox.com/cli_link?host_id=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
表示されたURLにブラウザからアクセスし、すでに持っているアカウントでログインすると同期完了。ホームディレクトリ上にDropboxディレクトリが作成され、同期が開始される。これで設定は終わり。Dropboxは動いている。
シェルでmysqldumpを実行して、Dropboxで同期する
Dropboxを常時デーモンとして動かしても良いのだけど、見たところ200MBくらいメモリを使う。CLOUD9の基本プランではメモリは1GBなので、出来るだけメモリは節約したい。バックアップ目的なので、バックアップ処理時だけDropboxを起動して、処理終了時にはDropboxも終了するようにする。
以下のようなシェルスクリプトで定期実行する。
#!/bin/bash prog="python2.7.1 Dropboxをインストールしたディレクトリ/dropbox.py" mysqldump --user=root --all-databases --password=パスワード > ホームディレクトリ/Dropbox/mysqldump/dump tar czvf ホームディレクトリ/Dropbox/mysqldump/dump`date '+%w'`.tgz ホームディレクトリ/Dropbox/mysqldump/dump rm -rf ホームディレクトリ/Dropbox/mysqldump/dump $prog start status=`$prog status` while [ "$status" != "Idle" ] do status=`$prog status` echo $status sleep 3 ← Dropboxの状態を次に確認するまでの秒数 done $prog stop
mysqldumpのパラメータは、使うデータベースを限定したり、状況に合わせて変更する。稼働中、Dropboxのステータスを表示するようにしたので、どのくらいの時間で同期できたかもざっくりわかる仕組み。
データセンターからのアップなので結構なスピードが出るのかと思ったら100KB/sec以下になることも多い。これはこちらの回線というよりもDropbox側の問題だと思われる。
と、ここでCLOUD9は回線速度のことを書いていないことに気づいた。SuitePROは1Gbpsと書いている。なんというか、全体にこんな印象なんだよね、CLOUD9。説明があるようで無いようである。探せばどこかに書いてあるのだろう。
WebARENA CLOUD9にLighttpd+PHPをインストール その2
WebARENA CLOUD9にLighttpd+PHPをインストール その1の続き。
FastCGIのインストール
Lighttpdは、PHPを外部のCGIとして実行する。それにFastCGIを使用する。
ソースを、http://www.fastcgi.com/dist/からダウンロードする。インストールした時点での最新版は、2.4.0。
サーバ上で以下の手順を実施。
#tar -zxvf fcgi-2.4.0.tar.gz #cd fcgi-2.4.0 #./configure #make #make install
FastCGIはこれで終わり。
PHPのインストール
せっかくなのでPHPも最新版をソースからインストールした。
CentOSでのインストールなのでhttp://redmine.lighttpd.net/wiki/lighttpd/TutorialLighttpdAndPHP#Othersを参照する。
ソースを、http://www.php.net/downloads.phpからダウンロードする。インストールした時点での最新版は、5.3.5。
サーバ上で以下の手順を実施。
#tar -zxvf php-5.3.5.tar.gz #cd php-5.3.5 #./configure \ --enable-mbstring \ --with-pear #make #make install
configureのパラメータが異なっているが、PHP5.3以降では、cgi-phpがデフォルトで作成される。–disable-cgiオプションでFastCGIを有効にする設定となる。
訂正:どうも–disable-cgiがあると、php-cgiが作成されない模様。ちょっと混乱しているので後で調べて書き直す
それ以前のPHPの場合には、http://redmine.lighttpd.net/wiki/lighttpd/TutorialLighttpdAndPHP#Othersの例に沿う。
参考:http://www.php.net/manual/ja/install.unix.lighttpd-14.php
Lighttpdの設定
PHP関連の設定は、http://redmine.lighttpd.net/wiki/lighttpd/TutorialLighttpdAndPHP#Configurationを参照する。
#vi /etc/lighttpd/conf.d/fastcgi.conf
fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket"
)))
#vi /etc/lighttpd/modules.conf
include "conf.d/fastcgi.conf" ← #でコメントアウトされているので、コメントアウトをはずす。
ここまでの設定で、ひとまずPHPも動作する、はず。
#service lighttpd restart
軽いように感じる
試しにwordpressをインストールしてみたが、apacheで動作させた時よりもプロセスとメモリの使用に関して軽く動作するようだ。apacheの時はアクセスが増えると、子プロセスが増え、メモリも使用するようになっていたが、Lighttpdでは、あまりメモリの使用量は増えない。FastCGIがLighttpdに変わって処理を捌く構成がapacheのそれよりも効率が良いようだ。
WebARENA CLOUD9にLighttpd+PHPをインストール その1
AmazonのASINを入力すると商品画像などを表示するサンプルは、WebARENA CLOUD9にLighttpd+PHPをインストールしてみる実験も兼ねていたので、インストール時のメモを。
参考サイト
Lighttpdのサイトを主に参考にした。ドキュメントは英文だけど、そんなにややこしくないので大丈夫。
Lighttpd – WikiStart – lighty labs
http://redmine.lighttpd.net/wiki/lighttpd
Lighttpdのインストール
ソースを、http://www.lighttpd.net/download/からダウンロードする。インストールした時点での最新版は、1.4.28。
サーバ上で以下の手順を実施。
#tar -zxvf lighttpd-1.4.28.tar.gz #cd lighttpd-1.4.28 #./configure \ --without-zlib \ --without-bzip2 \ --disable-ipv6 #make #make install
インストール後の設定は、http://redmine.lighttpd.net/wiki/lighttpd/InstallFromSource#Init-scriptの項目に沿って実施する。
サーバがCentOSなので
#sed -e 's/FOO/lighttpd/g' doc/initscripts/rc.lighttpd.redhat > /etc/init.d/lighttpd #chmod a+rx /etc/init.d/lighttpd #cp -p doc/initscripts/sysconfig.lighttpd /etc/sysconfig/lighttpd #mkdir -p /etc/lighttpd #cp -R doc/config/conf.d/ doc/config/*.conf doc/config/vhosts.d/ /etc/lighttpd/ #chkconfig lighttpd on
起動スクリプト中のサーバのパスが /usr/sbin/lighttpd で、実際のインストールパスが /usr/local/sbin/lighttpd なので、シンボリックリンクを作成。
#ln -s /usr/local/sbin/lighttpd /usr/sbin/lighttpd
Lighttpdの設定
後でFastCGIやPHPはインストールするとして、Lighttpdがうまく動くかを確認。色々な仕組みを一緒に使う時は、ひとつひとつ動くことを確認しながら進めると意外とはまらない。設定については、http://redmine.lighttpd.net/wiki/lighttpd/TutorialConfigurationで大まかな設定例があり、それに沿えば良い。
#vi /etc/lighttpd/lighttpd.conf var.log_root = "/var/log/httpd" ←apacheと同じ場所に設定 server.port = 80 ←サーバのポート。apacheがポート80でまだ動いているような場合は別のポートにする必要がある server.username = "nobody" ←デフォルトで lighttp になっているが、ユーザもグループも作っていないので nobody にした server.groupname = "nobody" server.document-root = "/var/www/public_html" ←デフォルトのドキュメントルートを設定
実行ユーザをnobodyにしたので、ログディレクトリ /var/log/httpd がnobodyでアクセス出来るよう設定する。
#chown nobody:nobody /var/log/httpd
ここまでの設定でひとまずLighttpdは動く、はず。
#service lighttpd start
apacheのようにデフォルトページが用意されていないので、最初は何も表示されない。自前でindex.htmlを作ってドキュメントルートにアップして確認する。
WebARENA CLOUD9にLighttpd+PHPをインストール その2へ続く。
WebARENA CLOUD9障害中
先日からちょこちょこサーバを移行している、WebARENA CLOUD9が現在も障害中でつながらない。
[復旧中]12/4 障害発生のお知らせ
http://web.arena.ne.jp/cgi-bin/cloud9/news.cgi?target=20101204100800
来週やるイベントで配布するフリーペーパーのDTP作業立会いで徹夜して、ひとまず寝ようと帰った矢先、監視サービスで障害発生のメールが来ていた。それが朝、8時半前のこと。
うわっ、と思ってSSHでの接続を試すも駄目で、リソース食いつぶしが起きたかと思いコントロールパネルにアクセスしてみたら、コントロールパネルも重くてなかなか開かない。何とか開いてサーバ再起動を指示したら、再起動処理中のまま、何分待っても変わらない。コントロールパネル自体につながらなくなったりもする。
障害情報もあがっていないので自分のところだけなのかも知れないし、何かしくじったのかと思い、サポートから問い合わせを実施したのが9時過ぎ。それの返事が来たのが13時45分。
その間に、開かないとまずいサイトは並行運用しているWebARENA SuitePRO V2へ移動。最近の更新情報で手元に無いものは、Googleなどの検索エンジンのキャッシュから何とか引っ張り出して復旧。ちなみに、このブログもmysqlサーバを移動した。
作業は11時過ぎに完了。問い合わせから約2時間、その間に返答はなく、障害情報もあがっていなかった。
1時間ほど仮眠して、ランチをしに出かけた時、もしくはランチから戻ってきた14時過ぎのどちらかのタイミングで障害情報があがっていたのを覚えている。(なにせ徹夜でボーっとしてたもので…)
滅多に起きることでは無いのと、眠さと疲れのピークだったので結構ショックだった。WebARENA SuitePRO V2では、そういうトラブルに一度もあっていないので、余計にそう感じた。
問い合わせのレスポンスの速さ、障害情報の速さ、対応の速さ、どれを見てもお客様のサイトどころかテストサーバでも使えないかも知れないなぁと思った。切ない。
個人的にサーバ選定時の第一条件は、問い合わせ対応だと思っている。
普段安定運用できているのは当然の前提で、何か起きた場合、とにかく迅速な対応、仮に障害が複雑で時間がかかるとしても、それならそういうアナウンスを実施できるかは、とても大きな決め手になると思っている。
フューチャースピリッツは、10年以上の付き合いで、トラブルに遭った事は無いが、問い合わせの対応がとにかくしっかりしているという感触を持っており、すごく信頼を置いている。フューチャースピリッツでVPSやクラウドの安価なサービスを始めないかなぁ…なんて勝手なことを思いつつ、状況を見守りたい。
復旧しても特別なにがあるわけじゃない状況までサーバ構成を戻したので、復旧は時間がかかっても構わないのだけれど、はやくサーバ上のデータを消して解約したい。
追記
16時の段階では、まだsshやhttpでの接続は確認できず、コントロールパネルも再起動処理中のままだった。
18時45分、復旧とのことで、そのタイミングで、コントロールパネル含めて問題なく接続できた。データ損失など無く復旧した模様。
追記2
16時段階での復旧に関する案内について問い合わせをしたら、12/6 12:26にお返事いただいた。
問い合わせが立て込んで大変だったのだろうけれど、これじゃあやっぱり厳しいなぁ。
フューチャースピリッツ 共用レンタルサーバにデータベースを標準提供でも書いたように、www.mybenjo.net で運用しているwordpressは、mysqlのサーバを別サーバで運用している。現状は、WebARENA SuitePRO V2なのだが、WebARENA CLOUD9へ移行したのでメモ。
そもそもwordpressでmysqlを別サーバで運用するのは、いわゆるレンタルサーバを利用する層では一般的で無く、そういったケースは少ないのだろうけれど、よかったら参考にしてください。
ただし、以下は少しだけテクニカルな内容を一般論的に記述しているので、実施する場合、詳細は各自で検討するか、もしくはお仕事として依頼していただければと思います。
- WebARENA SuitePRO V2サーバで mysqldump を使ってwordpress用データベースのデータをエクスポート。
その際、 –default-character-set=binar の指定で生データとして出力する。
- WebARENA CLOUD9サーバで、wordpress用データベースとアカウントを作成。
その際、webサーバのIPからのみアクセスできるよう設定する。権限などに注意。
- WebARENA CLOUD9サーバのデータベースに、 mysql を使ってエクスポートしたデータファイルをインポート。
その際、 –default-character-set=utf8 を指定してUTF-8のデータとして取り込むようにする。
- WebARENA CLOUD9サーバが、外部IPからmysql接続できるよう、ポートマップの設定を実施する。
- webサーバからWebARENA CLOUD9サーバへ、mysql接続できるよう、ポートなどの設定を実施する。
- wordpressの設定ファイル、wp-config.phpのDB_HOSTをWebARENA CLOUD9サーバのIPに変更する。
WebARENA SuitePRO V2は、mysql4.1.22、WebARENA CLOUD9は、5.0.77とバージョンが異なるが、上記の流れで問題なく移行は完了した。WebARENA CLOUD9の方がメモリが少なく、それ以外でもスペックが異なるので、これから様子を見つつ、チューニング出来るところはいじっていく必要があるかも知れない。