サイト移転の覚書

Advertisement

今後の事を考えてドメインを移転いたしました。
サイト名とドメインが乖離してるのが気持ち悪かった、というのが最大の理由だったんですけどね;

 

新規ドメイン名”rainbowsound.cafe”を取得し、引っ越しを行いました。

サイトとしてもそれなりのアクセスを集めるようになってしまった事と、個人用で作成したドメインで続けていくのはサイトの設立趣旨的にも沿わないのでサイト単体として名目を掲げようと思い変更しました。

また移転にあたりいくつかの点で利便性の向上を目指しAmazon Web ServiceのCloudfrontなどのCDNの利用、ドメインレジストラの変更など多岐に渡って構成の変更を目指しました。

WordPressにサイトを移したい、あるいはドメインを移動しようと思っている方の役に立つかもしれない移転にまつわる事を記録して行こうと思います。

移行計画を立てる

サイト(ブログ)の移転は簡単なようで意外と大変です。

被リンクやアナリティクス、広告などを掲載していれば広告の取り扱い等、長く続けているサイト程移転に伴う作業量は大きくなります。

これを無計画にぽんと行って上手く行くのは奇跡に近いです。
移転に当たって変えたいこと、完成はどういう形になるか決めて必要な作業をまとめなければ無駄なコストを支払うことになりかねません。

そうならないためにも最初にデータのバックアップとテスト環境への移動、そこで発生する問題を確認して一つ一つに対策を立てることから始めます。

そして全ての基本ですが移行が完了するまでの間、復元可能なバックアップを維持しておくのは「必須」です。

今回もまずはバックアップを作成してから作業に臨みました。

テスト環境の構築

ドメインや環境の移転を行うにあたり、まずは事前調査を行います。

昨今ではレンタルサーバーやブログスタンドなども試用期間を設けている場所も多いので、試用期間があるならその間にテストを実施します。

試用期間がない場所であれば「どこから移動したい」「Wordpressを使いたい」など自分の希望をサポートに伝えて事例や問題について確認を必ずしておきましょう。

今回のケースではWordpress to WordPressの同一システム間での移行ですのでデータの互換性については問題はありません。
しかし試しにデータを動かしてみると問題点を複数発見しました。

リンク切れやデータの修正が必要な部分、ハードコーディングされた修正点などをチェックし、対策をリスト化して本番稼働時に行う操作を記録しておきましょう。

実際の作業を開始します

そんな訳でざっと目論見をまとめ、実際の移行作業について。

今回の移行はGMOのCorepress Cloudで構築していた前のサイトを新規ドメインに変更する作業です。
同一サーバでの操作なので心配が少ないのは良い事です。

ダウンタイム(接続できない時間)を減らすために旧ドメインのサイト稼働は停止させずに新規のドメインにクローンを作成、クローンの稼働が確認できたら旧ドメインへのアクセスは全て新ドメインへのリダイレクトを行う事で綺麗に移行できるはずです。

まず最初に行うのは移行時の不整合を無くすためにMaintenance ModeというWordpressプラグインで一時的にサイトをクローズすることから。
このプラグインは設定を行う事で一次的に改修中の画面を表示するものです。
移行中にコメントなどがあるとそれが消えてしまったり、カウンタの不整合やそのほか予期しない動作が入り込む可能性があるため最初の安全対策として一時停止をしておきました。

こうすれば移行データでもデータ投入時はメンテナンス中表示になるため、無用な混乱も避けられます。

まずはデータの移行から

Maintenance ModeをEnableにしてからデータベースに接続し全てのデータをエクスポートします。

CorePressではクローン作製がメニュー上で可能なのでクリック一つで全て移動できてしまいますが、上手く行かない事を考えてデータは手動で取得しました。
他の環境への移動であればFTPでwp-content以下の使用中テーマ、アップロードファイルなどを取得して新しい環境にアップロードしなおす必要があります。

次に新規に立ち上げるサイトを作成します。
手動の場合は空っぽのWordpressサイトを新たにインストールして、必要なテーマ等のファイルをアップロードします。

