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


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が停止するといった事例がタイムリーにおきたことで悩ましい状況になっている。

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

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


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