サーバーの引っ越しとパフォーマンス比較

最初に契約したレンタルサーバーにてエラーが頻発するという問題がありましたので、他のレンタルサーバーと新たに契約し、サイトの引っ越しをしました。本稿ではサーバーの引っ越し手順の概説と、パフォーマンスの比較結果を示します。

はじめに

「phptop_hook.phpでサイトのパフォーマンス測定」に示しましたように、当初契約したレンタルサーバー屋さんでは500エラーが頻発するという問題がありました。結局他のレンタルサーバー屋さんと新たに契約し、サイトの引っ越しを行いました。

本記事ではレンタルサーバーを批評する意図はありませんので、具体的なレンタルサーバー屋さんの名前は書きません。（他の記事では書いてしまいますが。。。）

パフォーマンスは、それぞれのサイトの環境（利用しているCMS、WordPressであればインストールしているプラグインやテーマとそれぞれのバージョン）、契約したプラン、実際にホスティングされたサーバー等で異なると思います。

またレンタルサーバーやプランの選択は、企図するサイトの目的と利用法、レンタルサーバーが提供するサービスとコストなど、さまざまな項目を検討すべきです。私の環境・企図が当初のレンタルサーバーとマッチしなかった、ということになります。

ですので、以下の記事は一事例として参照していただき、レンタルサーバーでサイトを運用している方々はご自身の環境・目的においてパフォーマンス測定をしていただければと思います。

順番は前後しますが、最初にパフォーマンスの測定結果を示し、次にWordPressで構築したサイトの引っ越し作業について概説したいと思います。

パフォーマンス測定

引っ越し先でのデータ収集

引っ越し先レンタルサーバーでも、提供されている管理ツールを使ってphp.iniにphptop_hook.phpを設定して、パフォーマンス測定をすることが出来ました。

このレンタルサーバーでは、WEBの管理ツールよりエラーログがダウンロードできます。しかしエラーログを毎日3時に消してしまい、一日丸ごとのエラーログは取得できません。cronで2:59にコピーすることも考えましたが、エラーログの実体がどこにあるかわりません。

この点をサポートに問い合わせた結果、「この度はご希望に添えず申し訳ございません。」とのことでした。orz

そこで一週間寝る前にログを手動で取得することにしたのですが、結局忘れずに取得できたのは5日分の3:00-約24:00のデータです。これを解析しました。

ログには「SystemException」というエラーもありましたが、同時刻に「Premature end of script headers:」も出力されていましたので同件と判断しました。また「Premature end of script headers:」の発生元はwp-cron.phpで、リクエストに起因したものはありませんでした。

結果

解析手法に関しては「phptop_hook.phpでサイトのパフォーマンス測定」をご覧ください。

また前述の通りに引っ越し元と引っ越し先でデータの収集期間が異なりますし、何よりアクセス内容が異なります。引っ越し元では管理ツールによくアクセスしていたのですが、引っ越し先では管理ツールにそれほどアクセスしていません。

データの平均値を比較すると以下の様になりました。

引っ越し先で時間が1秒を超えるのは腑に落ちません。

データを見てみると、20秒もかかっているwp-cron.phpの呼び出しが複数あります。wp-cron.phpのリクエスト元はサーバー自身で、WordPress内部からリクエストされています。

そこでサーバー自身のIPアドレスからのリクエストを削除して比較してみます。

それでも引っ越し先の時間が長いです。

元データーを見てみると、30秒程かかっているリクエストが1件、8秒程かかっているリクエストが2件ありました。いずれもPHP処理時間（user+sys）自体は0.4秒程なので、PHP以外のどこかで処理がブロックされているのでしょう。

0.2%（3÷1458）の割合で時間が長くなってしまうのはユーザーに迷惑をかけてしまいますが、エラーの発生はなくすことができました。

グラフによる分析

横軸にメモリ使用量をとり、時間を比較してみました。尚、自サーバーからのリクエストを除いたデーターです。