アップロードができたら空のWordpressサイトを新たに設定したいドメインとして初期設定を行います。
初期設定ができたらSQLとしてエクスポートしたファイルを新しい環境を構築するデータベースに接続しデータをインポートします。

Bloggerなど他のブログスタンドなどから移行する場合は直接移行可能なフォーマットがあるか、あるいは移行を補助するプラグインがあるかを事前にチェックしてください。
方法があれば多くの場合取り込みで問題になることはありません。

問題はデータ中に含まれるリンクの取り扱いです。

WordPressのデータはシリアライズと言って書き込まれているデータに対してある種のチェックサムを持っています。
直接書き込まれているリンクアドレス等のドメインを丸ごとリプレースするSQLや処理を流すことも可能ですが、何の準備もなくこれを行うとシリアライズされたデータと不整合を起こして有効なデータとして認識されなくなってしまいます。

ドメインのアドレスはそれ以外にもユーザー情報などにも含まれますので下手な操作は命取りになります。

データの修正は専用のツールかプラグインで

こういったデータの操作は専用のツールを使用するのが原則です。
Wordpressの引っ越しで検索すればすぐに公式ツールが見つかると思います。

ここでは公式の引っ越しツールはパーミッションの関係で使用できない為、同じ機能を持ったプラグインを使用しました。

Better Search Replaceです。

これはWordpressデータベース内にある特定の文字列をリプレースする処理をしてくれるプラグインです。
これを使用するとリプレースと同時にシリアライズ処理も実行してくれるので一括処理でもデータの不整合を発生させずにリンクの更新などが可能になります。

さらにこのプラグインではDryrRunモードがあり、リプレース前に指定条件での入れ替え箇所をカウントして返してくれます。
ミスによって大量の更新を走らせて取返しが付かなくならないようにDryRunで変更箇所のチェックは必ずしておきましょう。
(想定より変更箇所が多い=条件の誤りなのでクラッシュを防ぐことができる)

これを使用して文中に挿入されていた旧ドメインのページ間リンクや、その他のデータに含まれるハードリファレンスを新規のドメインに一括して変更しました。

また、これはアフィリエイトリンクに使用しているデータの一括更新にも使用しています。
これはプロバイダによって操作が異なるのでデータ構造や処理構造についてよく理解してから実行してください。

ここまでを処理するととりあえず大体の表示は正常に出来るようになるはずです。
正常に表示されない場合はデータまたはファイルの移動で大きなミスをしている可能性がありますのでまずは元のファイルを確認してみましょう。

ありがちなパターンはfunctions.phpなどのテーマのコアファイルや改造したプラグイン内で追加したコードなどがハードリファレンスを持っているケースです。
この場合リファレンスを見失ってエラーで停止してWordpress全体が機能不全を起こすケースがあります。

移行元に修正している場合は記録をしっかり残しておくか、追加部分に目印のコメントを残すなどして移行時に見落としの無いようにしておきましょう。

応答速度の向上、CloudFrontでコンテンツ配信

WordPressのようなCMSは機能を追加したりプラグインを動かすとどうしても重くなります。
特にアクセスが集中するような状況になるとリクエストの数も急増してしまいます。

一部参照の多い記事が不定期にアクセス呼び込むので負荷対策とレスポンスの向上に向けてCloudFrontを使用することにしました。

旧ドメインではCloudFlareを使用していたのですが、無料アカウントではキャッシュルールの設定面に自由が利かない事とネームサーバーの応答とリバースプロキシのレスポンスがイマイチ鈍い感じがしていました。
(もちろんCloudFlareも直接読み込むより格段に速いです。)

速度比較でみるとCloudFrontよりCloudFlareの方が高速であるという結果もあるのですが、CloudFlareのネームサーバーとエッジサーバーはアジアにないためオーバーヘッドでアジアにもエッジとネームサーバーが存在するAWSの方が高速にレスポンスを返してくれます。

