ネイルブログ HP再生請負人～Vol.6 – いよいよ本丸！高速サーバーに移転せよ！～

ここまでネイルブログは、見られるためになにをしていくべきか、それを考えながら記事を書いてもらってきていました。
そして、読み応えのあるクオリティの記事をかけるようになり、そして、修飾で見た目もきれいな、飽きの来ないブログになってきたと思います。

接続エラー頻発。。。

もう少し先でもいいと思っていたサーバーの移転ですが、以下の2つの理由から早めに移転を検討することになりました。

PHPバージョンによるエラー

まず一つ目、WordPressで運営しているネイルブログ、プラグインも結構導入していますが、プラグインのアップデートが走るたびにエラー。
これは、現在利用しているサーバーのPHPバージョンが少し古いためにおきているようです。
プラグインのアップデートができない現状となりつつあり、ちょっと困った状態になってきました。

エラーによるページの表示不具合

結局のところ、ブログ記事がまともに表示されなくなりつつありました。
Googleからも404エラーや501エラーによるクロール中止の案内が届くようになりました。

容易に移転できないワケ

普通なら、こんな重いサーバーダメだから少しでも早く、もう少し快適なサーバーに移動しましょうというところなのですが。。。
どうしてもそう言えない理由がありました。
なぜなら、このブログは【あくまでおまけ】だからです。

元々は、ショッピングサイトで、ショッピングカートシステムをレンタルし、そのカートシステムに紐づけしてあるドメインです。
そのレンタルカートシステムのあくまで<<オプション>>のブログシステムなのです。
WordPressのブログで、サーバー内でPHPが動きそしてFTPが提供されているので、そのブログのWebスペースでオリジナルで作成したPHPプログラムも動かせるので、何となくレンタルサーバーでブログを運営している感覚になりますが、もともとはレンタルカートシステムのオプションなのです。
なので、URL自体も該当ドメインの下階層のディレクトリに/blog/というフォルダがあり、そこにWordPressが入っている形です。
カートシステムがメインのドメインなので、このドメインを快適なサーバーに引っ越す。。。というわけにはいきません。
また、ブログは確かに異常なまでに重いのですが、カートシステムはそうでもなく、たぶんサーバーが別なんでしょうね。
オマケのブログは重い。。。けどカートはそこまでではないという状況です。
なので、カートシステムはそのまま維持したうえでブログだけを切り分けたいのですが、、、なにぶん同ドメイン内の下層ディレクトリがブログですから、ブログだけサーバーを別に…というのはちょっと特殊な処理をしないと無理なので、現実的ではありません。

ブログを別ドメインで運営

今回、オーナー様には、ブログを別ドメインとし、ドメインを一つ取得してもらううえで切りはなして運営してもらうことを検討し了承してもらうことにしました。
ブログを別のものとして切り離すことに対するコスト増については何ら問題なく了承をいただけるのですが、大きな問題はドメインが変わる→要は評価が0から始まるかもしれないということ。これが問題です。
もちろん私も一番の問題として認識しています。
今までのブログとドメインが根本的に替わるわけですから普通にやればやり直しです。
Googleで受けていた評価がいったんなくなるわけです。
これを少しでも防ぎたい。今ある評価を引き継ぎたい。
ということで、301転送をかけることで、可能な限り評価も引っ越しできるように手配します。
これにてオーナー様から了解を得たうえでさっそく移転手続きに入りました。

ドメインの選定・サーバーの契約

まずは、新ドメイン。
ドメインは基本的に早い者勝ちなので希望するドメイン名が開いているかどうかは、探してみないとわかりません。
幸いにも、現在使っているトップレベルドメインが.netで、同じ名前で.jpドメインが開いていました。
なので、今回は、.jpドメインとすることにしました。

つぎにサーバー。
ドメインは単体であること、基本的にメールはたぶん使わないこと（仮に使いたかったら使っても差し支えのないサーバーにしておきたい）
WordPressで運用することがハナから決まっていること。
条件としてはこのような感じで、理想を言えば、

cronが使えること
SSHが使えること（移転時にコンテンツデータをZIPでアップロードしてSSHでunzipできたら楽だから）
無料のSSL証明書が利用できればなお良し

ということで、今回はロリポップ！のハイスピードプランというサーバーを契約してもらいました。
このプランは3年契約なら月額500円という超低価格でかつ、WordPress運営に特化してチューニングされているサーバーで、かなり高速です。
そして、cronが使え、SSHでunzipが可能、無料SSL証明書が導入可能ということで、何の文句も無いサーバーです。
オマケにムームードメインでドメインを取得し、その上でサーバーを契約すると、サーバー契約期間中はこのドメインの利用料が無料になるという特典付きです。
ブログを切り離して運営するのなら最適ではないかということで、ロリポを契約してもらいました。

ブログコンテンツの引っ越し！

ここからが、HP再生請負人の仕事です。
まずはブログのコンテンツデータの引っ越しです。

データベースのデータ移動

まずは、これです。
DBのデータを新サーバーに移転します。

実はあまりの重さにDBだけは一度外部DBに移動している経験があります。
これが一番リスキーで面倒な作業に見えるのですが、そうでもありません。
MariaDB（MySQL）には、phpMyAdminという管理ツールがあり、これがまた運よく、元サーバーにも、一時的に退避していたDBサーバーにも、今回のロリポにも導入済みです。
phpMyAdminで、エクスポート処理を行い、新DBサーバー側のphpMyAdminで、インポート処理を行えばデータはそのまま移動可能です。
DBの中身が移動してしまえば、あとはWordPressの設定ファイルwp-configのDB周りの接続設定の情報を新しいDBサーバーのものに書き換えればOKです。

WordPressコアファイルの移動

次はWordPressの実態ファイルの移動です。
旧サーバー側のWPも最新のバージョンに上げてあるので、わざわざデータをダウンロードしてアップロードしなくても新しいWPをインスト―ルして、DB接続だけを旧コンテンツが入っているDBに切り替えれば復元できるのですが、どのみち、画像ファイルの移動やログデータなども引き継ぎたいので、旧サーバーからデータをまるまるダウンロードしてそのまま新サーバーにアップロードする方法で移転することにしました。

しかし、重い。。。

まずは、旧サーバーからのデータダウンロード。
データ件数が多いのもありますがなにせ重い。
1MBのファイルをダウンロードするのに、10秒くらいかかります。。。このペースだと何時間かかるのか。。。

結局2時間30分近くかかりました。

次はロリポサーバーにアップロード。
こちらは快適ではあるのですが、ファイルのLIST取得のコマンドが何なのかわからない状態のままアップロード。
そうすると必ずどこかでつまずきます。。。
ロリポサーバーはきゃっしゅみたいなものももつんでしょうかね。LISTコマンドがわからない七アップロードしていると、途中からおかしくなってフォルダの階層がおかしくなり、アップロードがまともに行かなくなりました。
そして、そんな状態になると、今度は削除コマンドでファイルやフォルダの削除もできなくなりました。。。

ロリポFTPなる、ブラウザベースのファイルマネージャーがあったのでそちらを使ってみましたが、途中で501エラーやタイムアウト。。。
どうしてもアップロードが上手くいきません。。。

SSHを使うか。。。

サーバー選定の条件にSSHが使えることというのを上げましたが、やっぱり使うことなりました。
まず、コンテンツデータをZIPに圧縮。これはWindowsクライアントなので、そんなに難しくなくできます。
ZIPに圧縮したらZIPファイルをロリポサーバーにアップロード。
これはFTPで。1ファイルなのでおかしくなりようがないですね。ただ、データ量はそれなりに大きいのでUPするのに15分くらいかかりました。

いよいよSSHの登場です。

まずは、先ほどの変になってしまったファイルやフォルダを一旦削除。
SSHなら、【rm】コマンドで一発ですね。
必要なものだけを残してあとは全部rmで削除しました。

つぎに、アップロードしたZIPファイルの解凍です。これは、【unzip】コマンド。
コマンドで一発で展開してくれます。
これにて、なんとか旧サーバーにあったWordPressのファイル一式が同じパス構成のまま新サーバーに移動できました。

そうか…ドメインが違うのか…

HP再生請負人という名前にしただけのことは合って、サーバー移転の案件は何十件、何百件とこなしてきました。
ここまで来たらほとんどの場合はい終了！
なのですが、今回はそういきませんでした。
動くには動きました。
よしよし。
と。
WordPressのコンパネにログインしようと。ユーザ・パスワードを入れてログインドン！をやると、ログイン先が旧ドメインになってしまいます。。
ああ。。そうか。。。WordPressの一般設定という欄で接続URLなどを指定している関係で、旧ドメインが設定されたままなのでそうなります。。
サー困った。
旧ドメイン側はそもそも接続しているDBが古いので、こちらをいじっても、新しいDBで動いている新ドメインの方の設定には影響しませんので、新ドメイン側から新ドメインのコンパネにはどうやってもログインできない状況になります。
そこにつけ今のブラウザはCookieの受付状況が昔と違って、ドメインの違うところからのCookieは受け付けない仕様(サードパーティのCookie)なので、結局無限ループ状態になりました。。。
あまり直接DBのデータをいじるような行為はしたくはないのですが、事ここに至っては本当に仕方がないので、、、DBの中を直接編集。旧ドメインになっているところを新ドメインに修正することで解決に至りました。

これでやっと、新ドメイン側でWordPressのコンパネにログインできるようになりました。

ここまでにかかった時間はやく6時間w
そのうち5時間30分くらいはデータのダウンロードとアップロードでしたw
なんてことだw

旧ドメインから新ドメインへの転送

これで、新ドメイン側でとりあえず動くことが確認できたのでつぎは、旧ドメイン側にアクセスをしてきた方には、新ドメインに自動的に誘導したいと思います。
そして、ただ誘導するのではなく、引っ越ししたことを示しながら転送したいと思います。
これは、301リダイレクトと言われる転送の方法で、これは301番のヘッダ番号を付けて転送をかけるというのは、旧アドレスからこの新アドレスに引っ越ししました。なので、今度からこっちに来てねという番号なのです。
なので、Googleさんなどは301リダイレクトと認識したら、リダイレクト先に評価を移転してくれるようになっている（はずな）のです。
旧サーバーの方に、301リダイレクトで同じ記事に転送がかかるようにrewriteルールを書いて設置。
旧サーバーのAの記事URLにアクセスすると新ドメインのAの記事に転送がかかることを確認。
これにて、旧サーバーから新ドメインへの評価の移転設定も完了です。
あとはGoogleさんが評価を移転してくれるのを待って、ある程度移転したら旧サーバーのブログオプションを解約して終了です。
1日経過後、アクセスを見ると、転送がかかっているので新ドメインの方にアクセスが来ていることは確認できました。
あとは徐々に評価移転してくれればOKかな。

できなかった最適化チューニング

旧サーバーでは重すぎてダメだった高速化チューニングを再度。
まずはキャッシュ系のプラグインから。
旧サーバーの場合、重すぎて、一時ファイルを持つときにタイムオーバーしてしまい、一時ファイルが呼び出し途中でできてしまい、デザインが崩れるという本末転倒なことが頻発し採用できませんでした。
今回はそれなりに高速なサーバーですのでキャッシュサーバーを導入することでさらに高速化を図ることができました。

つぎに、画像のwebp化。
こちらはできないことはなかったのですがWebp画像を書きだそうとすると重すぎて途中で止まるという事態に…
なので、古いものはとりあえずWebp化せずに今からアップする画像だけWebp化という部分最適化にとどめていましたがこちらも移転したことでWebp画像の書き出しが可能になったのですべての画像をwebp化して展開。

バックアップもクラウドサーバーに
旧サーバーでは外部とのサーバー接続もあまりの重さで途中でタイムアウトするのでローカルにバックアップを取得していました。
また、ログを見ると、1回のバッグアップでかかっている時間が6000秒でした。
今回こちらも新サーバーに移転したことでドロップボックスなどの外部サーバーへバックアップを保存できるようになりました。
また、バックアップにかかる時間は450秒。実に10倍以上時間が短縮できた計算になりますねw

そして、コンテンツ内の旧サーバーURLをすべて新ドメインに置換！

置換用のプラグインというものまであるのですね。
今回は置換用プラグインを利用して旧サーバーURLになっている画像やリンクを一括して新ドメインURLに置換しました。
実に2400個ありましたが10秒くらいでできました。
置換の検索文字をブログURLと指定したのでショップサイトのカートページのリンクなどは置換せず残しています。
これで、新ドメイン側に旧ブログURLは残っていない状態になりました。

wp-cronも、LinuxCronで！

最後に、wp-cron。もともと旧サーバーの時からWP-CronのWebアクセスからの実行は外していましたが、LinuxCronが使えないのでLinuxCronの使える私の自前のサーバーからwgetを利用してwp-cronにアクセスして実行するようにしていましたが、この度自サーバーでCronが使えるようになったのでローカルで実行するように設定しました。
これで、すべてが自己完結で高速最適なWP運用ができるようになりました。
さあこれであとは伸びるだけですねw