まずPHPが実行し終わるまでの時間を比較しました。引っ越し先の方が潤沢にメモリを割り当ててくれるようです。また2つの山を比べると引っ越し先の方が早いといえます。0.2%の長時間待ちにさえ引っかからなければですが。（長時間待ちの3点はグラフのはるか上にあり表示されていません。）

次にPHPのみの処理時間を比べてみます。これを見ると引っ越し先では0.4sec以内であり、明らかに早いです。

引っ越し先はFastCGI等でさらにPHPを高速化できるようですが、それ以外（データーベース？）でブロックされるようでしたらそれほど効果がないように思います。

引っ越し手順

引っ越し手順をさらりと解説します。

引っ越し先候補の選定

候補のスペック・サービスを比較します。またGoogle先生から、ブログ等のレピュテーション（評判）もお聞きました。ただし関係者によるサクラと思われる記事も多数あるので注意します。

実際に作成した比較表を以下に示します。

	A社 プランA	B社 プランA	C社 プランA／プランB
スペック
CPU	Westmere E56xx/L56xx/X56xx (Nehalem-C)	Xeon E5-2430L ( 2.00GHz )	XEON
メモリ	5GB	24GB	4GB
サーバー利用者数	75
バックボーン	国内最大級のバックボーン	高速232Gbps	各サーバー1Gbpsで 複数の大手ISPバックボーン(計500Gbps)へ
OS	FreeBSD 8.1-RELEASE-p13 amd64	Linux	Linux
コスト／サポート
初期費用	1,000円	3,150円	無料
月額費用	500円	1,050円	400円/500円
電話サポート	○	○	○
メールサポート	○	○	○
基本機能
ディスク容量	30GB（現在100GB）	200GB	30GB/60GB
MySQLのDB数	20個	30個	10個/無制限
マルチドメイン	20	無制限	50/無制限
RAID構成		RAID10
バックアップ	システム全体	毎日、7日間保持
SSH	○	○	○
Cron	○	○	○
WEB
Apache	2.2.25	2.2.x
共有SSL	○	○	○
独自SSL		○	400円/500円（月）
FTPアカウント	1	無制限	10/無制限
PHP	PHP4/PHP5	PHP4/PHP5	PHP4/PHP5
CGI高速化		FastCGI, APC/OPcache
メール
アカウント数	無制限	無制限	200/無制限
アンチウイルス	○	○
スパムフィルタ		○	○
メーリングリスト	10	転送で代用	○
その他		ユーザーによるサーバの移動が可能	プランAを年契約すると、年2500円

引っ越し作業計画

候補が決まったら、公開されている利用規約や設定マニュアルを読んで、問題が発生しないことなどを確認します。

そして以下の日付、期間を確認し、引っ越し作業計画を立てます。

• 現在のレンタルサーバーの契約解除通告期限
• 引っ越し先候補の無料お試し期間
• 引っ越し先候補の契約期間

仮契約

引っ越し先候補のレンタルサーバー屋さんと仮契約します。無料のお試し期間に留意し、その間に引っ越しとテストをします。

引っ越し作業１

作業としては以下を行いました。

基本設定

アカウントについての設定、ドメインの登録、PHPのバージョン設定を行いました。

引っ越し先のサーバーは、ドメイン名がドキュメントルートになる仕様でしたので、独自ドメインを登録しました。ただしこの時点ではネームサーバーの切り替えはしません。

PHPのバージョン設定に関して、引っ越し先はドキュメントルートの.htaccessに書き込まれる仕様でした。後の.htaccessの編集作業では、それを知らずに何回も上書きをしましたので、PHPのバージョンがデフォルトに戻ってしまいWordPressが動かなくなるということがありました。（サポートに問い合わせして解決しました。）

またお試し期間には共有SSLの利用とメールの利用ができませんので、これらの設定はできませんでした。

FTPによるファイルの転送

FTPツールを設定し、ミラーリングしているローカルのファイルを転送します。WordPressでは、インストールディレクトリ以下のファイルを全てPUTします。

MySQLのデータの転送

まず引っ越し先のMySQLにデータベースとユーザーアカウントを作成します。