設定についてはVoltechnoさんのブログが非常に参考になりました。(ネイキッドドメインのCNAME問題にぶつかりました)
これを解決するためにAWSのRoute 53をネームサーバーとして使用しています。

キャッシュ設定も自由度が高いので積極的にキャッシュさせて、オリジナルへの問い合わせは極力減らすように設定を行いました。
現在の最高効率でCacheHitが86%前後です。

CloudFrontは12か月間は無料ですが、それ以降は従量制です。(非常に安いですが)
CloudFlareの無料プランはずっと無料ですが、ここは好みの問題ですね。

勿論Akamaiなどしっかりコスト掛けてもいい!!という方はそういったサービスを利用される方が有利です。

ドメインの取得と管理を移管する

リダイレクト処理を行うために当初はDNSサーバーでHTTP 301 Move Permanetlyを返してリダイレクトを行うつもりでいました。
301でリダイレクトすることで旧ドメインでの評価を新しいドメインへそのまま引き継ぐ事が可能になります。
ブックマークをして頂いている方にとってもわかりやすいですし、検索から入ってきた方もそのまま誘導できるという点でこの対応は確実にしておきたい点でした。

バックアップや一部の改修の間にドメインレジストラ(こちらもGMOのValueDomain)にDNSで301出したいので設定はできますか?という問い合わせを投げておきました。

回答は「できません」でしたw
少なくとも現在のネームサーバーでは設定が出来ないので仕方ありません。
そうなればやる事は一つ、レジストラ移管です。

ドメイン名は取得した場所以外で管理が出来れば自分の手元でもどこでも使う事が出来ます。
今回は新規ドメインを.cafeという新gTLDで取得するためにValueDomainではない別の海外レジストラに申請を行っていました。
そちらのネームサーバーには301を返す機能があったのでこの際まとめてしまえと速攻で移管を申請。
確認のメールや移管申請の承認のための登録変更などを速やかに実行して数時間で移管を終了させました。

移管先は.cafeというドメインを比較的安く取得でき、ネームサーバーの設定など機能面でも充実しているUniregistryに設定しました。
取得価格の高めなドメインも比較的安価に取得でき、更新のコストも安いので有利です。
海外レジストラにしては珍しく日本語にも対応しています。
ネームサーバーも十分な機能が提供されているためある程度知識のある方には自由度が高いのも良いですね。

旧ドメインからリダイレクトを行う

DNSサーバーからMove Permanentlyの発行は可能でしたが、実行してみたところこれだけではブラウザからのリダイレクトができない事が分かりました。
(クローラーの認識を振り向けるだけのようです)

下位レベルで解消できれば楽なのになーと思いつつ、ダメだった時の対策として見つけておいたプラグインSimple 301Redirectsを使用しました。

これはアクセスを受け取ったURIをそのまま新ドメインに転送するHTTP 301レスポンスを吐き出すだけのプラグインです。

最初に転送先の設定を誤っていたのでうまく転送ができていない箇所がありましたが、設定自体は簡単なので誰にでも使用することが出来ると思います。

これで一通りの作業を完了しました。

手間がかかるように思うかもしれませんが、データ周りの操作を失敗さえしなければ実はそれほど問題にはならなかったりします。

いきなり全部をずどんと移行したい!!という方は事前によく計画を練った方がいいです。

お引越し予定の方がうまく行きますように。

Advertisement
みるくここあ
About みるくここあ 302 Articles
ウィンドシンセを片手に曲を作っています、演奏するのも聴くのも好き。 ゲームとITと変な情報を拾ってくるのが得意。 色々とやっているらしいけど詳細はヒミツ。 オリジナル曲を公開しています。 http://www.nicovideo.jp/mylist/31704203 作曲風景の生放送もしています。 https://rainbowsound.cafe/rainbow-sound-cafe-live/ 音楽やDTMに纏わる話題を色々と書きます。

あなたのコメントをお待ちしています

コメントをどうぞ

Your email address will not be published.




このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください