はじめに
先日、AWS の利用期間が 12 か月を超え、無料利用枠が終了しました。
それに伴い、費用が増大しました。
上記は月の中旬時点のグラフですが、既に前月までの費用を大幅に超えています。
特に、無料利用枠を終了したことによって、EC2, RDS, ElastiCache, ELB の費用が増大しています。
今回の記事では、費用削減を目的としてレンタルサーバーのロリポップ!へ移行したので、その理由と手順を詳しく解説します。
それでは早速始めましょう。
移行前の確認事項
もちろん、何も考えずにロリポップ!への移行を決めたわけではありません。
「そもそもなぜ費用が上がったのか、その上げ幅は想定内なのか、その費用は工夫によって抑えられるのか」について、一旦確認してから移行を検討するべきです。
もし移行実施を決定した場合にも、レンタルサーバは他にも X サーバー や ConoHa WING 等有名どころが色々ありますので、きちんと選定をする必要があります。
この章では、KUDs が移行前に確認したこと、検討したことを記載します。
そもそもなぜこんなにも費用がかかっているのか
先ほどの画像を見て、「なぜ筆者はこんなにも色々な AWS サービスを使ってるんだ…」と思った方もいるかと思います。
答えはシンプルに、「色々な AWS サービスを使ってみたかったから」です。
そもそも WordPress でブログをホスティングするだけが目的ならレンタルサーバーで十分です。
リソースをフレキシブルにスケーリングしたい人は VPS、 AWS なら Lightsail を利用するのも手だと思います。
それなのにわざわざ AWS EC2 上でホスティングしているのは、「様々な AWS サービスと連携したりしてみたい」という KUDs の願望があったためです。
実際に、当 WordPress では以下のようなサービスを使い分けしています。
- EC2: WordPress のホスト用
- RDS: データべース用
- S3: メディアファイルのオフロード用
- ElastiCache: 永続オブジェクトキャッシュ用
- ELB: 負荷分散用
- Cloudflare(AWS 外部): CDN / DNS
こんな使い方をしているため、今回、無料利用枠終了と共に費用が上がることも目に見えていました。
そのため、「なぜこんなに費用がかかるのか?」は、「様々な AWS サービスを利用しているから」であり、想定内です。
AWS EC2 を継続運用することについて
もちろん、EC2 を継続利用することも検討できます。
EC2 で WordPress を運用しつつも費用を抑えるためには、以下のような対策が検討できます。
- データベースをローカルに移して RDS の利用を停止
- キャッシュをローカルに移して ElastiCache の利用を停止
- ELB の利用を停止
※ EC2 データ転送量の観点があるので、CloudFront の利用は検討する必要があるかとは思います
KUDs も上記は検討しましたが、この場合当初の「様々な AWS サービスと連携したりしてみたい」が満たされないので微妙だなー、と思いました。
また、この 1 年で結構な AWS サービスを触れられたので、「もうこれを機にレンタルサーバーでいいや」と思ったというのが結論です。
余談ですが、今年 2 月以降に有償化されたパブリック IP による費用増加も大きいですよね。
※ ALB を利用するとパブリック IP *2 分は発生するため
※ 詳細は以下記事参照
どのレンタルサーバーに移行するべきか
結論、費用観点でロリポップ!に決定しました。
速度重視なら ConoHa WING や X サーバーが有力候補に上がるかと思いますが、このブログサイトは長く細く続ける想定なので、費用重視でロリポップ!が適しているという判断です。
どのレンタルサーバーにするかしっかり検討したい方は、以下の記事でガッツリ比較しているのでよければご参照ください。
EC2 からロリポップ!へ WordPress 簡単引っ越しで移行してみる
この章では、実際に EC2 からロリポップ!へ WordPress 簡単引っ越し という機能を用いて移行する手順を確認します。
が、結論を先に行っておくと、 AWS EC2 からロリポップ!へ WordPress 簡単引っ越しはできませんでした。
残念ながら、原因はわからずです。
以下、KUDs の実際の実施手順を書きますので、良ければご参照ください。(何か考慮不足があったのかもしれない)
※ なお、実際には簡単引っ越し機能を使わず手動で移行しましたので、その手順は後述します。
※ 移行手順だけ知りたい方は読み飛ばしてください。但し、メディアファイルのオフロード等を行っている方は一応次の章を読んでおくことをおすすめします
ロリポップ!の WordPress 簡単引っ越し機能とは
ロリポップ!には WordPress 簡単引っ越しという機能が存在します。
こちらの機能は、別サーバーで稼働している WordPress を、ロリポップ!サーバーへとお引越しするものです。
引っ越し対象データについて確認
まず、お引越しの対象となるデータを確認してみましょう。
引っ越し対象となるデータ
- WordPressのデータベース内のデータ
- wp-content ディレクトリ以下のデータ(バックアップ系プラグインのデータを除く)
引っ越し対象外のデータ
https://lolipop.jp/manual/startup/wordpress-migrator
- 引っ越し元にある .htaccess ファイル
- wp-content ディレクトリ以下のバックアップ系のプラグインのデータ
- wp-content 以外のデータ
この時点で、いくつか疑問点が沸き上がります。
- データベースは RDS だけど引っ越しは正常に進むのか
- S3 にオフロードしているメディアファイルはどうすればいいのか
- ElastiCache の永続オブジェクトキャッシュはどうすればいいのか
等々、簡単引っ越し機能でどこまでできるかがよくわかりません。
このあたり私がどうしたのかは後述します。
動作要件について確認
次に、動作要件を確認しましょう。
動作要件
https://lolipop.jp/manual/startup/wordpress-migrator
- ご契約のアカウントにおいてデータベース作成上限に達していないこと
- 引っ越し元サイトで使用しているWordPressのバージョンが4.0以上であること
- 引っ越し元サイトで使用しているPHPのバージョンが5.3以上であること
- 引っ越し元サイトで使用しているWordPressのバージョンの動作環境に、ロリポップで利用しているPHPのバージョンが含まれていること
- 引っ越し元サイトが次の条件にあてはまる場合、利用することができません
- WordPressでマルチサイト機能を使用している場合
- データベースの容量が1GBを超えている場合
- WordPress.comで運用されている場合
- PHPからファイルを圧縮するツールが利用できない場合
上述の通りですが、事前に WordPress 、PHP のバージョンは確認しておいた方がよさそうですね。
WordPress 簡単引っ越し前の事前作業
では、簡単引っ越し前に事前に確認した方がいい項目を見てみましょう。
WordPress と PHP のバージョン確認
WordPress と PHP のバージョンが先ほどの動作要件を満たしているか確認しましょう。
$ grep "wp_version =" /var/www/html/wp-includes/version.php
$wp_version = '6.6';
$ php -v
PHP 8.2.19 (cli) (built: May 21 2024 22:55:32) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.19, Copyright (c) Zend Technologies
大丈夫そうですね。
セキュリティ系プラグインの無効化
マニュアルに記載の通りですが、セキュリティ系のプラグインを導入していて、管理者ページのURLが変更されている場合は、引っ越しを行う際に一旦無効にして、引っ越しが完了した後に有効に戻してください。
永続オブジェクトキャッシュの無効化
永続オブジェクトキャッシュ(ElastiCache)を使用している場合、事前に利用を停止しておくことをおすすめします。
理由は、ロリポップ!では永続オブジェクトキャッシュをサポートしていないためです。
WordPressの「永続オブジェクトキャッシュ」は使えますか?
WordPressのサイトヘルスステータスに表示されている「永続オブジェクトキャッシュ」を当サービスで使用することが出来ません。
https://support.lolipop.jp/hc/ja/articles/12441086733843-WordPress%E3%81%AE-%E6%B0%B8%E7%B6%9A%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5-%E3%81%AF%E4%BD%BF%E3%81%88%E3%81%BE%E3%81%99%E3%81%8B
私の場合、プラグイン「Redis Object Cache」を使用しているので、予め無効化しました。
メディアファイルのオフロードの無効化
S3 等へメディアファイルをオフロードしている場合、事前にオフロード機能を停止し、メディアファイルをローカルに移しておくことをおすすめします。
理由は、簡単引っ越し機能の対象データが、「wp-content ディレクトリ以下のデータ」と記載されているためです。
メディアファイルは通常 wp-content/uploads/ ディレクトリ配下に保持されます。
そのため、事前にオフロード先 (S3 上) からローカルの wp-content/uploads/ ディレクトリ配下に戻しておくことで、正常に引っ越しされることが期待できます。
S3 からローカルへメディアファイルを移しておく
まずローカルと S3 の容量差分をチェックします。
$ du -sh /var/www/html/wp-content/uploads/2023/
12M /var/www/html/wp-content/uploads/2023/
$ du -sh /var/www/html/wp-content/uploads/2024/
9.7M /var/www/html/wp-content/uploads/2024/
$ aws s3 ls s3://kuds-wordpress/wp-content/uploads/2023/ --recursive --summarize --human-readable | grep "Total Size"
Total Size: 22.3 MiB
$ aws s3 ls s3://kuds-wordpress/wp-content/uploads/2024/ --recursive --summarize --human-readable | grep "Total Size"
Total Size: 11.0 MiB
若干ローカルの方が容量小さく差分があります。
ローカルの方が定期的に削除を行っているためでしょう。
このままでは参照エラーが発生する可能性があるので、差分をなくしておきましょう。
$ aws s3 sync s3://kuds-wordpress/wp-content/uploads/ /var/www/html/wp-content/uploads/
...
download: xxx to xxx
download: xxx to xxx
...
$ du -sh /var/www/html/wp-content/uploads/2024/
12M /var/www/html/wp-content/uploads/2024/
$ du -sh /var/www/html/wp-content/uploads/2023/
26M /var/www/html/wp-content/uploads/2023/
なんか、想像より大きくなりましたが気にしないことにします。誤差です。多い分には問題なし。
補足: aws s3 sync で Permission Denied が出る人へ
まずは実行元の IAM ユーザなり IAM ロールなりが S3 の権限を持つことを確認しましょう。
(この記事を読んでいる方は元々オフロードできていた方なので、問題ないとは思いますが)
IAM に問題が無くても、以下のようなエラーが発生する場合があります。
$ aws s3 sync s3://kuds-wordpress/wp-content/uploads/ /var/www/html/wp-content/uploads/
download failed: s3://kuds-wordpress/wp-content/uploads/2023/12/xxx.png to ../../var/www/html/wp-content/uploads/2023/12/xxx.png [Errno 13] Permission denied: '/var/www/html/wp-content/uploads/2023/12/xxx.abcd1234'
実行ユーザが対象のディレクトリ配下への操作権限を持たない場合に上記のようなエラーが発生します。
解消方法は、「ユーザを変える or sudo 実行する」です。
私はルートユーザで実行し、その後にファイルの所有ユーザを Web サーバに戻してます。
# aws s3 sync s3://kuds-wordpress/wp-content/uploads/ /var/www/html/wp-content/uploads/
...
download: xxx to xxx
download: xxx to xxx
...
# chown -R apache /var/www/wp-content/uploads/
オフロードプラグインの無効化 (データベースの修正)
前の章では S3 からローカルにメディアファイルを移しました。
しかし、単にメディアファイルを移すだけでは、データベース上のメディアファイルの参照先 URL がオフロード先のままとなってしまいます。
実際に WordPress 管理画面 > メディア > ライブラリ を確認してみましょう。
ファイルの URL が記載されています。
WordPress では、この URL から実際のファイルを取得します。
現状 S3 を指していますね。
しかし、引っ越し後にもずっとここを参照してしまってはまずいです。
今回私が使用していたのは、「WP Offload Media Lite」というプラグインです。
こちらのプラグインは、無効化と同時に参照先 URL を自動的にローカルに修正します。
プラグインによっては、手動でデータベースを修正する必要があるかもしれません。
適宜ご確認ください。
いざ AWS EC2 からロリポップ!へ簡単引っ越し実行
いよいよ簡単引っ越しを実行してみましょう。
「あれ、RDS は?」と思われた方もいるかと思います。
公式の手順的に、データベースがローカル上にある必要性は言及されていないので、一旦やって見ようと思います。
結果
無理でした。
その後以下の対策をしてみるも、改善せずでした。
- RDS インスタンスを一時的にパブリック化
- セキュリティグループをオープン
- ロリポップ!レンタルサーバーから直接 RDS インスタンスに接続できることを確認
残念ながら簡単引っ越しはエラーが発生し正常に完了しませんでした。
EC2 からロリポップ!へ手動で移行してみる
自動で無理なら手動でやりましょう。
そんなに大変な作業ではありません。
RDS のデータベースからダンプファイルを取得し移行
まずは RDS DB のダンプファイルを取得しましょう。
ロリポップ!サーバから RDS DB へ接続可能な方は直接取得しましょう。
EC2 からしか DB 接続できない場合は、ダンプファイル取得後にロリポップ!サーバに SCP 等で移しましょう。
## ダンプファイルを取得
$ mysqldump --host=kuds-wordpress-instance.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com --user=<DB ユーザ> --password="<DB パスワード>" --single-transaction --set-gtid-purged=OFF --skip-lock-tables <DB テーブル> > rds_dump.sql
## ダンプファイルを SCP で転送
$ scp -P 2222 -i ~/.ssh/<ロリポップSSH用秘密鍵>' ./rds_dump.sql <ロリポップSSH用ユーザ名>@<ロリポップSSH用ホスト名>:<配置したいディレクトリ>
## ロリポップ!サーバに SSH 接続
$ ssh -P 2222 -i ~/.ssh/<ロリポップSSH秘密鍵>' <ロリポップSSHユーザ名>@<ロリポップSSHホスト名>
## ダンプファイルのインポート
$ mysql -u <ロリポップDBユーザ> -p <ロリポップDB名> < <配置したディレクトリ>/rds_dump.sql
※ <ロリポップSSH用秘密鍵> は事前に配布されたりはしません。ロリポップではデフォルトパスワード接続なので、事前にキーペアを作成しておくことをおすすめします
※ まだロリポップ!データベースを作成していない方は、以下の公式ドキュメントを参考にさくっと作りましょう
WordPress ファイルとデータベースのダンプファイルを SCP で転送する
次に、 WordPress のデータをロリポップ!サーバへ移しましょう。
$ rsync -avz -e 'ssh -p 2222 -i ~/.ssh/<ロリポップSSH用秘密鍵>' /var/www/html/ <ロリポップSSH用ユーザ名>@<ロリポップSSH用ホスト名>:<配置したいディレクトリ>
上記は /var/www/html/ ディレクトリ配下を一括で移しています。もし一時データなど不要なデータがあれば、–exclude オプションで除外したり、或いはコピー後に削除しても良いです。
wp-config.php ファイルの修正
次に、新サーバーのデータベース情報に合わせて、wp-config.php ファイルを編集しましょう。
$ vi wp-config.php
...
define('DB_NAME', 'ロリポップ!データベース名');
define('DB_USER', 'ロリポップ!データベースユーザー');
define('DB_PASSWORD', 'ロリポップ!データベースパスワード');
define('DB_HOST', 'ロリポップ!データベースホスト');
...
define('WP_SITEURL', 'ロリポップ!初期ドメイン (例:http://●●●.main.jp)');
define('WP_HOME', 'ロリポップ!初期ドメイン (例:http://●●●.main.jp)');
ここまでで必要なデータは移行が完了しているはずです。一度、ロリポップ!の初期ドメイン (例:http://●●●.main.jp) 等で問題なく表示されるか確認してみましょう。
DNS のレコード修正
次に、移行元で独自ドメインを利用していた方は、DNS レコードを修正して名前解決先を修正しましょう。
私の場合は Cloudflare ですが、Route53 の場合はマネコンから A レコードや CNAME レコード等を修正し、ロリポップ!の初期ドメイン (例:http://●●●.main.jp) へ解決させます。
もしロリポップ!で新たに独自ドメインを取得して割り当てる場合は、ドキュメントに従いましょう。
その他
最後に、その他の検討事項としてはサイトの SSL 化や LightSpeed Cache の実装等が考えられます。
外部でドメインを管理している場合の SSL 化は少々ややこしい & 皆がやるものではないはずなので割愛します。
※設定をミスるとリダイレクトループが発生します
LightSpeed Cache の実装はプランによって可否が異なるので、こちらも割愛します。
※利用可能なプランはハイスピード、エンタープライズのみ
最後に
今回は AWS EC2 からロリポップ!レンタルサーバーへの WordPress 移行する手順を確認しました。
残念ながら、WordPress 簡単引っ越し機能はエラーが発生してしまいました。
もし正常に実行できた方いらっしゃいましたらコメントいただけますと嬉しいです。
今回はロリポップ!レンタルサーバーへの移行でしたが、他レンタルサーバーへの移行でも同じような手順になるかとは思います。
ちなみに、ロリポップ!は現状 OS が古く、セキュリティの観点では脆弱です。
詳細は以下記事に記載しておりますので、興味があればご参照ください。
以上です。
コメント