Conoha VPSからAWSへ個人ブログを移行した話

投稿者: | 2021-05-04

今回はConoha VPS上で構築した当ブログをAWSへ移行した話について、移行の経緯や新構成の構築でハマったところを中心に書いていきます。

移行の経緯

個人ブログの移行については、DNSサーバをAWS Route 53に移行した時から検討していました。移行の主な理由は以下の通りです。

  • CentOS 8のサポート終了
  • 運用面の簡略化・構成の変更
  • クラウドの運用周りを勉強したかった

■CentOS 8のサポート終了

昨年、CentOS 8のサポートが2021年12月で終了になるとのアナウンスがありました。個人ブログではCentOS 8を使用していたため、サポート終了までに新規でVPSを作成し移行するか他のサービスに移行する等の何かしらの対応が必要な状態となっていました。

CentOS 8もDNSサーバからメールサーバ、Webサーバで1年ほど触っており、そろそろ他のLinuxディストリビューションも勉強しておきたいと考えていました。

■運用面の簡略化・構成の変更

VPS時代に構築した個人ブログは、1つのVPS上にApache、PHP、MySQLをまとめた環境にしていました。VPSで個人ブログを構築した時は、最新バージョンを導入するためにApacheやPHPをソースインストールで導入していました。そのため、新しいバージョンへ更新する際の作業や管理が多少面倒になっていました。

また、WebサーバについてはApacheだけでなくNginxについても勉強したく、いずれ構成を変えたいと考えていました。

■クラウドの運用周りを勉強したかった

個人でAWS等のパブリッククラウドを操作してWordPressを作ってみたりサービスを組合せてみる、といったことはできますが、運用周りとなると継続的にサービスを使用する必要が出てきます。特に、単発のサービスを作成しただけではデータの収集等があまりできないこともあり、何かしらのサービスをクラウド上に構築して運用してみたいと思ってました。

移行先の選定

個人ブログの移行先については、以下で検討していました。

  • AWS
  • Azure
  • その他パブリッククラウド

■AWS

現在、パブリッククラウドの中では一番扱い慣れていることもあり、一番の候補でした。また、Route 53を使用していることもありリソースの一元管理や余っているクレジットを使用できることから第一候補としていました。

■Azure

現在勤めている会社の方針もあり、勉強でAzure上にVMを構築してWordPressを構成する方法も検討しました。ただ、AWSと比較するとまだまだ扱い慣れていないことやリソースが分散してしまう等から見送りとなりました。

■その他パブリッククラウド

GCP等のパブリッククラウド、も考えてみましたが、個人ブログとはいえある程度環境に慣れていることが欲しいことから今回は見送りとしました。

総合的な理由でAWSが優位だったため、AWS上に個人ブログを移行することに決めました。

移行後の構成

移行後の構成は以下の構成で作成しました。

WordPressを使用しているため、WebサーバとDBが必要になることからEC2とRDSのシンプルな構成に落ち着きました。Google Analyticsの利用者数から、ALBやASGの構成は不要と判断しました。また、コストを抑えるためにEC2とRDSについてはリザーブドインスタンスを購入しています。

予算の関係でAWS上にはバックアップは作成せず、現状は必要なファイル等を手動でバックアップする方針にしています。もう少しお金に余裕があればスナップショット等もちゃんと取得していきたいです。

各構成については以下の通りです。セキュリティの関係上、PHP以外のバージョンは省略しています。

■EC2

Webサーバ Nginx
PHP 8系

■RDS

DBエンジン MySQL

新構成の構築でハマったこと

新環境の構築はデータの移行時に以下のことでちょっとハマったりつまづきました。

  • SiteGuardのログインURL変更について
  • NginxでWordPressを構築した際のパーマリンクについて
  • PHPのメモリリークについて
  • サイトヘルスステータスのREST APIエラーについて

■SiteGuardのログインURL変更について

新環境へ移行後、WordPressのダッシュボードからSiteGuardを使用しログインURLの変更を行い、新しいURLで再ログインしようとしたところ、「404 Not Found」が表示されログインURLにたどり着けなくなりました。

原因はWebサーバをNginxに変更したことにより、「.htaccess」のrewrite設定を読み込めず、ログインURLに遷移できなかったためです。SiteGuardのログインURL変更を設定すると、「wp-admin」のところにrewriteの記述を行った「.htaccess」を配置します。Apacheであればmod_rewriteを有効にすることでこの動作を行えますが、Nginxでは「.htaccess」を読み取らないためログインURLにたどり着けなくなってしまいます。もしNginxで同様の動作を行いたい場合は、Nginxの設定ファイルに変更後のURLを「wp-admin」に遷移させる設定が必要となります。今回は遷移させる設定を行い解決としました。

もし同様の事象でログインURLにたどり着けなくなってしまった場合は、「wp-admin」と同じ配下にある「.htaccess」を削除(もしくはリネーム)することで、ログインURL変更の設定を初期化することができます。

■NginxでWordPressを構築した際のパーマリンク設定について

新環境へ移行後、ブログのトップページから記事へアクセスを行おうとすると、「404 Not Found」となり記事にアクセスできない事象が発生しました。ダッシュボードから投稿一覧を確認したところ、過去記事の投稿内容は一通り存在していました。

原因はログインURL変更と同様にrewriteの設定がないことにより、設定したパーマリンクに正しく遷移できなかったためです。WordPressのパーマリンク設定もmod_rewriteを使用してURLを遷移させているとのことでした。ログインURL変更と同様にNginx用の設定が別途必要になったため、追加の設定を行い解決としました。

■PHPのメモリリークについて

新環境へ移行し、Route 53からドメインを切り替えたところでサーバが500エラーを吐きました。エラーログを確認してみると、PHPのメモリの割り当てに失敗したとの内容を確認しました。少し調べた結果、「php.ini」に割り当てられてたメモリが少々多かったことが原因とのことで、PHPのメモリ割り当ての設定を修正し解決としました。

■サイトヘルスステータスの「REST APIは正しく動作しませんでした」について

個人ブログの移行後、WordPressのダッシュボードから確認できるサイトヘルスステータスに「REST APIは正しく動作しませんでした」との表示があることを確認しました。少し調べてみると、WordPressのテーマで古い記述等が残っている時に正しく動作しないことがあるとの情報があったため、現在使用しているテーマ側の問題と見ています。

現時点で記事が表示されない等の致命的なエラーが起きていないことや改善程度の内容であることから、一旦はスルーとしています。

移行実施

移行実施は5月2日の23時あたりに実施しました。移行時にはアクセスしているユーザーがいないかどうかをGoogle Analyticsで確認しつつ、DNSの向き先を新環境に変更する作業を実施しました。

DNSの向き先を変更するだけで無事終了…、と言いたかったですが、ハマったところに記載した通り、向き先を変えた後にPHPでメモリリークを起こして数十分ほどブログが繋がらない状態となっていました。実務であれば想定外のエラー等で切戻しを検討しますが、個人ブログということで今回はそのまま修正を実施し解決としました。

まとめ

インフラ構成の変更を伴うWordPressの移行を行ってみて、一般的な手順以外にも色々とハマるポイントがあって勉強になりました。特にrewrite周りの仕組みやPHP周りの設定を見ていて、まだまだ勉強していくことは多いなぁと感じました。また、クラウドにおいてもリザーブドインスタンスの購入等、個人ではあまりやらない経験もできたため良かったです。

ブログの移行が完了したので、またぼちぼちと更新をしていきたいと思ってます。しばらくはLinux周りやAzure関連を中心に書いていくと思いますのでよろしくお願いします。