WordPress の Azure PaaS 移行ではまったこと

この記事の内容

Azure VM 上の WordPress を Azure App Service（PaaS）へ移行した際の手順と注意点をまとめています
画像データのオフロードには Azure Blob Storage 連携プラグインを活用しました
MySQL の文字コード設定不整合による文字化け問題とその対処法を解説します
WordPress プラグインの不整合が原因で画面が真っ白になる問題についても触れます
VM を手放すことで運用負荷が大幅に下がった点についても紹介します

移行前後の構成

移行元（VM ベース）

Azure VM 上で Apache 2 + WordPress が稼働
同一 VM 内に MySQL が動作
複数ブログを運用

移行先（PaaS ベース）

Azure App Service（Linux コンテナ）
Web アプリとしてブログを 1 つずつ移行
データベースは Azure Database for MySQL を使用

コンテナイメージは以前から自作したものを流用しました。WordPress 公式イメージをベースに、テーマやプラグインを組み込んだ Dockerfile を管理しているリポジトリがあり、それをそのまま活用する形にしました。

ステップ 1: 画像データのオフロード

コンテナ環境ではデータが永続化されないため、画像ファイルを直接コンテナ内に置き続けることはできません。今回は WP Offload Media（wp-azure-offload） プラグインを使って、既存の画像データを Azure Blob Storage へ移行しました。

このプラグインには以下の機能があります。

WordPress のメディアライブラリ内の画像を Blob Storage にアップロードする
データベース内の画像 URL を Blob Storage（または CDN）のエンドポイントに書き換える

フリープラグインではありますが、動画執筆時点では問題なく動作しました。より新しい Azure 対応プラグインも存在するため、最新情報を確認した上で選定することをおすすめします。

ステップ 2: MySQL のデータ移行

当初の方針と断念

当初は Azure Database Migration Service の利用を検討しましたが、スキーマ移行に MySQL Workbench が必要であり、MySQL Workbench 自体にもデータベース移行機能が備わっているため、今回は直接 mysqldump を使う方針に切り替えました。

文字コード設定の問題

移行元 VM の MySQL データベースの文字コードが latin1（latin1_swedish_ci）に設定されており、実際のデータは UTF-8 で格納されているという不整合な状態になっていました。過去に何度か引っ越しを繰り返した際にどこかでミスが生じていたようです。

この状態でそのまま移行すると、文字化けが発生します。移行先でも同じ文字コード設定を引き継いでしまうためです。

対処手順

移行先のデータベースを先に UTF-8 で作成しておき、mysqldump でダンプしたファイルの文字コードと照合順序を変換してからインポートするという手順で対処しました。

1. 移行先データベースの作成（UTF-8 指定）

CREATE DATABASE your_db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

2. 移行元でダンプ（文字コード指定なし・そのまま出力）

mysqldump --default-character-set=latin1 -u root -p your_db_name > dump.sql

3. ダンプファイルの文字コードを UTF-8 に変換

iconv -f latin1 -t utf8 dump.sql > dump_utf8.sql

または sed コマンドでファイル内の文字セット宣言を書き換える方法も有効です。

4. 照合順序（COLLATION）の書き換え

ダンプファイル内の latin1_swedish_ci などの記述を utf8mb4_unicode_ci に置換します。

sed -i 's/latin1_swedish_ci/utf8mb4_unicode_ci/g; s/latin1/utf8mb4/g' dump_utf8.sql

5. 移行先データベースへのインポート

mysql -u your_user -p your_db_name < dump_utf8.sql

この手順でほとんどのブログで正常に移行できました。

ステップ 3: WordPress プラグインの整合性確認

移行後、一部のブログでプラグインが参照するファイルパスがコンテナ内に存在しなくなっていたことが原因で、WordPress の管理画面が真っ白になる問題が発生しました。

具体的には、Cocoon テーマの設定画面を開くと何も表示されず、デバッグモードを有効にしてもエラーメッセージが出力されない状態でした。

原因と回避策

VM 上で使用していたプラグインがコンテナイメージ内のプラグインと一致していない状態で移行したことが原因でした。

回避策: 移行元でプラグインを無効化してからダンプする

移行元の WordPress でプラグインをすべて無効化した状態でデータベースをダンプし、移行先でインポートした後に改めてプラグインを有効化すると、正常に動作しました。

特殊ケース: 移行元がすでに壊れていたブログ

今回 6〜7 個のブログを移行しましたが、1 つのブログは移行前の段階ですでに正常に動作していない状態でした。上記の手順では対処できなかったため、以下の方法で対応しました。

WordPress の標準エクスポート機能（XML）で記事データをエクスポート
コンテナを一から作り直してデータベースも再作成
WordPress の標準インポート機能でデータを取り込む

ユーザーデータや細かい設定は失われましたが、投稿データは救出でき、画像は事前に Blob Storage にオフロード済みだったため、表示にも問題はありませんでした。

なお、エクスポートしたファイルが大きくなった場合は分割ツールの使用が必要になることもあります。

PaaS 移行で得られたメリット

常時稼働サーバーの管理が不要になりました。大学時代から自作 PC や VM でサーバーを管理してきた経験がありましたが、今回の移行で常時稼働の Web サーバーが完全にゼロになりました
セキュリティパッチ適用の心配が軽減されます。VM 時代は定期的なパッチ適用を怠るとリスクが生じていましたが、マネージドサービスでは自動的に管理されます
SSL 証明書の自動管理が無料で利用できます

まとめ

WordPress を Azure VM から Azure App Service（PaaS）+ Azure Database for MySQL に移行する際の主なポイントをまとめます。

画像データは事前に Azure Blob Storage へオフロードする。WP Offload Media プラグインが有効です
MySQL の文字コード設定を必ず確認する。latin1 設定のまま移行すると文字化けが発生します。移行先を UTF-8（utf8mb4）で作成し、ダンプファイルを変換してからインポートしましょう
プラグインは移行前に無効化してからダンプすると、画面真っ白問題を回避しやすくなります
移行元がすでに壊れている場合は、WordPress 標準のエクスポート/インポート機能で記事データだけでも救出する方法が有効です
PaaS 化することでサーバー運用の心理的負担が大幅に軽減されます