ども、キャレット合同会社の椎原です。今回、お客様より、アプリ開発を受ける前段階として、WordPressの高速化、AWSへの載せ替えを行いました。ふふん、kusanagi使って、WordPressの移行プラグインでちょちょいのちょいだぜ！ と高をくくって作業したら、トラブル続出。いやはや、大変でした。
WordPress構築は最近はほぼボタン一つで構築できるようになってますが、移行は正常に表示されているかいちいち確認せねばならないので。失敗したらお客様の損失になります。これがECサイトだったら莫大な損害賠償が……((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
この記事では注意点を記しておきます。
前提条件
- 現サーバーはさくらインターネットのサーバーを使っている。
- ドメイン（DNS)はお名前.comを使っている。
- 移行するサーバーはAWSのEC2にkusanagiを載せたものを使う。
- AWSでtestサブドメインを作って、サブドメインなしに切り替える。
- ダウンタイムは最小限にしたい。
- 現在、異様に重いので、早く移行したい。
といった感じ。
手順
- testでWordPressのサーバーを立てる（PHPのバージョンを旧と一致させる※現在のバージョン PHP 7.4.14 (モジュール版)）
- 旧サーバーのWordPressバージョンアップ（やらない）
- 旧サーバーのバックアップ(ダウンロードは問題なくできる）
- testドメインを
R53をお名前のDNSに登録 - 新サーバーへのリストア（winSCPでアップ。復元）
- 新サーバーでテーマやプラグインの更新
- robots.txtをルートに置く
- 更新後正常に動いているか確認
- 新サーバーのバックアップ
stgドメインに新サーバー切り替え
- stg,、ACMで証明書を作成し、ALBにアタッチ。Aレコードを新サーバーのALBに切り替え（お名前にCNAMEレコード追加）
ｗwwドメインを新サーバーに切り替え
- 新www、ACMで証明書を作成し、ALBにアタッチ。Aレコードを新サーバーのALBに切り替え（お名前にCNAMEレコード追加して後で有効 Aレコード無効→失敗）
-
sakuraのwww設定を解除 - testで入って、URLの切り替え
- wwwドメインで正常に動いているか確認
- 動いてなかったら、旧サーバーに切り戻し
- お名前の旧Aレコード、旧CNAMEレコード削除（sakuraのCNAMEレコードは念のため残す）
- robots.txt削除
- バックアップ、鍵、手順書はBackLogのGitへ
- 不要データー削除
- リザーブにするか
phpmyadmin削除- CloudWatch監視設定
- さくらサーバー解約？
1）お名前.comのNS設定をミスってダウンタイムを発生させてしまう。
EC2ーACMーALBーRoute53の構成でやろうとして、いつも通りRoute53に表示されるNSをお名前.comにDNSにアタッチしました。
→現サーバーの接続が切れました（ダウンタイム発生)
これ見てください。「その他」「初期設定」「お名前.com」の3種類があるのですが、私は「その他」（カスタムのNS設定）のところを、以下のチェックボックスにチェック入れてしまったがためにNS情報が消えてしまったのです。
勝手にチェック入れてはいけません。というか、移行時にRoute53を入れてはいけません。testドメインはALBの値をCNAMEで登録します。
対策→Aレコードに現サーバーのIPを直接入れてアクセスできるようにしました（冷や汗）。あと、切り替えは一人でやってはいけません。ある程度知識がある人と一緒にすべきです（一人は冷静な人がいないと大変です）
2）コンテンツが巨大
「All-in-One WP Migration」というプラグインを使って移行しようしました。コンテンツは圧縮して2.2G。これだけ大きいと回線状況によって上手くアップロード、ダウンロードができない場合があります。私はブツブツ切断され、ようやくアップロードが終わったと思ったら、復元が有料だとか（無料は数十Mしかアップロード制限があったのでSCPでアップロードしてました）Duplicatorプラグインも使ってみましたが上手くいかなかったので、All-in-One WP Migrationを課金して復元しました。所要時間2日。要したネット容量40Gくらい（何度も失敗したため）
3）データーベース内のURLをtest.xxx.comからxxx.comに書き換える。
kusanagiサーバーにphpmyadminが入ってなかったので入れ、「Search-Replace-DB-master」というツールでDB内のURLをtest.xxx.comからxxx.comに書き換えようとした。
なかなか上手くいきませんでした。最終的には移行できましたけど。最初、ツールがポンコツなのか、手順が悪かったのか、はたまた、WPが古いのが悪いのか、全部変換してくれませんでした。お客様のご指摘で上手くいってないのが判明。phpmyadminからtestサブドメインだけ検索し、置換しました。※test（例です）だけで置換してはいけません。他で使って居る場合があります。あくまでも、test.xxx.comをxxx.comに置き換えるような感じでやりましょう。
https://ishida-webkontor.com/417/みるとなぜ全部変換しないかわかりました。
4）CloudWatch監視設定
調べれば、CPU、ディスク、メモリ、死活管理は簡単にできます。悩んだのはロードアベレージ。AWSに機能がないので、皆さん独自実装しててその記事があるんですが、記事がすっぽ抜けているところがあったりして、苦労しました。取りあえず、AWS CloudWatchメトリックスにEC2のロードアベレージを追加する で上手くいきましたが。
5）アプリへ送るRSSとの整合性
このサイトは某ニュースアプリと契約していて、広告画像がアプリ側で表示されないとの話です。調べてみたら、WordPressのプラグインでRSSで、旧画像リンクをこのアプリに送っていて、リンクの更新ができない状態です。おそらく仕様で改めて再更新することはできない模様。推測ですがドメインは変えてませんので、テストドメインでRSS投稿をしていた時期にひっかっかのではないかと。この時期、予約投稿とかしていたのですよね。
アプリのRSSは計算外でした。
6）お名前.comのDNS登録はAレコードで
ドメイン登録時に、www.xxx.comだとCNAMEレコードにALBのFQDNを紐付けて登録すれば良いです。ただ、Apexのxxx.comがCNAMEレコードに登録できません。CNAMEレコードの場合、お名前.comはサブドメインでないと登録不可です。Route53だとエイリアスも可能なので、CNAMEレコードと同じようなことが可能なんですが。
だけど、お名前.comのAレコードはIPしか入れられないという仕様です。ALBは変動するため、nslookupとかで出てきたIPを入れてはいけません。
こういうときは、ALBの機能の一つ、Global Acceleratorを使います。
【初心者】AWS Global Accelerator を使ってみる
固定のIPが払い出されるので、それをALBと紐づけることで、結果的にALBに固定IPでアクセスできるようになる。
このIPをAレコードに紐付ければ、xxx.comといったサブドメインなしでもアクセスできるようになります。本来はAWSのネットワークを使うことで、レイテンシーが１／１０になって高速化になるのが主目的ですが、こういう使い方もあります。
弊社にDBに詳しい者がいるためなんとかなりましたけど、これクラウドソーシングとかで一人で受けてたら爆死だったでしょう。実際、頼んだら移行が上手くいかず困っているとかいう話を聞いたことがあります。当時、ふーんと聞き流していましたがホントに大変でした。
2021.07.21
