‘レンタルサーバ’ タグのついている投稿


2013年はWEBサイトそのものの面倒を見る機会が何度かあり、その中でサイトにつながりにくくなるという現象に遭遇した。
出来るだけそうならないよう心がけてはいるものの、そうなってしまったのは自分に原因が無くても申し訳ない気持ちになる。

ネットなどでつながらない報告がある時
「光の100メガプランだけどダメ」
といった書き込みを見かけたりする。それでもダメな時は100%無理だったりするけれど、多くの人はそこまでは知らないよねぇ、と思うことがあるので大まかに原因をまとめてみた。

サーバ負荷が高い

重いスクリプトを実行してサーバそのものが重くなっている場合。

例えばスクリプトの中で無限ループが起きればいつまでたってもレスポンスが返ってこないし、そこまで単純なことで無くてもデータベースへの問い合わせが遅いとか、ロジックが複雑で時間がかかるとか、インターネットで無くても手元のPCでだってよく起きている現象。
WEBサーバの場合はそれが複数同時に起きているので負荷が上がり出すと他の処理も巻き込まれてどんどん重くなってしまうケースが多い。

思い切ってapacheを再起動すると瞬間的に軽くなるが、また同じパターンで重くなることが殆どなので、それで嵐が過ぎるのを待つといった消極的な対応をすることもある。

解決策としてはスクリプトの軽量化や負荷が高くなるボトルネックの対応、サーバを増やしてロードバランシングするなど、色々な手法があり、システム屋として一番頑張れるところではある。
ただし実際起きてしまうと即対応がなかなか出来ないという針のむしろを味わうことになる。

負荷試験を行うという場合は大抵はこの負荷を測って改善する作業を想定する。

サーバのネットワーク負荷が高い

インターネットからサーバまでの回線速度はサーバによって様々で、たとえば「さくらのVPS」では、共有100Mbpsで接続されている。ざっくりな理屈の上では「光の100メガ」の人が一人サーバにガッツリ接続して通信してれば他からの通信は割り込めない状態になる。そうなれば他の人達がいくら速い回線でも繋がらない。

現実にはそこまでネットワークが専有される状況というのは滅多に無いのかもしれないけれど、スペックそのものが良くなっていくにつれて通信出来る量も増えていっているので、昔からの感覚があるのであれば、きっとそれよりは起きやすい。

もっとも簡単に起きるケースに巨大ファイルのダウンロード公開がある。
100Mbpsの回線で50MBのファイルを公開して3人が同時にダウンロードしはじめたら…ということを想像すると分かりやすい。単純計算で考えればもう一杯だ。

ちなみにネットワークが原因でつながらない場合はサーバ負荷は比例して高くなるということは無い。50MBファイルのダウンロードであれば頑張っているのはapacheのプロセス3つだけでしかないし、やっているのはバイナリのレスポンスなだけだ。

CDNといったコンテンツの分散がもっとも簡単な対策だけど、利用するにはお金がかかるわけで、その費用が必要であることを説明して理解してもらうには、現状ではまだそれなりの努力が必要だと思われる。

サーバのネットワークまで届いていない

DNSが参照できなかったりでサーバの名前解決ができない場合や、モバイル環境などで通信トラフィックが混んでいてそもそもインターネットまでちゃんと繋がっていない場合。サーバ側には来てないので状況が全然分からないので解決がなかなか難しい。

「光の100メガ」といった、クライアント側の回線の話ではあるのだけど、それぞれのクライアントで状況が違うので、実はもっとも厄介ではある。ただし、そういった報告やクレームが正式にくることは稀で、コミュニケーション出来る相手であればtracerouteしてもらうなんて手段で個別に解決は出来る。


無料枠でテスト的に使うとして

AWSは、業務で使うことはあるけれど、テスト的に導入するといった場合にどれだけ気軽に出来るのか?ということは考えたことはなかった。制限があるし、その制限が無いことがAWSを使う利点でもあるという意識があったからだ。
とはいえそこで否定するのもアレなので、もし無料利用する場合にはどんな条件なのかをメモしてみた。

参照元は クラウドサービス 無料利用枠のご案内 | アマゾン ウェブ サービス(AWS 日本語) で、2013年11月17日現在の情報なので、あくまで参考までに。

前提として利用期間は12ヶ月間でさらに月内の利用時間に上限がある

AWS新規申込みのユーザーに対してのサービスで12ヶ月間の提供となっている。1年無料ということ。
さらに以下の制限がある。

月750時間というのは、24時間×30=720時間なのでEC2を1台起動しっぱなしで問題ないと判断出来る。複数台の場合は起動しっぱしは出来ない。AWSの柔軟な部分は切り捨てて1台のレンタルサーバと考えれば問題ないとは言える。

