Webサイトのお助け隊

借りているサーバーのプランが変わる、PHPのバージョンが引き上げられる、データが上限に近づく。きっかけはそのつど違っても、行き着く先は同じです。期限までに別のサーバーへ移すしかありません。Zenlogicで動いているサイトの移行も、たいていはこの形で相談が来ます。ファイルとデータベースを運ぶだけなら難しくないはずなのに、実際にはWAFとアップロード制限、それにPHPのメモリ設定で足止めされます。ここでは実際に移した案件について、どの順番で何につまずいたのかを、作業記録のまま書きます。

移すしかなくなる、二つの入口

移行の相談は、大きく二つの形で来ます。一つは、使っているプランの仕様が変わるパターン。PHP7.3で動いていた環境に対して、PHP8.1へ引き上げるという告知が出る、といったものです。もう一つは、サイトが大きくなりすぎて、いまのプランの制限の中では作業そのものが回らなくなるパターンです。

前者で厄介なのは、サイト側がその新しいPHPで動くとは限らないところです。EC-CUBEで構築された物販サイトの相談では、本体が4.0.2でした。EC-CUBEはPHP7.4に対応するのに4.1.0以上、PHP8.1に対応するのに4.2系が必要で、しかも4.1系と4.2系の間に互換性がありません。つまり「PHPを上げたい」という依頼が、実質的には「ECサイトを二段階作り直したい」という依頼に化けます。

このサイトには独自プラグインと直接書き換えたカスタマイズが積み重なっており、検証用に立てた環境でバージョンアップを試した時点で、復元できないところまで壊れました。結論として選んだのは、バージョンを上げることではなく、古いPHPが動く別のサーバーへ丸ごと移して延命することでした。サイトの運用終了時期があらかじめ決まっていたため、恒久対応より延命のほうが事業の都合に合っていたからです。技術的に正しい選択と、そのサイトにとって正しい選択は、いつも一致するわけではありません。

移行先を決めるときには、実際のアクセス量を根拠にします。この案件では月平均でおよそ1万2千PV、アクセスが集中した日で2万5千PV超という実測値を共有したうえで、プランを選びました。「将来的に増えるかもしれないので余裕を」と言われるまま上位プランを選ぶと、使わない性能に毎月払い続けることになります。

見積りの前に確認した5項目

移行の相談を受けたとき、金額を出すより先に聞くことが5つあります。データの総容量、ファイル数、いま試している移行方法、単体で最大のファイルサイズ、そしてエラーが出ているかどうかです。

このうち一番効くのは最後の項目です。何度やっても最後まで進まないのに、エラーメッセージが何も出ない。この状態は、コードの不具合ではなくタイムアウトかサイズ上限に当たっていることを意味します。相談の時点でここが判明すれば、原因の候補を半分に減らせます。「エラーが出ていない」は、それ自体が有力な情報です。

見積りをもっとも大きく動かすのはSSHの可否です。移行元と移行先の両方でSSHが使えれば、rsync や tar でサーバー間の直接転送ができます。SFTPしか使えない場合は、いったん手元のPCへ全部落としてから再アップロードすることになり、100GB規模のデータでは所要時間が桁ひとつ変わります。接続方式の確認を飛ばした見積りは、そのまま納期の破綻につながります。

移行範囲の線引きも先に決めます。本番だけか、開発環境やステージングも含むか。メールデータを運ぶか、運ばないか。EC-CUBEのサイトを上位プランへ移した案件では、開発用サブドメインは本番と同じ工数がかかるため対象外にすると契約時に明示しました。メールは受信をすべて外部のメールサービスへ転送していたので、移行対象から外せています。転送設定になっていない場合、旧サーバーのメールボックスを事前に取り出さなければ、切り替えと同時に消えます。

この5項目の答えは、そのまま「自分で進めるか、外に出すか」の判断材料にもなります。分かれ目の条件はサーバー移行を自分でやるか業者に頼むか、分かれ目になる条件に整理しています。

WAFとアップロード制限で、作業そのものが止まる

Zenlogicの環境で最初に引っかかるのがWAFです。Web Application Firewallは不正なリクエストを遮る仕組みですが、移行作業では管理画面の操作やファイルのアップロードを、こちらの意図とは無関係に遮ります。厄介なのは、遮られたときに「WAFが止めました」とは表示されないことです。管理画面が白くなる、アップロードが途中で終わる、保存を押しても反映されない。原因不明の失敗として時間だけが溶けます。作業に入る前に一時停止し、完了したら必ず戻す。この二つを手順書に書いておかないと、止めたまま放置される事故が起きます。

もう一つが、Webからのアップロードにかかる時間とサイズの制限です。All in One WP Migration のような移行プラグインは、標準ではブラウザ経由でバックアップファイルを送り込みます。ここに上限があると、大きなサイトは何度やっても復元まで到達しません。相談を受けた案件は、ファイル数13,870という規模の会員制サイトでした。

プラグインの画面を経由しない

回避策は単純で、ブラウザからのアップロードをやめることです。FTPで wp-content/ai1wm-backups ディレクトリへバックアップファイルを直接置くと、プラグインはその中身を「バックアップ」の一覧として認識します。あとは管理画面から復元を実行するだけで、Web経由の時間制限もサイズ制限も丸ごと回避できます。有料の拡張機能を買う前に、まずこれを試す価値があります。

置き方には注意が要ります。アップロードの方法によっては、ファイルの所有者やパーミッションがWebサーバーから読めない状態になり、一覧に何も出てきません。「置いたのに出てこない」ときは、コードを疑う前にパーミッションを見てください。

復元処理そのものにも時間がかかります。途中でブラウザのタブを閉じると処理が中断するため、終わるまで画面を開いたままにしておく必要があります。復元の前に重いプラグインを止めておくと成功率が上がります。この案件では、投稿を表形式で一括編集するプラグインが出していたエラーが、復元処理を最後まで進ませない原因になっていました。

「重大なエラーが発生しました」の正体

復元が終わってサイトを開くと、WordPressのこのサイトで重大なエラーが発生しました。という画面が出ました。この画面はPHPの致命的エラー全般で表示されるため、これだけでは原因が絞れません。ただ、重い復元処理を通した直後であれば、PHPのメモリ不足がまず疑わしくなります。

ここで一度つまずきました。.htaccess に php_value memory_limit 512M を書いても、値がまったく変わらなかったのです。PHPがCGIやFastCGIのモードで動いている環境では、.htaccess の php_value は読まれません。書いた本人は設定したつもりでいるので、効いていないことに気づかないまま別の原因を探し続けることになります。

この環境で効いたのは wp-config.php への追記でした。

<code>/* データベース設定の下、「編集が必要なのはここまでです」の行より上に置く */
define('WP_MEMORY_LIMIT', '512M');</code>

値を書いたら、必ず反映を確認します。phpinfo() を出力するか、管理画面の「ツール」から「サイトヘルス」の情報タブを開けば、実際に効いているメモリ制限が読めます。設定したつもりの値と、実際に効いている値は別物です。ここを確認しないまま次の作業へ進むと、後の工程で出た不調の原因を切り分けられなくなります。

同じサーバーに同じ構成で複数のサイトが載っている場合、1サイトで判明した原因は残りにもそのまま当てはまります。この案件でも、本体サイトで特定したメモリ不足を、会員向けのサブドメイン側へ先回りして適用しました。1件目で原因が分かった時点で残りを点検しておけば、同じ問い合わせが後から返ってきません。

切り替えたあとに出た症状と、その原因

移行は切り替えたところで終わりません。むしろ切り替え直後の数時間に症状が集中します。実際に報告が来た順に書きます。

個別のページだけがエラーになる

EC-CUBEで動く物販サイトを同じ事業者の上位プランへ移した案件では、トップページは表示されるのに、商品詳細ページなど個別のページだけがエラーになりました。原因はキャッシュです。EC-CUBEはコンパイル済みのテンプレートと旧環境のパスをキャッシュとして保持しているため、移行後は管理画面の「コンテンツ管理」から「キャッシュ管理」を開いて消す必要があります。移行手順の最後に組み込んでおくべき作業でした。

2ページ目が開けない、管理画面に入れない

ネームサーバーを変更した直後は、一覧の2ページ目以降が開けない、管理画面にログインできないといった部分的な不具合が出ます。参照先が新旧で入り混じっている状態で起きるもので、反映が進むと解消するものが多く含まれます。ここで慌てて設定を触ると、本当の原因が分からなくなります。まず nslookup でどのIPアドレスが返ってきているかを確認してください。手元のPCは自身のDNSキャッシュを見るため反映が遅く、スマートフォンのWi-Fiを切って携帯回線から開くと、先に新しい側が見えます。この確認方法を依頼元へ渡しておくと、「まだ古いサイトが見える」という連絡を自分で切り分けてもらえます。