両レンタルサーバーともphpMyAdminを提供していましたので、データの転送にはそれを利用しました。引っ越し元からsqlファイルでデータをエクスポートし、引っ越し先にそれをインポートします。

もし独自ドメインを取得しておらず、引っ越しによってURLのホスト名が変わってしまう場合はデータベース内に書かれたホスト名も書き換える必要があります。

phpMyAdminの操作手順やデータの書き換えについては、「WordPressテーマ開発（準備編）：サイトをローカルにミラーリングする」をご参照ください。

wp-config.php

wp-config.phpに書かれているMySQLへアクセスするための情報（データベース名、ユーザー名、パスワード、MySQL のホスト名）を修正します。

動作確認

以上にてサイトの動作確認をします。引っ越し先は「動作確認URL」という名前でレンタルサーバー屋のサブドメインを発行してくれる仕様になっていましたので、これを利用して確認しました。しかし共有SSLの動作確認はこの時点ではできません。

本契約

共有SSLの動作が確認できない不安はありましたが、動作確認して問題がなさそうでしたので、引っ越し先にお金を振り込んで本契約しました。

引っ越し作業2

本契約後に使えるようになった機能についての引っ越し作業をします。私の場合のほとんどは「共有SSLをWordPressのサイトで使う」で書きました、共有SSLにまつわる作業でした。

基本設定

共有SSLのURLの発行と、メールアドレスと登録をしました。共有SSLのURLはレンタルサーバー屋のサブドメインになります。

.htaccessの編集

共有SSLを利用するために、当サイトの.htaccessにはドメイン名を指定してのリダイレクトが多数書かれています。これらのURLを全て書き換えました。パスも異なりますので、これについても留意しました。（この作業でPHPのバージョンを戻してしまいました。）

wp-config.phpの編集

wp-config.phpにも共有SSLのURLを直書きしていましたので、これも修正しました。（引っ越し元の共有SSLを使うためのコードは最早必要ありませんが、悪さもしませんので書きっぱなしです。）

その他修正

Google Analyticsのクロス・ドメイン・トラッキングするためのコードに共有SSLのドメインを直書きしていましたので、これも修正しました。

また反省点ですが、引っ越し元の共有SSLのURLにアクセスがあった場合に引っ越し先の共有SSLのURLにリダイレクトするRewriteRuleを、この時点で引っ越し元の.htaccessに追加すべきでした。（引っ越し後、しばらくして気が付きました。）

ネームサーバーの切り替え

この時点でネームサーバーの切り替えをしました。当サイトの場合、ドメインのレジストラはレンタルサーバー屋とは別に契約しています。そのレジストラの設定ページにて、引っ越し先のネームサーバーを設定しました。

動作確認

ネームサーバーの切り替えには時間がかかります。nslookupでドメインのIPアドレスを確認し、切り替わったのを確認したら最終の動作確認をします。私の場合は翌朝には切り替わっていましたので、動作確認と修正を行いました。

メールの引っ越し

コミュニティの代表アドレスに来るメールは、他の運営メンバーも確認できるようにIMAPでサーバーに残るようにしてあります。これらのメールデータも引っ越し先に移動しました。

方法は単純です。今利用しているThunderbirdにて、引っ越し元の対象アカウントのメールを、全てローカルフォルダにドラッグ＆ドロップし、その後引っ越し先の対象アカウントのフォルダンにドラッグ＆ドロップしました。

ネームサーバーの情報が全世界に広がるまでは三日くらいかかるらしいので、その間は２つのアカウントのメールをチェックすることになります。

引っ越し元との契約解除

ネームサーバーが切り替わった後にしばらく様子を見て、問題がなさそうであれば引っ越し元との契約を解除します。

以上で引っ越し作業完了です。

まとめ

サーバーの引っ越し手順について概説しました。また引っ越し元と引っ越し先のパフォーマンスを比較しました。

引っ越し先はたまに処理に時間がかかってしまうものの、外部からのリクエストによるエラーは０で、目的は達成されたと言えます。