Webサーバー移転でハマったこと

引っ越し
2021.01.22
スポンサーリンク

.htaccessの記述をよく見よう！

何回かハマってる気がする。

引越し前のWebサーバに合わせた記述が足引っ張ることがよくある。

.htaccess内の記述をよく見て、不要そうなところはコメントアウトするなりすること。

 

DNSのAレコードを更新する前段階で、hosts編集でWebコンテンツを確認しているときに予期せぬフルパスURL表記が無いか？

移行対象コンテンツにブラックボックス（システムの内容の細部を把握しきれないもの）がある場合、例えばWordPressや自分以外のコーダーが作ったものなど。その場合、中にURLフルパスでコンテンツが指定されている場合がある。

今回ハマった事例。

  1. サーバAであるコンテンツのページが重く、アクセスすると504 Gateway Timeoutしてしまう
  2. サーバAからサーバBへ引っ越しをしたい
  3. サーバAはスペックが低く、またWebサーバのTimeout値が低く設定されている（ちょっとの間応答がなかったら504エラーとなって閲覧できない）
  4. サーバBはスペックが高く、またWebサーバのTimeout値が高く設定されている（URLにアクセスして表示されるまで結構な間待ってくれる）
  5. つまりサーバBの環境は必要充分
  6. サーバBにコンテンツを移行
  7. DNSのAレコードをサーバAからサーバBのIPアドレスに書き換える前に、自身のローカルPCのhostsでサーバBのIPアドレスを指定する
  8. Webブラウザを使用しアドレスバーにドメインを入力、アクセスし、サーバBの動作を確認する

しかし、必要充分なスペックや設定であるはずのサーバBなのに504 Gateway Timeoutが発生する。

3日ぐらいハマった。

色々調べてみると、当該ページのコンテンツはWordPressのプラグインで生成されており、プラグイン君がフルパスのURL（https://example.com/image.pngみたいな)で大量画像を取得していた。

この場合、サーバBから「example.com」へアクセスされるため、いくらローカルPCのhostsにサーバBのIPアドレスを書いていても、サーバBはサーバAへアクセスしてしまう。

サーバAのスペックは必要なスペックを満たせていなかったので504 Gateway Timeoutが発生していた。

 

対応

移行先のサーバ（上記の例で行くと、サーバB）でhostsでの確認を行う場合、そのサーバの、

  • hosts
  • 参照するDNSサーバ
  • proxy

などが指定できる環境であればそれらを指定して確認することができる。（たとえばサーバBのhostsに、対象のドメインとサーバBのIPアドレスを紐付ける記述を追記してから動作確認すればよい）

または軽微な修正であればコンテンツ側を修正すればいいが（URLフルパスを相対パスに変える）、確認後の戻し忘れに要注意。

しかしそれができない場合（レンタルサーバなどでは難しいはず）、DNSのAレコードがサーバAからサーバBに変更されるまで確認することはできない。

 

その他確認したほうが良いポイントを列挙する

ハマッタことではないが、確認する際のポイントを以下に列挙する。自分がするサーバ引っ越し作業の際の雛形にしたい。

  • サーバ環境
    • phpのバージョンはあっているか
    • Webサーバの設定
      • レンタルサーバの場合、結構サーバのベースになる設定が違っている
      • .htaccessを見直す
  • ログ
    • 特にWebサーバのエラーログを確認する
      • 500番台のエラーでもログに何かしら残っていることがある
  • WordPress
    • 動作確認に関係ないプラグインを無効にしてみる
  • サポートに投げる
スポンサーリンク

コメント