決済が全部落ちて、代金引換だけ通る

ECサイトを別サーバーへ移したときに出た症状です。クレジットカードもキャリア決済も通らず、代金引換だけが成立する。原因は決済プラグインの設定ファイルに、移行前のサーバー固有の絶対パスが直書きされていたことでした。具体的には 3GPSMDK.properties の CA_CERT_FILE、つまり証明書ファイルの置き場所と、log4php.properties のログ出力先です。ここが古いパスのままだと、決済代行会社との通信そのものが成立しません。決済を積んだECサイトを移すときは、プラグインのディレクトリ内にサーバー固有のパスが書かれた設定ファイルがないかを、事前チェックの項目に必ず入れてください。

あわせて、キャリア決済は通信事業者ごとに決済代行会社が分かれていることがあります。ドコモとauは決済プラグイン側、ソフトバンクは別の決済代行サービス側、という具合に、管理画面も担当窓口も別々です。「キャリア決済が通らない」という報告を受けたら、どのキャリアなのかを先に確認します。切り替え後にこうした形でサイトが止まってしまった状態から戻す作業は、移行というより障害復旧の範囲になります。

メールが届かない

移行後に「特定の宛先にだけメールが届かない」という報告が来たときは、自分の設定ミスを疑う前に、移行先ホスティング事業者の障害情報とお知らせを見てください。大手のメールサービス宛に送信エラーが出ているケースが事業者側で告知されていることがあり、そのときは待つ以外にできることがありません。メールの切替そのものの手順はサーバー移行でメールが届かなくなる理由と、DNS切替の正しい順番で分けて書いています。

サイト以外のものが公開領域から外れる

同じサーバーの中にサイト以外のものが同居している場合、ドキュメントルートの変更で巻き込まれます。SSL化の作業に合わせて公開ディレクトリを切り替えた結果、サブディレクトリに置いてあったグループウェアが公開領域の外に出て、まったく開けなくなった案件がありました。証明書やhttps化そのものではなく、公開ディレクトリが動いたことが原因です。

復旧で選んだのは、アプリを動かさずにURLのほうを寄せる方法でした。新しいサブドメインを旧ドキュメントルートに向けて即座にアクセスを回復させ、旧URLからは.htaccessの301リダイレクトで誘導します。ファイル移動もデータベース移行も伴わないため、深夜の緊急対応でも事故の余地が小さくて済みます。

この種の作業でディレクトリをコピーする前には、cronや常駐スクリプトの有無を必ず確認してください。実行パスが固定されたシェルスクリプトがある状態でディレクトリを二重化すると、同じ処理が二重に走ってデータが壊れます。この案件ではコピー直前にスクリプトの存在に気づいて中止しました。もう一つ、旧URLは一つとは限りません。リダイレクトを入れたあともアクセスログと利用者への確認で取りこぼしを洗い出す必要があり、実際に後日、別のWebメールが同じ原因でログインできなくなっています。

切り替え後にどこまで見れば「終わった」と言えるのか、旧サーバーをいつ止めるのかについてはサーバー移行が終わった後に確認する項目と、旧サーバーを止める時期にまとめています。

よくある質問

移行中、サイトは何時間くらい止まりますか

手順次第です。新しいサーバーにデータを載せ終えてから切り替える形を取れば、表示が完全に止まる時間はほぼありません。ただしDNSの反映が進む間は、見る人によって新旧どちらが表示されるか制御できない時間帯が生じます。この間に投稿や受注が入ると、旧サーバー側にだけデータが残ってしまいます。更新を止める時間帯を先に決めておくのが安全です。

移行したのに、まだ古いサイトが表示されます

DNSの反映待ちであることがほとんどです。PCはブラウザとOSの両方にDNSのキャッシュを持つため、切り替え直後は古い情報を見続けます。スマートフォンのWi-Fiを切って携帯回線から開く、あるいは nslookup で返ってくるIPアドレスを確かめると、実際にどちらを向いているかが分かります。数時間経っても切り替わらない場合は、DNSレコードの設定そのものを見直します。

移行のためにWAFを止めたままにしておけば、今後も作業が楽になりますか

戻してください。WAFを止めた状態はそのままセキュリティが下がった状態です。特定の操作だけがWAFに引っかかるのであれば、全体を止めるのではなく、その操作に対する除外ルールを設定するのが本来の対処です。移行作業の完了報告に「WAFを再度有効化しました」の一行を入れる運用にしておくと、戻し忘れが起きません。