データ転送が15GB/月なので、大きめのファイルやトラフィックの多い場合には注意が必要だ。ソフトバンクのテザリングが7GB/月を超えると速度低下が発生するということなので、15GB/月というのもそこまで余裕のある数字では無いのかもしれないが、そもそも論でそんなにスペックの高いサービスでは無いことを考えると、高トラフィックでデータ転送量が跳ね上がる恐れはそこまで無いかも知れない。そんなに心配ならばチェックしよう、ということだとは思う。

1台のレンタルサーバとしてのスペック

EC2で使えるインスタンスはマイクロインスタンス。マイクロインスタンスのスペックはインスタンスタイプを参照すると以下のようになっている。

AWSの考え方前提なので他のレンタルサーバと比較するのは簡単では無いけれど、乱暴にまとめると

というVPSサーバ1台に相当する。さくらのVPSの1Gよりも低いスペックだと判断しても良いと思われる。

経験上、メモリが1GB無いとapache+phpだけでも物理メモリを圧迫する。mysqlをRDSに外出しするにしてもリソースギリギリの構成だと想像できる。
980円/月のプランより低い、期間限定の無料プランだと考えれば仕方の無い内容だとは思うけれど、そこまでしてAWSを使う理由は感触を確かめたりオペレーションの学習といった理由以外ではあまり利点は無いのではと考える。

セットアップの手間などはどこまで一般的に想定されているのか分からないのですが

これは他のVPSやクラウドでも言えることだけれど、セットアップは自前で行う必要がある。
この部分、自分では感覚がズレていることだけは分かっているのだけど 通常サーバを借りる=必要なシステムは用意出来ている という感覚であるならばAWSではもう一手間、しかも今まで知らなかったような作業が発生することになる。
今はネットで検索すれば、セットアップ方法もそれなりにあるだろうし、それの練習だと思えば問題ないけれど、無料のレンタルサーバのサービスだと考えてしまうとハマってしまうのでは無いかと思われる。


震災直後からネットは、お遊びなだけではない現実に即した情報やサービスが配信される傾向になったと思う。もちろんそこには誤りなんかもあるけれど、使われ方がより社会に密接に結びつくことが増えたと思う。

「思う」だけでなく、何かしらの数値なり例題なりを出して説明することで、より説得力のある文章になるのだろうけれど、あくまで肌感覚のメモということで以下も個人の感想と体験をベースにして書いていく。

震災によって情報発信ができない状況が発生

3月11日の夜には、自治体のサイトが落ちてしまうケースが発生していた。これは、アクセス過多によるもの、被災や停電によるもの、など色々なケースがあった。結果震災後、自治体からの情報をTwitterで配信するケースが増えた。

という利点がある。

自治体では、各部署がそれぞれに独自資料を公開したいという要望から、庁舎内のネットワーク上にWEBサーバを配置して公開する形式の所もある。情報を統括して公開する専門部署を作るよりも、導入はシンプルだ。
ただ、そうなると庁舎内に公開用のサーバルームを用意することになる。停電だけならUPSや自家発電で何とかなるとしても、それ以上の被害が出てしまった場合はアウトだ。回線が止まるということだってあり得る。

また、原発のトラブルや、計画停電の情報配信についてもアクセス過多で電力会社のサイトにつながらないという事象が発生した。単純なPDFの資料で、サーバ側でスクリプトやDBが動くという類のもので無いとしても、まったくつながらないタイミングがあった。

実数として、どのくらいのアクセスが集中していたのか、参考値としてかなり貴重なものとなると思うので、今後どこかのタイミングで公表してもらいたいものだと思う。
視聴率が1%でどのくらいの人間が見ているかという大雑把な計算をすることがある。電波は何人見ても落ちることは無いけれど、ネット上ではこういう構成で人口の何%がアクセスすると情報が行き渡らなくなるか?という情報は認識として共有したい。

落ちないサービスに情報を集める傾向

自治体の情報発信にTwitterが使われだしたという傾向は

という理由から、緊急避難的なケースも含めて選択されたものと考える。
同じ理由から情報収集をしにTwitterにアクセスしたユーザーも多く、結果的により多くのユーザーに情報を配信出来たのではないだろうか。

計画停電の情報についても、そもそも情報がPDFだったので、大手ブログサービスや、Googleドキュメントなどにダウンロードできたファイルを再度アップロードすることで情報の拡散が出来た。ただし、これは訂正情報が入った場合の対応に問題があり、計画停電発表直後は

という具合に情報が錯綜してしまった。
その後、電力会社もCDNなどの導入を実施したのか、改善されているようだ。実際のアクセス状況と共に、改善実績も公表してもらえるとありがたいと思う。

落ちないサービスから落ちるサイトへのリンク

比較的安定しているという前提のTwitterであるが、Twitter内の情報だけであれば問題はないのだが、ツイート内に高負荷に耐えないサイトへのリンクがあると大変だ。フォロワーが多いアカウントにツイートされたり、リツイートされまくったりすると一気にアクセスが増える。
自治体や電力会社のサイトも、それによって高負荷になったという場面があったと思う。
リンク先が、大手ブログやWEBサービスの場合には問題無いのだけど、そればっかりでは無いわけで、これは当面の大きな課題ではあると思う。

こういった検討は、これから頻繁にされていくのでは無いだろうか。
システム屋としては開発工数が発生した方が仕事としてはありがたいのだけど、とはいえ高負荷対応まで考えるとなると色々と手がかかり、コストも増える。お客さんもそこまでは考えていなかったり、費用を出せなかったりするだろう。
かといって、大手サービスを利用する前提で、そのメニュー内でやることを収めるよう進めると、殆ど作業が発生せず、コンサル料的なものがいただければ…といった仕事になってしまう。

保守的に仕事をやっていこうとは思わないけれど、なかなか難しいタイミングに来ているのかも知れない。

さらに落ちないサービスが落ちるケースが

Twitterなどが落ちないサービスであるという前提も、AWSが停止するといった事例がタイムリーにおきたことで悩ましい状況になっている。

何が安定か?という部分、落ちるまでは安定という禅問答のような話になってしまうと意味があまり無いのかも知れないが

といった部分を事前に明確にした上で、インフラやサーバや運用を検討するという作業を明確にしていく必要があるのだと考える。


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が日本国内にデータセンタを設置し、ニフティクラウドといった国内での競合も現れてきている。これからも安定したサービスと、機能の開発に頑張っていただきたいと思う。

短い間でしたけど、勉強になりました。ありがとうございました。


さくらのVPSに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

ここで、configure: error: xml2-config not found. Please check your libxml2 installation. のエラーが出たので、libxml2,libxml2-develをインストールして再度実行。

#tar -zxvf php-5.3.5.tar.gz
#yum install libxml2
#yum install libxml2-devel
#./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/local/bin/php-cgi",
                     "socket" => "/tmp/php.socket"
                 )))

#vi /etc/lighttpd/modules.conf
include "conf.d/fastcgi.conf" ← #でコメントアウトされているので、コメントアウトをはずす。

ここまでの設定で、ひとまずPHPも動作する、はず。

#service lighttpd restart

今度は、さくらのVPSにLighttpd+PHPをインストールしてみたので、インストール時のメモ。OSは、前回と同じくCentOS5なので、基本的には、WebARENA CLOUD9にLighttpd+PHPをインストール その1の時と同じ。前回は、すでにApache+PHP環境だったのをyum removeしてからのインストールだったのが、今回は、さくらのVPSをセットアップした直後の作業だったので、今回の方が例外が少ないと思う。

参考サイト

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

ここで、configure: error: pcre-config not found, install the pcre-devel package or build with –without-pcre のエラーが出たので、pcre-develをインストールして再度実行。

#yum install pcre-devel
#./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を作ってドキュメントルートにアップして確認する。

 
さくらのVPSに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のそれよりも効率が良いようだ。


AmazonのASINを入力すると商品画像などを表示するサンプルは、WebARENA CLOUD9にLighttpd+PHPをインストールしてみる実験も兼ねていたので、インストール時のメモを。

参考サイト

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へ続く。


mybenjo.netのサーバを、フューチャースピリッツFutureWeb2にプラン変更した。
それまでのプランではmysqlが持てず、仕方なしでデータは別サーバでの運用だったり、そもそも費用が今より安くなったりしていたので、年間契約更新のタイミングで乗り換えた。
フューチャースピリッツは、サポートがしっかりしていて、簡単なことなのだが、日本語を理解してくれる。そしてちょっとだけ気が利いている。特別、上客向けに何でもしてくれる感じとまではいかないけれど、スムーズに事が運ぶ感じが体験できるという意味で満足度が高い。

今回

私:更新の連絡のタイミングでプラン変更する上で、その際の懸念事項を質問
       ↓
F社:懸念事項を回答
       ↓
私:それをうけてプラン変更を申し出る
       ↓
F社:プラン変更の段取りを連絡。現プランの解約願いのPDFを添付
       ↓
私:現プラン解約と新プラン申請のスケジュールを連絡
       ↓
F社:よろしくおねがいします
       ↓
私/F社:それにそって対応

といった風な段取りにそって粛々と進んだ。やりとりはメールとFAXのみで、レスポンスの遅延も殆どなし。トラブルもなし。

旧プランと新プランでDNSサーバが異なるので、hosts変更で新サーバの設定を行った上で、ドメイン情報のDNSを切り替え、同時にフューチャースピリッツ側でメールのルーティング情報を変更して作業終了した。

DNS変更時には小さいゴタゴタがあるなんて話は経験したり、聞いたりすることは多いのだけど、フューチャースピリッツではそういった事が無く、とても助かっている。

WebARENA CLOUD9障害中

2010年12月4日

先日からちょこちょこサーバを移行している、WebARENA CLOUD9が現在も障害中でつながらない。

来週やるイベントで配布するフリーペーパーの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にお返事いただいた。
問い合わせが立て込んで大変だったのだろうけれど、これじゃあやっぱり厳しいなぁ。